Satellite window-aware cross-domain cooperative scheduling method in space-air cross-domain network

Abstract

The application discloses a satellite window-aware cross-domain cooperative scheduling method in space-sea cross-domain network and belongs to the technical field of space-air-ground-sea integrated network and marine Internet of Things. The space-sea cross-domain network comprises a water surface gateway, a low-orbit satellite and a group of underwater autonomous vehicles (AUVs). The water surface gateway is used as a cross-domain coordinator to schedule the AUVs to perform a target area verification task and upload the cached data in a low-orbit satellite coverage window. The application integrates the AUV task execution, the gateway data caching and the intermittent satellite backhaul into a unified scheduling link. The cross-domain execution consequences of each candidate action are predicted, the AUV energy constraint, the task queue constraint, the gateway cache constraint and the satellite window capacity constraint are jointly used for feasibility screening, and a compact candidate action space is constructed. A state-related adaptive soft constraint weight is used to dynamically balance the end-to-end completion delay, the AUV energy consumption and the window waiting time, and a scheduling strategy is updated based on a near-end policy optimization framework. The application can effectively reduce the end-to-end delay from the generation to the data backhaul completion of the space-sea cross-domain verification task, and improve the adaptability and efficiency of the cross-domain cooperative scheduling under the intermittent satellite link.

Description

Technical Field

[0001] This invention belongs to the field of integrated air-space-ground-sea network, marine Internet of Things and cross-domain collaborative scheduling technology, specifically involving a cross-domain collaborative scheduling method based on satellite window perception in an air-sea cross-domain network. Background Technology

[0002] With increasing attention focused on technologies such as 6G, air-sea cross-domain networks integrating heterogeneous network resources from air, sea, and underwater are gradually becoming an important development direction for future integrated air-space-ground-sea communication infrastructure. In a typical network architecture: the underwater network is responsible for performing detection and data acquisition of the target sea area; the low-Earth orbit satellite network, leveraging its high-altitude position, provides wide-area coverage and high-speed communication, offering signal access and data transmission to its jurisdiction, and utilizing its remote sensing equipment for coarse-grained monitoring of the area.

[0003] Current research largely focuses on resource management, path planning, task allocation, or data transmission optimization within a single network domain. For example, in underwater networks, research mainly focuses on AUV collaborative operations, underwater acoustic communication optimization, and energy management; in satellite networks, research mainly focuses on satellite link scheduling and data transmission. However, for cross-domain collaborative scenarios involving underwater mission execution, surface data aggregation, and satellite backhaul, existing research is relatively limited, and a unified coordination and scheduling mechanism for the entire cross-domain mission process is still lacking.

[0004] Therefore, this invention considers an air-sea cross-domain network architecture, in which the cross-domain collaborative task is specifically the verification of pollution locations in a specific target water area. In this architecture, the underwater AUVs are the scheduled objects, responsible for specific patrols, detection, and data collection, and submitting the task results to the surface gateway after collecting the data; the surface gateway acts as a cross-domain coordinator, with both radio and underwater acoustic communication heterogeneous link interfaces, responsible for the coordinated scheduling and forwarding of task flow and data flow between the satellite network and the underwater network; after the satellite network discovers the water area to be measured through coarse-grained remote sensing, it issues specific pollution verification tasks to the surface gateway, and receives the verification data uploaded by the gateway after the task is completed.

[0005] Current research on air-sea cross-domain networks mainly focuses on air-sea interface communication, cross-medium channel modeling, air-sea relay communication, and information transmission between underwater unmanned platforms and aerial platforms. The relevant literature is as follows:

[0006] 1. In 2024, Zhijian Lin et al. conducted a joint offloading strategy optimization study on the computation offloading from sea surface equipment to ground or satellite edge nodes in the paper "Maritime Distributed ComputationOffloading in Space-Air-Ground-Sea Integrated Networks", which determined the offloading ratio, offloading objects and the allocation method of bandwidth or computing resources.

