Cross-layer cooperative scheduling and service task offloading method and system for computing power network

Abstract

The application belongs to the technical field of optical transport network and computing power network integration, and specifically discloses a cross-layer cooperative scheduling and service task offloading method and system for computing power network, which comprises the following steps: constructing a unified cross-layer resource information model, abstracting time slot or slice resources of OTN, SPN and PON into a unified bandwidth unit LBU, and generating a network-computing joint topology view; receiving a task request and analyzing constraints; performing network-computing cooperative decision, screening candidate computing power nodes and calculating end-to-end effective paths, and determining the optimal offloading node and transmission path through comprehensive scoring; generating configuration instructions and issuing them in parallel to reserve network resources, triggering task offloading; and after the completion of the task, recycling resources and updating the view in linkage. The application can realize cross-layer cooperative scheduling of three-layer optical networks of OTN, SPN and PON, and establish a mechanism for deep integration of network scheduling and computing power demand and linkage of task offloading.

Description

Technical Field

[0001] This application belongs to the field of optical transport network and computing network integration technology, and more specifically, relates to a cross-layer collaborative scheduling and service task offloading method and system for computing networks. Background Technology

[0002] With the large-scale advancement of cloud computing, edge computing, and artificial intelligence technologies, computing networks have become the core infrastructure supporting the efficient sharing and dynamic scheduling of ubiquitous computing resources. Their core requirement is to achieve network-based computing collaboration and global resource optimization. That is, the network not only needs to provide highly reliable and low-latency data transmission channels, but also needs to perceive and announce the resource status of distributed computing nodes in real time, and coordinate the scheduling of multi-dimensional resources such as computing, storage, and bandwidth.

[0003] At the computing power network bearer level, the industry has currently formed a standardized three-tiered deployment architecture: the backbone layer uses Optical Transport Network (OTN) to achieve high bandwidth, long distance, and high reliability transmission; the aggregation layer uses Slicing Packet Network (SPN) to achieve flexible slicing and low-latency forwarding; and the access layer uses Passive Optical Network (PON) to achieve widespread access for end users and edge computing nodes. However, existing technical solutions still have core technical defects and cannot meet the core requirement of "deep integration of network and computing" in computing power networks. Specifically: First, the network layers are fragmented, lacking an end-to-end collaborative scheduling mechanism. Existing technologies do not treat the OTN, SPN, and PON three-layer optical networks as a unified logical resource pool, resulting in a lack of seamless cross-domain resource allocation; Second, scheduling decisions are disconnected from computing power requirements, failing to achieve network-computing collaborative optimization. Existing optical network scheduling is based only on network indicators such as bandwidth and latency, without incorporating computing power requirements and node status; Third, task offloading and network scheduling processes are disconnected, making it impossible to guarantee service quality. Upper-layer task offloading and lower-layer network resource scheduling are independent of each other.

[0004] Therefore, how to achieve cross-layer collaborative scheduling of OTN, SPN, and PON three-layer optical networks, and establish a mechanism for deep integration of network scheduling and computing power demand, as well as task offloading linkage, is an urgent problem to be solved. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the purpose of this application is to provide a cross-layer collaborative scheduling and service task offloading method and system for computing power networks, which can realize cross-layer collaborative scheduling of three-layer optical networks (OTN, SPN, and PON) and establish a mechanism for deep integration of network scheduling and computing power demand and linkage of task offloading.

[0006] To achieve the above objectives, in a first aspect, this application provides a cross-layer collaborative scheduling and service task offloading method for computing power networks, executed by a collaborative controller, comprising the following steps: S10, Construct a unified cross-layer resource information model. The unified cross-layer resource information model includes abstracting the ODUk time slot resources of the OTN network, the FlexE slice resources of the SPN network, and the T-CONT time slot resources of the PON network into a unified logical bandwidth unit (LBU), collecting the status of computing power nodes, and generating and maintaining a network-computing power joint topology view containing a network resource topology matrix and a computing power resource matrix. S20: Receive a business task request and parse it to obtain a set of task characteristics and constraints; S30, based on the network-computing power joint topology view and the set of task characteristics and constraints, perform network-computing power collaborative decision-making: filter candidate computing power nodes that meet the computing power side constraints, calculate and filter end-to-end effective paths covering the entire link of PON access, SPN aggregation, and OTN backbone for each candidate computing power node, generate a candidate node-effective path pairing list, comprehensively score the pairing list, select the optimal solution, and determine the target offloading node and the end-to-end optimal transmission path; S40, Based on the end-to-end optimal transmission path, generate configuration instructions for PON segment, SPN segment, and OTN segment, and send them out in parallel to perform network resource reservation. After receiving the configuration success confirmation, trigger the service task to be unloaded to the target unloading node along the established path. S50, after the task is completed, a resource release command is issued to perform the coordinated reclamation of network and computing resources, and the network-computing power joint topology view is updated.

[0007] As a further preferred embodiment, in step S10, the acquisition of the state of the computing power node specifically includes: defining the feature vector of the computing power node as... ; in, ID It serves as a unique identifier for computing power nodes; CPU This indicates the node's CPU resource status, including CPU architecture and number of cores. and number of available cores ,satisfy ; MEM This indicates the node's memory resource status, including total memory capacity. and available memory capacity ,satisfy ; GPU This indicates the status of the node's GPU or NPU resources, including model and memory capacity. and available video memory capacity ; IO This indicates the node's storage IOPS performance, including the maximum IOPS value. and current available IOPS value ,satisfy ; L Indicates the current load rate of the node. ,in This represents the number of CPU cores currently in use by the node. This represents the memory capacity already used by the node. This represents the amount of GPU memory already used by the node. , , The weighting coefficients and , ; E This represents the current energy consumption value of the node. ,in This refers to the idle energy consumption of a node. The energy consumption at full load for a node. This represents the maximum load threshold for the node.

[0008] As a further preferred embodiment, step S10, which involves generating and maintaining a network-computing power joint topology view that includes a network resource topology matrix and a computing power resource matrix, specifically includes: The topology status of LBU resources in each domain is collected from the Layer 3 optical network controller, including the total number of LBUs. Number of available LBUs Analyze the LBU occupancy status of each link to construct a network resource topology matrix. ; Collect feature vectors from all computing nodes from the computing resource manager. Construct a computing resource matrix ,in M This represents the total number of computing power nodes, with each row corresponding to the feature vector of a single computing power node. The network resource topology matrix R and the computing power resource matrix C are merged to generate and maintain a joint network-computing power topology view. .

[0009] As a further preferred embodiment, step S20, which involves receiving a service task request and parsing it to obtain a set of task features and constraints, specifically includes: Define each task request as a task feature vector. ,in As a unique identifier for the task, D For the size of the task data, Calculate the complexity metric for the task. The maximum tolerable latency for the task. This is the vector representing the minimum computational resource requirements of the task. Based on task feature vectors T Extracting network-side constraints and computing power constraints Forming a constraint set The network-side constraints These include bandwidth constraints, latency constraints, and LBU resource constraints; the computing power-side constraints... These include CPU constraints, memory constraints, GPU constraints, IOPS constraints, and load constraints.

[0010] As a further preferred embodiment, in the network-side constraints, the bandwidth constraint satisfies the minimum bandwidth required for task transmission. ,in The maximum transmission delay of the task and , To minimize the computational latency of the task, , The maximum GPU computing power among all computing nodes; The delay constraint satisfies the total end-to-end delay of the task. , ,in For the transmission delay of the task across three layers of optical network and , , , These are the transmission delays for the PON, SPN, and OTN segments, respectively. The computation latency of the task on the computing node; The LBU resource constraint satisfies the number of LBUs required for task transmission. ,in Indicates rounding up. This refers to the bandwidth granularity of a single LBU.

[0011] As a further preferred embodiment, in step S30, the screening of candidate computing power nodes that meet the computing power-side constraints specifically includes: traversing all... M Each computing node has a feature vector. Perform constraint verification to ensure that the constraints are met. All nodes subject to the constraints are included in the candidate computing power node set. ; The process of calculating and filtering end-to-end effective paths covering the entire PON access, SPN aggregation, and OTN backbone for each candidate computing power node specifically includes: using a K-shortest path algorithm, based on the network resource topology matrix R in the network-computing power joint topology view, to calculate the path from the source node s to the target node. There are K end-to-end logical paths, each path All paths cover the entire link from PON access and SPN aggregation to OTN backbone; each path is based on the network resource topology matrix R. Perform resource verification, specifically checking whether the number of available LBUs in the PON, SPN, and OTN segments meets the network-side constraints. Given the LBU resource constraints and bandwidth constraints, calculate the end-to-end transmission delay for this path. Retain all valid paths that satisfy all network-side constraints to form the candidate node. valid path set ;like If not empty, generate a list of candidate node-valid path pairs. All valid pairings form a pairing list. ,in This is the index of the candidate node in the set Scandidate. The path number. =1,2,...,K, For the first Candidate computing power nodes.

