Cloud-edge collaborative service chain deployment method and device

Abstract

The present application provides a cloud-edge collaborative service chain deployment method and device, the method comprising: applying a cloud-side algorithm based on network calculation to determine whether the cloud center network currently meets the latency requirement corresponding to the service chain request, and if so, calling the optimal path algorithm to obtain the first target deployment path of the service chain request in the cloud center network and deploying the service chain request in the cloud center network; if the service chain request is not deployed in the cloud center network, and if it is known based on the edge algorithm that the edge system currently meets the resource requirement corresponding to the service chain request, then determining whether the edge system currently meets the latency requirement, if not, and if a second target deployment path for the service chain request in the edge system is generated based on the optimal path algorithm and the latency requirement, then deploying the service chain request in the edge system based on the second target deployment path. The present application can realize dynamic collaborative deployment of service chains in cloud and edge environments under the premise of high latency requirements and limited resources.

Description

Technical Field

[0001] The present application relates to the technical field of service chain deployment, and in particular to a cloud-edge collaborative service chain deployment method and device. Background Art

[0002] A service chain (SFC) combines a certain number of virtual network functions (VNFs) based on user needs. This approach addresses the high costs and deployment difficulties faced by operators in providing network services, making it ideally suited for the rapidly increasing Internet of Things (IoT) traffic. Many IoT scenarios often place stringent requirements on end-to-end latency. For example, autonomous driving requires a network latency of less than 10ms to ensure timely vehicle operation. AR and VR devices require a latency of less than 20ms to ensure synchronization between user actions and the visuals. Therefore, optimizing service chain deployment is crucial to ensure stringent end-to-end latency for IoT devices.

[0003] Currently, deploying service chains solely in the cloud, despite ample resources, can't guarantee high latency between the cloud and edge, making it unsuitable for scenarios with high real-time requirements. Deploying service chains solely in edge environments can eliminate latency between the cloud and edge, but resources in edge environments are limited, making service chain deployment reliability unreliable. One existing service chain deployment approach uses a service chain deployment algorithm that assumes the latency of virtual network functions is fixed, but this approach introduces significant errors in the calculation of the end-to-end latency of the service chain. Another existing service chain deployment approach uses a service chain deployment algorithm based on queuing theory. However, since the latency calculated based on queuing theory is the average latency of packets, it cannot guarantee that every packet will be transmitted within the calculated latency, making it unsuitable for latency-sensitive IoT scenarios such as autonomous driving. Yet another existing service chain deployment approach uses a service chain deployment algorithm in a cloud-edge environment, but this algorithm's consideration of latency is imprecise, resulting in significant errors and making it unsuitable for IoT scenarios. In other words, existing service chain deployment approaches cannot simultaneously meet the resource requirements of service chain deployment and the high latency requirements of application scenarios.

[0004] Therefore, how to realize service chain deployment in cloud and edge environments under the premise of high latency requirements and limited resources is an urgent problem that needs to be solved. Summary of the Invention

[0005] In view of this, the embodiments of the present application provide a cloud-edge collaborative service chain deployment method and device to eliminate or improve one or more defects in the prior art.

[0006] One aspect of the present application provides a cloud-edge collaborative service chain deployment method, including:

[0007] Apply a cloud-based algorithm based on network calculation to determine whether the cloud center network currently meets the latency requirement corresponding to the service chain request. If so, call the optimal path algorithm to obtain the first target deployment path of the service chain request in the cloud center network and deploy the service chain request in the cloud center network based on the first target deployment path;

[0008] If the service chain request is not deployed in the cloud center network, and if it is known based on the edge algorithm that the edge system currently meets the resource requirements corresponding to the service chain request, then it is determined whether the edge system currently meets the delay requirement. If not, and if a second target deployment path for the service chain request in the edge system is generated based on the optimal path algorithm and the delay requirement, then the service chain request is deployed in the edge system based on the second target deployment path.

[0009] In some embodiments of the present application, the application uses a cloud-based algorithm based on network calculus to determine whether the cloud center network currently meets the latency requirement corresponding to the service chain request. If so, the optimal path algorithm is called to obtain a first target deployment path for the service chain request in the cloud center network and deploy the service chain request in the cloud center network based on the first target deployment path, including:

[0010] Receive a service chain request and obtain the latency requirement value corresponding to the service chain request;

[0011] Determine the upper limit of the delay of the service chain request to be deployed in the cloud center network based on the network calculation method;

[0012] Determine whether the upper limit of the delay of the cloud center network is less than or equal to the delay requirement value, and if so, store the service chain request in a preset cloud service chain set;

[0013] For the service chain request in the cloud service chain set, the optimal path algorithm is called to obtain the target deployment path of the service chain request in the cloud center network, the target deployment path is determined as the first target deployment path, and the service chain request is deployed in the cloud center network based on the first target deployment path.

[0014] In some embodiments of the present application, further comprising:

[0015] If it is determined that the current delay upper limit value of the cloud center network is greater than the delay requirement value of the service chain request, the service chain request is stored in a preset edge service chain set.

[0016] In some embodiments of the present application, if the service chain request is not deployed in the cloud center network, and if it is known based on the edge algorithm that the edge system currently meets the resource requirements corresponding to the service chain request, then it is determined whether the edge system currently meets the delay requirement; if not, and if a second target deployment path for the service chain request in the edge system is generated according to the optimal path algorithm and the delay requirement, then the service chain request is deployed in the edge system based on the second target deployment path, including:

[0017] Obtaining a service chain resource requirement value of the service chain request and a VNF resource requirement value of each virtual network function VNF in the service chain request;

[0018] Generate an initial deployment plan for the service chain request in the edge system according to the service chain resource requirement value, the VNF resource requirement value, and the current available resource value of each edge node in the edge system;

[0019] Determine whether the service chain resource demand value is less than or equal to the current available resource value of the edge system; if so, determine a first latency upper limit for the service chain request to be deployed on the edge system based on a network calculation method;

[0020] determining whether the first delay upper limit value is less than or equal to the delay requirement value; if not, invoking the optimal path algorithm to generate a target deployment path for the service chain request in the edge system;

[0021] Based on a network calculation method, applying the deployment path to re-determine a second upper limit of the delay for the service chain request to be deployed on the edge system;

[0022] Determine whether the second delay upper limit value is less than or equal to the delay requirement value. If so, confirm the target deployment path of the service chain request in the edge system as the second target deployment path, and deploy the service chain request in the edge system based on the second target deployment path.

[0023] In some embodiments of the present application, further comprising:

[0024] If it is determined that the first delay upper limit value is less than or equal to the delay requirement value, the initial deployment plan is used as the second target deployment path, and the service chain request is deployed in the edge system based on the second target deployment path.

[0025] In some embodiments of the present application, further comprising:

[0026] If it is determined that the service chain resource requirement value is greater than the current available resource value of the edge system, or if it is determined that the second delay upper limit value is still greater than the delay requirement value, the service chain request is refused to be executed.

[0027] In some embodiments of the present application, the optimal path algorithm includes:

[0028] Obtaining a deployment path of the service chain request in a current target environment, wherein the target environment includes: the cloud center network or the edge system;

[0029] Determine whether each service node in the deployment path meets the resource requirements corresponding to the service chain request, and if so, determine the deployment path as the optimal path;

[0030] If there is a service node among the service nodes in the deployment path that does not meet the resource requirements corresponding to the service chain request, then delete the service node that does not meet the resource requirements in the deployment path, and then determine the deployment path as the optimal path;

[0031] It is determined whether each service node in the optimal path meets the pre-examination bandwidth restriction. If so, the optimal path is determined as the target deployment path.

[0032] Another aspect of the present application provides a cloud-edge collaborative service chain deployment device, including:

[0033] A cloud deployment module is used to determine whether the cloud center network currently meets the latency requirement corresponding to the service chain request based on the cloud algorithm. If so, the optimal path algorithm is called to obtain the first target deployment path of the service chain request in the cloud center network and deploy the service chain request in the cloud center network based on the first target deployment path;

[0034] An edge deployment module is used to determine whether the edge system currently meets the latency requirement if the service chain request is not deployed in the cloud center network and if it is known based on the edge algorithm that the edge system currently meets the resource requirements corresponding to the service chain request; if not, and if a second target deployment path for the service chain request in the edge system is generated based on the optimal path algorithm and the latency requirement, then deploy the service chain request in the edge system based on the second target deployment path.

[0035] Another aspect of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the cloud-edge collaborative service chain deployment method when executing the computer program.

[0036] Another aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, which implements the cloud-edge collaborative service chain deployment method when executed by a processor.

[0037] The cloud-edge collaborative service chain deployment method provided in the present application applies a cloud-side algorithm based on network calculus to determine whether the cloud center network currently meets the latency requirements corresponding to the service chain request. If so, the optimal path algorithm is called to obtain the first target deployment path of the service chain request in the cloud center network and deploy the service chain request in the cloud center network based on the first target deployment path; if the service chain request is not deployed in the cloud center network, and if it is known based on the edge algorithm that the edge system currently meets the resource requirements corresponding to the service chain request, then it is determined whether the edge system currently meets the latency requirements. If not, and if a second target deployment path for the service chain request in the edge system is generated based on the optimal path algorithm and the latency requirements, then the service chain request is deployed in the edge system based on the second target deployment path. By applying network calculus theory to cloud-edge collaborative service chain deployment, if the latency requirements of the service chain are met, it is preferentially deployed in the cloud to save edge resources. If the upper limit of the delay deployed in the cloud is greater than the delay requirement of the service chain, then the service chain will be deployed on the edge node; this can ensure the reliability of the network service with a certain delay, and can deploy the service chain with a certain delay upper limit under resource constraints, which can effectively improve the delay accuracy of the service chain deployment; and then it can realize the dynamic collaborative deployment of the service chain in the cloud and edge environment under the premise of high latency requirements and resource constraints, which can provide an end-to-end delay guarantee for the deployed service chain, and can improve the effectiveness and reliability of the collaborative deployment of the service chain in the cloud and edge systems, effectively reduce errors, and improve the effectiveness and reliability of the service chain deployment, which is especially suitable for IoT scenarios with high latency requirements.

[0038] Additional advantages, purposes, and features of the present application will be described in part in the following description and will become apparent to those skilled in the art upon study of the following or may be learned from practice of the present application. The purposes and other advantages of the present application may be achieved and obtained by the structures specifically pointed out in the specification and drawings.

[0039] Those skilled in the art will understand that the purposes and advantages that can be achieved by the present application are not limited to the above specific description, and the above and other purposes that can be achieved by the present application will be more clearly understood based on the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The drawings described herein are intended to provide a further understanding of the present application, constitute a part of the present application, and do not constitute a limitation of the present application. The components in the drawings are not drawn to scale, but are only for the purpose of illustrating the principles of the present application. In order to facilitate the illustration and description of some parts of the present application, the corresponding parts in the drawings may be enlarged, that is, they may become larger than other components in the exemplary device actually manufactured according to the present application. In the drawings:

[0041] Figure 1 This is a schematic diagram of the overall process of the cloud-edge collaborative service chain deployment method in one embodiment of the present application.

[0042] Figure 2 This is a diagram showing an example of a curve for network calculation.

[0043] Figure 3 This figure shows an example of the composition of the end-to-end delay of the service chain.

[0044] Figure 4 This is a specific flow chart of step 100 in the cloud-edge collaborative service chain deployment method in one embodiment of the present application.

[0045] Figure 5 This is a specific flow chart of step 200 in the cloud-edge collaborative service chain deployment method in one embodiment of the present application.

[0046] Figure 6 This is a structural diagram of a cloud-edge collaborative service chain deployment device in another embodiment of the present application. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail in conjunction with the embodiments and drawings. Here, the illustrative embodiments of this application and their descriptions are used to explain this application, but are not intended to limit this application.

[0048] It should also be noted here that in order to avoid obscuring the present application due to unnecessary details, the accompanying drawings only show structures and / or processing steps that are closely related to the scheme according to the present application, while other details that are not closely related to the present application are omitted.

[0049] It should be emphasized that the term "include / comprises" when used herein refers to the existence of features, elements, steps or components, but does not exclude the existence or addition of one or more other features, elements, steps or components.

[0050] It should also be noted that, unless otherwise specified, the term "connection" herein may refer not only to a direct connection but also to an indirect connection involving an intermediate.

[0051] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings. In the accompanying drawings, the same reference numerals represent the same or similar components, or the same or similar steps.

[0052] In recent years, the rapid advancement of IoT technology has led to a dramatic increase in new application scenarios for existing IoT devices, such as autonomous driving, smart healthcare, and smart manufacturing. This proliferation of IoT device applications has also led to a surge in the traffic generated by these devices, posing a significant challenge to traditional network infrastructure. This is because traditional network infrastructure is built on dedicated hardware. Operators' provision of network function services based on this infrastructure is costly and difficult to deploy, making it difficult to meet the network service requirements of the IoT. Consequently, Network Function Virtualization (NFV) has emerged. NFV decouples network services from specific hardware. As a result, network services such as NAT, firewalls, intrusion detection, DNS, and caching can be delivered as software and deployed on general-purpose hardware platforms. This provides significant flexibility and resiliency in the design, deployment, and management of network services, addressing the high costs and deployment difficulties faced by operators in providing network services.