[0007] 2. In 2025, Jingzehua Xu et al., in their paper "UACOF: A USV-AUV Collaboration Framework for Underwater Tasks Under Extreme Sea Conditions," proposed a collaborative framework between unmanned surface vessels (USVs) and autonomous underwater vehicles (AUVs) for underwater data acquisition tasks under extreme sea conditions. This method uses USVs as a collaborative surface platform, leveraging their maneuverability and positioning advantages in the surface environment. Through USV path planning optimized based on the Fisher information matrix, it provides more favorable positioning and observation conditions for multiple underwater AUVs, thereby mitigating the error accumulation problem caused by AUVs' primary reliance on inertial navigation, acoustic positioning, and relative ranging underwater.

[0008] 3. In 2024, Hin Wang Lin et al. proposed a multi-robot system architecture for nearshore underwater evidence search and retrieval tasks, involving surface and underwater collaboration, in their paper "Coastal Underwater Evidence Search System with Surface-Underwater Collaboration". This system consists of an Autonomous Surface Vessel (ASV), a towed underwater vehicle (TUV), and a biomimetic hexapod robot (BU-HEXA). The ASV serves as the surface mission control center, responsible for autonomous navigation, mission management, communication with shore-based base stations, and the deployment and retrieval of underwater equipment. The TUV, towed by the ASV, conducts large-scale underwater searches of the target area, collecting underwater images and environmental data, and identifying potential regions of interest using target detection algorithms. The BU-HEXA performs close-range, detailed inspections of key areas discovered by the TUV, utilizing its stable movement capabilities in complex seabed topography to complete target confirmation, marking, or retrieval operations.

[0009] In summary, existing research on air-sea cross-domain networks mainly focuses on optimizing single communication links, executing local tasks, offloading computations, or controlling platforms. It has not yet fully established a multi-domain collaborative scheduling mechanism for the entire process of marine missions, encompassing air-space, surface, and underwater environments. In particular, it has neglected the impact of the core constraint of intermittent coverage of surface gateways by low-orbit satellites on the end-to-end completion latency of cross-domain missions. Therefore, it is necessary to propose a whole-process scheduling method that can uniformly coordinate AUV mission execution, gateway data caching, and satellite window uploading. Summary of the Invention

[0010] To address the issue that existing research on air-sea cross-domain networks often focuses on optimizing single communication links, executing local tasks, offloading computations, or controlling platforms, and has not yet fully established a multi-domain collaborative scheduling mechanism covering the entire process of marine missions, this invention proposes a cross-domain collaborative scheduling method based on satellite window awareness in air-sea cross-domain networks.

[0011] This invention addresses an air-sea inter-domain network comprised of low-Earth orbit (LEO) satellites, surface gateways, and autonomous underwater vehicles (AUVs). Due to their mobility, LEO satellites provide intermittent coverage of the surface gateway; during coverage periods, the gateway can transmit data back via satellite links. The surface gateway, acting as an inter-domain coordinator, receives verification tasks for the target area, schedules AUVs to perform these tasks, caches the verification results returned by the AUVs, and uploads data within the satellite coverage window. AUVs, following the scheduling instructions of the surface gateway, travel to the target area to perform patrol, detection, or data acquisition tasks, and return to the surface gateway to submit the verification results upon completion.

[0012] The technical problem to be solved by this invention is: under the conditions that the low-orbit satellite coverage of the surface gateway is intermittent, the window duration is limited, and the upload capacity is limited, how to enable the surface gateway to simultaneously consider the AUV execution process, the gateway cache status, and the low-orbit satellite coverage window status when scheduling AUVs to perform target area verification tasks, thereby reducing the end-to-end completion latency of the verification task from generation, AUV execution, result return to satellite backhaul completion.

[0013] To achieve the above-mentioned technical objectives and effects, the present invention is implemented through the following technical solution:

[0014] A cross-domain cooperative scheduling method based on satellite window awareness in an air-sea cross-domain network, comprising a surface gateway, low-Earth orbit satellites, and a group of autonomous underwater vehicles (AUVs), wherein the surface gateway acts as a cross-domain coordinator, used to schedule AUVs to perform target area verification tasks and upload cached data within a window covered by low-Earth orbit satellite signals; the method includes the following steps:

[0015] S1, the surface gateway observes and obtains the current scheduling status, which includes information on tasks to be scheduled, AUV status information, gateway cache status information, and the coverage window status of future low-orbit satellites;

