Service carrying method and system in computing power network

Abstract

The present invention discloses a method for carrying services in a computing power network: for each service that can be provided by each MEC cloud in the computing power network, a computing power scheduling table is generated, and the computing power scheduling table for each service is sent to the PE node and CAN node of the access network. At the PE node, for each Service requested by the user, the corresponding computing power scheduling table is searched to find the most suitable CAN node, and the Service is forwarded to the most suitable CAN node; the CAN node further determines whether the computing task is met. If the local load is too high and cannot meet the user's computing power request, the CAN will search the local computing power scheduling table and find the next suitable CAN for forwarding. The present invention can find a suitable computing power service node in the computing power network, and under the condition of meeting the SLA constraints, the results are fed back to the user as soon as possible, without the user having to perceive the specific location of the computing power and other information. The present invention also provides a corresponding service carrying system in the computing power network.

Description

Technical Field

[0001] The present invention belongs to the field of communication technology, and more specifically, relates to a service carrying method and system in a computing power network. Background Art

[0002] The 5G packet transport network mainly carries various services requested by end users in the 5G bearer network, and these services are distributed in different edge computing (Mobile Edge Computing, MEC) clouds.

[0003] Driven by SLA (Service Level Agreement) constraints like latency, the core network is moving downward, and edge computing nodes like MEC are increasingly deployed at a highly distributed scale. The MEC cloud where a user's requested computing service is delivered is governed by a range of key factors, including the distribution of computing resources, service type, transaction model, and SLA constraints.

[0004] Because the location of computing nodes in the MEC cloud is transparent to users, forwarding decisions in the computing network must be made based on several key factors: the provided service (Service ID), reachability, SLA constraints, transaction model, and other constraints. However, it is impossible for packets to simultaneously search multiple forwarding decision tables during forwarding; otherwise, latency and jitter cannot be controlled. Summary of the Invention

[0005] In response to the above-mentioned defects or improvement needs of the existing technology, the present invention provides a service carrying method and system in a computing power network, which can find suitable computing power service nodes in the computing power network and feedback the results to users as soon as possible while meeting SLA constraints, without the user needing to perceive the specific location of the computing power and other information.

[0006] To achieve the above-mentioned purpose, according to one aspect of the present invention, there is provided a method for carrying services in a computing power network, characterized in that the method includes: for each service that can be provided by each MEC cloud in the computing power network, a computing power scheduling table is generated, and the computing power scheduling table of each service is sent to the PE node and CAN node of the access network. At the PE node, for each Service requested by the user, the corresponding computing power scheduling table is searched to find the most suitable CAN node, and the Service is forwarded to the most suitable CAN node; the CAN node further determines whether the computing task is met. If the local load is too high and cannot meet the user's computing power request, the CAN will search the local computing power scheduling table and find the next suitable CAN for forwarding.

[0007] In one embodiment of the present invention, the computing power scheduling table includes the following fields:

[0008] CAN_Node is a CAN node that can provide the Service_ID service; Com_cost is the computing power cost in the transaction model; Connect_cost represents the connection relationship; SLA_Metric is the sum of the delays of the service through all nodes, which is less than the maximum delay value that the business can tolerate. For each hop forwarding, the SLA_Metric value in the forwarding decision data structure needs to increase the consumed delay; X_Domain indicates whether it is a cross-domain service.

[0009] In one embodiment of the present invention, before searching the corresponding computing power scheduling table to find the most suitable CAN node, a set of CAN nodes that meet the conditions is first screened, specifically:

[0010] For a specific service requested by the user, the set of CAN nodes that meet the conditions is first screened. The components of this set are considered from four dimensions. Its prerequisite is the result of the truth table. These four are in an "and" relationship and are arranged in order of priority as follows:

[0011] T(path reachable) = 1;

[0012] T(SLA meets requirements) = 1;

[0013] T(service available) = 1;

[0014] T(transaction model exists) = 1;

[0015] If one of the above conditions is not met, the corresponding CAN_hit = +∞. For the remaining CAN sets that meet the above four conditions, the optimal CAN node is selected according to the computing power scheduling model.

[0016] In one embodiment of the present invention, the computing power scheduling model is specifically: CAN_hit = Com_cost × Connect_cost × SLA_Metric × X_Domain, and the one with the smallest CAN_hit value is selected.

