Cloud ground station computing resource elasticity arrangement method and device

Abstract

The application discloses a computing resource elasticity arrangement method and device of a cloud ground station, and the method comprises the following steps: the computing resources in the ground station are uniformly virtualized as a globally shared computing resource pool to realize cloud of the ground station; a prediction window is calculated, and a window-level business volume prediction table is output; the predicted business volume is mapped to resource demand, a resource pre-arrangement plan in the window is generated, and the computing resources are preheated; satellite access confirmation is completed within the prediction window operation period, and idle ready state micro-service container instances are switched to a running state; the satellite state and the remaining capacity of the cloud resource pool are monitored in real time, the deviation between the measured state and the estimated result is calculated, and secondary scheduling is performed; after the operation period ends, the container instances raised during the transit period are quickly destroyed, and the computing resources are recycled. According to the application, in the multi-satellite concurrent and short transit window burst scene, the task start delay caused by container cold start can be reduced, the resource utilization rate can be improved, and the high-reliability service of real-time transit tasks can be ensured.

Description

Technical Field

[0001] This application relates to the field of satellite communication and ground station resource scheduling technology, and in particular to a method and apparatus for flexible scheduling of computing resources for cloud-based ground stations. Background Technology

[0002] With the widespread application of low-Earth orbit (LEO) satellite constellations in communications, remote sensing, and navigation, ground stations, as the key interface between the satellite system and ground users, are responsible for handling important tasks such as telemetry, tracking, and command (TT&C) signals, data transmission, and mission scheduling during satellite transit. As the scale of LEO satellite constellations continues to expand, the number of tasks and the amount of data that ground stations need to process are growing exponentially, placing higher demands on the management of their computing resources.

[0003] Currently, ground stations typically manage computing resources using dedicated hardware stacking or a static resource deployment model based on physical servers. In this model, computing resources such as CPUs, GPUs, and FPGAs are fixedly allocated to specific tasks, such as telemetry and control services and data transmission services.

[0004] However, while this static resource allocation method can provide relatively stable performance guarantees in single-task scenarios, its limitations include: 1. Telemetry, tracking, command, and data transmission services often occupy computing resources in a static, exclusive manner, preventing resources from being reused across services. This fragmented resource allocation method results in low overall resource utilization, with a large amount of idle resources not being effectively utilized. 2. Low-Earth orbit satellites have short transit windows, and traditional passive response scheduling methods struggle to promptly activate computing resources and switch links, easily leading to task startup delays and affecting satellite mission execution efficiency. 3. During multi-satellite concurrent access, high-throughput data transmission services can easily crowd out resources for high-priority services such as telemetry, tracking, and command, affecting the real-time performance and reliability of critical services, making it impossible to effectively differentiate service priorities and provide sufficient resource guarantees for high-priority tasks. Summary of the Invention

[0005] This application provides a method and apparatus for elastic orchestration of computing resources for cloud-based ground stations. To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments. Its sole purpose is to present some concepts in a simple form as a prelude to the detailed description that follows.

[0006] In a first aspect, embodiments of this application provide a method for elastically orchestrating computing resources for cloud-based ground stations, the method comprising:

[0007] By establishing a schedulable cloud computing resource pool and a microservice container image library for ground stations, the cloudification of ground stations can be achieved.

[0008] From the operations control center, we obtain satellite orbit ephemeris and multi-source data, which include planned mission data and historical sample data.

[0009] Based on satellite orbit ephemeris and multi-source data, calculate the satellite's prediction window and window-level traffic forecast table;

[0010] Map the predicted workload in the window-level workload forecast table to resource requirements, and generate a pre-arrangement plan for resources within the window based on the resource requirements; execute the computing power resource preheating action to obtain the preheating plan and readiness flag;

[0011] During the prediction window's runtime, satellite access confirmation is performed based on the warm-up plan and readiness flags. After satellite access confirmation, microservice container instances in the idle ready state are identified from the microservice container image library, and these instances are switched to the running state.

[0012] After the satellite successfully connects to the ground station, the satellite status and the remaining capacity of the cloud resource pool are monitored in real time, the deviation between the measured status and the estimated results are calculated, and secondary scheduling is performed.

[0013] After the prediction window ends, the container instances launched by the satellite during its transit are destroyed, the computing resources occupied by the containers are recovered, and the status of low-priority non-real-time offline tasks is sorted out and backfilled.

[0014] Optionally, the method also includes:

[0015] By monitoring the current time and the predicted satellite transit window, it can be determined whether the satellite is currently in a non-transit state;

[0016] If the satellite is not currently in transit, perform non-real-time offline data tasks. These tasks include in-depth analysis and cleaning of historically accumulated data, analysis of remote sensing imagery using AI technology, and organization and archiving of system operation logs.

[0017] When a satellite is not currently in a non-transiting state and is currently in the resource preheating phase of a mission, a preemption mechanism is triggered to release non-real-time mission resources to ensure the satellite's real-time mission.

[0018] Optionally, the cloudification of ground stations can be achieved by establishing a schedulable cloud computing resource pool and a microservice container image library, including:

[0019] By utilizing software-defined networking and network function virtualization technologies, all computing resources within the ground station are virtualized into a globally shared computing resource pool, resulting in a cloud-based computing resource pool that can be scheduled for the ground station.

[0020] Under the network function virtualization technology and the pre-set container orchestration framework, virtualized computing resources are encapsulated into microservice container images that can be deployed independently, resulting in a microservice container image library, thus realizing the cloudification of ground stations.

[0021] Optionally, based on satellite orbital ephemeris and multi-source data, calculate the satellite's prediction window and window-level traffic prediction table, including:

[0022] By using satellite orbit ephemeris, the specific time period during which the satellite is within the visible range of the ground station can be determined;

[0023] Based on a specific time period, the specific time window for satellite transit is calculated, thus obtaining the satellite transit window;

[0024] Using planned task data, historical sample data, and transit windows, the following steps are performed sequentially: generating a forecast window, calculating the expected remaining amount of planned tasks, estimating historical baseline traffic volume, and fusion of forecast results. This yields a forecast window that includes a safe time boundary and a window-level traffic volume forecast table that includes the estimated load for each type of business.

[0025] Optionally, the predicted traffic volume in the window-level traffic forecast table is mapped to resource requirements, and a pre-scheduling plan for resources within the window is generated based on the resource requirements, including:

[0026] Construct a business profile parameter table, which contains key parameters for each business type;

[0027] Faced with the forecast window, the forecasted business volume in the window-level business volume forecast table is converted into resource requirements based on the business profile parameter table;

[0028] Based on the business priority and data volume of each business type, the business types within the prediction window are classified into different levels to obtain the classification results.

[0029] Based on the hierarchical results and resource requirements, a pre-arrangement plan for resources within the forecast window is generated.

[0030] Optionally, real-time monitoring of satellite status and remaining capacity of the cloud resource pool, calculation of the deviation between measured status and predicted results, and execution of secondary scheduling, including:

[0031] Activate pre-configured SDN routing rules to enable real-time import of RF or baseband data flow into the processing chain, and start collecting operational metrics;

[0032] After the satellite successfully connects to the ground station, it acquires key parameters for the operational indicators of the connected satellite.