[0016] S2, the surface gateway predicts the cross-domain execution consequences of the candidate scheduling action consisting of the task to be scheduled and the AUV; the cross-domain execution consequences include at least the time when the AUV is expected to return to the surface gateway, the time when the verification result data enters the gateway cache, the low-orbit satellite window that can upload the verification result data, the window waiting time, and the time when the upload is expected to be completed.

[0017] S3, the surface gateway performs feasibility screening on candidate scheduling actions based on AUV energy constraints, AUV task queue constraints, gateway buffer constraints, and low-orbit satellite coverage window capacity constraints, and obtains a set of candidate actions;

[0018] S4, the water surface gateway scores each candidate scheduling action based on the cross-domain execution consequences of each candidate scheduling action in the candidate action set, and selects one scheduling action to execute.

[0019] S5, the surface gateway dispatches the corresponding AUV to perform the target area verification task according to the selected scheduling action; after the AUV completes the verification and returns to the surface gateway, the gateway receives and caches the verification data, and determines the time to transmit the data back according to the low-orbit satellite coverage window status; if the remaining capacity or time of the current window is insufficient to complete the upload, the data is kept in the cache and postponed to the next window that meets the conditions for upload.

[0020] S6. Update the status of the task to be scheduled, the AUV status, the gateway cache status, and the remaining capacity of the low-orbit satellite visible window based on the execution result of the scheduling action, so as to be used for subsequent scheduling decisions.

[0021] Preferably, the aforementioned low-orbit satellite coverage window status includes: the start time, end time, duration, remaining upload capacity, and assigned tasks for each future window; the status of the tasks to be scheduled includes the target area location, task generation time, task data volume, and task type; the AUV status includes the AUV's current location, remaining energy, earliest available time, communication link quality, and current task queue length; and the gateway cache status includes the number of verification results waiting to be uploaded, remaining cache capacity, and cache occupancy ratio.

[0022] Preferably, the specific method for predicting the cross-domain execution consequences in step S2 above is as follows:

[0023] S21, based on the target area location, the current location of the AUV, the AUV execution speed, and the task verification time, predict the time when the AUV will arrive at the target area and the time when it will return to the surface gateway;

[0024] S22, Based on the estimated time when the AUV returns to the surface gateway, estimate the estimated time when the verification result data will enter the gateway cache;

[0025] S23. Based on the estimated time when the verification result data enters the gateway cache, the queuing status of existing data in the gateway cache, and the low-orbit satellite coverage window status, estimate the timing when the data can be connected to the satellite signal backhaul data.

[0026] S24, based on the satellite backhaul timing, calculate the satellite backhaul waiting time and the estimated time when the verification result data will be uploaded.

[0027] Preferably, when determining the timing of satellite backhaul, the surface gateway allocates data to windows in sequence according to the order in which the verification result data enters the cache and the remaining upload capacity of the satellite window; if the current window cannot accommodate the data, the data is reserved for the subsequent window that meets the conditions.

[0028] Preferably, in step S3 above, the candidate scheduling action must simultaneously meet the following conditions to pass the feasibility screening:

[0029] S31, After the selected action is executed, the remaining energy of the AUV performing the task is not lower than the preset safe energy threshold;

[0030] S32, after the selected action is executed, the length of the AUV task queue for the task to be executed shall not exceed the preset queue limit;

[0031] S33, After the verification result data enters the gateway cache, the gateway cache usage shall not exceed the preset cache limit;

[0032] S34, based on the low-orbit satellite coverage window status, can determine at least one satellite backhaul window that meets the upload conditions for the verification result data.

[0033] Preferably, when scoring candidate scheduling actions in step S4 above, at least the expected end-to-end completion delay, expected energy consumption, satellite backhaul waiting time, and waiting time caused by missing the window are considered; wherein, the end-to-end completion delay is the total time from the time the target area verification task is generated to the time when the verification result data is uploaded via the low-orbit satellite link; the risk of missing the satellite backhaul window is determined based on the expected time when the verification result data enters the gateway cache, the end time of the current satellite backhaul window, the remaining upload capacity of the current satellite backhaul window, and the existing waiting upload data in the gateway cache, and is used to characterize the possibility that the verification result data will be postponed to a subsequent satellite backhaul window because it failed to catch up with the current satellite backhaul window.