[0017] In one embodiment of the present invention, before the PE node searches for the corresponding computing power scheduling table, pre-service analysis and scheduling are also performed, including: after the PE node searches for the user service request table, it updates the forwarding decision data structure according to the search result, and then searches for the computing power scheduling table based on the updated forwarding decision data structure.

[0018] In one embodiment of the present invention, the user service request table is issued by the orchestrator. The user service request table includes each user connected to the PE. The user service request table includes the following fields:

[0019] Account is each user's account number; ServiceID is the type of service the user has signed up for; Service Mode refers to whether it is a sticky service. If so, the corresponding CAN_No is given, indicating that the service requested by the user can only be provided by the MEC cloud connected to the CAN; if N / A, the system determines it based on the availability and load of the entire network resources.

[0020] In one embodiment of the present invention, the forwarding decision data structure includes the following fields:

[0021] Service ID, the type of service requested; Time To Live, the lifetime; Stickiness, the sticky service bit; Relay, the relay bit; Com_cost, the calculation cost field; CAN_Node, the CAN node number in the computing power network; Delay_t: the maximum delay value; Jitter_t, the maximum jitter value.

[0022] In one embodiment of the present invention, when a CAN node forwards a service to the next CAN node, the corresponding SLA field is updated: that is, the consumed delay is subtracted from the Delay_t in the current service request message forwarding decision data structure; when a serviceable MEC is found, the CAN notifies the PE node to update the path, that is, the remaining service requests for the service are sent directly to the selected CAN.

[0023] In one embodiment of the present invention, the SLA attribute requirements of the carried service are defined in the forwarding decision data structure. The algorithm for executing the SLA attribute requirements is expressed as follows:

[0024] A. Fill in the SLA constraint value into the corresponding field at the PE node;

[0025] B. Send to the CAN node selected by PE;

[0026] C. The CAN node determines whether S=1 service;

[0027] If C.1 is true, forward it to the scheduler and end this service request; if not, go to C.2;

[0028] C.2 determines whether the local server can provide the requested service. If so, forward the request to the local scheduler, which provides the corresponding computing power service. After the calculation is completed, the result is fed back to the user, and the service request is terminated. If not, proceed to C.3.

[0029] C.3CAN selects the next CAN node that can provide the service and updates the forwarding decision data structure in the corresponding service request message;

[0030] D. The new CAN receives the service request data and checks the SLA. If it exceeds the range, it sends an alarm message. Otherwise, go to C.

[0031] According to another aspect of the present invention, a service carrying system in a computing power network is also provided, including an MEC cloud, a PE node of an access network, and a CAN node. The service carrying system generates a computing power scheduling table for each service that can be provided by each MEC cloud in the computing power network, and sends the computing power scheduling table of each service to the PE node and CAN node of the access network. At the PE node, for each Service requested by the user, the corresponding computing power scheduling table is searched to find the most suitable CAN node, and the Service is forwarded to the most suitable CAN node; the CAN node further determines whether the computing task is met. If the local load is too high and cannot meet the user's computing power request, the CAN will search the local computing power scheduling table and find the next suitable CAN for forwarding.

[0032] In general, the above technical solutions conceived by the present invention have the following beneficial effects compared with the prior art:

[0033] (1) Service request parsing is performed by the front-end PE, which shares the load of the computing power routing node (CAN node) and avoids congestion of service requests;

[0034] (2) Through a simple forwarding decision model, the forwarding vectors with dimensions of more than 4 are converted into 1 dimension, thus greatly simplifying the forwarding logic and making it compatible with current forwarding equipment;

[0035] (3) Use the Service ID to filter out the set of computing power routing nodes that meet the requirements, and then use the computing power scheduling table and forwarding decision model to select the "optimal" computing power routing node for forwarding;

[0036] (4) A strict SLA constraint model is implemented, which is directly related to the service type and forwarding strategy. At the same time, it avoids the waste of bandwidth in the network caused by traffic related to service requests when the service is not available. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 This is a schematic diagram of a computing power network in an embodiment of the present invention;

[0038] Figure 2 is a schematic diagram of a forwarding decision data structure according to an embodiment of the present invention;

[0039] Figure 3 Schematic diagram of user service request forwarding in a computing power network according to an embodiment of the present invention;

[0040] Figure 4Schematic diagram of the pre-analysis principle of a PE node for a service request in an embodiment of the present invention;

