An energy consumption perception task scheduling method for sea area serverless edge computing

Abstract

The application provides an energy consumption perception task scheduling method for sea area serverless edge computing, and belongs to the technical field of digital information transmission, and comprises a model training step, an online deployment step and an online scheduling step.The model training step comprises the following steps: constructing a task scheduling model, a communication transmission model, a queue state model, a container life cycle model and a computing processing energy consumption model; constructing an optimization target and a constraint condition; training the task scheduling model; the online deployment step is decentralized online inference based on local observation state, actionable set and action mask, and a task scheduling scheme comprising computing offloading, edge node selection and container keep-alive time level is obtained and executed.The method of the application determines the energy perception weight according to the residual power, and adaptively suppresses the excessive call to the low-power node.Through the establishment of the container life cycle model, unnecessary cold start is reduced, and repeated measurement of keep-alive energy consumption is avoided.

Description

Technical Field

[0001] This application relates to the fields of edge computing, serverless computing, and multi-agent reinforcement learning, and in particular to an energy consumption-aware task scheduling method for serverless edge computing in marine areas. Background Technology

[0002] With the development of marine environmental monitoring, maritime safety early warning, resource exploration, and collaborative applications of maritime equipment, maritime perception tasks are placing higher demands on low-latency, low-energy-consumption, and highly robust computing capabilities. Traditional centralized cloud computing solutions, due to their long backhaul distances and high transmission latency, are unable to meet the real-time response requirements of sudden maritime missions. Edge computing, by pushing computing power down to the network edge—such as unmanned surface vessels, offshore platforms, and shore base stations—can shorten the mission processing chain.

[0003] Serverless computing offers a novel approach to edge computing scenarios by launching function containers on demand, reducing manual maintenance, and improving resource elasticity. However, source nodes for tasks in the ocean typically rely on limited energy sources such as batteries for power, resulting in significant differences in remaining power among nodes. If scheduling is based solely on linear total energy consumption, nodes with low power levels may be over-utilized. Furthermore, serverless function containers exhibit both cold start and hot reuse characteristics. If the container keep-alive time is too short, frequent cold starts will incur significant latency costs; conversely, if the keep-alive time is too long, it will continuously consume edge resources and generate static standby power consumption.

[0004] Furthermore, maritime communication links are significantly affected by evaporation waveguides, multipath reflections, sea state changes, and node movement, resulting in time-varying link quality. Task scheduling needs to simultaneously consider the amount of task input data, task computation, remaining node power, edge node resources, function container state, and link quality, exhibiting multi-agent collaboration and partially observable characteristics. Existing solutions typically handle energy consumption awareness, container keep-alive, or collaborative offloading issues separately, lacking a unified modeling, joint optimization, and online deployment mechanism for serverless edge computing scenarios in maritime areas. Summary of the Invention

[0005] To address the challenges of task scheduling caused by the coupling of heterogeneous power supply to existing marine nodes, dynamic link quality fluctuations, serverless cold start latency, and container keep-alive energy consumption, this invention proposes an energy consumption-aware task scheduling method for serverless edge computing in marine areas, which can solve the aforementioned problems.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: An energy consumption-aware task scheduling method for serverless edge computing in marine areas includes a model training step, an online deployment step, and an online scheduling step. The model training step includes: Based on the pre-built serverless edge computing system in the sea area, a task scheduling model, a communication transmission model, a queue state model, a container lifecycle model, and a computing processing energy consumption model are constructed. The serverless edge computing system in the sea area includes multiple task source nodes and multiple edge nodes. Construct optimization objectives and constraints; Based on the task scheduling model, communication transmission model, queue state model, container lifecycle model, computing energy consumption model, optimization objective and constraints, the task scheduling process is modeled as a partially observable Markov decision process (POMDP), and the task scheduling model is trained using a multi-agent reinforcement learning method with centralized training and decentralized execution. The online deployment steps include deploying the local value network parameters, hidden state update rules, and action mask generation rules corresponding to each task source node to the task source node; In the online scheduling step, the task source node performs decentralized online reasoning based on the local observation status, the set of actionable actions, and the action mask to obtain a task scheduling scheme that includes computation unloading, edge node selection, and container keep-alive time levels, and then executes it.