[0033] Based on the key parameters, determine the current real-time status of the accessed satellite;

[0034] Based on the pre-arranged plan, the estimated results of the access satellites are determined;

[0035] Calculate the deviation between the current real-time state and the predicted result;

[0036] Based on the deviation of the results, a secondary scheduling is performed to dynamically adjust the computing resources in the cloud computing resource pool available for scheduling at the ground station until the operation period of the prediction window of the access satellite ends.

[0037] Optionally, perform computing resource preheating actions, including:

[0038] At the preheating trigger moment, create a resource slice for each service;

[0039] Based on the preset preheating ratio, resource quotas are locked for resource slices;

[0040] Pull the required images from the microservice container image repository and start the containers to an idle and ready state;

[0041] Preload ephemeris and protocol parameters and configure the hardware;

[0042] Pre-deploy software-defined network traffic redirection rules;

[0043] After passing the health check, the ready flag is set, and the preheating plan and ready flag are obtained.

[0044] Optionally, perform satellite access confirmation, including:

[0045] Real-time monitoring of the current time;

[0046] When the safe entry time is reached at the current time, the link layer identifier is parsed to determine the satellite's identity and associate it with the set of services planned for the prediction window.

[0047] Establish a control plane signaling channel between the orchestrator and the computing plane, and verify the resource readiness status to ensure that all service chain resources have been initialized as a prerequisite for enabling the processing chain.

[0048] Optionally, based on a specific time period, the specific time window for satellite transit can be calculated to obtain the satellite transit window, including:

[0049] By iterating through the satellite set and the ground station set and combining them, multiple pairs of satellite and ground station combinations are obtained;

[0050] Acquire satellite orbital data;

[0051] Using orbital data, orbital propagation calculations are performed for each pair of satellites and ground stations within the predicted time period to obtain the satellite state sequence;

[0052] Based on the satellite status sequence, calculate the elevation angle sequence for each satellite;

[0053] Based on the elevation angle sequence and preset visibility conditions, continuously visible segments of the satellite are identified;

[0054] Based on the continuously visible segments of satellites, the original arrival time and original departure time of each satellite are obtained to obtain the original transit window;

[0055] By introducing preset window margin parameters and preset departure hold margin, the original border crossing window is adjusted to obtain the safe window boundary and window duration;

[0056] Define the warm-up lead time parameter, which includes container cold start time and network configuration time;

[0057] The preheating trigger time for each satellite is calculated using the safety window boundary and window duration, as well as the preheating lead time parameters.

[0058] For each satellite, construct a window object, which includes the satellite ID, ground station ID, original transit window, preheating trigger time, and the window duration of the original transit window;

[0059] Use the window object as the satellite's transit window.

[0060] Secondly, embodiments of this application provide a flexible orchestration device for computing resources of a cloud-based ground station, the device comprising:

[0061] A module is established to enable the cloudification of ground stations by creating a schedulable cloud computing resource pool and a microservice container image library for ground stations.

[0062] The acquisition module is used to acquire satellite orbit ephemeris and multi-source data from the operations control center. The multi-source data includes planned mission data and historical sample data.

[0063] The calculation module is used to calculate the satellite's prediction window and window-level traffic prediction table based on the satellite's orbital ephemeris and multi-source data.

[0064] The orchestration processing module is used to map the predicted business volume in the window-level business volume forecast table to resource requirements, and generate a pre-arrangement plan for resources within the window based on the resource requirements; it executes computing power resource preheating actions to obtain the preheating plan and ready flags;

[0065] The confirmation module is used to perform satellite access confirmation based on the warm-up plan and readiness flag during the prediction window's runtime. After satellite access confirmation, it identifies microservice container instances in the idle ready state from the microservice container image library and switches these instances to the running state.

[0066] The secondary scheduling module is used to monitor the satellite status and the remaining capacity of the cloud resource pool in real time after the satellite successfully connects to the ground station, calculate the deviation between the measured status and the estimated results, and perform secondary scheduling.

[0067] The destruction and recycling module is used to destroy the container instances launched by the satellite during its transit state after the prediction window ends, reclaim the computing resources occupied by the containers, and perform status sorting and backfilling for low-priority non-real-time offline tasks.

[0068] The technical solutions provided in this application embodiment may include the following beneficial effects:

[0069] In this embodiment, computing resources are unified into a globally shared computing resource pool. Based on this, resource management methods are implemented for the three stages before, during, and after satellite transit, including resource pre-scheduling and computing resource warm-up, dynamic secondary scheduling during operation, and rapid resource recovery after transit. This reduces task startup latency caused by container cold starts, improves resource utilization, and ensures highly reliable service for real-time transit tasks in scenarios with multiple satellite concurrency and short transit windows.

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

[0071] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0072] Figure 1 This is a flowchart illustrating a method for elastically orchestrating computing resources of a cloud-based ground station, as provided in an embodiment of this application.

[0073] Figure 2 This is a schematic diagram of a transit window calculation and window-level traffic volume prediction process provided in an embodiment of this application;

[0074] Figure 3 This is a schematic diagram of a resource demand mapping, business classification and resource pre-arrangement generation and computing resource preheating process provided in an embodiment of this application;

[0075] Figure 4This is a schematic diagram of an access event confirmation, runtime switching, and SDN traffic activation process during the predicted window runtime provided in an embodiment of this application;

[0076] Figure 5 This is a schematic diagram of a process for identifying the deviation between the measured state and the predicted result during operation and for secondary scheduling and adjustment, provided in an embodiment of this application.

[0077] Figure 6 This is a schematic diagram of a non-transit period idle time task allocation and preheating trigger resource preemption process provided in an embodiment of this application;

[0078] Figure 7 This is a schematic diagram of the structure of a cloud-based ground station computing resource elastic orchestration device provided in an embodiment of this application;

[0079] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0080] The following description and accompanying drawings fully illustrate specific embodiments of this application to enable those skilled in the art to practice them.

[0081] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0082] In the following description, when referring to the accompanying drawings, the same numbers in different drawings denote the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0083] In the description of this application, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0084] This application provides a method and apparatus for elastic orchestration of computing resources for cloud-based ground stations to address the problems existing in the aforementioned related technologies. In the embodiments of this application, computing resources are uniformly cloudified into a globally shared computing resource pool. Based on this, resource management methods are implemented for the three stages before, during, and after satellite transit, including resource pre-orchestration and computing resource warm-up actions, dynamic secondary scheduling during operation, and rapid resource recovery after transit. This reduces task startup latency caused by container cold starts, improves resource utilization, and ensures highly reliable service for real-time transit tasks in scenarios involving multiple satellite concurrency and short transit windows. The following detailed description uses exemplary embodiments.

[0085] The following will be combined with the appendix Figure 1 -Appendix Figure 6 This application provides a detailed description of the method for flexible orchestration of computing resources for cloud-based ground stations, as provided in the embodiments of this application. This method can be implemented using a computer program and can run on a flexible orchestration device for computing resources of cloud-based ground stations based on the von Neumann architecture. This computer program can be integrated into applications or run as a standalone utility application.

[0086] Please see Figure 1 This is a flowchart illustrating a method for elastically orchestrating computing resources for cloud-based ground stations, as provided in this application embodiment. Figure 1 As shown, the method in this application embodiment includes the following steps:

[0087] S101 achieves cloudification of ground stations by establishing a schedulable cloud computing resource pool and a microservice container image library for ground stations;

[0088] In some embodiments of this application, the specific process of realizing the cloudification of ground stations by establishing a schedulable cloud computing resource pool and a microservice container image library includes: using software-defined networking and network function virtualization technologies, all computing resources within the ground station are virtualized into a globally shared computing resource pool to obtain a schedulable cloud computing resource pool for the ground station; under network function virtualization technology and a preset container orchestration framework, the virtualized computing resources are encapsulated into independently deployable microservice container images to obtain a microservice container image library, thereby realizing the cloudification of the ground station.

[0089] Software-defined networking (SDN) is a network architecture approach that separates the network's control plane (responsible for network management and configuration) from the data plane (responsible for packet forwarding). This allows for more flexible and centralized network management, facilitating the definition and management of network behavior through software programming. Computing resources refer to computing resources, including hardware resources such as CPUs, GPUs, and FPGAs, and the computing power these hardware components can provide. A globally shared cloud computing resource pool is a centrally managed collection of resources containing virtualized computing resources, which can be shared and scheduled by the entire system or multiple users. In satellite communication systems, ground stations are facilities located on the ground for communicating with satellites; they can send and receive signals and process data. A pre-configured container orchestration framework is a pre-configured system used to manage and schedule containers to support microservice architectures. Common container orchestration frameworks include Kubernetes and Docker Swarm. A microservice container image is a special software package containing all the dependencies, libraries, environment variables, and configuration files required to run a microservice. Container images can be instantiated into containers to run microservices.

[0090] S102 obtains satellite orbit ephemeris and multi-source data from the operations control center. The multi-source data includes planned mission data and historical sample data.

[0091] The Operations Control Center (OCC) is responsible for monitoring and managing satellite operations. It typically handles satellite launch, orbit control, mission planning, and daily maintenance. Satellite orbital ephemeris is detailed data describing the satellite's position and time in orbit. It usually includes orbital parameters such as altitude, inclination, right ascension of the ascending node, and the satellite's position at a specific time. Multi-source data refers to a collection of data from different sources. In satellite communication systems, multi-source data may include data from different sensors, different time points, and different missions. Planned mission data is pre-arranged mission data, including specific tasks the satellite needs to perform, such as data transmission, remote sensing imaging, and scientific experiments. These tasks are usually planned by the OCC before launch or during satellite operation. Historical sample data refers to samples of data collected in the past, which can be used to analyze, predict, and optimize current and future missions. In satellite communication, historical sample data may include past communication patterns, mission execution status, and satellite status.

[0092] S103, Calculate the satellite's prediction window and window-level traffic prediction table based on satellite orbit ephemeris and multi-source data;

[0093] In some embodiments of this application, the specific process of calculating the satellite's prediction window and window-level traffic prediction table based on satellite orbit ephemeris and multi-source data includes: using satellite orbit ephemeris to determine the specific time period when the satellite is within the visible range of the ground station; calculating the specific time window for satellite transit based on the specific time period to obtain the satellite's transit window; and using planned mission data, historical sample data, and the transit window, sequentially performing prediction window generation, planned mission expected remaining volume calculation, historical baseline traffic volume estimation, and prediction result consistency fusion to obtain a prediction window containing safe time boundaries and a window-level traffic prediction table containing estimated load values ​​for each service type.

[0094] Specifically, the process of calculating the specific time window for satellite transit based on a specific time period includes: traversing and combining the satellite set and the ground station set to obtain multiple pairs of satellite and ground station combinations; acquiring satellite orbit data; using the orbit data, performing orbit propagation calculations for each pair of satellite and ground station combinations within the predicted time period to obtain a satellite state sequence; calculating the elevation angle sequence for each satellite based on the satellite state sequence; identifying continuously visible segments of the satellite based on the elevation angle sequence and preset visibility conditions; and obtaining the original arrival time of each satellite based on these continuously visible segments. The original transit window is obtained by combining the original departure time with the original departure time. Preset window margin parameters and preset departure hold margins are introduced to adjust the original transit window, resulting in the safety window boundary and window duration. A preheating lead time parameter is defined, including container cold start time and network configuration time. The preheating trigger time for each satellite is calculated using the safety window boundary, window duration, and preheating lead time parameter. For each satellite, a window object is constructed, including the satellite ID, ground station ID, original transit window, preheating trigger time, and the original transit window duration. This window object is then used as the satellite's transit window.

[0095] For example Figure 2 As shown, Figure 2 This is a schematic diagram of a transit window calculation and window-level traffic volume forecasting process provided in this application, which specifically includes the following steps:

[0096] S201, calculation of multiple satellite transit windows;

[0097] Specifically, traverse the satellite set Joining the ground station For each pair of combinations Based on orbital data In the prediction time domain Orbital propagation is performed within the system to obtain the satellite state sequence; elevation angle sequence is calculated for each satellite. Based on visibility conditions, continuous visible segments are identified to obtain the original entry time. With the original departure time Introducing window margin parameter Maintain leeway when leaving By modifying the original window, the safe window boundary is obtained. With window duration Define the preheating advance parameter. This is the sum of container cold start time and network configuration time, based on the secure entry time and... Calculate the preheating trigger time .

[0098] It should be noted that, considering the link handshake latency and antenna servo stabilization time in a cloud environment, the following settings are made: Seconds are used to ensure resource readiness before signal locking; settings Seconds are used to ensure integrity verification after data transmission is completed; for heavy images involving resources such as FPGAs / GPUs, a specific setting is set. The time (including 150 seconds for image fetching and loading and 30 seconds for network routing convergence) is set for lightweight images that only involve CPU. Second.

[0099] S202, The specific process for calculating the expected remaining amount of the planned task includes:

[0100] Define sample variables for each service type (such as measurement and control services, narrowband data transmission, broadband data transmission, etc.). Calculate the observation duration With deletion mark :

[0101] ,

[0102] ;

[0103] in At the time of task generation, The moment the business is completed. This is the observation cutoff time;

[0104] Construct the log-likelihood function based on the Weibull distribution:

[0105]

[0106] Solving for the maximum value parameter of the above function yields the residual function used for prediction:

[0107]

[0108] For each window Select the start time of the window based on the business type. The previously generated set of planned tasks is used to utilize the residual function. Calculate the expected surplus as the planning-side forecast:

[0109] ,

[0110] in The amount of data for the task;

[0111] It should be noted that the specific parameters of Weibull in this embodiment are as follows:

[0112] For measurement, operation, and control-related tasks, the typical shape parameters obtained are obtained. Scale parameters This manifests as the task being completed quickly after it is generated;

[0113] Typical shape parameters for broadband data transmission services Scale parameters It exhibits a long trailing distribution characteristic.

[0114] S203, The specific process for estimating historical baseline traffic volume (historical baseline forecasting) includes:

[0115] Construct a feature vector that includes duration and periodic features. Historical window samples :

[0116]

[0117] in It is a daily cycle. It is a weekly cycle;

[0118] Ridge regression is used to estimate model parameters And for the window to be predicted Construct the corresponding feature vector Baseline predictions are obtained. .

[0119] S204, the specific process of forecast consistency fusion (consistency fusion of planned and historical forecasts) includes:

[0120] Calculate the consistency score It is used to measure the degree of deviation between planned forecasts and historical forecasts. The constant for the smooth minimum value:

[0121] ;

[0122] Calculate fusion weights , The adjustment coefficient constant is:

[0123] ;

[0124] The fused output is calculated and truncated to non-negative values, and finally an output window-level traffic forecast table is generated. :

[0125] ,

[0126] Window-level business volume forecast table .

[0127] It should be noted that the smoothing minimum constant is set. This is used to prevent calculation errors where the denominator is zero; it sets an adjustment coefficient constant. Its manifestation is when the consistency score When the value is 1, the fusion weight ;when When the weight increases, the weight shifts towards the planned value.

[0128] S104: Map the predicted business volume in the window-level business volume forecast table to resource demand, and generate a pre-arrangement plan for resources within the window based on the resource demand; execute the computing power resource preheating action to obtain the preheating plan and ready flag;

[0129] In some embodiments of this application, the specific process of mapping the predicted business volume in the window-level business volume prediction table to resource requirements and generating a pre-arrangement plan for resources within the window based on the resource requirements includes: constructing a business profile parameter table, which contains key parameters for each business type; facing the prediction window, converting the predicted business volume in the window-level business volume prediction table into resource requirements according to the business profile parameter table; classifying each business type within the prediction window according to the business priority and data volume of each business type to obtain a classification result; and generating a pre-arrangement plan for resources within the prediction window based on the classification result and resource requirements.

[0130] Specifically, for each prediction window Based on the business profile parameter table, the business volume will be predicted. Converted into resource requirements Based on business priority and data volume, classify the various business types within the window and generate a pre-arrangement plan for resources within the window; at the preheating trigger time... , and perform computing resource preheating actions.

[0131] For example Figure 3 As shown, Figure 3 This application provides a schematic diagram of a resource demand mapping, business classification and resource pre-arrangement generation, and computing resource preheating process, which includes the following steps:

[0132] S301, Business Profile Parameter Table Construction;