[0053] Network functions implemented through network function virtualization, such as NAT and firewalls, are called virtual network functions (VNFs). Combining a certain number of VNFs based on user needs constitutes a service chain. Deploying the individual VNFs that make up the service chain onto servers is called service chain deployment. Different users require different network services, with varying requirements for latency, computing power, and so on. Therefore, determining how to deploy service chains is crucial.

[0054] Many IoT scenarios often have stringent requirements for end-to-end latency. For example, autonomous driving requires a network latency of less than 10ms to ensure timely vehicle operation. AR and VR devices require a network latency of less than 20ms to ensure synchronization between human movement and the visuals. Therefore, strict guarantees for the end-to-end latency of IoT devices are essential. Deploying service chains solely in the cloud, while providing ample resources, can hinder high latency between the cloud and edge, making them unsuitable for scenarios requiring high real-time performance. Deploying service chains solely in edge environments can mitigate latency between the cloud and edge, but resource constraints in edge environments make deployment reliability unreliable.

[0055] There is currently extensive research on optimizing service chain deployment to provide end-to-end latency guarantees, but none of this work addresses the issue of providing strict latency guarantees. One existing service chain deployment approach utilizes the SFC deployment algorithm, which assumes constant VNF latency. During the modeling process, this assumes constant latency for packets passing through the VNF, leading to significant errors in the calculation of the end-to-end latency of the service chain. Each VNF has different resource requirements, and the amount of resources allocated to a VNF affects the packet processing rate, and thus the latency of packets passing through the VNF. Another existing service chain deployment approach utilizes the SFC deployment algorithm based on queuing theory to address this issue. However, the latency calculated based on queuing theory is the average latency of packets. Therefore, it cannot guarantee that every packet will be transmitted within the calculated latency. This is obviously unacceptable for latency-sensitive IoT scenarios such as autonomous driving. Other researchers have pioneered the use of network calculus to calculate the end-to-end latency of service chains. However, these authors only considered the scenario of a single service chain. Other researchers have considered resource competition among multiple service chains and derived an upper bound on the end-to-end latency of service chains based on network calculus. However, these studies only derived the latency of service chains and did not consider their deployment.

[0056] Some researchers are currently studying service chain deployment in cloud edge environments. For example, they formulated the SFC placement problem into two sub-problems: graph matching and SFC mapping. They proposed a linear programming-based approach to solve the graph matching problem and then designed a Hungarian-based placement algorithm to solve the SFC mapping problem. However, this work only considered computing resources and not latency. Other researchers considered latency, but did not account for the high link latency between cloud and edge nodes. Another scholar proposed a dynamic VNF rescheduling method based on latency fluctuations. However, this work only considered VNF deployment at edge nodes, ignoring the cloud center. Consequently, when the number of SFC requests increases, deployment failures may occur due to insufficient edge resources, making it difficult to provide reliability. Another scholar comprehensively considered latency and resource consumption in cloud edge environments, but the authors did not consider the VNF computational latency when calculating latency, which can lead to large errors.

[0057] Specifically, existing service chain deployment methods can be summarized into the following three categories:

[0058] 1) SFC deployment algorithm assuming constant VNF latency: Assuming a constant latency for packets passing through the VNF will result in significant errors in the calculation of the end-to-end latency of the service chain. Each VNF has different resource requirements, and the amount of resources allocated to a VNF affects the packet processing rate, and thus the latency of packets passing through the VNF.

[0059] 2) SFC deployment algorithm based on queuing theory: The latency calculated based on queuing theory is the average latency of data packets. Therefore, it cannot guarantee that every data packet will be transmitted within the calculated latency. However, some latency-sensitive IoT scenarios, such as autonomous driving, cannot tolerate this situation.

[0060] 3) SFC deployment algorithms in cloud-edge environments: Some of the algorithms in this area consider only computing resources but not latency; some consider latency but not the high link latency between cloud and edge nodes; and some consider latency and resource consumption in cloud-edge environments but fail to factor in VNF computational latency when calculating latency. Overall, this work's consideration of latency is imprecise, resulting in large errors and making it unsuitable for IoT scenarios.

[0061] Therefore, how to realize service chain deployment in cloud and edge environments under the premise of high latency requirements and limited resources is an urgent problem that needs to be solved.

[0062] Based on this, in this application, we applied network calculus theory to the deployment of cloud-edge collaborative service chains for the first time, aiming to provide an end-to-end latency guarantee for the deployed service chains. However, we encountered two challenges in implementing cloud-edge collaborative service chain deployment. The first challenge was the high latency of the link between the cloud and the edge, and how to ensure the reliability of the network services provided with a deterministic latency. The second challenge was the limited resources of edge nodes, and how to deploy a service chain with a deterministic latency limit under resource constraints.

[0063] To address these challenges, the inventors first modeled the service chain deployment problem for cloud-edge collaboration. Because network calculus introduces nonlinear constraints when deriving the upper bound on service chain latency, the problem was ultimately modeled as a mixed-integer nonlinear program. We first proved that this problem is NP-hard and can be verified in polynomial time, and then proposed a heuristic algorithm to address the two challenges mentioned above.

[0064] This application first uses network calculus theory to calculate the upper limit of the service chain's latency when deployed in the cloud. If the service chain's latency requirements are met, deployment in the cloud is prioritized to conserve edge resources. If the upper limit of the cloud deployment latency exceeds the service chain's latency requirements, a second deployment method is adopted, deploying the service chain on edge nodes.

[0065] In one or more embodiments of the present application, the cloud-edge collaborative deployment refers to the collaborative deployment of the cloud and the edge, specifically the collaborative deployment between the cloud center network and the edge system. The cloud center network can deploy various cloud servers. The edge system is composed of various edge nodes, and the edge nodes can be servers or client devices with data processing functions.

[0066] In one or more embodiments of the present application, the service chain may also be referred to as a service function chain. A service chain request may be written as SFCs.

[0067] In one or more embodiments of the present application, some parameters are described as follows:

[0068] G,refers to the set of service chains deployed in the cloud center network;

[0069] E, E', refers to the set of service chains deployed at edge nodes;

[0070] It refers to the upper limit of the latency of service chain requests deployed in the cloud center network;

[0071] Refers to the latency requirement corresponding to the service chain request;

[0072] It refers to the resource requirements requested by the service chain;