[0041] Figure 5 Schematic diagram of the forwarding process of a service request by a CAN node in an embodiment of the present invention;

[0042] Figure 6 This is a schematic diagram of the computing power scheduling principle within the MEC cloud in an embodiment of the present invention. DETAILED DESCRIPTION

[0043] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely for the purpose of explaining the present invention and are not intended to limit the present invention. In addition, the technical features involved in the various embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other.

[0044] First, the key nouns and terms involved in the present invention are described or explained:

[0045] (1) Sticky services: a certain service for a certain user can only be completed on a specific MEC cloud computing node. For most services in the computing network, they are non-sticky, and the service requested by the user may be assigned to an "optimal" node;

[0046] (2) The service type (ServiceID), transaction model (e.g., transaction price), SLA parameters, etc. that each MEC cloud can provide are sent by the orchestrator or controller to each CAN node that executes the forwarding decision, and each CAN node generates a local forwarding decision table entry.

[0047] (3) The Controller Area Network (CAN) is a forwarding node in the computing network and is also the routing portal for a MEC cloud. The computing nodes within the MEC cloud perform computing tasks.

[0048] (4) The present invention is based on the Underlay computing network architecture, that is, when forwarding packets, the computing routing node needs to consider at least four major factors at the same time: path reachability, SLA constraints, transaction model and the load of the corresponding computing node, etc.

[0049] refer to Figure 1This is a diagram of a computing network. In this network, the network and computing power work together to deliver the requested service to the user as quickly as possible after completing it. However, all computing resources are distributed across MECs and the central cloud, making it uncertain which MEC or central cloud computing power will deliver the requested service. CAN nodes, working with orchestrators and routing protocols, create a map of the computing power distribution across the entire network. Guided by this map, they direct user requests to nodes with computing power to complete the requested service.

[0050] However, there are some exceptions. Some users' service requests can only be completed in a specific MEC cloud. This type of service is called a "sticky service". Its forwarding is relatively simple and can be generated by searching for the information sent by the orchestrator. Its source is the service agreement signed between the user and the operator.

[0051] (1) Define the forwarding decision data structure for controlling the forwarding decision. The forwarding decision data structure can reuse the first extension option of the IPv6 extension header, namely the routing option, to achieve message forwarding. For each service request of the user, the forwarding decision data structure needs to be parsed. Its basic definition is as follows: Figure 2 shown.

[0052] The forwarding decision data structure has a total of 128 bits, and the definitions of each field are as follows:

[0053] Service ID: 12 bits, indicating the type of service requested;

[0054] Time To Live (TTL): 4 bits, time to live. This prevents services from being passed around by CAN nodes, which could cause network storms. Generally, after 16 hops of forwarding, the latency in the SLA is no longer met.

[0055] Stickiness (S), 1 bit ， Sticky service bit. For a certain service of a certain user, if the S field is 1, it means that it can only be completed on a certain MEC computing node;

[0056] Relay (R): 1 bit, relay bit. If the R field is 1, it means that the service request will be sent to the next forwarding node;

[0057] Com_cost (C): 6 bits, computation cost field. Indicates the computation cost of executing the task;

[0058] CAN_Node(N): 12 bits, CAN node number in the computing network. This number can be used to route user-requested services to this CAN node.

[0059] Delay_t: 16 bits, maximum delay value. This belongs to the SLA Metric field, that is, the maximum delay that the service can tolerate. For each CAN, this field subtracts the consumed delay.

[0060] Jitter_t: 16 bits, maximum jitter value. This belongs to the SLA Metric field and specifies the maximum jitter value that the service can tolerate.

[0061] Reserved: 32 bits, reserved field. It can be expanded according to user needs.

[0062] (2) Computing power scheduling model

[0063] (2.1) Computing Power Scheduling Table

[0064] Figure 3 This is a schematic diagram of user service request forwarding in the computing network. For each service (APP for short) that each MEC cloud in the computing network can provide, a computing scheduling table (ComputingSchedulingTable) is generated and sent to the PE (Portal, enterprise portal platform) node and CAN node of the access network. Its basic structure is shown in Table 1. At the PE node, for each Service requested by the user, the corresponding Service ID table is searched, the most suitable CAN node is found, and it is forwarded to the CAN. The advantage of this method is that the service request resolution is pre-set (presetAPPresolution), which avoids the large workload of CAN resolution. Specifically, the message can be notified through the orchestrator, and the CAN node and PE node generate a computing scheduling table based on the received message.