[0007] Compared with existing technologies, the advantages and positive effects of this invention are as follows: First, the energy-aware task scheduling method for serverless edge computing in marine areas determines energy-aware weights based on remaining power, and adaptive weights suppress excessive calls to nodes with low power. Second, by establishing a container lifecycle model, cold start, hot container reuse, keep-alive energy consumption, and hot container resource occupation are incorporated into a unified model, reducing unnecessary cold starts and avoiding redundant metering of keep-alive energy consumption. Third, by modeling the task scheduling process as a partially observable Markov decision process (POMDP), the technical problem that each task source node can only directly obtain broadcast summaries of local tasks, local queues, local remaining power, and reachable edge nodes, and cannot fully observe all edge queues, all task record tables, and all container lifecycle states is solved. Fourth, a multi-agent reinforcement learning architecture with centralized training and decentralized execution, namely the QMIX framework, is adopted: in the centralized training phase, a hybrid network can be trained using global state, joint actions, and global rewards; in the online execution phase, each task source node only uses its own local observations, local hidden states, local value networks, and action masks for action selection. The value of the joint action remains monotonic relative to the value of any local action. Therefore, within the set of candidate actions that satisfy the action mask, each task source node can achieve decentralized action selection that is compatible with maximizing the value of joint actions by maximizing the value of local actions, thereby improving the online scheduling adaptability in dynamic marine environments.

[0008] Other features and advantages of the present invention will become clearer after reading the detailed description of the embodiments of the present invention in conjunction with the accompanying drawings. Attached Figure Description

[0009] Figure 1 A flowchart of an embodiment of the energy consumption-aware task scheduling method for serverless edge computing in marine areas provided in this application; Figure 2 This is a schematic diagram of the architecture of a serverless edge computing system in the sea area according to an embodiment of this application; Figure 3 This is a schematic diagram of the state transition of the function container in an embodiment of this application; Figure 4 This is a schematic diagram of a multi-agent reinforcement learning algorithm based on a centralized training and decentralized execution architecture, according to an embodiment of this application. Figure 5 This is a schematic diagram of the online scheduling, action masking, and status write-back process in an embodiment of this application; Figure 6 This is a schematic diagram of the energy consumption sensing task scheduling device according to an embodiment of this application. Detailed Implementation

[0010] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

[0011] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0012] Example 1, as Figure 1 and Figure 2 As shown, this embodiment is oriented towards a serverless edge computing system in the ocean area, consisting of multiple task source nodes and multiple edge nodes. The task source nodes can be microbuoys, drones, unmanned surface vessels (USVs) with onboard sensors, or other nodes with ocean perception capabilities but limited computing and power supply; the edge nodes can be USVs, offshore operation platforms, shore base stations, or other nodes that provide edge computing capabilities and a serverless function container runtime environment.

[0013] In this application, the task source node refers to the node that generates the marine perception task and participates in online scheduling decision-making; the edge node is the node that provides serverless function container execution capability; the container keep-alive time level refers to the duration level for which the corresponding function container continues to maintain a reusable idle hot state after the task is completed; the idle hot container state refers to a function container that is not in the cold start process and has not executed a task, but can be directly reused.

[0014] like Figure 1 As shown, the method in this embodiment generally includes model building, optimization problem construction, policy training, online deployment, and online scheduling. The following is combined with... Figures 2 to 5 Each section describes the system scenario, task model, communication and queue model, container lifecycle model, energy consumption model, POMDP modeling, and online scheduling process.

[0015] In some embodiments, the set of task source nodes is denoted as... The set of edge nodes is denoted as The set of function types is denoted as The set of discrete time slots is denoted as .in, , , and represents the set size; n, m, f, and t represent the task source node index, edge node index, function type index, and time slot index, respectively. This embodiment uses discrete time slots as the system state update period, with a time slot length of . Within each time slot, tasks are generated, scheduled, transmitted, and processed. After the time slot ends, the queue status, container lifecycle status, and remaining node power are updated.

[0016] Define task arrival indicator variables ,when At that time, the task source node A task to be scheduled is generated in time slot t; when When this time slot is specified, it indicates that no new task was generated by that node in that time slot, and the input data volume and computation volume of the corresponding task are set to 0. For The task can be represented as ,in, For the amount of input data, It is a function type. For task computation, To meet the data storage requirements of the task, This represents the maximum allowable completion delay. (Task computation load) Determined according to the following formula: .

[0017] in, Indicate function type The corresponding computational density coefficient, in units of CPU cycles / bit, is then The unit is CPU cycle.

[0018] In some embodiments, the task scheduling model includes calculating unloading decision variables. Edge node selection decision variables and container survival time level decision variables ,in This indicates that the task will be executed locally. This indicates that the task will be unloaded and executed. Choose variables for edge nodes. Indicates the task source node The generated tasks are assigned to edge nodes. implement, This represents the container keep-alive time level corresponding to the task assigned to edge node m; each variable satisfies the coupling relationship between edge node selection and unloading decision, as well as the coupling relationship between container keep-alive time level and edge node selection.

[0019] Task source node In the time slot The local action is represented as ,in, Number the target edge nodes. Set the container keep-alive time level. Given the preset maximum container survival time level, the value ranges of the above three variables are as follows:

[0020] .