[0034] Preferably, the scheduling cost of the above-mentioned candidate scheduling actions is calculated using state-related adaptive soft constraint weights. The adaptive soft constraint weights are generated from the current scheduling state and dynamically adjust the relative impact of the expected end-to-end completion delay, expected AUV energy consumption, satellite backhaul waiting time, and satellite backhaul window miss risk in the scheduling action score based on the task load, AUV remaining energy status, gateway cache occupancy status, and low-orbit satellite coverage window status.

[0035] Preferably, the current scheduling action includes discrete scheduling decision and continuous control decision. The discrete scheduling decision is used to determine the target area verification task to be scheduled and the AUV to execute the task. The continuous control decision is used to determine the AUV dispatch delay and the AUV execution speed factor.

[0036] Preferably, the aforementioned surface gateway models the cross-domain collaborative scheduling process as a Markov decision process and acts as a scheduling agent. It selects scheduling actions based on the current scheduling state, obtains reward feedback based on the end-to-end completion delay, AUV energy consumption, satellite backhaul waiting time, and upload completion result after the scheduling action is executed, and updates the scheduling strategy based on the reward feedback. The reward feedback includes a negative reward for end-to-end completion delay, an AUV energy consumption penalty, and a satellite backhaul window miss penalty.

[0037] Preferably, the above scheduling strategy is updated using a near-end policy optimization framework, which jointly optimizes the policy loss, value loss, policy entropy regularization term, and adaptive soft constraint weight regularization term; the surface gateway uses a state-conditional attention aggregation mechanism to encode a dynamically sized set of candidate actions to obtain a fixed-dimensional candidate action context vector, and inputs the candidate action context vector into the value network to estimate the long-term benefits of the current scheduling state.

[0038] Compared with the prior art, the present invention has the following beneficial effects:

[0039] First, this invention incorporates the AUV mission execution process, gateway caching process, and low-orbit satellite backhaul process into a unified scheduling link, enabling the surface gateway to assess the return time of the verification data and its corresponding satellite backhaul timing in advance when dispatching AUVs, thus avoiding excessively long total end-to-end delays caused by scheduling based solely on AUV distance, energy, or local execution time.

[0040] Second, by sensing the coverage window status of low-orbit satellites, the present invention enables the surface gateway to sense the time location, duration, and remaining upload capacity of the satellite backhaul window; when the verification data cannot be uploaded within the current window, the gateway retains it in the cache and postpones it to the subsequent window that meets the conditions, thereby more accurately depicting the impact of intermittent satellite backhaul links on task completion delay.

[0041] Third, by predicting the consequences of cross-domain execution and screening candidate actions, this invention eliminates candidate actions that do not meet the conditions of AUV energy, AUV queue, gateway cache, or satellite backhaul before scheduling, thereby reducing invalid scheduling decisions and improving the physical feasibility and strategy search efficiency of the scheduling process.

[0042] Fourth, this invention enables the scheduling strategy to dynamically balance end-to-end completion latency, AUV energy consumption, and satellite backhaul waiting time based on the current task load, AUV resource status, gateway cache pressure, and satellite coverage window status, thereby improving the adaptability of air-sea cross-domain collaborative scheduling under different operating conditions. Attached Figure Description

[0043] Figure 1 A schematic diagram of the system architecture and a single collaborative process of an air-sea cross-domain network;

[0044] Figure 2 This is a flowchart illustrating the cross-domain collaborative scheduling method based on satellite window perception in an air-sea cross-domain network. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0046] This embodiment addresses a marine pollution location verification scenario, considering an air-sea cross-domain network. The system includes a shore-based remote control center, LEO satellites (low-Earth orbit satellites), a surface cross-domain gateway, an underwater AUV cluster, and an underwater sensor network. The LEO satellites operate at an altitude of approximately 500 to 1200 kilometers, providing intermittent coverage over the target sea area. The available window for each coverage of the surface gateway lasts approximately 5 to 10 minutes, with intervals of more than 30 minutes between adjacent coverage windows, and varies periodically due to orbital operation and coverage geometry. The elevation angle between the satellite and the surface gateway... When, where θ min This represents the minimum communicable angle formed by the line connecting the satellite and the gateway with sea level as the baseline, indicating that the satellite is considered to be in a coverage state.