[0012] As a further preferred embodiment, step S30, which involves comprehensively scoring the pairing list, specifically includes: Define the comprehensive scoring function ,in , , The weighting coefficients and , To score network performance, Scoring the computing power nodes Score resource costs; Network performance rating The calculation formula is: ,in The maximum transmission delay for the task. For path The minimum number of available LBUs, The number of LBUs required for task transmission; Computing Node Rating The calculation formula is: ,in Candidate nodes load rate, To preset the load threshold, The number of available CPU cores for candidate nodes. Minimum number of CPU cores Candidate nodes Available memory capacity Minimum memory capacity; Resource cost rating The calculation formula is: ,in Candidate nodes Energy consumption value, This represents the maximum energy consumption value for all candidate nodes. This represents the total number of available LBUs across the entire network. The selection of the optimal solution specifically includes: traversing the pairing list. Calculate each pair Overall rating The pair with the highest score is selected as the optimal solution. Determine the target unloading node End-to-end optimal transmission path .

[0013] As a further preferred embodiment, in step S40, generating configuration instructions for the PON segment, SPN segment, and OTN segment based on the end-to-end optimal transmission path and issuing them in parallel to perform network resource reservation specifically includes: Optimal transmission path based on network domain The configuration is divided into PON segment configuration instructions, SPN segment configuration instructions, and OTN segment configuration instructions. The PON segment configuration instruction includes the PON segment link identifier and the number of reserved LBUs. The T-CONT time slot allocation scheme and access node port configuration parameters, the SPN segment configuration instructions include the SPN segment link identifier and the number of reserved LBUs. The FlexE slice allocation scheme and forwarding path configuration parameters, the OTN segment configuration instructions include the OTN segment link identifier, the number of reserved LBUs. ODUk time slot allocation scheme and cross-connect configuration parameters; The corresponding resource reservation and cross-connection configuration commands are sent in parallel to the PON controller, SPN controller, and OTN controller via the southbound interface; after receiving the commands, each layer controller verifies the number of available LBUs for the corresponding link in its domain. Confirmed to meet the requirements , Set the number of LBUs required for task transmission; lock the corresponding number of LBU resources, mark them as reserved, update the resource status of this domain, and establish cross-connections; after each layer controller completes the configuration, it sends a configuration success confirmation message to the coordination controller. If any controller fails to send a message, the coordination controller sends a resource release command to all controllers, terminates the current configuration, and re-executes step S30.

[0014] As a further preferred embodiment, step S50, which involves issuing a resource release command after the task is completed to perform coordinated recycling of network and computing resources and updating the network-computing power joint topology view, specifically includes: When the target unloads the node After completing the task calculation, a task completion event is sent to the coordination controller. The coordination controller then issues connection teardown and resource release instructions to the OTN controller, SPN controller, and PON controller. The instructions include path identifiers and the number of reserved LBUs. After each layer controller performs the resource release operation, it updates the resource status of its domain, marks the released LBU as available, and sends a confirmation message of successful release to the coordination controller. After receiving the confirmation information, the collaborative controller updates the network resource topology matrix R in the network-computing power joint topology view, increasing the number of available LBUs for the corresponding link by the number of LBUs required for task transmission. Simultaneously update the feature vector of the target computing node. Restore available resources to Add the minimum computational resource requirement vector for the task It also sends a notification to the computing network orchestrator that the task is completed and resources have been successfully recycled.

[0015] Secondly, this application provides a cross-layer collaborative scheduling and service task offloading system for computing power networks, including a collaborative controller. The collaborative controller interfaces with a computing power network orchestrator in the north via a standardized interface, and connects to an OTN controller, an SPN controller, and a PON controller in the south via an OTN standard interface, an SPN controller interface, and a PON controller interface, respectively. It also interfaces with a computing power resource manager via a computing power resource management interface. The collaborative controller is used to execute the cross-layer collaborative scheduling and service task offloading method for computing power networks as described in any of the above-mentioned methods.

[0016] Compared with existing technologies, this application achieves three core breakthroughs through the above-mentioned technical solution, possessing significant technological advantages and industrial value. The specific beneficial effects are as follows: (1) Pioneering a unified scheduling mechanism for three-level optical networks to eliminate cross-domain scheduling blind spots: For the first time, the three-layer optical networks of OTN, SPN, and PON are regarded as a unified logical resource pool. Through LBU unified resource modeling, the standardized and pooled management of heterogeneous resources at the three layers is realized, and an end-to-end collaborative scheduling mechanism that runs through "access-aggregation-backbone" is constructed, eliminating the blind spots in existing technologies. (OTN domain) (SPN domain), The scheduling blind spots caused by the independence of PON domains. Tests show that end-to-end latency jitter is reduced by more than 40%, and transmission reliability is improved to 99.99%, providing a true end-to-end deterministic channel for computing tasks.

[0017] (2) Achieving deep integration of network and computing to improve overall resource utilization: The real-time status (load, energy consumption, resource redundancy) of computing nodes is deeply embedded into network routing decisions. A multi-dimensional comprehensive scoring model of "network-computing power" is designed to achieve joint optimal matching of "network path + computing node", breaking the architectural limitations of network-computing separation in existing technologies. Tests show that the overall network resource utilization rate is improved by more than 28%, and the computing power resource utilization rate is improved by more than 32%, effectively solving the problem of coexistence of local congestion and resource idleness, and reducing resource waste.

[0018] (3) Establish a linkage mechanism between task offloading and network assurance to provide deterministic QoS: Through a closed-loop process of "network resource reservation → confirmation of readiness → task offloading → resource reclamation", a deterministic mechanism of "first ensuring the network path, then executing task offloading" is realized, ensuring that the latency and bandwidth requirements of task transmission and computation are accurately met. After testing, the timeout rate of latency-sensitive tasks was reduced to below 0.2%, and the task offloading success rate reached 99.8%. It can perfectly adapt to computing power application scenarios with extreme requirements for latency and reliability, such as industrial internet and autonomous driving, and has strong practicality and industrial promotion value. Attached Figure Description

[0019] Figure 1 This is the system architecture diagram provided in this application; Figure 2 This is a schematic diagram of the unified resource modeling and LBU mapping provided in this application; Figure 3 This is the main flowchart of cross-layer collaborative scheduling provided in this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0021] This application, through research, has identified three major technical deficiencies in existing solutions, which fail to meet the core requirement of "deep integration of network and computing" in computing power networks, as follows: (1) Fragmented network layers and lack of end-to-end collaborative scheduling mechanism: Existing technologies mostly focus on the interoperability between OTN and PON layers (such as protocol adaptation through Flexible Optical Service Unit (OSU) frames), or cross-layer optimization between the IP layer and the optical layer. A technical solution that treats the OTN, SPN, and PON three-layer optical networks as a unified logical resource pool has not yet been formed, and an end-to-end collaborative scheduling mechanism spanning "access-aggregation-backbone" has not been established. Let the resource scheduling domains of the three layers be respectively... , , In existing technology , , The systems are independent of each other, and scheduling decisions are based solely on the resource status of the local domain. This results in a lack of seamless resource allocation strategies when computing tasks are transmitted across domains, leading to a coexistence of local congestion (resource utilization ≥ 90%) and resource idleness (resource utilization ≤ 30%), and failing to provide end-to-end deterministic transmission guarantees.