[0021] This indicates local execution. and . This indicates that the uninstallation process will be executed. .

[0022] When the task source node n does not generate a task to be scheduled in time slot t, only idle actions are recorded, and no candidate unloading actions are selected. At that time, the task source node This does not trigger local execution, computation unloading, edge node selection, or container keep-alive time-level decisions. To maintain consistency in POMDP state transition samples, previous time-slot action records, and action mask input formats, this situation can be recorded as an idle action or no-operation action in the algorithm record. The idle action does not incur additional task computation, transmission energy consumption, local execution energy consumption, edge execution energy consumption, or task latency exceeding limits.

[0023] Select variables by defining edge nodes Keep-alive level variables associated with edge nodes This can facilitate resource constraints and energy consumption measurement.

[0024] .

[0025] From the above formula, we can see that This indicates that the task has been assigned to an edge node. ; Only when the task is unloaded to the edge node Effective immediately. The above variables satisfy the following action coupling constraints: .

[0026] The above formula indicates that when the task is executed locally, no edge nodes are selected and the keep-alive level is 0; when the task is unloaded and executed, only one edge node is selected. The container keep-alive duration is obtained by mapping the keep-alive time level: .

[0027] when hour, and Only when and hour, This indicates the keep-alive time for the corresponding function container after the task is completed. The keep-alive level only applies to the target function container after the unloading task is completed.

[0028] In some embodiments, to prevent cross-slot tasks from using the function type or keep-alive level of the new task in the current slot for erroneous write-back, edge nodes... Maintenance Task Log The task record index is denoted as... Each record must include at least the task source node number. Record function type Input data volume Task storage requirements , Joining time Remaining computational load Record the survival level and task status Task statuses include queued, booting, executing, and finished.

[0029] When the task source node In the time slot Select Unload to Edge Node At that time, edge nodes Add a record And order: .

[0030] The above formula ensures that when a task executed across time slots is completed, the completion event judgment, keep-alive timer write-back, and resource release are still performed according to the function type and keep-alive level recorded when it was enqueued.

[0031] In some embodiments, the communication transmission model includes a computing task source node. With edge nodes In the time slot Channel gain : .

[0032] in, This represents the linear domain channel gain at the reference distance. Indicates the task source node With edge nodes The distance between them This represents the path loss index. This represents the correction factor for the evaporation waveguide. This represents the small-scale fading component. It can be estimated from environmental parameters such as sea surface temperature, humidity, wind speed, and propagation altitude, or it can be corrected by edge nodes based on pilot or link measurement feedback and then broadcast to reachable task source nodes.

[0033] According to the channel gain Calculate the uplink transmission rate : .

[0034] in, Indicates bandwidth allocation. Indicates the transmission power. Represents the noise power spectral density. This represents noise power.

[0035] The transmission delay and transmission power consumption can also be calculated based on the uplink transmission rate: .

[0036] when Below the preset link rate threshold, or edge nodes Not a task source node The set of reachable edge nodes At that time, the corresponding unloading action is set as an invalid action in the action mask.

[0037] In some embodiments, the queue state model includes task source nodes. In the time slot Initial local queue pending workload and edge queue pending workload The unit is CPU cycle. At the end of each time slot, the workload pending in the local queue and the workload pending in the edge queue are updated according to the computational workload of newly added tasks, the computational workload already served, and the processing capacity of the corresponding nodes.

[0038] The update method for local queue updates is as follows: Calculate the total latency of the task's local execution: ; in, For task computation, For task source node The local effective processing frequency, measured in CPU cycles / s. This represents the time slot length.

[0039] Update the local queue: ; in, To determine the actual local service computation volume, the local queue and energy consumption can be updated in a closed loop according to the actual execution process. The calculation method is as follows: .

[0040] The above-mentioned local actual service computation is used for subsequent local execution energy consumption calculations. For the specific energy consumption model, please refer to the calculation and processing energy consumption model section below.

[0041] The update method for the edge queue is as follows: .

[0042] in, This indicates that the task record is allocated to the actual service computation in the current time slot.

[0043] The above formula avoids prematurely deducting the workload of the edge queue during the cold start waiting period or when the queue is empty. Definition For edge nodes Storage usage for data already transmitted but not yet completed has been updated as follows: .

[0044] By updating queues, containers, and power status in a time-slot manner, the model possesses a reproducible state transition closed loop; the action mask rules will be uniformly explained in the subsequent POMDP modeling and online scheduling sections.

[0045] To ensure that cold start energy consumption measurement is consistent with the time-slot-by-time energy update process, a function type is defined to represent the actual cold start duration occurring within a time slot at the edge node. This variable is only used to calculate the cold start energy consumption of the current time slot and does not represent the waiting delay for a complete cold start of the task; the specific energy consumption formula is uniformly described in the energy consumption calculation model below.