[0047] like Figure 1 As shown, coarse-grained sensing methods such as underwater sensor networks and satellite remote sensing are used to detect suspected contaminated areas; the shore-based remote control center generates a pollution confirmation task based on the sensing results; the surface cross-domain gateway receives the task, schedules AUVs, caches verification data, and completes uplink transmission within the LEO coverage window; the AUVs are responsible for going to the target area to complete the specific location verification, and after the verification is completed, they deliver the results to the surface gateway.

[0048] The specific scheduling process in this embodiment is as follows. Figure 2 As shown, the specific steps include:

[0049] Step 1: Problem Modeling. The scheduling problem of cross-domain pollution verification tasks in the air and sea is modeled as a Markov decision process. The state space, action space, state transition function, and reward function are defined, with the optimization objective being to minimize the end-to-end completion delay of the verification task.

[0050] The Markov decision process is represented as:

[0051]

[0052] in For state space, For the action space, This is the state transition function. For the reward function, As a discount factor, the cross-domain gateway on the water surface acts as a scheduling agent at each decision-making moment. Observed system state Select scheduling action Subsequently, based on the energy consumption, task queue changes, gateway cache evolution, and LEO upload process during the specific execution of the AUV, it transitions to the next state. .

[0053] state space elements in For containing every decision moment All the necessary information, including the tasks to be scheduled, AUV running status, gateway cache status, and information about future LEO coverage windows, namely:

[0054]

[0055] in, This represents the set of tasks to be scheduled at the current gateway. Represents the set of states of the AUV cluster. Indicates the gateway cache status. This represents the set of LEO coverage windows visible from the current moment. For any AUV Its state vector is:

[0056]

[0057] in, , , , and They represent The location, remaining energy, earliest available time, communication link quality, and current task queue length. The gateway's cache state can be represented as:

[0058]

[0059] in This indicates the number of verification results waiting to be uploaded in the cache. Indicates the remaining cache capacity. This indicates the percentage of cache usage.

[0060] Elements in motion space Indicates the gateway at time The hybrid scheduling decision is made. The action simultaneously determines which task to execute, selects the AUV, determines the timing of dispatch, and the AUV's execution speed; therefore, it is defined as:

[0061]

[0062] discrete parameters This corresponds to a specific <task-AUV> combination and its window-aware prediction result. Continuous parameters... for:

[0063]

[0064] These are used to control scheduling delay and speed factor, respectively. Specifically, the continuous parameters have two effects: one is the scheduling delay from the current decision time to the actual dispatch time. :

[0065]

[0066] Second, the speed factor relative to the reference speed when the AUV is performing the current task. :

[0067]

[0068] The state transition function is:

[0069]

[0070] Its meaning is that the water surface gateway performs the action. The selected AUV is based on the velocity factor. After completing the process of traveling to the target area, conducting on-site inspections and verifications, and then returning to the gateway, the system consumes corresponding energy and updates its available time. Subsequently, the verification results are cached in the gateway and uploaded to the LEO within the subsequent LEO's coverage window. The entire task is then complete, and the status changes from [status from [status] to [status]]. Updated to .

[0071] The reward function is designed as follows:

[0072]

[0073] in This indicates the number of tasks or task weights associated with the decision step, used to reflect the impact of a single decision on the system load in a multi-task scheduling scenario; This indicates the end-to-end latency from the generation of the verification task to the final completion of the LEO upload by the gateway; This indicates the energy consumption of the AUV performing this task; This indicates penalties for missed uploads or failure to upload in a timely manner. and These are the time delay and energy consumption normalization constants, respectively; and Control the relative weights of energy consumption items and error penalty items in the rewards respectively.

[0074] Step 2: Constructing the candidate action space with window awareness. For each candidate task-AUV pairing, hard constraints are used to filter out inoperable actions that do not meet the energy threshold, window capacity, and queue limit. Explicit consequence estimation is then used to calculate the expected return time, execution energy consumption, LEO waiting time, and window miss risk for each candidate action. Candidate actions that meet the constraints and have predictable consequences are then used to construct a compact candidate space.

[0075] The candidate action space is the action space composed of action elements that meet the screening criteria after resource constraints have been applied to the original action space. Its resource constraints are:

[0076]