[0073] Refers to the resource requirements of each VNF that belongs to the service chain request;

[0074] Fs, Fs', refers to the set of VNFs that belong to the service chain request;

[0075] R v , refers to the current available resources of the edge system;

[0076] v, refers to a server in a cloud-centric network or edge system. The server can be a cloud server in a cloud-centric network or an edge node in an edge system;

[0077] V, V′,refers to the set of servers in the edge system;

[0078] R v , refers to the available resources of each edge node in the edge node set;

[0079] It refers to the upper limit of the latency of service chain requests deployed in the edge system;

[0080] It refers to the upper limit of the delay of the service chain request deployed in the edge system after obtaining the fastest path through Algorithm 3;

[0081] l ij , refers to the path formed by link i and link j;

[0082] L, refers to the path set;

[0083] Refers to the bandwidth demand of the current service chain;

[0084] It refers to the remaining bandwidth between link i and link j.

[0085] The details are described in detail through the following examples.

[0086] This application embodiment provides a cloud edge collaborative service chain deployment method, see Figure 1 The cloud-edge collaborative service chain deployment method specifically includes the following contents:

[0087] Step 100: Apply a cloud-based algorithm based on network calculation to determine whether the cloud center network currently meets the latency requirements corresponding to the service chain request. If so, call the optimal path algorithm to obtain the first target deployment path of the service chain request in the cloud center network and deploy the service chain request in the cloud center network based on the first target deployment path.

[0088] It is understandable that step 100 of the present application introduces network calculus, and network calculus introduces nonlinear constraints when deriving the upper limit of the service chain delay, so the problem is ultimately modeled as mixed integer nonlinear programming.

[0089] In step 100, the most important concepts in network calculus are arrival curves and service curves. The core idea is to model the arrival flows and services provided by the network using arrival curves and service curves. The arrival curve describes the upper limit of the amount of data that a flow can send, while the service curve describes the lower limit of the amount of data that a data processing node can guarantee to process.

[0090] See also Figure 2, we assume that the traffic of the business first passes through the token bucket filter TBF (Token Bucket Filter), where the sending rate of TBF is ρ and the size of the token bucket (Token Bucket) is σ, then the arrival curve of the flow sent by TBF is modeled as ρt+σ, that is, straight line ①, which represents the upper limit of the amount of data (traffic) arriving over time. The business flow is then sent to the node for processing. The service curve of the node is straight line ②, γ(t-θ). Among them, γ represents the processing rate of the node, and θ represents the waiting time of the flow before being processed by the node. Based on the arrival curve and the service curve, we can get the upper limit of the delay, whose value is the maximum horizontal deviation of the two curves, that is Figure 2 If we use α(t) to represent the arrival curve and β(t) to represent the service curve, then the upper bound of the delay can be expressed as the following formula (1). Figure 2 In the example, the upper bound on delay is calculated as σ / γ+θ.

[0091]

[0092] Another very important concept in network calculus is the cascade theorem, which is applied when multiple nodes are connected in series. Let's assume there are two service curves, β1(t) = γ1(t-θ1) and β2(t) = γ2(t-θ2). Then, according to the cascade theorem, the two service curves can be combined into one service curve, which is The symbols It represents the minimization of convolution, and its expression is shown in the following formula (2). In the example assumption, the service curve after concatenation is calculated as γ2(t-θ1-θ2), where γ3 is: γ3=min{γ1,γ2}.

[0093]

[0094] The composition of the service chain end-to-end latency is as follows:

[0095] Generally speaking, the end-to-end delay of a service chain includes link delay and node delay, such as Figure 3 As shown in the figure, link latency refers to the delay caused by data packet propagation in the physical link and is primarily determined by the length of the physical link. Node latency, on the other hand, refers to the VNF node latency. We use network calculus to calculate the upper limit of VNF node latency. This network calculus calculation takes into account VNF processing latency and queuing delays incurred by the VNF. VNF processing latency is not considered in existing service chain deployment solutions. Figure 3The NIC in the text stands for network interface card or network interface controller, which is a piece of computer hardware designed to allow computers to communicate on a computer network.

[0096] Step 200: If the service chain request is not deployed in the cloud center network, and if it is known based on the edge algorithm that the edge system currently meets the resource requirements corresponding to the service chain request, then determine whether the edge system currently meets the delay requirement; if not, and if a second target deployment path for the service chain request in the edge system is generated based on the optimal path algorithm and the delay requirement, then deploy the service chain request in the edge system based on the second target deployment path.

[0097] From the above description, it can be seen that the cloud-edge collaborative service chain deployment method provided by the embodiment of the present application applies network calculation theory to the cloud-edge collaborative service chain deployment. If the delay requirement of the service chain is met, it is preferentially deployed in the cloud to save edge resources. If the upper limit of the delay deployed in the cloud is greater than the delay requirement of the service chain, the service chain is deployed on the edge node; it can ensure the reliability of the network service with a certain delay, and can deploy the service chain with a certain delay upper limit under resource constraints, which can effectively improve the delay accuracy of the service chain deployment; and then it can realize the dynamic collaborative deployment of the service chain in the cloud and edge environment under the premise of high delay requirements and limited resources, and can provide an end-to-end delay guarantee for the deployed service chain, and can improve the effectiveness and reliability of the collaborative deployment of the service chain in the cloud and edge system, effectively reduce errors, and improve the effectiveness and reliability of the service chain deployment, which is especially suitable for IoT scenarios with high delay requirements.

[0098] In order to improve the application reliability and effectiveness of cloud algorithms based on network calculations, in a cloud-edge collaborative service chain deployment method provided in an embodiment of the present application, see Figure 4 , step 100 in the cloud-edge collaborative service chain deployment method specifically includes the following content:

[0099] Step 110: Receive a service chain request and obtain a delay requirement value corresponding to the service chain request.

[0100] Step 120: Determine the upper limit of the delay of the service chain request to be deployed in the cloud center network based on a network calculation method.

[0101] Step 130: Determine whether the upper limit of the latency of the cloud center network is less than or equal to the latency requirement value. If so, execute step 131: store the service chain request in a preset cloud service chain set;

[0102] Step 140: For the service chain request in the cloud service chain set, call the optimal path algorithm to obtain the target deployment path of the service chain request in the cloud center network, determine the target deployment path as the first target deployment path, and deploy the service chain request in the cloud center network based on the first target deployment path.

[0103] In order to further realize the dynamic collaborative deployment of service chains in cloud and edge environments under the premise of high latency requirements and limited resources, in a cloud-edge collaborative service chain deployment method provided in an embodiment of the present application, see Figure 4 , step 100 in the cloud-edge collaborative service chain deployment method further specifically includes the following content:

[0104] After executing step 130, if it is determined that the current delay upper limit value of the cloud center network is greater than the delay requirement value of the service chain request, step 132 is executed: the service chain request is stored in a preset edge service chain set.

[0105] Specifically, the cloud-based algorithm is used to determine whether the service chain SFC is deployed in the cloud-centric network. Define G as the set of service chains deployed in the cloud-centric network, and E as the set of service chains deployed on edge nodes. First, both G and E are set to empty sets. The specific cloud-based algorithm process is as follows:

[0106] S1: For each incoming service chain request (SFCs), network calculus theory is used to calculate the upper limit of the delay of the service chain request deployed in the cloud center network. The service chain request contains its corresponding delay requirement

[0107] S3: set the upper limit of the delay With the delay requirement After comparison, if the upper delay limit is less than or equal to the delay requirement, then the service chain request is placed in set G; otherwise, the service chain request is placed in set E.

[0108] Based on this, S1-S3 complete the cloud-side computation, then call Algorithm 3 to execute S4, and then call the edge algorithm to execute S5. You can see that the cloud-side algorithm doesn't give much consideration to resources, but rather to latency requirements. This is because the cloud-centric network has vast resources, while the cloud-edge link latency is high. Therefore, we prioritize latency over resource requirements in the cloud-side algorithm.

[0109] S4: For the service chain request in set G, call the optimal path algorithm to obtain the optimal deployment path within the cloud center network, and complete the service chain deployment corresponding to the service chain request;

[0110] S5: For the service chain requests in set E, input the set E into the edge algorithm.

[0111] In order to improve the reliability and effectiveness of applications based on edge algorithms, in a cloud edge collaborative service chain deployment method provided in an embodiment of the present application, step 200 in the cloud edge collaborative service chain deployment method can be performed after step 132, see Figure 5 , the step 200 specifically includes the following contents:

[0112] Step 210: Obtain a service chain resource requirement value of the service chain request and a VNF resource requirement value of each virtual network function VNF in the service chain request;

[0113] Step 220: Generate an initial deployment plan for the service chain request in the edge system based on the service chain resource requirement value, the VNF resource requirement value, and the current available resource value of each edge node in the edge system;

[0114] Step 230: Determine whether the service chain resource demand value is less than or equal to the current available resource value of the edge system. If so, execute step 231: Determine a first upper limit of the latency for deploying the service chain request on the edge system based on a network calculation method.

[0115] Step 240: Determine whether the first delay upper limit is less than or equal to the delay requirement value. If not, execute step 241: invoke the optimal path algorithm to generate a target deployment path for the service chain request in the edge system.

[0116] Step 250: Based on a network calculation method, apply the deployment path to re-determine a second upper limit of the delay for deploying the service chain request on the edge system;

[0117] Step 260: Determine whether the second delay upper limit value is less than or equal to the delay requirement value. If so, execute step 261: confirm the target deployment path of the service chain request in the edge system as the second target deployment path, and deploy the service chain request in the edge system based on the second target deployment path.

[0118] In order to improve the comprehensiveness and reliability of edge algorithm-based applications, in a cloud-edge collaborative service chain deployment method provided in an embodiment of the present application, see Figure 5 , step 200 in the cloud-edge collaborative service chain deployment method further specifically includes the following content:

[0119] If it is determined in step 240 that the first delay upper limit value is less than or equal to the delay requirement value, step 242 is executed: the initial deployment plan is used as the second target deployment path, and the service chain request is deployed in the edge system based on the second target deployment path.

[0120] In order to improve the comprehensiveness and reliability of edge algorithm-based applications, in a cloud-edge collaborative service chain deployment method provided in an embodiment of the present application, see Figure 3 , step 200 in the cloud-edge collaborative service chain deployment method further specifically includes the following content:

[0121] If it is determined in step 230 that the service chain resource requirement value is greater than the current available resource value of the edge system, or if it is determined in step 260 that the second delay upper limit value is still greater than the delay requirement value, the service chain request is rejected, and step 270 is executed: the service chain request is rejected.

[0122] Specifically, the edge algorithm is used to determine whether the remaining SFCs are deployed on edge nodes. For the above step S5, the specific cloud algorithm process is as follows:

[0123] S51: Request the corresponding resource requirements according to each service chain Arrange the service chain requests in set E from small to large, and set the newly obtained set as E';

[0124] S52: Resource requirements of each VNF according to the service chain request The VNF set Fs belonging to the service chain request is also arranged in order from small to large, and the newly obtained VNF set Fs' is obtained;

[0125] S53: According to the available resources R of each edge node in the edge node set v Arrange the edge node set V in descending order to obtain a new edge node set V';

[0126] S54: Regarding E', from the resource demand The smallest service chain request SFCs starts deployment. For Fs', each service chain request SFCs also starts from the resource requirements. The smallest virtual network function VNF f is deployed;

[0127] S55: If the resource requirements of the virtual network function VNF f Less than or equal to the available resources R of server v v , then deploy it in the server v first;

[0128] S56: If the virtual network function VNF f is not successfully deployed after traversing the edge node set V′, the SFC request containing the virtual network function VNF f will be rejected;

[0129] S57: After all SFCs in E' are deployed, network calculus theory is used to calculate the upper bound of their deployment delay.

[0130] like Less than or equal to the latency requirement Then it is determined that all SFCs in E' are deployed; if Greater than latency requirements Then execute S4: call Algorithm 3-Optimal Path Algorithm to obtain the fastest path.

[0131] S58: Receive the optimal path calculation result returned by Algorithm 3. If the returned path is not empty, calculate the deployment delay upper limit again. If the deployment meets the latency requirements The SFC is deployed, otherwise the SFC request is rejected.

[0132] It can be seen that the edge algorithm did not directly call the optimal path algorithm to obtain the shortest path at the beginning, but instead did not meet the latency requirements when it was first deployed. Only then is the optimal path algorithm invoked. This is because resource scarcity is the top priority in edge node environments. Therefore, we prioritize deployment based on resource requirements before determining whether latency requirements are met. If latency requirements are not met, we prioritize deployment based on latency requirements.

[0133] In order to improve the application effectiveness and reliability of the optimal path algorithm, in a cloud edge collaborative service chain deployment method provided in an embodiment of the present application: the optimal path algorithm in the cloud edge collaborative service chain deployment method specifically includes the following contents:

[0134] Step 300: Obtaining a deployment path of the service chain request in the current target environment, wherein the target environment includes: the cloud center network or the edge system;