[0046] When multiple tasks are assigned to the same edge node in the same time slot, the service order is determined based on the task arrival time, priority, or node number, and the computational workload of the task that is ranked first is included in the additional waiting workload of the task that is ranked later.

[0047] For cases where multiple tasks are assigned to the same edge node within the same time slot, the service order can be determined based on the task arrival time, task priority, or node number, and the additional computational load of the task ranked first can be used as the additional waiting load of the task ranked later; the available waiting time for containers is determined according to three scenarios: idle hot container, cold start, and cold state.

[0048] Combining local execution latency and edge execution latency, the task The total latency is: .

[0049] To prevent edge queues from being prematurely depleted during cold start waiting periods, define task records. In the time slot From edge nodes Actual service computing volume It satisfies: .

[0050] When task record While still in a cold start waiting state, before reaching the head of the queue or obtaining execution resources, order The remaining computation time in the task record is updated according to the actual service volume: .

[0051] definition This indicates the task completion indicator variable, i.e., the task record. In the time slot Execution complete: .

[0052] In some embodiments, the container lifecycle model includes a container keep-alive timer corresponding to the function type on the edge node, a task start execution indicator variable, a task completion indicator variable, and a hot container status indicator variable. When there is a service request for the corresponding function type on the edge node, and there is no idle reusable hot container for the corresponding function type, it is not in the cold start process, and it is not in the execution process, a cold start is triggered. When the task is completed, the container keep-alive timer is written back according to the container keep-alive time level recorded in the task scheduling scheme. When no task of the same function type is completed on the corresponding edge node, the container keep-alive timer decreases with time slots. When the container keep-alive timer reaches zero, the resources occupied by the corresponding container are released, and the hot container status is set to cold state.

[0053] like Figure 3 As shown, the lifecycle states of the function container in this embodiment include cold state, cold start state, execution state, and idle hot state. The states transition between each other based on service requests, cold start completion, task execution completion, and the expiration of the keep-alive time.

[0054] To distinguish between "requesting service", "starting execution", and "completing execution", define: Represents task record In the time slot Located at the edge node The service team leader requests a container of the corresponding function type. Edge nodes function type The request service indicator variable is: .

[0055] definition Define the remaining keep-alive timer for idle hot containers after the task is completed; For edge nodes function type In the time slot An indicator variable indicating whether it is in the execution process. Represents edge nodes function type In the time slot In the process of task execution, otherwise Idle reusable hot container state. Represented as: .

[0056] The above formula clearly defines that idle hot containers are mutually exclusive with cold-start and execution states, avoiding the classification of containers that are currently executing or undergoing cold start as idle reusable hot containers. Cold start state variables. Represented as: .

[0057] A cold start is triggered only when there are no idle hot containers, it is not in the cold start process, it is not in the execution process, and there are service requests. (Definition) For cold start trigger indicator variables: .

[0058] Cold start remaining time Updated to: .

[0059] To describe the situation where the function container can be immediately used for task execution after a cold start, a cold start completion indicator variable is defined. and the executable state of function containers .in, Represents edge nodes function type The cold start process in time slots Completed within the time limit; This indicates that the corresponding function container is available for task execution in the current time slot. The expressions are as follows: .

[0060] .

[0061] definition For edge nodes Task records on In the time slot An indicator variable indicating whether execution has begun. The conditions for a task record to begin execution are: the task record is at the head of the service queue, the function container of the corresponding function type is in an executable state, and the edge node has allocated actual execution resources to it, represented as: .

[0062] In the formula, This indicates that the task record is allocated to the actual service computation in the current time slot.

[0063] edge nodes function type Execution status Determined based on actual service volume: .

[0064] definition Represents edge nodes Function types on In the time slot If at least one task record has been completed, the aggregate completion event is used to trigger the write-back of the keep-alive timer for the corresponding function type. Its expression is: .

[0065] definition The keep-alive level recorded when a task is enqueued or scheduled is represented as: .

[0066] If the set in the above formula is empty, then let .

[0067] definition This indicates the remaining keep-alive time for the idle hot container after the task is completed. To avoid multiple states occurring simultaneously—task completion, cold start, execution, and keep-alive decreasing—this embodiment updates the keep-alive timer in the following order: task completion first, cold start and execution second, and idle keep-alive decreasing last.

[0068] If multiple tasks of the same function type complete in the same time slot, then Take the maximum value among the keep-alive levels of each completed task record. When the keep-alive timer reaches zero and the function type is not in a cold start or execution process, release the resources occupied by the corresponding idle hot container and set it to a cold state.