[0022] (2) Scheduling decisions are disconnected from computing power requirements, failing to achieve network-computing co-optimization: Existing optical network scheduling methods only include network performance indicators such as bandwidth (B), latency (T), and jitter (J) as decision factors, failing to incorporate the core requirements of upper-layer computing power tasks (such as the number of CPU cores (C), memory capacity (M), GPU / NPU computing power (G), and storage IOPS (I)) and the real-time status of target computing power nodes (load rate (L), energy consumption (E)) into the decision system. This separation architecture, where "the network only manages the path and the computing power only manages the computation," has a scheduling objective that is only... or Unable to be time-delay sensitive ( ), computationally intensive ( Different types of tasks, such as network and computing power, provide optimal solutions for multi-dimensional matching of network and computing power, resulting in the utilization rate of network resources being less than 60% and the task completion efficiency being more than 40% lower than the theoretical optimal value.

[0023] (3) The task offloading and network scheduling processes are disconnected, and the Quality of Service (QoS) cannot be guaranteed deterministically: The task offloading decision of the upper-layer business platform (i.e., selecting the optimal computing node to execute the task) is independent of the resource scheduling of the underlying optical network. The offloading decision is based only on the resource status of the computing node and does not know whether the network side can provide bandwidth and latency guarantees to meet the task requirements. The network scheduling is based only on the link status and does not take into account the intention of task offloading to actively reserve resources and plan paths. Let the set of task offloading decisions be U and the set of network scheduling decisions be R. In the existing technology, U and R have no linkage relationship, which makes it impossible to guarantee the end-to-end service quality deterministically. The timeout rate of latency-sensitive tasks is ≥15%, which is difficult to adapt to the needs of high-end computing power application scenarios such as industrial Internet and autonomous driving.

[0024] To address the technical problems of fragmented optical network layers, disconnect between network scheduling and computing power requirements, and lack of coordination between task offloading and network resource allocation in existing technologies, this application provides a cross-layer collaborative scheduling and service task offloading method and system for computing power networks (OTN-SPN-PON). This method is applicable to scenarios with stringent requirements for end-to-end latency, bandwidth determinism, and resource utilization, such as industrial internet, autonomous driving, and AI computing power scheduling. By constructing a unified cross-layer resource model, designing a network-computing collaborative decision-making algorithm, and establishing a linkage mechanism between task offloading and network assurance, it achieves deep integration of "network and computing power," improves the efficiency of computing power task execution and global resource utilization, provides end-to-end deterministic QoS guarantees, and adapts to the needs of various high-end computing power application scenarios.

[0025] Among them, such as Figure 1 As shown, the cross-layer collaborative scheduling system provided in this application takes the collaborative controller as its core. In the north, it interfaces with the computing network orchestrator through standardized interfaces (such as RESTCONF / YANG) to receive service task requests and feedback the scheduling status. In the south, it connects with the OTN controller, SPN controller, and PON controller through the OTN standard interface (GMPLS), SPN controller interface, and PON controller interface (OMCI), respectively. At the same time, it interfaces with the computing resource manager through the computing resource management interface to realize unified perception, decision-making, and scheduling of three-layer optical network resources and computing resources. The system architecture meets the high reliability and low latency requirements of industrial-grade deployment (control plane latency ≤100ms).

[0026] like Figure 3 As shown, the cross-layer collaborative scheduling and business task offloading method provided in this application adopts closed-loop control logic and consists of 5 core steps: Step S1: Construct a unified cross-layer resource information model and periodically collect and update the overall network status view. The core innovation of this step lies in breaking down the resource barriers between the OTN, SPN, and PON three-layer optical networks, constructing a standardized unified resource model and a joint "network-computing power" topology view, providing a data foundation for subsequent network-computing collaborative decision-making. Specific sub-steps are detailed below: Sub-step S11: Construct a unified logical bandwidth unit (LBU) model to achieve standardized and pooled management of three-layer optical network resources.

[0027] Specifically, the ODUk time slot resources of the OTN network, the FlexE slice resources of the SPN network, and the T-CONT time slot resources of the PON network are abstracted into a unified LBU according to their respective resource granularity, and the bandwidth granularity of the LBU is defined as follows: The following mapping relationship is satisfied: OTN domain LBU mapping: 1 LBU corresponds to One ODUk time slot, i.e. ,in positive integers ( ≥1), The standard bandwidth for a single ODUk time slot (e.g., 10 Gbit / s for ODU2 and 100 Gbit / s for ODU4). SPN domain LBU mapping: 1 LBU corresponds to A FlexE slice, i.e. ,in positive integers ( ≥1), The bandwidth for a single FlexE slice (flexibly configurable to 1Gbit / s, 5Gbit / s, or 10Gbit / s). PON domain LBU mapping: 1 LBU corresponds to One T-CONT time slot, i.e. ,in positive integers ( ≥1), The bandwidth of a single T-CONT time slot (typically 1 Gbit / s or 2.5 Gbit / s).

[0028] like Figure 2 As shown, through the above mapping, the heterogeneous resources of the three-layer optical network are unified into standardized LBUs, eliminating resource type differences and achieving... , , The resource pooling and integration solves the problem of the inability to uniformly schedule optical network resources at different levels in existing technologies.

[0029] Sub-step S12: Define a unified computing node description model to achieve standardized quantification and perception of computing resources.

[0030] Define the feature vector of the computing power node as The mathematical definitions of each parameter are as follows: ID: Unique identifier for computing power nodes, in string type (e.g., “Edge-Node-001”); CPU: Node CPU resource status, including CPU architecture (e.g., x86, ARM) and number of cores. Available core count ,satisfy ; MEM: Node memory resource status, including total memory capacity (Unit: GB) Available memory capacity (Unit: GB), meets ; GPU: Status of node GPU / NPU resources, including model (e.g., NVIDIA A100, Ascend 910) and video memory capacity. (Unit: GB) Available video memory capacity (Unit: GB), this parameter is 0 when there is no GPU / NPU; IO: Node storage IOPS performance, including maximum IOPS value. Current available IOPS value ,satisfy ; L: Current load rate of the node ,in , , Weighting coefficients ( ); ; The number of CPU cores used by the node is obtained by subtracting the number of available cores from the total number of cores. = ; The node's used memory capacity (unit: GB) is obtained by subtracting the available memory capacity from the total memory capacity. = ; The node's used GPU memory capacity (unit: GB) is obtained by subtracting the available GPU memory capacity from the total GPU memory capacity. = .

[0031] E: Current energy consumption of the node (unit: W). ,in This refers to the idle energy consumption of a node. The energy consumption at full load for a node. This is the maximum load threshold for the node (usually set to 0.8).

[0032] Using the aforementioned feature vectors, the collaborative controller can accurately quantify the real-time resource status of each computing node, providing a quantitative basis for subsequent computing power selection and collaborative decision-making.

[0033] Sub-step S13: Periodically collect resource status, generate and maintain a joint "network-computing power" topology view. The collaborative controller collects data from the OTN controller, SPN controller, PON controller, and computing power resource manager through the southbound interface at a period T (T can be configured from 100ms to 1s, dynamically adjusted according to network size), as follows: The topology status of LBU resources in each domain is collected from the Layer 3 optical network controller, including the total number of LBUs. Number of available LBUs Analyze the LBU occupancy status of each link to construct a network resource topology matrix. ,in Represents a node To the node The number of available LBUs on the link. ; Collect feature vectors from all computing nodes from the computing resource manager. Construct a computing resource matrix , where M is the total number of computing nodes, and each row corresponds to the feature vector of a computing node; The network resource topology matrix R and the computing power resource matrix C are merged to generate and maintain a joint "network-computing power" topology view in the memory of the co-controller. This enables integrated perception of "network resources + computing resources", breaking the current situation of network-computing separation in existing technologies and ensuring that scheduling decisions are based on the real-time status of the entire network.

[0034] Step S2: Receive business task requests and parse task characteristics and multi-dimensional constraints. This step is used to accurately extract the network and computing power requirements of business tasks, providing clear constraints for subsequent collaborative decision-making. Specific sub-steps are detailed below: Sub-step S21: Receive business task requests and collect core task parameters.

[0035] The collaborative controller receives service task requests from the computing network orchestrator via the northbound interface. Each task request is defined as a task feature vector. The parameters are defined as follows: : Unique identifier for the task, which is a string type (e.g., "Task-001"); D: Task data size (unit: GB), representing the basic bandwidth requirements during task transmission; Task computational complexity index (unit: TOPS), which represents the intensity of a task's demand for computing resources; The maximum tolerable latency for a task (unit: ms) means that the total latency (transmission latency + computation latency) from task initiation and unloading to completion of computation must not exceed this threshold. ; : Minimum computational resource requirements vector for the task ,in Minimum number of CPU cores Minimum memory capacity (GB). Minimum GPU memory capacity (GB). This is the minimum IOPS requirement.

[0036] Sub-step S22: Analyze the task feature vector and extract multi-dimensional constraints. Based on the task feature vector T, extract network-side constraints and computing power-side constraints respectively to form a constraint set. The details are as follows: Network-side constraints (1) Bandwidth constraint: The minimum bandwidth required for task transmission ,in The maximum transmission delay for the task. , To minimize the computational latency of the task, , The maximum GPU computing power among all computing power nodes in the entire network can be pre-statized and updated periodically by the computing power resource manager; (2) Latency constraint: total end-to-end latency of the task. , ,in For the transmission delay of the task across the three-layer optical network ( , , , (These are the transmission delays for the PON, SPN, and OTN segments, respectively). The computation latency of the task on the computing node ( (3) LBU resource constraints: the number of LBUs required for task transmission. ,in Indicates rounding up, ensuring The value is a positive integer, and the number of available LBUs in each segment of the path is greater than or equal to 1. .

[0037] Computing power side constraints (1) CPU constraints: (2) Memory constraints: (3) GPU constraints: (This constraint is automatically satisfied when there is no GPU requirement); (4) IOPS constraint: (5) Load constraints: ( The preset load threshold is usually set to 0.8.

[0038] By extracting the constraints mentioned above, we can clarify the core requirements of the task for network and computing power, and provide a precise basis for subsequent collaborative decision-making on "network-computing power".

[0039] Step S3: Based on the joint topology view, perform multi-dimensional collaborative decision-making between the network and computing power to generate a set of candidate offloading nodes and end-to-end paths. This step is the core innovation step. By deeply embedding the computing power node status into network routing decisions, a multi-dimensional collaborative decision-making algorithm is designed to achieve joint optimal matching of "network paths + computing power nodes". The specific sub-steps are detailed below, supplemented by a mathematical decision-making model: Sub-step S31: Filter the set of candidate computing power nodes that meet the computing power constraints. Based on the computing power resource matrix C in the joint topology view V, traverse all M computing power nodes and analyze the feature vector of each node. Perform constraint verification to ensure compliance. All nodes subject to the constraints are included in the candidate computing power node set. ,Right now:

[0040] like If the value is empty, then report "No available computing power nodes" to the computing power network orchestrator and terminate this scheduling; if... If it is not empty, proceed to the next step.

[0041] Sub-step S32: For each candidate computing power node, perform end-to-end path calculation and resource matching across the OTN-SPN-PON layers to generate a valid pairing list. Let the task source address be S (located on the PON access side, corresponding to node s), and each candidate computing power node be... (corresponding node) , ), for each Perform the following operations: End-to-end path calculation: Using the K shortest path algorithm (K≥3, configurable), based on the network resource topology matrix R in the joint topology view V, the path from the source node s to the target node is calculated. There are K end-to-end logical paths, each path (j=1,2,...,K) all cover the entire link of "PON access → SPN aggregation → OTN backbone", that is:

[0042] in , , These are the access nodes of the source node in the PON, SPN, and OTN domains, respectively. , , These are the access nodes of the candidate nodes in the PON, SPN, and OTN domains, respectively.

[0043] Path resource verification: for each path Based on the network resource topology matrix R, the number of available LBUs in the PON, SPN, and OTN segments is verified to ensure that network-side constraints are met. The LBU resource constraints and bandwidth constraints in the text are: Each link in All satisfy .

[0044] Simultaneously, calculate the end-to-end transmission delay of this path. ( ),in The transmission delay of link l ( ),make sure .

[0045] Valid path selection: Paths with insufficient resources or excessive latency are eliminated, and valid paths that meet all network-side constraints are retained to form the candidate node. valid path set .

[0046] Generate a pairing list: If If not empty, then generate "candidate node-valid path" pairings. All valid pairings form a pairing list. ,in This is the index of the candidate node in the set Scandidate. The path number. =1,2,...,K, For the first Candidate computing power nodes.

[0047] Sub-step S33: Check the pairing list A multidimensional comprehensive scoring method is used to establish a scoring model. The comprehensive scoring function S is defined as a dimensionless index (…). The higher the score, the better the matching scheme. The scoring function combines three dimensions: network, computing power, and cost. The specific expression is as follows:

[0048] in, , , For the weighting coefficients, satisfying It can be dynamically adjusted according to the task type (latency-sensitive tasks). , , Computationally intensive tasks , , Resource-saving tasks , , ); To score network performance, Scoring the computing power nodes For resource cost scoring, the scores for each sub-item are calculated as follows: Network performance rating Based on path transmission delay and bandwidth redundancy, ,in For path The minimum number of available LBUs (i.e., the minimum number of available LBUs for each segment of the path). After normalization ; Computing Node Rating Based on the load rate of computing nodes and resource redundancy, ,in Candidate nodes load rate, After normalization ; Resource cost rating Based on the energy consumption of computing nodes and the cost of network resource occupation, ,in This represents the maximum energy consumption value for all candidate nodes. This represents the total number of available LBUs across the entire network. .

[0049] Sub-step S34: Select the optimal pairing scheme and determine the target unloading node and cooperative scheduling strategy. Traverse the pairing list. Calculate each pair Overall rating The pair with the highest score is selected as the optimal solution, i.e.:

[0050] in, Unload the target node. This pairing scheme serves as the optimal end-to-end transmission path and is the collaborative scheduling strategy for this task, ensuring the scientific and optimal nature of the decision-making.

[0051] Step S4: Coordinated Execution of Network Resource Reservation and Service Task Offloading. The core innovation of this step lies in achieving a deterministic closed-loop mechanism of "network reservation first, task offloading later," ensuring the coordinated matching of network resources and computing resources. Specific sub-steps are detailed below: Sub-step S41: Split path configuration instructions to adapt to the Layer 3 optical network controller. The coordinating controller determines the optimal path... The configuration instructions are divided into PON, SPN, and OTN sections according to network domain. Each section contains core information such as path information, LBU resource reservation quantity, and cross-connection parameters, as detailed below: PON segment configuration commands: include PON segment link identifier and the number of reserved LBUs. T-CONT time slot allocation scheme, access node port configuration parameters; SPN segment configuration commands: including SPN segment link identifier and number of reserved LBUs. FlexE slice allocation scheme, forwarding path configuration parameters; OTN segment configuration commands: including OTN segment link identifier and number of reserved LBUs. ODUk time slot allocation scheme and cross-connect configuration parameters.

[0052] Ensure that each instruction segment is compatible with the interface protocol of the corresponding optical network controller, and guarantee the accuracy and timeliness of instruction issuance.

[0053] Sub-step S42: Parallel issuance of resource reservation commands to establish end-to-end deterministic connections. The coordinating controller, through its southbound interface, issues corresponding resource reservation and cross-connection configuration commands in parallel to the PON controller, SPN controller, and OTN controller. A parallel execution mechanism (execution latency ≤ 50ms) ensures that the three-layer optical networks synchronously complete resource reservation and connection establishment. The specific process is as follows: After receiving the instruction, each layer controller immediately checks the number of available LBUs on the corresponding link in its domain to confirm that the requirement is met. Lock the corresponding number of LBU resources, mark them as "reserved", update the resource status of this domain, and establish cross-connections to ensure path connectivity. After each layer controller completes the configuration, it sends a "configuration successful" confirmation message to the coordination controller. If any controller fails to send a confirmation message, the coordination controller immediately sends a "resource release" command to all controllers to terminate the current configuration and re-execute step S3.

[0054] This step, through parallel configuration, avoids connection failures or insufficient bandwidth caused by asynchronous cross-domain resource allocation, ensuring that the established end-to-end connection has deterministic bandwidth and latency guarantees.

[0055] Sub-step S43: Feedback on unloading preparation status to confirm network-computing linkage. After the collaborative controller receives "configuration successful" confirmation messages from all three-layer optical network controllers, it sends a "task unloading ready" notification to the computing network orchestrator. The notification includes the target unloading node identifier. End-to-end path Information, allocated network service levels (such as latency level, bandwidth level), and simultaneously update the network resource status in the joint topology view V (marking reserved LBUs as "occupied") and computing node status (marking target nodes) Available resources updated to ).

[0056] Sub-step S44: Trigger task unloading and execute computing power calculation. After receiving the "task unloading ready" notification, the computing power network orchestrator triggers the upper-layer business task, directing the task data flow along the established end-to-end deterministic path. Transmitted to the target unloading node , Based on the task's computational requirements, it calls upon its own CPU, GPU, and other computing resources to execute computational tasks. During the computation process, it provides real-time feedback on the computational status (such as computational progress and resource usage) to the collaborative controller, ensuring the monitorability of task execution.

[0057] Step S5: After the task is completed, perform coordinated recycling of network and computing resources. This step achieves closed-loop resource recycling, ensuring resource reuse and improving overall resource utilization. Specific sub-steps are detailed below: Sub-step S51: Receive the task completion event and issue a resource release command. When the target node is unloaded... After completing the task calculation, a "task completed" event is sent to the coordination controller. The coordination controller immediately issues connection teardown and resource release commands to the OTN controller, SPN controller, and PON controller. The commands include information such as path identifier and the number of reserved LBUs, requiring each layer controller to tear down the cross-connection and release the reserved LBU resources.

[0058] Sub-step S52: Update the overall network status view. After each layer controller performs the resource release operation, it updates the resource status of its local domain, marks the released LBUs as "available," and sends a "release successful" confirmation message to the coordinating controller. After receiving the confirmation message, the coordinating controller updates the network resource topology matrix R in the joint topology view V (increasing the number of available LBUs on the corresponding links). ), and update the target computing power nodes. eigenvectors (Restore available resources to) The collaborative controller sends a "task completed + resource recovery successful" notification to the computing network orchestrator, completing a complete scheduling loop, ensuring the recycling of resources and avoiding resource waste.