[0135] Step 400: Determine whether each service node in the deployment path meets the resource requirements corresponding to the service chain request. If so, execute step 410: determine the deployment path as the optimal path;

[0136] If there is a service node in the deployment path that does not meet the resource requirements corresponding to the service chain request, step 420 is executed: the service node that does not meet the resource requirements is deleted from the deployment path, and the deployment path is determined as the optimal path;

[0137] Step 500: Determine whether each service node in the optimal path meets the pre-qualified bandwidth restriction. If so, execute step 510: determine the optimal path as the target deployment path.

[0138] Specifically, the optimal path algorithm is used to find the fastest path that meets resource requirements. The optimal path algorithm only receives one SFC request at a time. For S4 above, the specific optimal path algorithm process is as follows:

[0139] S41: First, call the Dijkstra algorithm to obtain the optimal path l in the cloud-centric network or edge system ij , each optimal path l ij Form a set L;

[0140] S42: For each server v in the path, if it is determined that all servers meet the resource requirements Then finally return the path as output;

[0141] S43: If a server in the path does not meet the resource requirements The server is then deleted from the cloud server set of the cloud center network or the edge node set V' in the edge system, and the FastPath algorithm is iteratively called.

[0142] S44: Determine the bandwidth limit of the path. If the bandwidth limit is satisfied, the path is returned as output. If the path is ij If the bandwidth limit is not met, the path l ij Remove from the set L and iteratively call the FastPath algorithm.

[0143] From the software level, this application also provides a cloud edge collaborative service chain deployment device for executing all or part of the cloud edge collaborative service chain deployment method, see Figure 6 The cloud-edge collaborative service chain deployment device specifically includes the following contents:

[0144] The cloud deployment module 10 is used to apply a cloud algorithm based on network calculation to determine whether the cloud center network currently meets the delay requirements corresponding to the service chain request. If so, the optimal path algorithm is called to obtain the first target deployment path of the service chain request in the cloud center network and deploy the service chain request in the cloud center network based on the first target deployment path.

[0145] The edge deployment module 20 is used to determine whether the edge system currently meets the delay requirement if the service chain request is not deployed in the cloud center network and if it is known based on the edge algorithm that the edge system currently meets the resource requirements corresponding to the service chain request. If not, and if a second target deployment path for the service chain request in the edge system is generated based on the optimal path algorithm and the delay requirement, the service chain request is deployed in the edge system based on the second target deployment path.

[0146] The embodiment of the cloud edge collaborative service chain deployment device provided in this application can be specifically used to execute the processing flow of the embodiment of the cloud edge collaborative service chain deployment method in the above embodiment. Its functions will not be repeated here, and you can refer to the detailed description of the above cloud edge collaborative service chain deployment method embodiment.

[0147] The part of the cloud edge collaborative service chain deployment device that performs cloud edge collaborative service chain deployment can be executed in the server, and in another practical application scenario, all operations can also be completed in the client device. The specific selection can be based on the processing capability of the client device and the limitations of the user's usage scenario. This application is not limited to this. If all operations are completed in the client device, the client device may also include a processor for specific processing of the cloud edge collaborative service chain deployment.

[0148] The client device may include a communication module (i.e., a communication unit) that can establish a communication connection with a remote server to implement data transmission with the server. The server may include a server on the task scheduling center side, and in other implementation scenarios, may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a server structure of a distributed device.

[0149] The server and the client device may communicate using any suitable network protocol, including network protocols that have not yet been developed as of the filing date of this application. Examples of such network protocols include TCP / IP, UDP / IP, HTTP, and HTTPS. Furthermore, examples of such network protocols include RPC (Remote Procedure Call Protocol) and REST (Representational State Transfer) protocols, which are used on top of the aforementioned protocols.

[0150] From the above description, it can be seen that the cloud-edge collaborative service chain deployment device provided by the embodiment of the present application applies network calculation theory to the cloud-edge collaborative service chain deployment. If the delay requirement of the service chain is met, it is preferentially deployed in the cloud to save edge resources. If the upper limit of the delay deployed in the cloud is greater than the delay requirement of the service chain, the service chain is deployed on the edge node; it can ensure the reliability of the network service with a certain delay, and can deploy the service chain with a certain delay upper limit under limited resources, which can effectively improve the delay accuracy of the service chain deployment; and then it can realize the dynamic collaborative deployment of the service chain in the cloud and edge environment under the premise of high delay requirements and limited resources, and can provide an end-to-end delay guarantee for the deployed service chain, and can improve the effectiveness and reliability of the collaborative deployment of the service chain in the cloud and edge system, effectively reduce errors, and improve the effectiveness and reliability of the service chain deployment, which is especially suitable for IoT scenarios with high delay requirements.

[0151] In order to further illustrate the present solution, the present application also provides a specific application example for implementing a cloud-edge collaborative service chain deployment method, specifically involving a delay-sensitive cloud-edge collaborative service chain deployment algorithm based on network calculus. The cloud-edge collaborative deployment algorithm CECDA proposed in the application example of this application can be divided into three sub-algorithms. The first sub-algorithm is the cloud-end algorithm. We first call this algorithm to determine whether the SFC is deployed in the cloud center network. The second sub-algorithm is the edge algorithm. We will call this algorithm to determine whether the remaining SFCs rejected by the cloud can be deployed on the edge nodes and complete the deployment of the SFC. The third sub-algorithm is the optimal path algorithm. When Algorithm 1 determines that the SFC is deployed in the cloud, this algorithm will be called to determine the optimal deployment path; when the path initially planned by Algorithm 2 does not meet the delay requirements, this algorithm will also be called to find the optimal deployment path.

[0152] The CECDA algorithm completes the deployment of the cloud-edge collaborative service chain in three steps. First, call Algorithm 1 to determine whether it is deployed in the cloud. If so, call Algorithm 3 to complete the optimal path selection and complete the deployment; if not, call Algorithm 2 to deploy the SFC on the edge node. If the latency requirement is not met, call Algorithm 3 to obtain the optimal deployment path to complete the deployment. If the latency requirement is still not met, the SFC request is rejected. It mainly includes the following steps:

[0153] (1) Algorithm 1-Cloud Algorithm