[0133] During the resource requirement transformation, for each business type ( For all business sets, determine the business profile parameters and organize them into a business profile parameter table:

[0134]

[0135] in, A mirrored function chain corresponding to the business; This represents the baseline cost vector for running the service. A unit load factor vector; The resource vector with the lowest QoS guarantee.

[0136] Based on the current window Corresponding forecast business volume Calculate the equivalent rate within the window. :

[0137]

[0138] in This refers to the window duration.

[0139] Calculate runtime resource requirements based on a mapping model. :

[0140] .

[0141] It should be noted that the resource vector units are defined as: number of CPU cores, number of GPUs, number of FPGA logic units, and I / O bandwidth.

[0142] For broadband data transmission services Its baseline cost vector Set the unit load factor Set the minimum QoS guarantee vector Ensure minimum business availability;

[0143] For measurement, operation, and control (MEC) operations, its baseline overhead vector Set the unit load factor Set the minimum QoS guarantee vector .

[0144] S302, Construction of a business hierarchy system;

[0145] Specifically, when classifying the various business types within the prediction window, the businesses are divided into four quadrants: High Priority - High Data Volume (HP-HV), High Priority - Low Data Volume (HP-LV), Low Priority - High Data Volume (LP-HV), and Low Priority - Low Data Volume (LP-LV). Priority thresholds are then set. With data volume threshold For each business type Determine its priority constant And calculate the normalized data volume. :

[0146]

[0147] according to and The quadrant to which a business belongs is determined by its relationship to the threshold.

[0148] Calculate business allocation weights ,in Balance coefficient:

[0149] .

[0150] It should be noted that the parameters of the classification system are set as follows:

[0151] Set priority threshold Normalized data volume threshold Set the balance coefficient This indicates that when calculating and allocating weights, the weight of business priority is greater than the weight of data volume.

[0152] S303, Pre-scheduling plan generation;

[0153] Specifically, when the resource pre-scheduling plan is generated within the window, resources are allocated on demand when there is sufficient supply. When resources are insufficient, a "safety net first, then flexible" resource allocation strategy is implemented. First, the minimum required resources for the business are calculated. :

[0154]

[0155] After deducting the guaranteed resources for high-priority services and other services in sequence, based on the remaining capacity Weighting based on business Flexible resources are allocated using a single completion coefficient method:

[0156] Calculate the elasticity requirements of each business. ;

[0157] Define the revenue density of each business. for:

[0158]

[0159] By yield density Sort by size from largest to smallest and calculate business completion rate:

[0160]

[0161] Update remaining capacity in sequence And obtain the resource allocation results for each service segment within the final window:

[0162]

[0163] At the same time, The guaranteed minimum portion of the business is marked as "non-preemptible," while the flexible portion and... Services are marked as "preemptible". In the event of a sudden surge in high-priority traffic, the scheduling of "preemptible" resources will automatically apply bandwidth limiting or downgrade to low-priority services.

[0164] In some embodiments of this application, the specific process of performing computing resource preheating includes: creating a resource slice for each service at the preheating trigger time; locking the resource quota for the resource slice according to the preset preheating ratio; pulling the required image from the microservice container image library and starting the container to the idle and ready state; preloading ephemeris and protocol parameters and configuring the hardware; pre-deploying software-defined network traffic routing rules; and setting the ready flag after passing the health check to obtain the preheating plan and the ready flag.

[0165] S304, Computing resource preheating action executed;

[0166] Specifically, for each business, at the preheating trigger time First, create resource slices and lock resource quotas, then synchronize from the mirror repository. Pull the image and start the container to an idle ready state; then preload the ephemeris and protocol parameters, complete hardware acceleration configurations such as GPU kernel pre-compilation and FPGA bitstream download; finally, pre-deploy SDN traffic routing rules, and mark the container as ready after passing a health check. .

[0167] S105, during the prediction window's runtime, satellite access confirmation is performed based on the warm-up plan and readiness flags; after satellite access confirmation, microservice container instances in the idle ready state are identified from the microservice container image library, and these instances are switched to the running state.

[0168] In some embodiments of this application, the specific process of performing satellite access confirmation includes: real-time monitoring of the current time; when the current time reaches the safe entry moment, parsing the link layer identifier to determine the satellite's identity and associating it with the service set planned for the prediction window; establishing a control plane signaling channel between the orchestrator and the computing plane, and verifying the resource readiness status to ensure that all service chain resources have been initialized as a prerequisite for enabling the processing chain.

[0169] Specifically, in the prediction window During the operation period, the transit access and execution module will use the output preheating plan and readiness flags. Perform satellite access confirmation; switch the microservice container instance in the idle ready state to the running state.

[0170] For example Figure 4 As shown, Figure 4 This application provides a schematic diagram of an access event confirmation, runtime switching, and SDN traffic redirection activation process during the predicted window runtime, including the following steps:

[0171] S401, Access event confirmation aligned with window;

[0172] The system monitors the current time in real time. When the safe entry time is reached Time-resolved link layer identifier confirms satellite Identity and associated with the set of business functions planned in this window;

[0173] Establish a control plane signaling channel between the orchestrator and the computation plane, and verify it again. This is to ensure that all business chain resources have been initialized, as a prerequisite for enabling the processing chain.

[0174] Specifically, it activates pre-configured SDN routing rules to enable real-time import of RF or baseband data flow into the processing chain, while simultaneously enabling the collection of operational metrics.

[0175] S402, handles chain runtime switching and diversion rules;

[0176] This involves sending control commands to the business-bound nodes to switch the container instance from the "idle and ready state" to the "running state," opening the data port, and removing the blocking barriers of the internal queue.

[0177] Specifically, the ground station front-end output logic is bound to the function chain entry point, and the SDN traffic redirection rules are switched from the "pre-configured version" to the "effective version".

[0178] Start the assembly line operation in sequence and enable real-time data collection of indicators.

[0179] In this embodiment:

[0180] "Operational metrics" include queue length, processing latency, and resource utilization. Specifically, for queue length, the number of pending packets is counted in the function chain entry queue and the input and output queues of each microservice container instance, with a sampling period of 200ms. The capacity of the entry queue is set to 2048 packets. When the queue depth is sampled for 3 consecutive times with ≥1434 packets (70%), it is determined as a congestion warning; when it is sampled for 3 consecutive times with ≥1844 packets (90%), it is determined as a congestion alarm.

[0181] In handling latency, timestamps are applied to the entry and exit points of each group to calculate the end-to-end latency. Quantile indicators are used, and P95 and P99 are calculated using a 1-second sliding window. The end-to-end latency thresholds for the measurement, operation and control service chain are set to P95≤50ms and P99≤100ms, and the end-to-end latency thresholds for the broadband data transmission service chain are set to P95≤200ms and P99≤500ms.

[0182] In resource utilization, CPU utilization is counted and GPU and FPGA load are counted based on the acceleration device driver interface. The sampling period is set to 1 second. When the CPU utilization of a container instance is ≥85% for 5 consecutive samples or the GPU load is ≥90% for 5 consecutive samples, it is judged as resource stress. When the CPU utilization is ≤30% for 20 consecutive samples, it is judged as resource redundancy.

[0183] S106, after the satellite successfully connects to the ground station, monitors the satellite status and the remaining capacity of the cloud resource pool in real time, calculates the deviation between the measured status and the estimated results, and performs secondary scheduling.

[0184] In some embodiments of this application, the specific process of real-time monitoring of satellite status and remaining capacity of the cloud resource pool, calculating the deviation between the measured status and the estimated results, and performing secondary scheduling includes: activating pre-configured SDN diversion rules to realize real-time import of radio frequency or baseband data flow into the processing chain, and starting the collection of operational indicators; after the satellite successfully accesses the ground station, acquiring each key parameter for the operational indicator collection of the accessed satellite; determining the current real-time status of the accessed satellite based on each key parameter; determining the estimated results of the accessed satellite based on the pre-scheduling plan; calculating the result deviation between the current real-time status and the estimated results; and performing secondary scheduling based on the result deviation to dynamically adjust the computing resources in the cloud computing resource pool available for scheduling at the ground station until the end of the prediction window operation period of the accessed satellite.

[0185] Specifically, after the access is completed, the dynamic monitoring and secondary scheduling module monitors the satellite's actual entry time, departure time, link rate, and other statuses, as well as the remaining capacity of the resource pool nodes, in real time. Secondary scheduling is performed based on the deviation between the measured status and the estimated results during the operation period, calculated according to the pre-arranged plan.

[0186] For example Figure 5 As shown, Figure 5 This is a schematic diagram of a process for identifying and adjusting the deviation between the measured state and the predicted result during operation, as provided in this application, including the following steps:

[0187] S501, Identification of deviations between measured conditions and predicted results during operation;

[0188] Among them, obtaining the current time The actual access status includes the actual entry time, actual exit time, real-time link rate, and bit error rate.

[0189] Calculate the business rate deviation based on the actual transit duration and actual business volume. ;

[0190] When the deviation exceeds a preset threshold or resources are insufficient, a subsequent secondary scheduling process is triggered, taking into account the actual arrival rate. Calculate the actual requirements of the corrected operating segment :

[0191]

[0192] S502, secondary scheduling;

[0193] The process follows a baseline locking principle, ensuring that high-priority services retain their allocated resources without reduction, while only low-priority services are subject to incremental resource patching or preemption. For each resource scheduling action 'a', a "local priority" search order is adopted to reduce overall overhead: firstly, vertical scaling on the original mirror node is prioritized; if the original node's resources are insufficient, neighboring nodes within the same rack or switching domain are searched for horizontal migration; if the overall resource pool is strained, low-priority services are downgraded or rate-limited, and resources for non-real-time offline tasks are preempted if necessary.

[0194] S107, after the prediction window ends, destroys the container instances launched by the satellite during its transit, reclaims the computing resources occupied by the containers, and performs status sorting and backfilling for low-priority non-real-time offline tasks.

[0195] In some embodiments of this application, during the satellite's non-passage period, the idle resource scheduling module schedules idle computing power to process non-real-time offline data tasks such as historical data deep cleaning, AI remote sensing image analysis, and system log archiving; when it detects that the preheating phase is about to begin, a preemption mechanism is triggered to release non-real-time task resources to ensure real-time passage tasks.

[0196] Step S6: After the runtime ends, quickly destroy the container instances launched during the transition period and reclaim computing resources. Specifically, in the prediction window... After the runtime period ends, the resource reclamation and backfilling module immediately destroys the container instances started during the transition period and reclaims computing resources, and performs status reorganization and backfilling for low-priority non-real-time offline tasks. Specifically, this includes the following steps:

[0197] When detected Arrival of departure time At that time, the decision window During the recycling period, the data plane SDN diversion rule corresponding to the window is revoked, the injection path of radio frequency or baseband data is cut off, and the residual data in the buffer is written to disk or transferred.

[0198] Send instructions to the compute nodes to destroy the microservice container instances corresponding to each business under the window, and release the lock on the number of CPU cores, GPU memory and FPGA logic units;

[0199] Update the remaining available capacity of the cloud resource pool using the runtime quota before departure as the repayment amount:

[0200]

[0201] After completing the resource return, the scheduler organizes the subsequent processing of low-priority non-real-time services that were rate-limited or downgraded during operation, reads their saved status snapshots and progress information, regenerates the task descriptors and fills them back into the idle task pool queue, enters the next non-transit idle state and resumes execution.

[0202] For example Figure 6 As shown, Figure 6 This application provides a schematic diagram of a non-transit period idle time task allocation and preheating-triggered resource preemption process, including the following steps:

[0203] S701, off-peak task allocation during non-transit periods;

[0204] Among them, the scheduler monitors the current system time in real time. With the prediction window set, if at the current time During the warm-up or operation period that does not fall into any window, the system is determined to be in a "non-transit idle state";

[0205] Calculate reusable idle capacity This serves as the upper limit of resources for offline task scheduling;

[0206] Construct an idle task pool, select non-real-time offline data processing tasks to be processed, including data archiving tasks and deep analysis tasks, and allocate no more than [number missing] tasks to it based on task requirements. The computing and storage resources are allocated, and the usage of these resources is uniformly marked as "preemptible";

[0207] S702, securing resources before the warm-up period;

[0208] Specifically, when the system detects that the current time t has arrived or is approaching the window period, it triggers the resource preemption process, performs a suspension operation on offline tasks that are occupying idle resources, saves the current memory context and progress snapshot, updates the cloud resource pool status, and releases resources.

[0209] Furthermore, during non-passage periods, idle computing power is allocated to execute non-real-time offline tasks. Specifically, during satellite non-passage periods, the resource idle scheduling module allocates idle computing power to process non-real-time offline data tasks such as deep cleaning of historical data, AI remote sensing image analysis, and system log archiving; when it detects that the satellite is about to enter the warm-up phase, a preemption mechanism is triggered to release non-real-time task resources to ensure real-time passage tasks.

[0210] In some embodiments of this application, the system determines whether the satellite is currently in a non-passing state by monitoring the current time and the predicted satellite passing window. If the satellite is currently in a non-passing state, a non-real-time offline data task is executed. The non-real-time offline data task includes in-depth analysis and cleaning of historically accumulated data, analysis of remote sensing images using AI technology, and organization and archiving of system operation logs. Alternatively, if the satellite is not currently in a non-passing state and the current time is when the resource preheating action of the task begins, a preemption mechanism is triggered to release non-real-time task resources to ensure the satellite's real-time task.

[0211] In this embodiment, computing resources are uniformly virtualized into a globally shared computing resource pool. Based on this, resource management methods are implemented for the three stages before, during, and after satellite transit, including resource pre-scheduling and computing resource warm-up, dynamic secondary scheduling during operation, and rapid resource recovery after transit. This reduces task startup latency caused by container cold starts, improves resource utilization, and ensures highly reliable service for real-time transit tasks in scenarios with multiple satellite concurrency and short transit windows.

[0212] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0213] Please see Figure 7 This illustration shows a schematic diagram of the structure of a cloud-based ground station computing resource elastic orchestration device provided in an exemplary embodiment of this application. This cloud-based ground station computing resource elastic orchestration device can be implemented as all or part of an electronic device through software, hardware, or a combination of both. The device 1 includes an establishment module 10, an acquisition module 20, a calculation module 30, an orchestration processing module 40, a confirmation module 50, a secondary scheduling module 60, and a destruction and recycling module 70.