[0059] The following is a specific implementation example of this application: This embodiment adopts the standard deployment architecture of the operator's existing network, which consists of a three-level optical transmission network consisting of the access layer XG-PON, the aggregation layer SPN, and the backbone layer OTN. It is combined with edge computing nodes, central computing nodes, collaborative controllers, and computing network orchestrators to form a complete system.

[0060] The network hierarchy and device configuration are as follows: Access layer: XG-PON network; Optical line terminal (OLT): deployed in building / campus computer rooms, supporting T-CONT dynamic bandwidth allocation; Optical network unit (ONU): deployed on the user side as a source node for computing power tasks; Scheduling granularity: T-CONT time slot, basic bandwidth 1Gbit / s.

[0061] Aggregation layer: SPN slice packet network; SPN node devices: support FlexE hard slicing and low-latency forwarding; Slice granularity: FlexE 5Gbit / s slice.

[0062] Backbone layer: OTN optical transport network; OTN cross-connect equipment: supports ODUk time slot cross-connect and end-to-end hard pipe; Time slot granularity: ODU2, fixed bandwidth 10Gbit / s.

[0063] Computing node configuration: This embodiment deploys a total of 4 computing nodes, all of which support CPU / GPU heterogeneous computing, including edge computing nodes Edge-1, Edge-2, and Edge-3 (deployed in the aggregation data center, with low latency and medium computing power) and central computing node Cloud-1 (deployed in the provincial cloud data center, with high computing power and high bandwidth).