[0065] Each CAN node in the computing network has a number: CAN_Node. Based on this number, the computing network can send requested services to the corresponding CAN node. This number is uniformly specified by the orchestrator or controller.

[0066] Table 1. Computing power scheduling table

[0067] CAN_Node Com_cost Connect_cost SLA_Metric X_Domain 1 1 1 10 1 2 1.2 3 9 1 3 1.8 2.4 4 1 … … 5 … … N 4.6 6 5 1

[0068] In this computing power scheduling table, CAN_Node represents the set of all CAN nodes that can provide the service specified by Service_ID. Com_cost represents the computing power cost in the transaction model. Connect_cost represents the connection relationship. If the corresponding PE and CAN node are directly connected, Connect_cost is 1. In all other cases, Connect_cost is greater than 1. The more nodes the requested service must traverse in the network, the larger the Connect_cost value. SLA_Metric represents the sum of the latency of the service across all nodes, less the maximum latency tolerated by the service. With each hop forwarded, the SLA_Metric value in the forwarding decision data structure increases, representing the consumed latency. X_Domain represents whether the service is cross-domain. If not, X_Domain = 1. If so, X_Domain represents the number of domains traversed. This value is set by the orchestrator and distributed to all forwarding nodes, including PEs and CAN nodes.

[0069] (2.2) Computing Power Scheduling Model

[0070] According to the computing power scheduling table, for each MEC cloud routing portal CAN node that can provide services, the following model can be used for selection:

[0071] CAN_hit = Com_cost × Connect_cost × SLA_Metric × X_Domain. The one with the smallest CAN_hit value is selected.

[0072] It is worth mentioning that the model can be extended as needed, thereby converting the multi-dimensional forwarding factor into a one-dimensional forwarding factor, maintaining compatibility with the existing deployed routers on the forwarding plane.

[0073] (3) Pre-service analysis and scheduling

[0074] (3.1) PE analysis and scheduling of services

[0075] For each user connected to a PE, the orchestrator sends a user service request form with the following structure:

[0076] Table 2 User service request table

[0077] Account ServiceID Service Methods CAN_No 1012011100 VR 1 17 1012011105 V&A 0 N / A 1012011109 VR 0 N / A 1014011108 V2X 1 10

[0078] In the above table, Account is the account number of each user, ServiceID is the type of service that the user has signed up for and can obtain; Service Mode refers to whether it is a sticky service. If so, the corresponding CAN_No is given, indicating that the service requested by the user can only be provided by the MEC cloud connected to the CAN; if it is N / A, the system will determine it based on the availability of the entire network resources and load conditions. Figure 4 shown.

[0079] After the PE node searches the user service request table, it updates the forwarding decision data structure based on the search results. It also searches the computing power scheduling table and selects the most economical computing power node according to the model calculation to send the service to the corresponding CAN node. CAN node selection is based on calculating CAN_hit and selecting the CAN node with the minimum value to send the service request.

[0080] (3.2) CAN node forwarding scheduling of services

[0081] At any time, the MEC's ​​computing power resources are promptly notified to the MEC cloud's routing portal CAN node. Compared to PE nodes, CAN nodes are aware of the local computing load. If the local load is too high to meet the user's computing power request, the CAN node will search the local computing power scheduling table and find the next suitable CAN node for forwarding.

[0082] For a specific service requested by the user, the set of CAN nodes that meet the conditions is first screened. The components of this set are mainly considered from four dimensions. Its prerequisite is the result of the truth table. These four are in an "and" relationship and are arranged in order of priority as follows:

[0083] T(path reachable) = 1;

[0084] T(SLA meets requirements) = 1;

[0085] T(service available) = 1;

[0086] T(transaction model exists) = 1;

[0087] If any of the above conditions is not met, the corresponding CAN_hit = +∞. For the remaining CAN sets that meet the above four conditions, the optimal CAN node is selected according to the above computing power scheduling model.

[0088] When CAN forwards the service to the next CAN node, the corresponding SLA field is updated: that is, the consumed delay is subtracted from the Delay_t in the current service request message forwarding decision data structure; when a serviceable MEC is found, CAN notifies the PE node to update the path, that is, the remaining service requests for the service are sent directly to the selected CAN. Figure 5 shown.

[0089] (3.3) SLA constraints for user services