[0077] This constraint requires that the AUV's energy not fall below the safety threshold after the action is executed, the verification result can be uploaded within the available LEO window, and the AUV's load cannot exceed the upper limit, thus constructing a candidate space. for:

[0078]

[0079] Step 3: Adaptive Soft Constraint Policy Scoring and Action Sampling. State-related soft constraint weights are constructed to enable the policy to dynamically adjust its sensitivity to end-to-end latency, AUV energy consumption, and window miss risk based on the current system state (e.g., task load, AUV energy status, and LEO window urgency). Based on this, the soft constraint cost of each candidate action is calculated by combining its predicted consequences with the policy network's base preferences to form the final score. Actions are then executed according to the sampling distribution.

[0080] The state-related soft constraint weights are dynamically calculated based on the current task load, AUV energy status, and LEO window urgency.

[0081]

[0082] in, , , and These represent the end-to-end latency, energy consumption, LEO waiting time, and upload delay caused by missing the LEO coverage window, respectively, under the current state. Soft constraint weights do not directly delete candidate actions, but rather change the relative impact of different consequence items during the policy scoring process, thereby enabling the policy to form different scheduling preferences under different task loads, AUV resource states, and LEO coverage pressures.

[0083] The calculation method for soft constraint cost is as follows:

[0084]

[0085] in, and This is a normalization constant used to avoid different latency and energy consumption units directly affecting policy updates. Through this design, ASC-PPO does not fixate on classifying actions as good or bad, but rather dynamically adjusts the impact of latency, energy consumption, and window-related consequences on candidate actions based on the current state. For example, when the LEO coverage window is sparse or the task load is high, the policy can improve its response to... and The sensitivity to AUV energy is improved when the remaining AUV energy is low. The severity of the punishment.

[0086] The basic preference of the policy network is to use the description vector of each candidate action. Calculated candidate-level policy scores:

[0087]

[0088] in For candidate-level policy scoring functions, This indicates that the policy network, before undergoing soft-constraint modulation, is based on candidate representations. The given base score, and the description vector for each candidate action. It is an action description vector State transition caused by action The result of splicing and encoding:

[0089]

[0090] Among them, the action description vector The construction method uses a first-order method that includes information such as the corresponding AUV status, mission attributes, spatial distance, remaining energy, and queue status. A discrete candidate pair at time... Local description and continuous motion parameters :

[0091]

[0092] The state transition caused by the action The representation is as follows:

[0093]

[0094] in, Indicates the expected time when the verification results are returned to the gateway. This indicates the projected energy consumption for execution. This indicates the estimated LEO waiting time. This indicates the estimated time to complete the entire task. This indicates the risk of missing a window or having no service windows available.

[0095] The sampling distribution is as follows:

[0096]

[0097] Step 4: Policy Update. Based on the actual state transitions and reward feedback after action execution, a near-end policy optimization framework is used to update the policy network and value network, while also updating the soft constraint weight branches. This ensures that the scheduling policy continuously approaches the optimization objective of minimizing end-to-end latency during iteration.

[0098] The proposed near-end policy optimization framework employs a pruning objective and value function attention aggregation mechanism for updates, with the policy network updated using the PPO pruning objective.

[0099]

[0100] in This represents the estimation of the advantage function. Let be the pruning factor for PPO. To estimate the advantage function, this paper introduces a value function to estimate the long-term payoff of the current state and the candidate action space.

[0101] The value network update uses a reward objective calculated from the actual reward sequence. To supervise the value function, enabling the value network to approximate the long-term returns reflected by the actual sampled trajectory:

[0102]

[0103] The optimization objective is:

[0104]

[0105] in, This is the policy entropy regularization term, used to maintain necessary exploration; This is a soft-constraint weight regularization term used to prevent state-related weights from saturating prematurely or degenerating into fixed penalties; , and These are the coefficients for value loss, entropy regularization, and soft constraint regularization, respectively. Through this objective, the present invention simultaneously updates the discrete candidate selection branch, the continuous control branch, the value function, and the soft constraint weight branch.