[0214] Module 10 is established to enable the cloudification of ground stations by creating a schedulable cloud computing resource pool and a microservice container image library for ground stations.

[0215] The acquisition module 20 is used to acquire satellite orbit ephemeris and multi-source data from the operation and control center. The multi-source data includes planned mission data and historical sample data.

[0216] The calculation module 30 is used to calculate the satellite's prediction window and window-level traffic prediction table based on the satellite's orbital ephemeris and multi-source data.

[0217] The orchestration processing module 40 is used to map the predicted business volume in the window-level business volume forecast table to resource requirements, and generate a pre-arrangement plan for resources within the window based on the resource requirements; execute computing power resource preheating actions to obtain the preheating plan and ready flags;

[0218] The confirmation module 50 is used to perform satellite access confirmation according to the warm-up plan and readiness identifier during the runtime of the prediction window; after satellite access confirmation, it determines the microservice container instances in the idle ready state from the microservice container image library and switches the microservice container instances in the idle ready state to the running state.

[0219] The secondary scheduling module 60 is used to monitor the satellite status and the remaining capacity of the cloud resource pool in real time after the satellite successfully accesses the ground station, calculate the deviation between the measured status and the estimated results, and perform secondary scheduling.

[0220] The destruction and recycling module 70 is used to destroy the container instances launched by the satellite during its transit state after the prediction window ends, reclaim the computing resources occupied by the containers, and perform status sorting and backfilling for low-priority non-real-time offline tasks.

[0221] It should be noted that the cloud-based ground station computing resource elastic orchestration device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the cloud-based ground station computing resource elastic orchestration method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the cloud-based ground station computing resource elastic orchestration device and the cloud-based ground station computing resource elastic orchestration method embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0222] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0223] In this embodiment, computing resources are uniformly virtualized into a globally shared computing resource pool. Based on this, resource management methods are implemented for the three stages before, during, and after satellite transit, including resource pre-scheduling and computing resource warm-up, dynamic secondary scheduling during operation, and rapid resource recovery after transit. This reduces task startup latency caused by container cold starts, improves resource utilization, and ensures highly reliable service for real-time transit tasks in scenarios with multiple satellite concurrency and short transit windows.

[0224] This application also provides a computer-readable medium having program instructions stored thereon, which, when executed by a processor, implement the cloud-based ground station computing resource elastic orchestration method provided in the above-described method embodiments.

[0225] This application also provides a computer program product containing instructions that, when run on a computer, causes the computer to execute the cloud-based ground station computing resource elastic orchestration method of the above-described method embodiments.

[0226] Please see Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 8 As shown, the electronic device 1000 may include: at least one processor 1001, at least one network interface 1004, memory 1005, and at least one communication bus 1002.

[0227] The communication bus 1002 is used to realize the connection and communication between these components.

[0228] The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0229] The processor 1001 may include one or more processing cores. The processor 1001 connects to various parts within the electronic device 1000 using various interfaces and lines. It executes various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 1005, and by calling data stored in the memory 1005. Optionally, the processor 1001 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 1001 may integrate one or more of the following: a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip, without being integrated into the processor 1001.

[0230] The memory 1005 may include random access memory (RAM) or read-only memory. Optionally, the memory 1005 may include a non-transitory computer-readable storage medium. The memory 1005 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 1005 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 1005 may also be at least one storage system located remotely from the aforementioned processor 1001. Figure 8 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, and a cloud-based ground station computing resource flexible orchestration application.

[0231] exist Figure 8In the illustrated electronic device 1000, the processor 1001 can be used to call the cloud-based ground station computing resource elastic orchestration application stored in the memory 1005, and specifically perform the following operations:

[0232] By establishing a schedulable cloud computing resource pool and a microservice container image library for ground stations, the cloudification of ground stations can be achieved.

[0233] From the operations control center, we obtain satellite orbit ephemeris and multi-source data, which include planned mission data and historical sample data.

[0234] Based on satellite orbit ephemeris and multi-source data, calculate the satellite's prediction window and window-level traffic forecast table;

[0235] Map the predicted workload in the window-level workload forecast table to resource requirements, and generate a pre-arrangement plan for resources within the window based on the resource requirements; execute the computing power resource preheating action to obtain the preheating plan and readiness flag;

[0236] During the prediction window's runtime, satellite access confirmation is performed based on the warm-up plan and readiness flags. After satellite access confirmation, microservice container instances in the idle ready state are identified from the microservice container image library, and these instances are switched to the running state.

[0237] After the satellite successfully connects to the ground station, the satellite status and the remaining capacity of the cloud resource pool are monitored in real time, the deviation between the measured status and the estimated results are calculated, and secondary scheduling is performed.

[0238] After the prediction window ends, the container instances launched by the satellite during its transit are destroyed, the computing resources occupied by the containers are recovered, and the status of low-priority non-real-time offline tasks is sorted out and backfilled.

[0239] In one embodiment, the processor 1001 also performs the following operations:

[0240] By monitoring the current time and the predicted satellite transit window, it can be determined whether the satellite is currently in a non-transit state;