[0090] For ease of description, SLA processing at the PE and the MEC cloud routing portal (CAN) is described separately below. The basic idea is that for all service requests arriving at the CAN, the SLA constraints are first checked. If they cannot be met, an alarm is sent and a "Service unavailable!" message is fed back to the service requester.

[0091] The forwarding decision data structure defines the SLA attribute requirements for the service being carried. The definition of this field can vary depending on the service and the Service ID, such as delay (Delay_t, μs, 16 bits) and tolerable jitter (Jitter_T, μs, 16 bits). The algorithm for executing SLA attribute requirements is as follows:

[0092] A. Fill in the SLA constraint value into the corresponding field at the PE node;

[0093] B. Send to the CAN node selected by PE;

[0094] C. The CAN node determines whether S=1 service;

[0095] If C.1 is true, forward it to the scheduler and end this service request; if not, go to C.2;

[0096] C.2 Can the local server provide the required service? If yes, the request is forwarded to the local scheduler, which provides the corresponding computing power service. After the calculation is completed, the result is fed back to the user and the service request is terminated. If not, the request is forwarded to C.3.

[0097] C.3CAN selects the next CAN node that can provide service and updates the forwarding decision data structure in the corresponding service request message; for example, S=0, R=1, TTL-1, SLA corresponding field minus the consumed delay, and checks whether Jitter_t exceeds the range.

[0098] D. The new CAN receives the service request data and checks the SLA. If it exceeds the range, it sends an alarm and returns a "Service unavailable!" message to the source. Otherwise, go to C.

[0099] (3.4) MEC cloud computing power scheduling

[0100] Within the corresponding MEC, the CAN node sends the received service request to the scheduler and decomposes it into tasks. After obtaining resources, the resource manager assigns the task to the corresponding computing node to complete the service required by the user and notifies the CAN to feedback to the PE and connected users. Figure 6 shown.

[0101] Furthermore, the present invention also provides a service carrying system in a computing power network, including an MEC cloud, a PE node and a CAN node of an access network. The service carrying system generates a computing power scheduling table for each service that can be provided by each MEC cloud in the computing power network, and sends the computing power scheduling table of each service to the PE node and CAN node of the access network. At the PE node, for each Service requested by the user, the corresponding computing power scheduling table is searched to find the most suitable CAN node, and the Service is forwarded to the most suitable CAN node; the CAN node further determines whether the computing task is met. If the local load is too high and cannot meet the user's computing power request, the CAN will search the local computing power scheduling table and find the next suitable CAN for forwarding.

[0102] It will be easily understood by those skilled in the art that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for carrying services in a computing network, characterized in that: The method includes: for each service that can be provided by each MEC cloud in the computing network, a computing power scheduling table is generated, the computing power scheduling table of each service is sent to the PE node and CAN node of the access network, and for each Service requested by the user at the PE node, the corresponding computing power scheduling table is searched to find the most suitable CAN node, and the Service is forwarded to the most suitable CAN node; the computing power scheduling table includes the following fields: CAN_Node is the CAN node that can provide the Service_ID service; Com_cost is the computing power cost overhead in the transaction model; Connect_cost represents the connection relationship; SLA_Metric is the sum of the delays of the service through all nodes, which is less than the maximum delay value that the business can tolerate. For each hop forwarding, the SLA_Metric value in the forwarding decision data structure needs to be increased. The consumed delay; X_Domain indicates whether it is a cross-domain service; the CAN node further determines whether the computing task is satisfied. If the local load is too high and cannot meet the user's computing power request, the CAN will search the local computing power scheduling table and find the next suitable CAN for forwarding; before searching the corresponding computing power scheduling table to find the most suitable CAN node, first filter the set of CAN nodes that meet the conditions. Specifically: for a specific service requested by the user, first filter the set of CAN nodes that meet the conditions. The components of the set are considered from four dimensions. Its prerequisite is the result of the truth table. These four are in an "and" relationship and are arranged in priority as follows: T (path reachable) = 1; T (SLA meets the requirements) = 1; T (service is available) = 1; T (transaction model exists) = 1; If any of the above is not satisfied, the corresponding CAN_hit = +∞, for the remaining CAN sets that meet the above four conditions, the optimal CAN node is selected according to the computing power scheduling model; the computing power scheduling model is specifically: CAN_hit = Com_cost × Connect_cost × SLA_Metric × X_Domain, and the one with the smallest CAN_hit value is selected.