[0106] In summary, the cross-domain collaborative scheduling method for satellite window awareness in the air-sea cross-domain network of this invention can incorporate the low-orbit satellite coverage window status into cross-domain scheduling decisions during the process of scheduling AUVs to perform target area verification tasks at the surface gateway. This allows the system to perceive the intermittent characteristics of the satellite backhaul link in advance and to jointly match the AUV return time with the low-orbit satellite backhaul window during the task execution phase, thereby reducing long waiting times caused by window misses. At the same time, through unified modeling and collaborative scheduling of the AUV execution process, the surface gateway caching process, and the satellite backhaul process, the verification result data can be orderly cached at the surface node and carried over to the coverage window that meets the conditions for uploading, improving satellite link utilization and reducing the overall latency of task completion.

[0107] It should be noted that steps 1 to 4 above are a specific elaboration of the core optimization mechanism of this invention. Specifically, the state observation and transition in step one corresponds to S1 and S6 in the specification; the consequence prediction and hard constraint screening in step two correspond to S2 and S3; the scoring decision in step three corresponds to S4; and step four and the state transition process correspond to S5 and S6. Those skilled in the art, in conjunction with this specific embodiment, can undoubtedly implement all the steps defined in the specification. The above description is merely a preferred embodiment of this invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of this invention, and these improvements and modifications should also be considered within the scope of protection of this invention.

Claims

1. A cross-domain cooperative scheduling method based on satellite window awareness in an air-sea cross-domain network, characterized in that, The air-sea cross-domain network includes a surface gateway, low-Earth orbit satellites, and a group of autonomous underwater vehicles (AUVs). The surface gateway acts as a cross-domain coordinator, used to schedule AUVs to perform target area verification tasks and upload cached data within a window of low-Earth orbit satellite signal coverage. The method includes the following steps: S1, the surface gateway observes and obtains the current scheduling status, which includes information on tasks to be scheduled, AUV status information, gateway cache status information, and the coverage window status of future low-orbit satellites; S2, the surface gateway predicts the cross-domain execution consequences of the candidate scheduling action consisting of the task to be scheduled and the AUV; the cross-domain execution consequences include at least the time when the AUV is expected to return to the surface gateway, the time when the verification result data enters the gateway cache, the low-orbit satellite window that can upload the verification result data, the window waiting time, and the time when the upload is expected to be completed. S3, the surface gateway performs feasibility screening on candidate scheduling actions based on AUV energy constraints, AUV task queue constraints, gateway buffer constraints, and low-orbit satellite coverage window capacity constraints, and obtains a set of candidate actions; S4, the water surface gateway scores each candidate scheduling action based on the cross-domain execution consequences of each candidate scheduling action in the candidate action set, and selects one scheduling action to execute. S5, the surface gateway dispatches the corresponding AUV to perform the target area verification task according to the selected scheduling action; after the AUV completes the verification and returns to the surface gateway, the gateway receives and caches the verification data, and determines the time to transmit the data back according to the low-orbit satellite coverage window status; if the remaining capacity or time of the current window is insufficient to complete the upload, the data is kept in the cache and postponed to the next window that meets the conditions for upload. S6. Update the status of the task to be scheduled, the AUV status, the gateway cache status, and the remaining capacity of the low-orbit satellite visible window based on the execution result of the scheduling action, so as to be used for subsequent scheduling decisions.

2. The cross-domain cooperative scheduling method with satellite window awareness in an air-sea cross-domain network according to claim 1, characterized in that, The status of the low-Earth orbit satellite coverage window includes: the start time, end time, duration, remaining upload capacity, and assigned tasks for each future window; the status of the tasks to be scheduled includes the target area location, task generation time, task data volume, and task type; the status of the AUV includes the current AUV location, remaining energy, earliest available time, communication link quality, and current task queue length; and the status of the gateway cache includes the number of verification results waiting to be uploaded, remaining cache capacity, and cache occupancy ratio.

3. The cross-domain cooperative scheduling method with satellite window awareness in an air-sea cross-domain network according to claim 1, characterized in that, The specific method for predicting the consequences of cross-domain execution in step S2 is as follows: S21, based on the target area location, the current location of the AUV, the AUV execution speed, and the task verification time, predict the time when the AUV will arrive at the target area and the time when it will return to the surface gateway; S22, Based on the estimated time when the AUV returns to the surface gateway, estimate the estimated time when the verification result data will enter the gateway cache; S23. Based on the estimated time when the verification result data enters the gateway cache, the queuing status of existing data in the gateway cache, and the low-orbit satellite coverage window status, estimate the timing when the data can be connected to the satellite signal backhaul data. S24, based on the satellite backhaul timing, calculate the satellite backhaul waiting time and the estimated time when the verification result data will be uploaded.