[0064] Collaborative Controller and Interfaces: The hardware is a 2U rack-mount x86 server with dual CPUs, 256GB of memory, and dual 10G optical ports; the operating system is Linux Ubuntu 22.04 LTS; the southbound interfaces include the OTN controller GMPLS / NetConf interface, the SPN controller FlexE management interface, the PON controller OMCI / NetConf interface, and the computing resource manager Redfish API interface; the northbound interface is RESTCONF / YANG, which interfaces with the computing network orchestrator; the status acquisition cycle is 200ms, meeting industrial-grade real-time requirements.

[0065] The unified resource model and key parameter configurations are as follows: Unified Logical Bandwidth Unit (LBU) Definition and Mapping: The unified logical bandwidth unit is defined as 1 LBU = 10 Gbit / s. The Layer 3 network resource mapping relationship is as follows: OTN domain: 1 LBU = 1 ODU2 (10 Gbit / s); SPN domain: 1 LBU = 2 FlexE slices (5 Gbit / s × 2); PON domain: 1 LBU = 10 T-CONT time slots (1 Gbit / s × 10). That is, B_LBU = B_ODU2 = 2 × B_FlexE = 10 × B_TCONT Node feature vector parameters (taking Edge-1 as an example): Node ID is Edge-Node-001; CPU is 32 cores (x86), 20 cores are available; Total memory capacity is 128GB, 96GB is available; GPU is NVIDIA A100, 32GB of video memory, 24GB is available; Maximum storage IOPS is 50000, available IOPS is 35000; Load rate weighting coefficient ω_CPU=0.5, ω_MEM=0.3, ω_GPU=0.2; Maximum load threshold L_max=0.8; Idle power consumption E_idle=300W, full load power consumption E_max=800W.

[0066] Multidimensional scoring weighting coefficients (latency-sensitive tasks): network performance weight α=0.5, computing power node weight β=0.3, resource cost weight γ=0.2, satisfying α+β+γ=1.

[0067] Example of a business task request: The cooperative controller receives an autonomous driving environmental perception computing task through the northbound interface. The task feature vector is as follows: Task ID is Task-AV-001; Task data volume D = 2.5GB; Computational complexity C_comp = 400TOPS; Maximum tolerable total latency T_max = 30ms; Minimum computing power requirement vector C_req is CPU_req ≥ 8 cores, MEM_req ≥ 16GB, GPU_req ≥ 8GB, IOPS_req ≥ 10000.

[0068] The complete implementation process (S1–S5, detailed steps) is as follows: Step S1: Construct a unified resource model and a network-computing power joint topology view. Unified LBU modeling: The collaborative controller abstracts the PON's T-CONT, SPN's FlexE, and OTN's ODU2 into LBUs in a 10:2:1 ratio, achieving three-layer resource standardization. Computing power node information collection: The collaborative controller queries the computing power resource manager every 200ms to obtain the following for each node: available CPU cores, available memory capacity, available GPU memory, IOPS, load rate, and real-time power consumption. Network resource information collection: Obtain the available number of T-CONTs for each ONU-OLT link in the PON, the available number of FlexE slices between each node in the SPN, and the available number of ODU2 time slots for each link in the OTN from the PON / SPN / OTN controllers respectively. Generate a joint topology view V={R,C}, where R is an N×N dimensional network resource matrix, R[ ][ ] represents a node arrive The number of available LBUs is given, and C is an M×7 dimensional computing resource matrix, with each row corresponding to the complete feature vector of a computing node. The collaborative controller constructs a global unified view of the above information in memory.

[0069] Step S2: Receive and parse the task, generating multi-dimensional constraints. Parse task characteristics: extract task data volume, computational complexity, maximum latency, and minimum computing power requirement. Calculate network-side constraints: maximum allowable transmission latency T_trans_max ≤ T_max T_comp_min, where the minimum computation latency T_comp_min = C_comp / G_max = 400TOPS / 80TOPS = 5ms, therefore T_trans_max ≤ 30ms - 5ms = 25ms; minimum bandwidth requirement B_req = D / T_trans_max = 2.5GB / 0.025s = 1000Mbit / s ≈ 1Gbit / s; required number of LBUs N_LBU_req = B_req / B_LBU = 1Gbit / s / 10Gbit / s = 1 LBU. Computing power constraints: N_CPU_available ≥ 8, M_available ≥ 16GB, G_mem_available ≥ 8GB, I_available ≥ 10000, L ≤ 0.8.

[0070] Step S3: Network-based collaborative decision-making to generate optimal nodes and paths. Sub-step S31: Screening candidate computing power nodes. Traverse the four computing power nodes and verify their computing power constraints: Edge-1 meets the requirements for inclusion as a candidate, Edge-2 meets the requirements for inclusion as a candidate, Edge-3 is eliminated due to insufficient GPU, and Cloud-1 is eliminated due to excessive latency, resulting in a candidate set S_candidate = {Edge-1, Edge-2}. Sub-step S32: End-to-end path calculation and LBU resource verification. The task source node is the campus ONU (PON side), and the paths to Edge-1 and Edge-2 are calculated respectively. Path to Edge-1: ONU → OLT → SPN Node A → OTN Node X → SPN Node B → Edge-1. Verification shows that the PON segment has T-CONT ≥10, satisfying 1 LBU; the SPN segment has FlexE ≥2, satisfying 1 LBU; and the OTN segment has ODU2 ≥1, satisfying 1 LBU. Transmission delay T_trans = 12ms < 25ms, therefore the path is valid. Path to Edge-2: ONU → OLT → SPN Node A → OTN Node X → SPN Node C → Edge-2. Verification shows that the SPN segment C link has insufficient FlexE slices, not satisfying 1 LBU, therefore the path is invalid. The final valid pairing list only retains L_pair = { (Edge-1, P1)}. Sub-step S33: Multi-dimensional comprehensive scoring. Network performance score S_net = (1 - 12 / 25) × (1 + (10-1) / 10) = 0.52 × 1.9 = 0.988; Computing node score S_comp = (1 - 0.5 / 0.8) × (1 + (20-8) / 8+ (96-16) / 16) = 0.375 × (1+1.5+5) = 2.8125, normalized to [0,1] to get 0.78; Resource cost score S_cost = (1 - 450 / 800) × (1 - 1 / 120) ≈ 0.4375 × 0.99 = 0.433; Overall score S = 0.5×0.988 + 0.3×0.78 + 0.2×0.433 = 0.494 + 0.234 + 0.0866 = 0.8146. Sub-step S34: Determine the optimal solution. Optimal unloading node D_opt = Edge-1, optimal end-to-end path P_opt = P1.

[0071] Step S4: Network resource reservation + task offloading are executed in tandem. Sub-step S41: Configure instructions by domain. PON segment instruction: Allocate 10 T-CONT time slots, configure ONU-OLT uplink bandwidth of 1Gbit / s, and schedule with high priority; SPN segment instruction: Allocate 2 FlexE 5G slices, configure the end-to-end slice channel of SPN node A→X→B; OTN segment instruction: Allocate 1 ODU2 time slot, configure OTN cross-connection, and establish a bidirectional transparent transmission channel for X node. Sub-step S42: Parallel issuance and establishment of deterministic connections. The coordinating controller simultaneously issues configurations to the PON, SPN, and OTN controllers. Each controller verifies that the available LBU is ≥1, locks resources, and establishes cross-connections. All controllers return "configuration successful," with a total configuration latency of 32ms, meeting the system design specification of ≤50ms. Sub-step S43: Notify the computing power orchestrator that the network is ready. The collaborative controller updates the federated view, marking the corresponding path LBU as "occupied." Edge-1 deducts task requirements from available resources and sends a task offloading readiness message to the orchestrator. The target node is Edge-1, and the latency level SLA is ≤15ms. Sub-step S44: Execute task offloading. The computing orchestrator sends 2.5GB of sensing data to Edge-1 along the established channel. Edge-1 allocates CPU and GPU resources to perform inference computation and reports its status to the collaborative controller every 5ms.