2. The method for carrying services in a computing network according to claim 1, wherein: Before the PE node searches for the corresponding computing power scheduling table, it also performs pre-service analysis and scheduling, including: after the PE node searches the user service request table, it updates the forwarding decision data structure according to the search results, and then searches for the computing power scheduling table based on the updated forwarding decision data structure.

3. The method for carrying services in a computing network according to claim 2, wherein: The user service request table is issued by the orchestrator and contains each user connected to the PE. The user service request table includes the following fields: Account is each user's account number; ServiceID is the type of service the user has signed up for; Service Mode refers to whether it is a sticky service. If so, the corresponding CAN_No is given, indicating that the service requested by the user can only be provided by the MEC cloud connected to the CAN; if N / A, the system determines it based on the availability and load of the entire network resources.

4. The method for carrying services in a computing power network according to claim 2, wherein: The forwarding decision data structure includes the following fields: Service ID, the type of service requested; Time To Live, the lifetime; Stickiness, the sticky service bit; Relay, the relay bit; Com_cost, the calculation cost field; CAN_Node, the CAN node number in the computing power network; Delay_t: the maximum delay value; Jitter_t, the maximum jitter value.

5. The method for carrying services in a computing network according to claim 1, wherein: When a CAN node forwards the service to the next CAN node, the corresponding SLA field must be updated: that is, the Delay_t in the current service request message forwarding decision data structure is subtracted from the consumed delay; when a serviceable MEC is found, the CAN notifies the PE node to update the path, that is, the remaining service requests for the service are sent directly to the selected CAN.

6. The method for carrying services in a computing network according to claim 1, wherein: The SLA attribute requirements of the carried service are defined in the forwarding decision data structure. The algorithm for executing the SLA attribute requirements is described as follows: A. Fill in the SLA constraint value into the corresponding field at the PE node; B. Send to the CAN node selected by PE; C. The CAN node determines whether S=1 service; If C.1 is true, forward it to the scheduler and end this service request; if not, go to C.2; C.2 determines whether the local server can provide the requested service. If so, the request is forwarded to the local scheduler, which provides the corresponding computing power. After the calculation is completed, the result is fed back to the user, and the service request is terminated. If not, the request goes to C.

3. C.3 CAN selects the next CAN node that can provide the service and updates the forwarding decision data structure in the corresponding service request message; D. The new CAN receives the service request data and checks the SLA. If it exceeds the range, it sends an alarm message. Otherwise, it goes to C.

7. A service carrying system in a computing power network, characterized in that: Including MEC cloud, PE node and CAN node of access network, the service carrying system generates a computing power scheduling table for each service that can be provided by each MEC cloud in the computing power network, and sends the computing power scheduling table of each service to the PE node and CAN node of the access network. At the PE node, for each Service requested by the user, the corresponding computing power scheduling table is searched to find the most suitable CAN node, and the Service is forwarded to the most suitable CAN node; the computing power scheduling table includes the following fields: CAN_Node is the CAN node that can provide Service_ID service; Com_cost is the computing power cost overhead in the transaction model; Connect_cost represents the connection relationship; SLA_Metric is the sum of the delays of the service through all nodes, which is less than the maximum delay value that the business can tolerate. For each hop forwarding, the SLA_ The metric value needs to add the consumed delay; X_Domain indicates whether it is a cross-domain service; the CAN node further determines whether the computing task is satisfied. If the local load is too high and cannot meet the user's computing power request, the CAN will search the local computing power scheduling table and find the next suitable CAN for forwarding; before searching the corresponding computing power scheduling table to find the most suitable CAN node, first filter the set of CAN nodes that meet the conditions, specifically: for a specific service requested by the user, first filter the set of CAN nodes that meet the conditions. The components of the set are considered from four dimensions, and its prerequisite is the result of the truth table. These four are in an "and" relationship and are arranged in priority as follows: T (path reachable) = 1; T (SLA meets the requirements) = 1; T (service is available) = 1; T (transaction model exists) = 1; If one of the above is not satisfied, the corresponding CAN_hit = +∞, for the remaining CAN sets that meet the above four conditions, the optimal CAN node is selected according to the computing power scheduling model; the computing power scheduling model is specifically: CAN_hit = Com_cost × Connect_cost × SLA_Metric × X_Domain, and the one with the smallest CAN_hit value is selected.

Images