[0154] The cloud-based algorithm determines whether an SFC is deployed in the cloud-centric network. Define G as the set of SFCs deployed in the cloud-centric network, and E as the set of SFCs deployed on edge nodes. First, assume that both G and E are empty sets. For each incoming SFC request, we apply network calculus theory to calculate the upper bound on the latency of deploying the SFC in the cloud-centric network. We then compare this upper bound with the SFC's latency requirement. If the upper bound meets the SFC's latency requirement, the SFC is placed in set G; otherwise, it is placed in set E. For SFC requests in set G, the algorithm invokes the optimal path algorithm to determine the optimal deployment path within the cloud-centric network and complete the SFC deployment. Set E is output to Algorithm 2 and serves as input. As can be seen, the cloud-based algorithm does not prioritize resources, but rather latency requirements. This is because the cloud-centric network has vast resources, while cloud-edge links have high latency. Therefore, latency requirements are prioritized over resource requirements in the cloud-based algorithm.

[0155] Specifically, examples of Algorithm 1-Cloud Algorithm are shown in Table 1.

[0156] Table 1

[0157]

[0158]

[0159] In Table 1, the input service chain resource requirements are used in FastPath(). The reason only set E is output is that set G has already been deployed, so only set E is output, and the next algorithm is entered.

[0160] (2) Algorithm 2-Edge Algorithm

[0161] The edge algorithm is used to determine whether the remaining SFCs are deployed on edge nodes. Algorithm 2 first calculates the set E of SFCs according to resource requirements. Sort in descending order and set the newly obtained set as E'. Then sort the VNF set Fs belonging to SFCs according to resource requirements. Arrange in descending order, and set the newly obtained set as Fs'. The edge algorithm further arranges the server set V in descending order according to the available resources Rv to obtain the set V'. The algorithm starts deployment from the SFCs with the smallest resource requirements, and also deploys the VNF f with the smallest resource requirements within the SFCs. If the resource requirement of VNF f is less than or equal to the available resources Rv of server v, then we will deploy it in the server v first. If VNF f traverses the server set V' and is not deployed successfully, the SFC request containing the VNF f will be rejected. After the SFCs are deployed, the edge algorithm will refer to network calculus theory to calculate the upper limit of its deployment delay. If the latency requirement is met Then the SFC is deployed; if the delay requirement is not met, the optimal path algorithm is called to obtain the fastest path. If the returned path is not empty, the deployment delay limit is calculated again. If the deployment meets the latency requirements If the SFC is not deployed, the SFC request is rejected. You can see that the edge algorithm does not directly call the optimal path algorithm to obtain the shortest path. Instead, it calls the optimal path algorithm only after the initial deployment fails to meet latency requirements. This is because resource scarcity is the top priority in edge node environments. Therefore, we first consider resource requirements when deploying, and then determine whether latency requirements are met. If latency requirements are not met, we prioritize latency requirements for deployment.

[0162] Specifically, examples of Algorithm 2-Edge Algorithm are shown in Table 2.

[0163] Table 2

[0164]

[0165] (3) Algorithm 3-Optimal Path Algorithm

[0166] The optimal path algorithm is used to find the fastest path that meets resource requirements. Algorithm 3 only inputs one SFC request each time. The optimal path algorithm first calls the Dijkstra algorithm to obtain the optimal path. Then, for the server v in the path, if it is determined that all the resource requirements are met, the path is finally returned as the output; if it is determined that the server v does not meet the resource requirements, the server v is deleted from the set V' and the FastPath algorithm is iteratively called. The bandwidth limit of the path is then judged. If it is determined that all the bandwidth limits are met, the path is finally returned as the output; if it is determined that the path l ij If the bandwidth limit is not met, the path l ij Remove from the set L and iteratively call the FastPath algorithm.

[0167] Specifically, an example of Algorithm 3 - Optimal Path Algorithm is shown in Table 3.

[0168] Table 3

[0169]

[0170]

[0171] Compared with the prior art, the beneficial effects of the application example of this application are:

[0172] The application example of this application proposes a cloud-edge collaborative service chain deployment method, which provides a cloud algorithm for service chain deployment in a cloud edge environment, an edge algorithm for service chain deployment in a cloud edge environment, and an optimal path algorithm for service chain deployment in a cloud edge environment. Compared with previous methods, the application example of this application provides strict latency guarantees for the deployment of service chains; and increases the acceptance rate of service chain requests in a cloud edge environment.

[0173] The application example of this application can realize the dynamic collaborative deployment of service chains in cloud and edge environments under the premise of high latency requirements and limited resources. It can provide an end-to-end latency guarantee for the deployed service chain, and can improve the effectiveness and reliability of the collaborative deployment of service chains in cloud and edge systems, effectively reduce errors, and improve the effectiveness and reliability of service chain deployment. It is especially suitable for IoT scenarios with high latency requirements.

[0174] An embodiment of the present application also provides an electronic device (i.e., an electronic device), which may include a processor, a memory, a receiver, and a transmitter, wherein the processor is used to execute the cloud edge collaborative service chain deployment method mentioned in the above embodiment, wherein the processor and the memory may be connected via a bus or other means, taking a bus connection as an example. The receiver may be connected to the processor and the memory via a wired or wireless manner. The electronic device may receive real-time motion data from sensors in the wireless multimedia sensor network, and receive original video sequences from the video acquisition device.

[0175] The processor may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or a combination of the above chips.

[0176] The memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer executable programs, and modules, such as the program instructions / modules corresponding to the cloud edge collaborative service chain deployment method in the embodiments of this application. The processor executes the various functional applications and data processing of the processor by running the non-transitory software programs, instructions, and modules stored in the memory, thereby implementing the cloud edge collaborative service chain deployment method in the above method embodiments.

[0177] The memory may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created by the processor, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory may optionally include a memory remotely located relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0178] The one or more modules are stored in the memory, and when executed by the processor, execute the cloud edge collaborative service chain deployment method in the embodiment.

[0179] In some embodiments of the present application, the user equipment may include a processor, a memory and a transceiver unit, and the transceiver unit may include a receiver and a transmitter. The processor, memory, receiver and transmitter may be connected through a bus system. The memory is used to store computer instructions, and the processor is used to execute the computer instructions stored in the memory to control the transceiver unit to send and receive signals.

[0180] As an implementation method, the functions of the receiver and transmitter in this application can be considered to be implemented through a transceiver circuit or a dedicated transceiver chip, and the processor can be considered to be implemented through a dedicated processing chip, a processing circuit or a general-purpose chip.

[0181] As another implementation method, it is possible to use a general-purpose computer to implement the server provided in the embodiments of the present application. That is, the program code for implementing the functions of the processor, receiver, and transmitter is stored in a memory, and the general-purpose processor implements the functions of the processor, receiver, and transmitter by executing the code in the memory.

[0182] The present application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the aforementioned cloud-edge collaborative service chain deployment method. The computer-readable storage medium can be a tangible storage medium, such as a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a floppy disk, a hard disk, a removable storage disk, a CD-ROM, or any other form of storage medium known in the art.