[0069] The container lifecycle state machine includes a cold state, a cold start state, an execution state, and an idle / hot state. Cold start is triggered based on function container service requests and idle / hot container status checks, while the keep-alive timer is written back based on task completion events. For containers in the cold start or execution process, their resource occupancy status is recorded by cold start and execution state variables and is not released when the keep-alive timer reaches zero. The keep-alive timer primarily describes the reusable retention time of idle / hot containers after task completion. For tasks executed across time slots, edge nodes record the function type when the task is enqueued. and survival level When the task is completed in a subsequent time slot, according to the record... and Determine completion events, keep-alive timer write-back values, and container resource states to avoid replacing historical task records with the function type or keep-alive level of the new task in the current time slot.

[0070] In some embodiments, the computational processing energy consumption model includes edge nodes. Service energy consumption and task source node In the time slot Service energy consumption .

[0071] Energy consumption of edge node m service for: ; in, Energy consumption for edge execution The cold start energy consumption of function type f on edge node m, aggregated and measured according to the cold start process within time slot t. To ensure energy consumption, the following are: ; ; .

[0072] Let m be the equivalent energy consumption coefficient of the edge node. Represents edge nodes The equivalent service frequency, This refers to cold start power. To maintain the power of idle hot containers, Function type At the edge node Above the time slot The actual cold start duration that occurs within the timeframe. A collection of function types This indicates that the task record is allocated to the actual service computation in the current time slot.

[0073] The idle reusable hot container state of the function type on the edge node in the time slot follows the definition of the aforementioned container lifecycle model, and will not be repeated here.

[0074] Task source node In the time slot energy consumption for: .

[0075] For tasks from the task source node Transmitted to edge nodes Transmission energy consumption, For task source node The local execution energy consumption is calculated as follows: .

[0076] For task source node The equivalent energy consumption coefficient.

[0077] node The remaining battery level is updated as follows: .

[0078] In the above formula, The remaining power of the node. For battery capacity, This represents the actual energy consumption of the node. For optional energy replenishment; in scenarios where energy replenishment is not available. .when hour, ;when hour, .

[0079] In some embodiments, the step of constructing the optimization objective and constraints also includes computing nodes. Normalized remaining power and according to Calculate energy-sensing weights : ; .

[0080] in, As the benchmark weight, The energy sensitivity coefficient, As a stable term, This represents the upper limit of the weight.

[0081] To characterize the extent to which the task completion delay exceeds the maximum allowable completion delay, a task source node is defined. The slack variable for task delay exceeding the limit in time slot t When the task source node In the time slot When no tasks are generated to be scheduled, When the task source node In the time slot When generating tasks to be scheduled, Used to characterize the total task completion delay Exceeding the maximum allowed completion delay The part. When hour, And there is a corresponding relationship: .

[0082] Normalized single-slot cost function for: ;

[0083] in, and For reference energy scale, For the dimensionless delay violation penalty weight, For task arrival indicator variables, when When, it indicates the task source node. In the time slot Generate a task to be scheduled, which is represented as , The amount of input data; It is a function type. For task computation, To meet the data storage requirements of the task, To the maximum allowable completion delay, when When the time slot is specified, it indicates that no new tasks were generated by that node in that time slot. For task source node In the time slot Task delay exceeding the limit slack variable, when hour, ,when hour, .

[0084] The optimization objective is: .

[0085] In the above formula, This represents the set of all task latency slack variables.

[0086] In some embodiments, the constraints include at least action coupling constraints, edge node computing resource constraints, edge node bandwidth resource constraints, edge node storage resource constraints, remaining power constraints of task source nodes and edge nodes, and task latency threshold constraints with slack variables.

[0087] Action coupling constraints are: .

[0088] in, Associate keep-alive level variables with edge nodes. This represents the maximum container keep-alive time level.

[0089] The computational resource constraints for edge nodes are: .

[0090] in For edge nodes The amount of work pending in the queue, For edge nodes The maximum processing capacity of the queue.

[0091] The bandwidth resource constraints for edge nodes are: .

[0092] in, Represents edge nodes In the time slot The allocable uplink bandwidth resource limit is used to constrain the bandwidth resource usage when the same edge node receives multiple offload tasks.

[0093] The storage resource constraints for edge nodes are: .

[0094] in, Represents edge nodes Data from tasks that have been transmitted but not yet completed is being used. This represents the mirror image of function type f and its runtime resource consumption. Represents edge nodes Total available storage capacity.

[0095] The remaining power constraints for the task source node and edge node are as follows: .

[0096] The task delay threshold constraint containing slack variables is: .

[0097] .

[0098] For the task Total latency.

[0099] After completing the modeling of task scheduling, communication transmission, queue state, container lifecycle, energy consumption, optimization objective, and constraints, the task scheduling process is further modeled as a partially observable Markov decision process (POMDP). Since each task source node can only directly obtain the broadcast summary of its local task, local queue, local remaining power, and reachable edge nodes, and cannot fully observe all edge queues, all task record tables, and all container lifecycle states, this scheduling process belongs to a partially observable multi-agent decision process.