[0072] Step S5: Task Completion and Resource Recovery. Edge-1 completes the computation and returns a computation completion event, with a total time of 18ms; the collaborative controller issues resource release commands to the PON, SPN, and OTN controllers; each domain releases LBU resources and returns to the "available" state; the collaborative controller updates the joint topology views R and C; and returns to the computing network orchestrator: task completed, resources recovered. This completes one full scheduling loop.

[0073] To verify the beneficial effects of this application, a comparative test was conducted between the solution of this application and the prior art solution under the same conditions, as follows: This test is a technical solution effectiveness verification test, used to objectively verify and quantify the performance differences between the two scheduling schemes. The test was conducted under the same hardware environment, the same service traffic model, and the same network topology, performing a parallel comparative observation of the traditional three-layer independent optical network scheduling scheme and the three-level unified optical network scheduling scheme. All test data is authentic and traceable, logs contain accurate system timestamps, and the test process is reproducible, meeting the requirements for authenticity and standardization verification in technical evaluation.

[0074] The hardware testing environment is shown in Table 1.

[0075] Table 1 Hardware Testing Environment

[0076] The network test topology adopts a standard carrier three-tier optical network architecture: access layer (PON) → aggregation layer (SPN) → backbone layer (OTN), establishing an end-to-end transmission link. Service traffic is forwarded across all three layers of devices to simulate real-world commercial service scenarios. The topology links have no redundant bypasses and no additional optimized channels, ensuring that the environments of the two comparison schemes are completely identical, eliminating any interference from the topology structure on the test data.

[0077] The software environment and testing tools are as follows: the operating system is CentOS 7.9 on the server side, and the network equipment is an embedded commercial system; the traffic testing tools are Iperf3 and SmartBits network performance testers; the computing power load tool is a self-developed computing power pressure scheduling simulation platform; the log collection tools are device SNMP logs, system timestamp logs, and port traffic monitoring system.

[0078] The unified testing methodology is described below: (1) Delay jitter and reliability test method: The test data packet adopts the 1024B standard Ethernet data packet, the packet sending frequency is 1000pps, and the single continuous test duration is 24h; the port one-way transmission delay, jitter fluctuation value and packet loss number are statistically analyzed; the sampling period of all data is 1s, and the log automatically retains the timestamp to ensure that the time sequence data is complete and traceable.

[0079] (2) Statistical scope of resource utilization: The statistical period is 5 minutes; the statistical dimensions include: port bandwidth utilization, device time slot occupancy, computing power CPU occupancy, and memory occupancy; the average value within the test period is taken as the final statistical result, and the data calculation method is uniform and the statistical scope is consistent.

[0080] (3) Comparison with the benchmark scheme: The comparison scheme is the existing three-layer optical network independent scheduling architecture: OTN, SPN and PON networks are independently managed and scheduled, without unified resource pooling modeling and cross-layer collaborative optimization, which is the industry's common traditional optical network scheduling scheme. The optimized scheme under test is a three-level unified collaborative scheduling scheme, which adopts cross-layer resource pooling and network computing joint scheduling mechanism.

[0081] Test Report 1: End-to-End Latency Jitter Comparison Test Report Test objective: To compare the latency jitter changes of the traditional three-layer independent scheduling scheme and the three-level collaborative scheduling scheme under the same traffic conditions, to quantitatively record the jitter data of the two schemes, and to objectively analyze the improvement effect of the optimization scheme on network transmission stability.

[0082] Test environment: Using all hardware, software, and topology environments from the general pre-documentation, maintaining constant service traffic, and the services are a mix of broadband data services and latency-sensitive small packet services, closely matching the actual service mix of operators.

[0083] Test steps: 1. Build a traditional three-layer independent scheduling architecture, enable constant traffic transmission, and collect network latency jitter data continuously for 24 hours; 2. Without modifying the hardware link, switch to a three-layer optical network unified collaborative scheduling mechanism; 3. Keep the traffic size, data packet format, and service model completely consistent, and collect jitter data again continuously for 24 hours; 4. Calculate the average latency jitter of the two schemes, and calculate the data difference and reduction ratio.

[0084] The original test summary data is shown in Table 2.

[0085] Table 2. Raw summary data of latency jitter

[0086] Sampling details (continuous time-series sampling): 15 consecutive time-series sampling points were extracted from the middle of the test period. The detailed data is shown in Table 3.

[0087] Table 3 Continuous Time-Series Sampling Jitter Data

[0088] The table above shows the continuous sampling data within a fixed time window, which can intuitively reflect the difference in jitter fluctuation between the two schemes; all original sampling logs are stored as timestamp files, totaling 86,400 original records.

[0089] Data calculation: jitter reduction rate = (2.47 - 1.42) ÷ 2.47 × 100% = 42.51%. The statistical data is based on continuous sampling over 24 hours, with a sampling interval of 1 second, and a total of 86,400 effective sampling points per scheme.

[0090] Test conclusions: Under the same test conditions, the three-level collaborative scheduling scheme exhibits lower average latency jitter than the traditional scheduling scheme, with a jitter reduction of 42.51%. The optimized scheme shows smaller jitter amplitude and a smoother curve, resulting in significantly better network transmission stability than the traditional independent scheduling architecture.

[0091] Test Report 2: Transmission Reliability Test Report Test objective: To conduct long-term continuous stress testing, record packet loss, bit errors, intermittent interruptions and abnormal durations of the link, objectively analyze the transmission reliability performance of the optimization scheme, and verify the long-term stable operation capability of the link.

[0092] Test environment: Same as the general front-end environment, continuously increase the pressure on business traffic to simulate the peak concurrent business scenarios of operators, and amplify network anomalies such as instantaneous congestion and time slot preemption.

[0093] Test steps: 1. Build a test link and run it continuously for 1000 hours with stable business traffic; 2. Record packet loss, bit error, and link interruption every 1 second in the device log; 3. Calculate the total fault and abnormal duration and calculate the equivalent reliability for the whole year.

[0094] The original test statistics are shown in Table 4.

[0095] Table 4 Raw test statistics

[0096] Sampling details during high-load periods: During the test, link anomalies mainly originated from momentary port congestion and time slot preemption conflicts. Nine sets of sampling details from the high-load period are shown in Table 5.

[0097] Table 5 Sampling data during high-load periods

[0098] The above data was randomly sampled during periods of high load. During other periods, there was no packet loss or bit error on the link. All anomalies were caused by momentary port congestion, and there were no persistent link failures.

[0099] Test conclusion: After 1000 hours of continuous stress testing, the three-level collaborative scheduling scheme achieved an equivalent transmission reliability of 99.99004% throughout the year. It had few link anomalies and extremely low instantaneous packet loss rate, demonstrating excellent long-term stable transmission capabilities and meeting the high reliability requirements of commercial networks.

[0100] Test Report 3: Network Resource Utilization Test Report Test objective: Under the same bandwidth threshold and service traffic, compare the bandwidth usage of traditional independent scheduling and three-level collaborative scheduling, objectively count the difference in resource utilization, and verify the ability of cross-layer resource pooling scheduling to revitalize and optimize idle bandwidth.

[0101] Test environment: Maintaining consistent network topology, bandwidth limits, and service traffic models, the test environment combines high bandwidth, low latency, and computing power offloading of multiple types of services to simulate a multi-service integrated commercial scenario.

[0102] Test steps: 1. Traditional solution: Each of the three layers of the network reserves protection bandwidth and statically allocates time slots, with no resource interconnection between layers; 2. Calculate the average bandwidth utilization of each port and record the proportion of idle redundant bandwidth; 3. Switch to a three-level collaborative scheduling solution, reuse idle time slots, connect cross-layer redundant bandwidth, and realize dynamic resource pooling; 4. Under the same traffic conditions, calculate the overall network resource utilization again and complete the data comparison and analysis.

[0103] The original summary data is shown in Table 6.

[0104] Table 6. Raw summary data of network resource utilization

[0105] Sampling details during peak business hours: This statistical sampling period is 5 minutes, and 288 sets of average bandwidth data were collected evenly throughout the 24 hours. Table 7 shows the bandwidth sampling details for 15 consecutive sets during peak business hours on weekdays.