[0241] If the satellite is not currently in transit, perform non-real-time offline data tasks. These tasks include in-depth analysis and cleaning of historically accumulated data, analysis of remote sensing imagery using AI technology, and organization and archiving of system operation logs.

[0242] When a satellite is not currently in a non-transiting state and is currently in the resource preheating phase of a mission, a preemption mechanism is triggered to release non-real-time mission resources to ensure the satellite's real-time mission.

[0243] In one embodiment, when the processor 1001 executes the cloudification of the ground station by establishing a schedulable cloud computing resource pool and a microservice container image library for the ground station, it specifically performs the following operations:

[0244] By utilizing software-defined networking and network function virtualization technologies, all computing resources within the ground station are virtualized into a globally shared computing resource pool, resulting in a cloud-based computing resource pool that can be scheduled for the ground station.

[0245] Under the network function virtualization technology and the pre-set container orchestration framework, virtualized computing resources are encapsulated into microservice container images that can be deployed independently, resulting in a microservice container image library, thus realizing the cloudification of ground stations.

[0246] In one embodiment, when the processor 1001 calculates the satellite's prediction window and window-level traffic prediction table based on satellite orbit ephemeris and multi-source data, it specifically performs the following operations:

[0247] By using satellite orbit ephemeris, the specific time period during which the satellite is within the visible range of the ground station can be determined;

[0248] Based on a specific time period, the specific time window for satellite transit is calculated, thus obtaining the satellite transit window;

[0249] Using planned task data, historical sample data, and transit windows, the following steps are performed sequentially: generating a forecast window, calculating the expected remaining amount of planned tasks, estimating historical baseline traffic volume, and fusion of forecast results. This yields a forecast window that includes a safe time boundary and a window-level traffic volume forecast table that includes the estimated load for each type of business.

[0250] In one embodiment, when the processor 1001 maps the predicted traffic volume in the window-level traffic forecast table to resource demand and generates an in-window resource pre-scheduling plan based on the resource demand, it specifically performs the following operations:

[0251] Construct a business profile parameter table, which contains key parameters for each business type;

[0252] Faced with the forecast window, the forecasted business volume in the window-level business volume forecast table is converted into resource requirements based on the business profile parameter table;

[0253] Based on the business priority and data volume of each business type, the business types within the prediction window are classified into different levels to obtain the classification results.

[0254] Based on the hierarchical results and resource requirements, a pre-arrangement plan for resources within the forecast window is generated.

[0255] In one embodiment, when the processor 1001 performs real-time monitoring of satellite status and remaining capacity of the cloud resource pool, calculates the deviation between the measured status and the estimated results, and performs secondary scheduling, it specifically performs the following operations:

[0256] Activate pre-configured SDN routing rules to enable real-time import of RF or baseband data flow into the processing chain, and start collecting operational metrics;

[0257] After the satellite successfully connects to the ground station, it acquires key parameters for the operational indicators of the connected satellite.

[0258] Based on the key parameters, determine the current real-time status of the accessed satellite;

[0259] Based on the pre-arranged plan, the estimated results of the access satellites are determined;

[0260] Calculate the deviation between the current real-time state and the predicted result;

[0261] Based on the deviation of the results, a secondary scheduling is performed to dynamically adjust the computing resources in the cloud computing resource pool available for scheduling at the ground station until the operation period of the prediction window of the access satellite ends.

[0262] In one embodiment, when the processor 1001 performs the preheating action for computing resources, it specifically performs the following operations:

[0263] At the preheating trigger moment, create a resource slice for each service;

[0264] Based on the preset preheating ratio, resource quotas are locked for resource slices;

[0265] Pull the required images from the microservice container image repository and start the containers to an idle and ready state;

[0266] Preload ephemeris and protocol parameters and configure the hardware;

[0267] Pre-deploy software-defined network traffic redirection rules;

[0268] After passing the health check, the ready flag is set, and the preheating plan and ready flag are obtained.

[0269] In one embodiment, when the processor 1001 performs satellite access confirmation, it performs the following specific operations:

[0270] Real-time monitoring of the current time;

[0271] When the safe entry time is reached at the current time, the link layer identifier is parsed to determine the satellite's identity and associate it with the set of services planned for the prediction window.

[0272] Establish a control plane signaling channel between the orchestrator and the computing plane, and verify the resource readiness status to ensure that all service chain resources have been initialized as a prerequisite for enabling the processing chain.

[0273] In one embodiment, the processor 1001 calculates the specific time window for satellite transit based on a specific time period, obtains the satellite transit window, and specifically performs the following operations:

[0274] By iterating through the satellite set and the ground station set and combining them, multiple pairs of satellite and ground station combinations are obtained;

[0275] Acquire satellite orbital data;

[0276] Using orbital data, orbital propagation calculations are performed for each pair of satellites and ground stations within the predicted time period to obtain the satellite state sequence;

[0277] Based on the satellite status sequence, calculate the elevation angle sequence for each satellite;

[0278] Based on the elevation angle sequence and preset visibility conditions, continuously visible segments of the satellite are identified;

[0279] Based on the continuously visible segments of satellites, the original arrival time and original departure time of each satellite are obtained to obtain the original transit window;

[0280] By introducing preset window margin parameters and preset departure hold margin, the original border crossing window is adjusted to obtain the safe window boundary and window duration;

[0281] Define the warm-up lead time parameter, which includes container cold start time and network configuration time;

[0282] The preheating trigger time for each satellite is calculated using the safety window boundary and window duration, as well as the preheating lead time parameters.

[0283] For each satellite, construct a window object, which includes the satellite ID, ground station ID, original transit window, preheating trigger time, and the window duration of the original transit window;

[0284] Use the window object as the satellite's transit window.

[0285] In this embodiment, computing resources are uniformly virtualized into a globally shared computing resource pool. Based on this, resource management methods are implemented for the three stages before, during, and after satellite transit, including resource pre-scheduling and computing resource warm-up, dynamic secondary scheduling during operation, and rapid resource recovery after transit. This reduces task startup latency caused by container cold starts, improves resource utilization, and ensures highly reliable service for real-time transit tasks in scenarios with multiple satellite concurrency and short transit windows.

[0286] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program for the flexible orchestration of computing resources of the cloud-based ground station can be stored in a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the above methods. The storage medium for the program for the flexible orchestration of computing resources of the cloud-based ground station can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0287] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A method for elastically orchestrating computing resources for cloud-based ground stations, characterized in that, The method includes: By establishing a schedulable cloud computing resource pool and a microservice container image library for ground stations, the cloudification of ground stations is realized; the globally shared cloud computing resource pool contains virtualized computing resources, which can be shared and scheduled by the entire system or multiple users. The satellite orbit ephemeris and multi-source data are obtained from the operations control center. The multi-source data includes planned mission data and historical sample data. Based on the satellite orbit ephemeris and the multi-source data, calculate the satellite's prediction window and window-level traffic prediction table; Map the predicted business volume in the window-level business volume prediction table to resource requirements, and generate a pre-arrangement plan for resources within the window based on the resource requirements; perform computing power resource preheating actions to obtain the preheating plan and ready flags; During the operation of the prediction window, satellite access confirmation is performed according to the preheating plan and readiness identifier; after satellite access confirmation, microservice container instances in the idle ready state are determined from the microservice container image library, and the microservice container instances in the idle ready state are switched to the running state; After the satellite successfully connects to the ground station, the satellite status and the remaining capacity of the cloud resource pool are monitored in real time, the deviation between the measured status and the estimated result is calculated, and secondary scheduling is performed. After the prediction window ends, the container instances launched by the satellite during its transit are destroyed, the computing resources occupied by the containers are recovered, and the status of low-priority non-real-time offline tasks is sorted and backfilled.