[0100] In some embodiments, the POMDP model created based on the task scheduling process is as follows: .

[0101] in, For the global state space, For task source node Local observation space, For task source node Local action space, This is the state transition function. For the reward function, , where is the discount factor. If finite-time training is used, You can also choose 1.

[0102] In the time slot global state It includes at least the task queue status, queue status, task record status, link speed status, node power status, edge node resource status, and container lifecycle status, represented as: ; in, This indicates the task has reached its completion status. This indicates the local queue status. This indicates the edge queue status. For edge nodes Maintain the task log table. Indicates the node's battery status. Indicates the link rate status. This indicates the resource status of edge nodes, including edge computing resource status, bandwidth status, and storage status. It represents the lifecycle state of the function container.

[0103] In some embodiments, .

[0104] In the above formula, For edge nodes function type The remaining keep-alive timer for the idle hot container, Remaining time for cold start In the cold start state, In the execution state, This is an idle, reusable thermal container. This represents the executable state of the function container. This state, along with the aforementioned queues, containers, and power update rules, collectively ensures a closed-loop state transition mechanism in the POMDP.

[0105] Task source node In the time slot Local observation It consists of locally available information and edge node broadcast digests, and is represented as: ; For task source node The set of reachable edge nodes, , representing a summary of reachable link rates, This represents a summary of the computing, bandwidth, and storage resources broadcast by reachable edge nodes. This represents a summary of remaining battery power broadcast by reachable edge nodes. This represents the hot container and cold start summary broadcast by reachable edge nodes. This indicates the action in the previous time slot; local observation does not require the task source node to obtain the complete task record table of all edge nodes.

[0106] Local actions of task source node n in time slot t Represented using triples: .

[0107] in, For task source node In the time slot The target edge node number for task unloading. For task source node In the time slot The container keep-alive time level. The mapping between actions and edge node selection variables, and keep-alive level variables is as follows: .

[0108] At the task source node Set an idle action when no new tasks are generated. When generating tasks, the candidate action space can be written as: .

[0109] In the above formula, Used to indicate idle actions when a task has not yet been completed. Indicates local execution. Indicates unloading to the edge node And select the survival level. .when At that time, the action mask only retains ;when Idle actions are invalid.

[0110] To avoid mixing constraints for locally executed actions and unloaded actions, this embodiment defines separate sets of locally feasible actions and unloaded feasible actions. The feasibility condition for locally executed actions is: .

[0111] In the above formula, For task source node The lower limit of remaining battery power. This represents the upper limit of the allowed delay relaxation during the action pre-screening stage. This represents the maximum capacity of the local queue. The conditions for the unloading action to be feasible are: .

[0112] In the above formula, This is the link rate threshold. The estimated energy consumption of edge nodes for the action pre-screening stage. , and Representing edge nodes respectively The remaining computing, bandwidth, and storage resources obtained through broadcasting or secondary verification. , , and These represent the estimated computing resources, bandwidth, storage, and edge completion latency for the candidate offloading action, respectively.

[0113] Based on the above, obtain the task source node. Effective action set and action mask They are respectively: ; ; To the task source node Idle actions when no new tasks are generated. For task source node The set of local actionable actions For task source node The set of uninstallable actions. Indicates action .

[0114] Used for online motion pre-screening. Candidate actions are not selected during the training and online phases. Before actual execution, the target edge node can perform a secondary verification based on edge node computing, bandwidth, storage, power consumption, and container resource constraints. If the secondary verification fails, a rollback action is executed or a new candidate action is selected.

[0115] When the task source node In the time slot When no scheduled tasks are generated, only idle actions are recorded, and no candidate unloading actions are selected. This record is only used to maintain the consistency between the training samples and the action input of the previous time slot, and does not represent the execution of local computation tasks.

[0116] POMDP state transitions are determined by the aforementioned rules for communication transmission, task queuing, actual service volume allocation, task completion judgment, cold start remaining time update, container keep-alive timer update, storage usage update, and power update.

[0117] Get joint actions ; The reward function takes the negative of the normalized single-slot cost and applies additional penalties for constraint violations caused by secondary check failures or rollback actions to obtain the global reward. for: ; in, Indicates the task source node Does it trigger a rollback action? This indicates whether the action results in a constraint violation under edge-side secondary verification or random disturbance. and This is a non-negative penalty coefficient. When using this reward function, minimizing the long-run cumulative cost is equivalent to maximizing the long-run cumulative reward.

[0118] Use global state Joint actions and global rewards A centralized training hybrid network is used.