[0106] Table 7. Sampling data on bandwidth utilization during peak business hours

[0107] Data calculation: Utilization rate increase rate = (73.65-57.42) ÷ 57.42 × 100% = 28.26%.

[0108] Test results: Under the same workload, the three-level collaborative scheduling scheme achieves higher bandwidth resource utilization than the traditional scheduling scheme, with an improvement of 28.26%. The optimized scheme can effectively revitalize idle bandwidth between layers, reduce resource waste caused by static resource reservation, and significantly improve bandwidth utilization efficiency.

[0109] Test Report 4: Task Unloading Success Rate and Timeout Rate Test Report Test objective: To batch distribute heterogeneous computing power tasks, objectively statistically analyze task unloading success rate, timeout rate, and failure rate, verify the computing power task execution scheduling capabilities under two scheduling architectures, and compare task execution stability.

[0110] Test environment: Deployment of computing node clusters to simulate edge computing offloading services, with 10,000 concurrent tasks per day, including multiple types of heterogeneous computing tasks.

[0111] Test steps: 1. Batch distribution of heterogeneous computing power unloading tasks, including three types of tasks: latency-sensitive, computing power-intensive, and lightweight interactive; 2. Selection of computing power nodes based on unified evaluation criteria, and completion of task distribution and unloading execution; 3. Statistics on the number of successful unloadings, the number of task timeouts, and the number of task failures, and summary of execution metrics.

[0112] The original summary data is shown in Table 8.

[0113] Table 8. Original Summary Data of Task Unloading

[0114] Single Batch Task Sampling Details: In this test, the single batch execution details were statistically analyzed according to task type. 15 sets of task timing execution sampling data were randomly selected and are shown in Table 9. The data is complete and continuous.

[0115] Table 9 Sampling data for single batch task execution

[0116] Test Conclusion: In this batch heterogeneous computing task test, the three-level collaborative scheduling scheme achieved a task unloading success rate of 99.87% and a timeout rate within 0.12%. The algorithm can accurately match computing node resources and rationally plan task execution sequence. It has excellent adaptability to latency-sensitive, computing-intensive, and lightweight interactive heterogeneous tasks, and demonstrates excellent task scheduling stability and execution efficiency.

[0117] Test Report 5: Comparison Test Report on Computing Resource Utilization Test objective: Under the same business model, the same computing node configuration, and the same network environment, compare the computing resource utilization efficiency of the traditional three-layer independent scheduling scheme and the three-level collaborative scheduling scheme, objectively count the differences in the comprehensive utilization rate of computing power, and verify the ability of network-computing joint scheduling to optimize and revitalize computing resources.

[0118] Test environment: All hardware, software and topology environments are used in the general pre-documentation, keeping the computing node configuration, business task type and concurrency scale consistent. The test environment is not adjusted, eliminating the interference of hardware differences on the computing power statistics results.

[0119] Test steps: 1. Traditional three-layer independent scheduling scheme: adopts independent scheduling at each layer and passive access mode for computing nodes, running the same hybrid computing task; 2. Continuously collect computing node operation data for 24 hours, and statistically analyze CPU utilization, memory utilization, and computing load rate; 3. Keeping the environment unchanged, switch to a three-level collaborative scheduling scheme, enable the network-computing power joint scheduling mechanism, and dynamically allocate computing tasks; 4. Run the same hybrid computing task, and continuously collect the same dimensional indicators for 24 hours; 5. Calculate the average value and utilization improvement ratio of the two sets of data.

[0120] Test metrics and statistical methods: The overall utilization rate of computing power adopts a weighted statistical method: Overall utilization rate of computing power = CPU utilization rate × 0.5 + memory utilization rate × 0.3 + computing node load rate × 0.2; the statistical period is 5 minutes / time; the total number of sampling groups is 288 groups / scheme; the value is taken as the arithmetic mean within the test period.

[0121] The original summary data is shown in Table 10.

[0122] Table 10. Raw summary data on computing resource utilization.

[0123] Sampling details during peak business hours: This statistical sampling period is 5 minutes, with 288 sets of data collected evenly throughout the 24 hours. Table 11 shows the sampling details for 15 consecutive sets during the weekday peak business hours.

[0124] Table 11 Sampling data of computing power utilization during peak business hours

[0125] Data calculation: Utilization rate increase rate = (74.87 - 56.73) ÷ 56.73 × 100% = 31.98%.

[0126] Test Conclusion: Under the same test conditions, the three-level collaborative scheduling scheme achieves a higher overall utilization rate of computing power than the traditional three-level independent scheduling scheme, with an improvement of 31.98%. The optimized scheme can realize the coordinated scheduling of network and computing resources, effectively improving the problems of computing power idleness, resource idleness, and load imbalance in the traditional architecture. It results in fuller resource utilization, smaller load fluctuations, and better stability of the computing cluster operation.

[0127] Comprehensive Test Summary: All tests strictly adhered to the principles of comparison under identical hardware, traffic, and topology. The two solutions were compared and evaluated across five dimensions: latency jitter, transmission reliability, network bandwidth utilization, task offloading capability, and computing resource utilization. All test data was properly sampled, with complete timestamps, and was traceable and reproducible. The comprehensive test results show that compared to the traditional three-layer independent optical network scheduling architecture, the three-level collaborative scheduling scheme demonstrates significant improvements in transmission stability, link reliability, resource utilization, and task execution capability. The overall architecture exhibits excellent performance and meets commercial deployment and operation standards.

[0128] Compared with existing technologies, this application achieves three core breakthroughs through the above-mentioned technical solution, possessing significant technological advantages and industrial value. The specific beneficial effects are as follows: (1) Pioneering a unified scheduling mechanism for three-level optical networks to eliminate cross-domain scheduling blind spots: For the first time, the three-layer optical networks of OTN, SPN, and PON are regarded as a unified logical resource pool. Through LBU unified resource modeling, the standardized and pooled management of heterogeneous resources at the three layers is realized, and an end-to-end collaborative scheduling mechanism that runs through "access-aggregation-backbone" is constructed, eliminating the blind spots in existing technologies. , , The scheduling blind spots caused by the independent operation of each other. Testing showed that end-to-end latency jitter was reduced by more than 40%, and transmission reliability was improved to 99.99%, providing a truly end-to-end deterministic channel for computing tasks.

[0129] (2) Achieving deep integration of network and computing to improve overall resource utilization: The real-time status (load, energy consumption, resource redundancy) of computing nodes is deeply embedded into network routing decisions. A multi-dimensional comprehensive scoring model of "network-computing power" is designed to achieve joint optimal matching of "network path + computing node", breaking the architectural limitations of network-computing separation in existing technologies. Tests show that the overall network resource utilization rate is improved by more than 28%, and the computing power resource utilization rate is improved by more than 32%, effectively solving the problem of coexistence of local congestion and resource idleness, and reducing resource waste.

[0130] (3) Establish a linkage mechanism between task offloading and network assurance to provide deterministic QoS: Through a closed-loop process of "network resource reservation → confirmation of readiness → task offloading → resource reclamation", a deterministic mechanism of "first ensuring the network path, then executing task offloading" is realized, ensuring that the latency and bandwidth requirements of task transmission and computation are accurately met. After testing, the timeout rate of latency-sensitive tasks was reduced to below 0.2%, and the task offloading success rate reached 99.8%. It can perfectly adapt to computing power application scenarios with extreme requirements for latency and reliability, such as industrial internet and autonomous driving, and has strong practicality and industrial promotion value.

[0131] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A cross-layer collaborative scheduling and service task offloading method for computing power networks, executed by a collaborative controller, characterized in that, Includes the following steps: S10, Construct a unified cross-layer resource information model. The unified cross-layer resource information model includes abstracting the ODUk time slot resources of the OTN network, the FlexE slice resources of the SPN network, and the T-CONT time slot resources of the PON network into a unified logical bandwidth unit (LBU), collecting the status of computing power nodes, and generating and maintaining a network-computing power joint topology view containing a network resource topology matrix and a computing power resource matrix. S20: Receive a business task request and parse it to obtain a set of task characteristics and constraints; S30, based on the network-computing power joint topology view and the set of task characteristics and constraints, perform network-computing power collaborative decision-making: filter candidate computing power nodes that meet the computing power side constraints, calculate and filter end-to-end effective paths covering the entire link of PON access, SPN aggregation, and OTN backbone for each candidate computing power node, generate a candidate node-effective path pairing list, comprehensively score the pairing list, select the optimal solution, and determine the target offloading node and the end-to-end optimal transmission path; S40, Based on the end-to-end optimal transmission path, generate configuration instructions for PON segment, SPN segment, and OTN segment, and send them out in parallel to perform network resource reservation. After receiving the configuration success confirmation, trigger the service task to be unloaded to the target unloading node along the established path. S50, after the task is completed, a resource release command is issued to perform the coordinated reclamation of network and computing resources, and the network-computing power joint topology view is updated.