[0183] It should be understood by those skilled in the art that the various exemplary components, systems and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software or a combination of the two. Whether it is specifically performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application. When implemented in hardware, it can be, for example, an electronic circuit, an application-specific integrated circuit (ASIC), appropriate firmware, a plug-in, a function card, etc. When implemented in software, the elements of this application are programs or code segments that are used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link via a data signal carried in a carrier.

[0184] It should be understood that the present application is not limited to the specific configurations and processes described above and illustrated in the figures. For the sake of brevity, a detailed description of known methods is omitted here. In the above embodiments, several specific steps are described and illustrated as examples. However, the method process of the present application is not limited to the specific steps described and illustrated. Those skilled in the art can make various changes, modifications, and additions, or change the order of the steps after understanding the spirit of the present application.

[0185] In this application, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or replace features of other embodiments.

[0186] The above description is merely a preferred embodiment of the present application and is not intended to limit the present application. Those skilled in the art will appreciate that various modifications and variations of the present embodiment are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present application shall be included within the scope of protection of the present application.

Claims

1. A cloud-edge collaborative service chain deployment method, characterized in that: include: Apply a cloud-based algorithm based on network calculation to determine whether the cloud center network currently meets the latency requirement corresponding to the service chain request. If so, call the optimal path algorithm to obtain the first target deployment path of the service chain request in the cloud center network and deploy the service chain request in the cloud center network based on the first target deployment path; If the service chain request is not deployed in the cloud center network, obtaining the service chain resource requirement value of the service chain request and the VNF resource requirement value of each virtual network function VNF in the service chain request; Generate an initial deployment plan for the service chain request in the edge system based on the service chain resource requirement value, the VNF resource requirement value, and the current available resource value of each edge node in the edge system; Determine whether the service chain resource demand value is less than or equal to the current available resource value of the edge system; if so, determine a first latency upper limit for the service chain request to be deployed on the edge system based on a network calculation method; determining whether the first delay upper limit value is less than or equal to the delay requirement value; if not, invoking the optimal path algorithm to generate a target deployment path for the service chain request in the edge system; Based on a network calculation method, applying the deployment path to re-determine a second upper limit of the delay for the service chain request to be deployed on the edge system; determining whether the second delay upper limit is less than or equal to the delay requirement; if so, determining a target deployment path of the service chain request in the edge system as a second target deployment path, and deploying the service chain request in the edge system based on the second target deployment path; If it is determined that the first delay upper limit value is less than or equal to the delay requirement value, the initial deployment plan is used as the second target deployment path, and the service chain request is deployed in the edge system based on the second target deployment path.

2. The cloud edge collaborative service chain deployment method according to claim 1, characterized in that: The application determines whether the cloud center network currently meets the latency requirement corresponding to the service chain request based on a cloud-based algorithm based on network calculation. If so, the application calls the optimal path algorithm to obtain the first target deployment path of the service chain request in the cloud center network and deploys the service chain request in the cloud center network based on the first target deployment path, including: Receive a service chain request and obtain the latency requirement value corresponding to the service chain request; Determine the upper limit of the delay of the service chain request to be deployed in the cloud center network based on the network calculation method; Determine whether the upper limit of the delay of the cloud center network is less than or equal to the delay requirement value, and if so, store the service chain request in a preset cloud service chain set; For the service chain request in the cloud service chain set, the optimal path algorithm is called to obtain the target deployment path of the service chain request in the cloud center network, the target deployment path is determined as the first target deployment path, and the service chain request is deployed in the cloud center network based on the first target deployment path.

3. The cloud edge collaborative service chain deployment method according to claim 2, characterized in that: Also includes: If it is determined that the current delay upper limit value of the cloud center network is greater than the delay requirement value of the service chain request, the service chain request is stored in a preset edge service chain set.

4. The cloud edge collaborative service chain deployment method according to claim 1, characterized in that: Also includes: If it is determined that the service chain resource requirement value is greater than the current available resource value of the edge system, or if it is determined that the second delay upper limit value is still greater than the delay requirement value, the service chain request is refused to be executed.

5. The cloud edge collaborative service chain deployment method according to any one of claims 1 to 4, characterized in that: The optimal path algorithm includes: Obtaining a deployment path of the service chain request in a current target environment, wherein the target environment includes: the cloud center network or the edge system; Determine whether each service node in the deployment path meets the resource requirements corresponding to the service chain request, and if so, determine the deployment path as the optimal path; If there is a service node among the service nodes in the deployment path that does not meet the resource requirements corresponding to the service chain request, then delete the service node that does not meet the resource requirements in the deployment path, and then determine the deployment path as the optimal path; It is determined whether each service node in the optimal path meets the pre-examination bandwidth restriction. If so, the optimal path is determined as the target deployment path.

6. A cloud edge collaborative service chain deployment device, characterized in that: include: A cloud deployment module is used to determine whether the cloud center network currently meets the latency requirement corresponding to the service chain request based on the cloud algorithm. If so, the optimal path algorithm is called to obtain the first target deployment path of the service chain request in the cloud center network and deploy the service chain request in the cloud center network based on the first target deployment path; The edge deployment module is used to perform the following: If the service chain request is not deployed in the cloud center network, obtaining the service chain resource requirement value of the service chain request and the VNF resource requirement value of each virtual network function VNF in the service chain request; Generate an initial deployment plan for the service chain request in the edge system based on the service chain resource requirement value, the VNF resource requirement value, and the current available resource value of each edge node in the edge system; Determine whether the service chain resource demand value is less than or equal to the current available resource value of the edge system; if so, determine a first latency upper limit for the service chain request to be deployed on the edge system based on a network calculation method; determining whether the first delay upper limit value is less than or equal to the delay requirement value; if not, invoking the optimal path algorithm to generate a target deployment path for the service chain request in the edge system; Based on a network calculation method, applying the deployment path to re-determine a second upper limit of the delay for the service chain request to be deployed on the edge system; determining whether the second delay upper limit is less than or equal to the delay requirement; if so, determining a target deployment path of the service chain request in the edge system as a second target deployment path, and deploying the service chain request in the edge system based on the second target deployment path; If it is determined that the first delay upper limit value is less than or equal to the delay requirement value, the initial deployment plan is used as the second target deployment path, and the service chain request is deployed in the edge system based on the second target deployment path.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, it implements the cloud edge collaborative service chain deployment method as described in any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the cloud-edge collaborative service chain deployment method as described in any one of claims 1 to 5 is implemented.

Images