[0119] like Figure 4 As shown, this embodiment employs a multi-agent reinforcement learning architecture with centralized training and decentralized execution, namely the QMIX framework: the global state can be used during the centralized training phase. Joint actions and global rewards The hybrid network is trained; during the online execution phase, each task source node selects actions using only its own local observations, local hidden states, local value networks, and action masks.

[0120] By employing a multi-agent learning framework that combines centralized training with decentralized execution, the online scheduling adaptability in dynamic marine environments can be improved.

[0121] In some embodiments, for the task source node The local value network uses a recurrent neural network to extract historical observation and historical action information, and the local hidden state... Updated to: .

[0122] in, This is the set of parameters for the hidden state network to learn.

[0123] The value of a local action is: ; in, For value network parameters; The local action value is modified using an action mask as follows: .

[0124] The hybrid network employs a QMIX structure that satisfies monotonicity constraints, mapping the local action value of each task source node to its global state as a joint action value. During training, experience replay, the target network, and temporal difference can be used to update the parameters of the local value network and the hybrid network; the specific batch size, learning rate, target network update cycle, and exploration rate decay method can be preset according to the system scale.

[0125] After training, the online deployment phase does not require task source nodes to save the global state, hybrid network, or hypernetwork. Only the corresponding local value network parameters, hidden state update rules, and action mask generation rules are deployed to each task source node. The online execution action selection is as follows: .

[0126] like If empty, the task source node performs local queuing, delays to the next time slot, or performs a low-risk action according to a preset backoff mechanism, and feeds back the corresponding over-limit cost to subsequent training samples through the penalty term in the reward function. In an optional implementation, the state summary, action, reward, and next state summary generated during the online execution phase can be periodically transmitted back to the training platform for offline retraining or incremental updates; this optional process does not affect the decentralized inference performed by online nodes based on the local value network.

[0127] like Figure 5 As shown, during the online deployment phase, the trained local value network is deployed to each task source node, while the hybrid network and hypernetwork do not participate in online inference. Each time slot... At the beginning, the task source node The system collects the current task description, local queue status, remaining local battery power, previous time slot action, and link measurement information, and receives resource summaries broadcast by reachable edge nodes. The resource summaries include at least the edge node's remaining computing resources, remaining bandwidth resources, remaining storage resources, remaining battery power, idle hot container status, remaining cold start time, and container executable status.

[0128] During online scheduling, the task source node first generates a candidate action set according to the action coupling relationship, and then eliminates invalid actions based on the aforementioned action masking rules, combined with link quality, remaining node power, edge resources, hot container resource occupancy, and the expected total task latency. Subsequently, the task source node inputs local observations and historical hidden states into the local value network, and selects local actions from the valid action set; alternatively, the action value of invalid actions can be set to negative infinity before performing maximum value selection.

[0129] When the selected action When an action is performed locally, the task enters the local queue and is executed according to the actual local service volume. Update the local queue and the remaining battery level of the task source node. When the selected action is unload execution, the task source node transmits the task data to the target edge node. Before receiving a task, the target edge node performs a secondary verification of resources and power. This secondary verification is used to avoid constraint violations caused by link measurement errors, resource digest delays, or concurrent arrival of multiple tasks.

[0130] .

[0131] In the above formula, This indicates that the selected unloading action has passed secondary verification at the edge node. This represents the estimated additional energy consumption of the edge node in this time slot, based on the current task, cold start, keep-alive, and queue service processes. After secondary verification, the edge node is written into the task record table. ,Record , , and Task record fields; if the second validation fails, a rollback mechanism is triggered.

[0132] like or Then execute the rollback action. The rollback mechanism is executed according to a preset priority: First, local queuing is selected when the local remaining power and local queue capacity meet the constraints; second, when local queuing would violate the power limit or delay pre-screening conditions, the task is delayed to the next time slot for re-decision; third, when the task cannot be delayed or delay would lead to a higher risk of default, a preset low-risk action is executed, and the corresponding delay limit violation or constraint default penalty is added to the reward function.

[0133] .

[0134] After online execution, the system performs state write-back in the following order: "task record writing or updating—actual service volume calculation—queue status update—container lifecycle update—storage usage update—energy consumption and power consumption update—reward calculation." To ensure a closed-loop state transition, state write-back must include at least the following: updating the local queue. Edge queue Remaining computation time for task records Remaining cold start time Execution status Keep-alive timer Storage usage and the remaining power of the node .

[0135] .

[0136] At the end of each time slot, online transfer samples can be generated for use in runtime logs, policy evaluation, or optional subsequent retraining; this process does not change the decentralized inference execution method of the online deployment phase, which is based on local observations, local value networks, and action masks by the task source nodes.

[0137] Of course, the above description is not intended to limit the present invention, and the present invention is not limited to the examples given above. Any changes, modifications, additions or substitutions made by those skilled in the art within the scope of the present invention should also fall within the protection scope of the present invention.