4. The cross-domain cooperative scheduling method with satellite window awareness in an air-sea cross-domain network according to claim 3, characterized in that, When determining the timing of satellite backhaul, the surface gateway allocates windows to each data in the order in which the verification result data enters the cache and the remaining upload capacity of the satellite window; if the current window cannot accommodate the data, the data will be reserved for a subsequent window that meets the conditions.

5. The cross-domain cooperative scheduling method with satellite window awareness in an air-sea cross-domain network according to claim 1, characterized in that, In step S3, candidate scheduling actions must simultaneously meet the following conditions to pass the feasibility screening: S31, After the selected action is executed, the remaining energy of the AUV performing the task is not lower than the preset safe energy threshold; S32, after the selected action is executed, the length of the AUV task queue for the task to be executed shall not exceed the preset queue limit; S33, After the verification result data enters the gateway cache, the gateway cache usage shall not exceed the preset cache limit; S34, based on the low-orbit satellite coverage window status, can determine at least one satellite backhaul window that meets the upload conditions for the verification result data.

6. The cross-domain cooperative scheduling method with satellite window awareness in an air-sea cross-domain network according to claim 1, characterized in that, In step S4, when scoring candidate scheduling actions, at least the expected end-to-end completion delay, expected energy consumption, satellite backhaul waiting time, and waiting time caused by missing the window are taken into account. The end-to-end completion delay is the total time from the time the target area verification task is generated to the time when the verification result data is uploaded via the low-orbit satellite link. The risk of missing the satellite backhaul window is determined based on the expected time when the verification result data enters the gateway cache, the end time of the current satellite backhaul window, the remaining upload capacity of the current satellite backhaul window, and the existing waiting upload data in the gateway cache. This is used to characterize the possibility that the verification result data will be postponed to a subsequent satellite backhaul window because it failed to catch up with the current satellite backhaul window.

7. The cross-domain cooperative scheduling method with satellite window awareness in an air-sea cross-domain network according to claim 6, characterized in that, The scheduling cost of the candidate scheduling action is calculated using state-related adaptive soft constraint weights. These adaptive soft constraint weights are generated from the current scheduling state and dynamically adjust the relative impact of expected end-to-end completion delay, expected AUV energy consumption, satellite backhaul waiting time, and risk of missing satellite backhaul window in the scheduling action score based on task load, AUV remaining energy status, gateway cache occupancy status, and low-Earth orbit satellite coverage window status.

8. The cross-domain cooperative scheduling method with satellite window awareness in an air-sea cross-domain network according to claim 1, characterized in that, The current scheduling action includes discrete scheduling decisions and continuous control decisions. The discrete scheduling decisions are used to determine the target area verification task to be scheduled and the AUV to execute the task. The continuous control decisions are used to determine the AUV dispatch delay and the AUV execution speed factor.

9. A cross-domain cooperative scheduling method with satellite window awareness in an air-sea cross-domain network according to claim 1, characterized in that, The surface gateway models the cross-domain collaborative scheduling process as a Markov decision process and acts as a scheduling agent. It selects scheduling actions based on the current scheduling state, obtains reward feedback based on the end-to-end completion delay, AUV energy consumption, satellite backhaul waiting time, and upload completion result after the scheduling action is executed, and updates the scheduling strategy based on the reward feedback. The reward feedback includes negative rewards for end-to-end completion delay, penalties for AUV energy consumption, and penalties for missing satellite backhaul windows.

10. The cross-domain cooperative scheduling method with satellite window awareness in an air-sea cross-domain network according to claim 11, characterized in that, The scheduling strategy is updated using a near-end policy optimization framework, which jointly optimizes the policy loss, value loss, policy entropy regularization term and adaptive soft constraint weight regularization term. The surface gateway uses a state-conditional attention aggregation mechanism to encode a dynamically sized set of candidate actions, obtaining a fixed-dimensional candidate action context vector. This candidate action context vector is then input into a value network to estimate the long-term benefits of the current scheduling state.

Images