2. The cross-layer collaborative scheduling and service task offloading method for computing power networks as described in claim 1, characterized in that, In step S10, the acquisition of the state of the computing power node specifically includes: defining the feature vector of the computing power node as... ; in, ID It serves as a unique identifier for computing power nodes; CPU This indicates the node's CPU resource status, including CPU architecture and number of cores. and number of available cores ,satisfy ; MEM This indicates the node's memory resource status, including total memory capacity. and available memory capacity ,satisfy ; GPU This indicates the status of the node's GPU or NPU resources, including model and memory capacity. and available video memory capacity ; IO This indicates the node's storage IOPS performance, including the maximum IOPS value. and current available IOPS value ,satisfy ; L Indicates the current load rate of the node. ,in This represents the number of CPU cores currently used by the node. This represents the memory capacity already used by the node. This represents the amount of GPU memory already used by the node. , , The weighting coefficients and , ; E This represents the current energy consumption value of the node. ,in This refers to the idle energy consumption of a node. Energy consumption at full load for a node. This represents the maximum load threshold for the node.

3. The cross-layer collaborative scheduling and service task offloading method for computing power networks as described in claim 1, characterized in that, In step S10, generating and maintaining a network-computing power joint topology view that includes a network resource topology matrix and a computing power resource matrix specifically includes: The topology status of LBU resources in each domain is collected from the Layer 3 optical network controller, including the total number of LBUs. Number of available LBUs Analyze the LBU occupancy status of each link to construct a network resource topology matrix. ; Collect feature vectors from all computing nodes from the computing resource manager. Construct a computing resource matrix ,in M This represents the total number of computing power nodes, with each row corresponding to the feature vector of a single computing power node. The network resource topology matrix R and the computing power resource matrix C are merged to generate and maintain a joint network-computing power topology view. .

4. The cross-layer collaborative scheduling and service task offloading method for computing power networks as described in claim 1, characterized in that, In step S20, receiving the service task request and parsing it to obtain the task characteristics and constraint set specifically includes: Define each task request as a task feature vector. ,in As a unique identifier for the task, D For the size of the task data, Calculate the complexity metric for the task. The maximum tolerable latency for the task. This is the vector representing the minimum computational resource requirements of the task. Based on task feature vectors T Extracting network-side constraints and computing power constraints Forming a constraint set The network-side constraints These include bandwidth constraints, latency constraints, and LBU resource constraints, the computing power side constraints. This includes CPU constraints, memory constraints, GPU constraints, IOPS constraints, and load constraints.

5. The cross-layer collaborative scheduling and service task offloading method for computing power networks as described in claim 4, characterized in that, In the network-side constraints, the bandwidth constraint satisfies the minimum bandwidth required for task transmission. ,in The maximum transmission delay of the task and , To minimize the computational latency of the task, , The maximum GPU computing power among all computing nodes; The delay constraint satisfies the total end-to-end delay of the task. , ,in For the transmission delay of the task across three layers of optical network and , , , These are the transmission delays for the PON, SPN, and OTN segments, respectively. The computation latency of the task on the computing node; The LBU resource constraint satisfies the number of LBUs required for task transmission. ,in Indicates rounding up. This refers to the bandwidth granularity of a single LBU.

6. The cross-layer collaborative scheduling and service task offloading method for computing power networks as described in claim 4, characterized in that, In step S30, the screening of candidate computing power nodes that meet the computing power-side constraints specifically includes: based on the computing power resource matrix C in the network-computing power joint topology view, traversing all M Each computing node has a feature vector. Perform constraint verification to ensure that the constraints are met. All nodes subject to the constraints are included in the candidate computing power node set. ; The process of calculating and filtering end-to-end effective paths covering the entire PON access, SPN aggregation, and OTN backbone for each candidate computing power node specifically includes: using a K-shortest path algorithm, based on the network resource topology matrix R in the network-computing power joint topology view, to calculate the path from the source node s to the target node. There are K end-to-end logical paths, each path All paths cover the entire link from PON access and SPN aggregation to OTN backbone; each path is based on the network resource topology matrix R. Perform resource verification, specifically checking whether the number of available LBUs in the PON, SPN, and OTN segments meets the network-side constraints. Given the LBU resource constraints and bandwidth constraints, calculate the end-to-end transmission delay for this path. Retain all valid paths that satisfy all network-side constraints to form the candidate node. valid path set ;like If not empty, generate a list of candidate node-valid path pairs. All valid pairings form a pairing list. ,in This is the index of the candidate node in the set Scandidate. The path number. =1,2,...,K, For the first Candidate computing power nodes.

7. The cross-layer collaborative scheduling and service task offloading method for computing power networks as described in claim 6, characterized in that, In step S30, the comprehensive scoring of the pairing list specifically includes: Define the comprehensive scoring function ,in , , The weighting coefficients and , To score network performance, Scoring computing power nodes Score resource costs; Network performance rating The calculation formula is: ,in The maximum transmission delay for the task. For path The minimum number of available LBUs, The number of LBUs required for task transmission; Computing Node Rating The calculation formula is: ,in Candidate nodes load rate, To preset the load threshold, The number of available CPU cores for candidate nodes. Minimum number of CPU cores Candidate nodes Available memory capacity Minimum memory capacity; Resource cost rating The calculation formula is: ,in Candidate nodes Energy consumption value, This represents the maximum energy consumption value for all candidate nodes. This represents the total number of available LBUs across the entire network. The selection of the optimal solution specifically includes: traversing the pairing list. Calculate each pair Overall rating The pair with the highest score is selected as the optimal solution. Determine the target unloading node End-to-end optimal transmission path .

8. The cross-layer collaborative scheduling and service task offloading method for computing power networks as described in claim 1, characterized in that, In step S40, generating configuration instructions for the PON segment, SPN segment, and OTN segment based on the end-to-end optimal transmission path and issuing them in parallel to perform network resource reservation specifically includes: Optimal transmission path based on network domain The configuration is divided into PON segment configuration instructions, SPN segment configuration instructions, and OTN segment configuration instructions. The PON segment configuration instruction includes the PON segment link identifier and the number of reserved LBUs. The T-CONT time slot allocation scheme and access node port configuration parameters, the SPN segment configuration instructions include the SPN segment link identifier and the number of reserved LBUs. The FlexE slice allocation scheme and forwarding path configuration parameters, the OTN segment configuration instructions include the OTN segment link identifier, the number of reserved LBUs. ODUk time slot allocation scheme and cross-connect configuration parameters; The corresponding resource reservation and cross-connection configuration commands are sent in parallel to the PON controller, SPN controller, and OTN controller via the southbound interface; after receiving the commands, each layer controller verifies the number of available LBUs for the corresponding link in its domain. Confirmed to meet the requirements , Set the number of LBUs required for task transmission; lock the corresponding number of LBU resources, mark them as reserved, update the resource status of this domain, and establish cross-connections; after each layer controller completes the configuration, it sends a configuration success confirmation message to the coordination controller. If any controller fails to send a message, the coordination controller sends a resource release command to all controllers, terminates the current configuration, and re-executes step S30.

9. The cross-layer collaborative scheduling and service task offloading method for computing power networks as described in claim 1, characterized in that, In step S50, after the task is completed, issuing a resource release command to perform coordinated reclamation of network and computing resources, and updating the network-computing power joint topology view, specifically includes: When the target unloads the node After completing the task calculation, a task completion event is sent to the coordination controller. The coordination controller then issues connection teardown and resource release instructions to the OTN controller, SPN controller, and PON controller. The instructions include path identifiers and the number of reserved LBUs. After each layer controller performs the resource release operation, it updates the resource status of its domain, marks the released LBU as available, and sends a confirmation message of successful release to the coordination controller. After receiving the confirmation information, the collaborative controller updates the network resource topology matrix R in the network-computing power joint topology view, increasing the number of available LBUs for the corresponding link by the number of LBUs required for task transmission. Simultaneously update the feature vector of the target computing node. Restore available resources to Add the minimum computational resource requirement vector for the task It also sends a notification to the computing network orchestrator that the task is completed and resources have been successfully recycled.

10. A cross-layer collaborative scheduling and service task offloading system for computing power networks, characterized in that, The system includes a collaborative controller, which interfaces with the computing network orchestrator via a standardized interface to the north, and connects to the OTN controller, the SPN controller, and the PON controller via an OTN standard interface, respectively, to the PON controller via an OTN controller interface, and interfaces with the computing resource manager via a computing resource management interface. The collaborative controller is used to execute the cross-layer collaborative scheduling and service task offloading method for computing networks as described in any one of claims 1 to 9.

Images