Claims

1. An energy consumption-aware task scheduling method for serverless edge computing in a sea area, characterized in that, The process includes model training, online deployment, and online scheduling steps. The model training steps include: Based on the pre-built serverless edge computing system in the sea area, a task scheduling model, a communication transmission model, a queue state model, a container lifecycle model, and a computing processing energy consumption model are constructed. The serverless edge computing system in the sea area includes multiple task source nodes and multiple edge nodes. Construct optimization objectives and constraints; Based on the task scheduling model, communication transmission model, queue state model, container lifecycle model, computing energy consumption model, optimization objective and constraints, the task scheduling process is modeled as a partially observable Markov decision process (POMDP), and the task scheduling model is trained using a multi-agent reinforcement learning method with centralized training and decentralized execution. The online deployment steps include deploying the local value network parameters, hidden state update rules, and action mask generation rules corresponding to each task source node to the task source node; In the online scheduling step, the task source node performs decentralized online reasoning based on the local observation status, the set of actionable actions, and the action mask to obtain a task scheduling scheme that includes computation unloading, edge node selection, and container keep-alive time levels, and then executes it.

2. The method according to claim 1, characterized in that, The task scheduling model includes calculating unloading decision variables. Edge node selection decision variables and container survival time level decision variables ,in This indicates that the task will be executed locally. This indicates that the task will be unloaded and executed. Choose variables for edge nodes. Indicates the task source node The generated tasks are assigned to edge nodes. implement, This indicates that it has been assigned to an edge node. The task corresponds to the container keep-alive time level; each variable satisfies the coupling relationship between edge node selection and unloading decision, as well as the coupling relationship between container keep-alive time level and edge node selection.

3. The method according to claim 2, characterized in that, The communication transmission model includes a computing task source node. With edge nodes In the time slot Channel gain : ； in, This represents the linear domain channel gain at the reference distance. Indicates the task source node With edge nodes The distance between them This represents the path loss index. This represents the correction factor for the evaporation waveguide. This represents the small-scale fading component; According to the channel gain Calculate the uplink transmission rate : ； in, Indicates bandwidth allocation. Indicates the transmission power. Represents the noise power spectral density. This represents noise power.

4. The method according to claim 3, characterized in that, The queue state model includes the workload to be processed in the local queue. and edge queue pending workload At the end of each time slot, the workload pending in the local queue and the workload pending in the edge queue are updated according to the computational workload of newly added tasks, the computational workload already served, and the processing capacity of the corresponding nodes.

5. The method according to claim 4, characterized in that, The container lifecycle model includes a container keep-alive timer corresponding to the function type on the edge node, a task start execution indicator variable, a task completion indicator variable, and a hot container status indicator variable; A cold start is triggered when there is a service request of the corresponding function type on the edge node, and the corresponding function type does not have an idle reusable hot container, is not in the cold start process, and is not in the execution process. After the task is completed, the container keep-alive timer is written back according to the container keep-alive time level recorded in the task scheduling scheme; when no task of the same function type is completed on the corresponding edge node, the container keep-alive timer decreases with time slot; when the container keep-alive timer reaches zero, the resources occupied by the corresponding container are released and the hot container state is set to cold state.

6. The method according to claim 5, characterized in that, The computational energy consumption model includes edge nodes. Service energy consumption and task source node In the time slot Service energy consumption Among them, the energy consumption of the task source node includes local execution energy consumption and transmission energy consumption, and the energy consumption of the edge node service includes edge execution energy consumption, cold start energy consumption aggregated and measured by edge node and function type according to the cold start process, and container keep-alive energy consumption aggregated and measured by edge node and function type.

7. The method according to claim 6, characterized in that, The steps of constructing optimization objectives and constraints also include computation nodes. Normalized remaining power and according to Calculate energy-sensing weights ; Normalized single-slot cost function and minimize As an optimization target.

8. The method according to claim 7, characterized in that, The constraints include at least the action coupling constraints, edge node computing resource constraints, edge node bandwidth resource constraints, edge node storage resource constraints, remaining power constraints of the task source node and edge nodes, and task latency threshold constraints with slack variables.

9. The method according to claim 8, characterized in that, POMDP includes a global state space, a local observation space, a local action space, a state transition function, a reward function, and a discount factor. The global state includes task queue state, queue state, task record state, link rate state, node power state, edge node resource state, and container lifecycle state. Local observations consist of locally available information and edge node broadcast summaries.

10. The method according to claim 9, characterized in that, In the online deployment process, for the task source node The local value network uses a recurrent neural network to extract historical observation and historical action information and update the local hidden state. ; The local action value is calculated based on the local hidden state, and the local action value is corrected using an action mask.

Images