2. The method according to claim 1, characterized in that, The method further includes: By monitoring the current time and the predicted satellite transit window, it is determined whether the satellite is currently in a non-transit state; If the satellite is currently not in transit, perform non-real-time offline data tasks; these tasks include in-depth analysis and cleaning of historically accumulated data, analysis of remote sensing imagery using AI technology, and organization and archiving of system operation logs; or, When a satellite is not currently in a non-transiting state and is currently in the resource preheating phase of a mission, a preemption mechanism is triggered to release non-real-time mission resources to ensure the satellite's real-time mission.

3. The method according to claim 1, characterized in that, The establishment of a schedulable cloud computing resource pool and a microservice container image library for ground stations, to achieve cloudification of ground stations, includes: By utilizing software-defined networking and network function virtualization technologies, all computing resources within the ground station are virtualized into a globally shared computing resource pool, resulting in a cloud-based computing resource pool that can be scheduled for the ground station. Under the network function virtualization technology and the preset container orchestration framework, virtualized computing resources are encapsulated into independently deployable microservice container images to obtain a microservice container image library, thereby realizing the cloudification of ground stations.

4. The method according to claim 1, characterized in that, The step of calculating the satellite's prediction window and window-level traffic prediction table based on the satellite's orbital ephemeris and the multi-source data includes: Using the satellite orbit ephemeris, the specific time period during which the satellite is within the visible range of the ground station is determined; Based on the specific time period, the specific time window for the satellite's transit is calculated, thus obtaining the satellite's transit window; Using the planned task data, historical sample data, and the transit window, the following steps are performed sequentially: generating a prediction window, calculating the expected remaining amount of the planned task, estimating the historical baseline traffic volume, and fusion of prediction results. This yields a prediction window containing a safe time boundary and a window-level traffic volume prediction table containing the estimated load values ​​for each type of service.

5. The method according to claim 1, characterized in that, The step of mapping the predicted traffic volume in the window-level traffic volume forecast table to resource demand, and generating a pre-arrangement plan for resources within the window based on the resource demand, includes: Construct a business profile parameter table, which contains key parameters for each business type; Faced with the prediction window, the predicted business volume in the window-level business volume prediction table is converted into resource requirements based on the business profile parameter table; Based on the business priority and data volume of each business type, the business types within the prediction window are classified to obtain the classification results. Based on the classification results and the resource requirements, a resource pre-scheduling plan is generated within the prediction window.

6. The method according to claim 1, characterized in that, The real-time monitoring of satellite status and remaining capacity of the cloud resource pool, calculation of the deviation between the measured status and the estimated results, and execution of secondary scheduling include: Activate pre-configured SDN routing rules to enable real-time import of RF or baseband data flow into the processing chain, and start collecting operational metrics; After the satellite successfully connects to the ground station, it acquires key parameters for collecting operational indicators of the connected satellite. Based on the aforementioned key parameters, determine the current real-time status of the accessed satellite; Based on the pre-scheduling plan, the estimated results of the access satellites are determined; Calculate the deviation between the current real-time state and the predicted result; Based on the deviation of the results, a secondary scheduling is performed to dynamically adjust the computing resources in the cloud computing resource pool available for scheduling at the ground station until the operation period of the prediction window for the access satellite ends.

7. The method according to claim 1, characterized in that, The execution of the computing resource preheating action includes: At the preheating trigger moment, create a resource slice for each service; Based on the preset preheating ratio, the resource quota is locked for the resource slice; Pull the required image from the microservice container image repository and start the container to an idle and ready state; Preload ephemeris and protocol parameters and configure the hardware; Pre-deploy software-defined network traffic redirection rules; After passing the health check, the ready flag is set, and the preheating plan and ready flag are obtained.

8. The method according to claim 1, characterized in that, The execution of satellite access confirmation includes: Real-time monitoring of the current time; When the safe entry time is reached at the current time, the link layer identifier is parsed to determine the identity of the satellite and associate it with the service set planned for the prediction window. Establish a control plane signaling channel between the orchestrator and the computing plane, and verify the resource readiness status to ensure that all service chain resources have been initialized as a prerequisite for enabling the processing chain.

9. The method according to claim 4, characterized in that, The calculation of the specific time window for the satellite's transit based on the specific time period, to obtain the satellite's transit window, includes: By iterating through the satellite set and the ground station set and combining them, multiple pairs of satellite and ground station combinations are obtained; Acquire satellite orbital data; Using the orbital data, orbital propagation calculations are performed for each pair of satellites and ground stations within the predicted time period to obtain the satellite state sequence; Based on the satellite state sequence, calculate the elevation angle sequence for each satellite; Based on the elevation angle sequence and preset visibility conditions, segments of continuous satellite visibility are identified; Based on the continuously visible segments of the satellites, the original arrival time and original departure time of each satellite are obtained to obtain the original transit window; By introducing preset window margin parameters and preset departure hold margin, the original transit window is adjusted to obtain the safety window boundary and window duration; Define a warm-up lead time parameter, which includes container cold start time and network configuration time; The preheating trigger time for each satellite is calculated using the safety window boundary and window duration, and the preheating advance parameter. For each satellite, a window object is constructed, which includes the satellite ID, ground station ID, the original transit window, the preheating trigger time, and the window duration of the original transit window; Use the window object as the transit window of the satellite.

10. A flexible orchestration system for computing resources of a cloud-based ground station, characterized in that, The system includes: The module is designed to enable the cloudification of ground stations by establishing a schedulable cloud computing resource pool and a microservice container image library. The globally shared cloud computing resource pool contains virtualized computing resources that can be shared and scheduled by the entire system or multiple users. The acquisition module is used to acquire satellite orbit ephemeris and multi-source data from the operation and control center. The multi-source data includes planned mission data and historical sample data. The calculation module is used to calculate the prediction window and window-level traffic prediction table of the satellite based on the satellite orbit ephemeris and the multi-source data. The orchestration processing module is used to map the predicted business volume in the window-level business volume prediction table to resource requirements, and generate a pre-arrangement plan for resources within the window based on the resource requirements; execute computing power resource preheating actions to obtain the preheating plan and ready flags; The confirmation module is used to perform satellite access confirmation according to the preheating plan and readiness identifier during the operation period of the prediction window; after satellite access confirmation, it determines the microservice container instances in the idle ready state from the microservice container image library and switches the microservice container instances in the idle ready state to the running state. The secondary scheduling module is used to monitor the satellite status and the remaining capacity of the cloud resource pool in real time after the satellite successfully accesses the ground station, calculate the deviation between the measured status and the estimated result, and perform secondary scheduling. The destruction and recycling module is used to destroy the container instances launched by the satellite during its transit state after the end of the prediction window's operation period, reclaim the computing resources occupied by the containers, and perform status sorting and backfilling for low-priority non-real-time offline tasks.

Images