Traffic stream transmission method, apparatus and system

Abstract

The present application relates to the technical field of networks, and provides a traffic stream transmission method, apparatus and system. In the solution provided by the present application, an acceleration node in an overlay network can receive a plurality of traffic streams sent by a server, and acquire SLA requirements of the plurality of traffic streams. Moreover, the acceleration node can reduce the transmission quality of at least one target traffic stream having a lower SLA requirement when it is detected that the network resources of the overlay network do not satisfy the SLA requirements of the plurality of traffic streams. Thus, it can be ensured that when a plurality of traffic streams contend for network resources, the transmission quality of a traffic stream having a higher SLA requirement is first guaranteed.

Description

Method, device and system for transmitting business flow

[0001] This application claims priority to Chinese patent application No. 202311334476.4 filed on October 13, 2023, with the invention name “A collaborative transmission method and device”, and claims priority to Chinese patent application No. 202311602147.3 filed on November 24, 2023, with the invention name “Transmission method, device and system for business flow”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of network technology, and in particular to a method, device and system for transmitting a business flow. Background Art

[0003] Real-time communication systems are those that require real-time transmission of traffic flows such as audio, video, data, and signaling. These systems typically use multiplexing technology to transmit data. This means they can use multiple data channels to transmit different types of traffic flows, sharing the network bandwidth.

[0004] However, when the network bandwidth is insufficient, the real-time communication system will not be able to guarantee the transmission quality of each business flow.

[0005] Summary of the Invention

[0006] The present application provides a method, device and system for transmitting a business flow, which can solve the technical problem that the transmission method of the related art cannot guarantee the transmission quality of each business flow when the network bandwidth is insufficient.

[0007] In the first aspect, a method for transmitting a service flow is provided, which is applied to a real-time communication system, and the real-time communication system includes: a client, an access network, an overlay network, and a server. The method includes: an acceleration node in the overlay network receives multiple service flows sent by the server, and obtains the service level agreement (SLA) requirements of the multiple service flows. Afterwards, the acceleration node forwards the multiple service flows to the access network, so that the access network forwards the multiple service flows to the client. If the network resources of the overlay network do not meet the SLA requirements of the multiple service flows, the acceleration node can reduce the transmission quality of at least one target service flow among the multiple service flows. The SLA requirement of the at least one target service flow is lower than the SLA requirements of other service flows among the multiple service flows.

[0008] Based on the method provided in this application, it can be ensured that when multiple business flows compete for network resources of the overlay network, the transmission quality of business flows with higher SLA requirements (i.e., more important business flows) is prioritized.

[0009] Optionally, the process of the acceleration node forwarding the multiple service flows to the access network may include: for each service flow in the multiple service flows, the acceleration node forwards the service flow to the access network through a forwarding path that matches the SLA requirement of the service flow.

[0010] The acceleration node forwards the service flow through a forwarding path that matches the service flow's SLA requirements, ensuring that the overlay network can accurately schedule the service flow based on the service flow's SLA requirements.

[0011] Optionally, the SLA requirement may include a path selection policy that characterizes the service flow's requirements for a forwarding path. Before the acceleration node forwards the service flow to the access network via a forwarding path that matches the service flow's SLA requirement, the method may further include: the acceleration node reporting network parameters between itself and other acceleration nodes in the overlay network to a control node in the overlay network; the acceleration node receiving multiple forwarding paths issued by the control node, the multiple forwarding paths being determined based on the network parameters reported by each acceleration node in the overlay network; and, for each of the multiple service flows, the acceleration node determining, from the multiple forwarding paths, a forwarding path that matches the path selection policy for that service flow.

[0012] Since the multiple forwarding paths issued by the control node are determined in real time based on the network parameters of the overlay network, the method provided in this application can achieve flexible scheduling of business flows based on the status of the overlay network and the SLA requirements of the business flows.

[0013] Optionally, the process of the acceleration node reducing the transmission quality of at least one target business flow among the multiple business flows may include: the acceleration node delaying sending of at least one target business flow among the multiple business flows; and / or, the acceleration node discarding data packets of at least one target business flow among the multiple business flows.

[0014] By delaying the sending of target service flows and / or discarding data packets of target service flows within a certain period of time, the acceleration node can effectively save the network resources occupied by the target service flows, thereby ensuring that the network resources of the overlay network can guarantee the SLA requirements of other service flows.

[0015] Optionally, after the acceleration node discards a data packet of at least one target service flow among the multiple service flows, the method may further include: the acceleration node feeding back to the server an identifier of the discarded data packet of the at least one target service flow. The data packet identifier may include a flow identifier of the service flow to which the data packet belongs and a sequence number of the data packet.

[0016] After receiving the discarded packet identifier from the acceleration node, the server can mark the discarded packet as one that does not need to be retransmitted. Accordingly, upon receiving the client's retransmission request, the server will not retransmit the target service flow's packets. This prevents wasting network resources by retransmitting ineffective packets and reduces congestion in the overlay network.

[0017] Optionally, the real-time communication system may further include: an SLA management end, and the process by which the acceleration node obtains the SLA requirements of the multiple business flows may include: receiving the SLA requirements of at least one type of business issued by the SLA management end, and determining the SLA requirements of the at least one business flow based on the type of business to which at least one business flow among the multiple business flows belongs.

[0018] The SLA management terminal can be deployed in the cloud and registered with the SLA requirements of at least one type of service. The SLA management terminal can send the SLA requirements of the at least one type of service to the acceleration nodes in the overlay network. For example, the SLA management terminal can send the SLA requirements of the at least one type of service to each acceleration node in the overlay network via a representational state transfer (REST) ​​message.

[0019] Optionally, the process of the acceleration node acquiring the SLA requirements of the multiple service flows may include: the acceleration node acquiring the SLA requirement of at least one service flow from a data packet of the at least one service flow among the multiple service flows.

[0020] The Real-time Transport Protocol (RTP) extension header of a data packet can carry the SLA requirements for a service flow. It is understood that the SLA requirements issued by the SLA management end may be for certain types of services, or for certain service flows within a certain type of service. For services or service flows for which the SLA management end does not issue SLA requirements, the server can directly include the SLA requirements of the service flow in the data packets within the service flow when sending the service flow.

[0021] Alternatively, the SLA requirements issued by the SLA management end can be coarse-grained, meaning that the parameters in the SLA requirements can be limited to a large range. The SLA requirements carried by the server in the data packets of the service flow can be fine-grained, meaning that the parameters in the SLA requirements can be limited to a smaller range or precise numerical values.

[0022] Optionally, the SLA requirement may include requirements for at least one of the following parameters: end-to-end delay, reliability and forwarding priority, and accordingly, the end-to-end delay of at least one target business flow is higher than the end-to-end delay of other business flows; the reliability of at least one target business flow is lower than the reliability of other business flows; and / or the forwarding priority of at least one target business flow is lower than the forwarding priority of other business flows.

[0023] Based on the above SLA requirements, the acceleration nodes in the overlay network can prioritize the transmission quality of low-latency, high-reliability, and high-priority business flows.

[0024] In a second aspect, another method for transmitting service flows is provided, which is applied to a real-time communication system, the real-time communication system comprising: a client, an access network, an overlay network, and a server. The method comprises: the server sending multiple service flows to an acceleration node in the overlay network, for the acceleration node to forward the multiple service flows to the access network, and when the network resources of the overlay network do not meet the service level agreement (SLA) requirements of the multiple service flows, reducing the transmission quality of at least one target service flow among the multiple service flows. The SLA requirement of the at least one target service flow is lower than the SLA requirements of other service flows in the multiple service flows. After the multiple service flows are forwarded to the access network, the access network forwards the multiple service flows to the client.

[0025] Optionally, the method may also include: the server receives the congestion level of the access network fed back by the client, where the congestion level is determined by the client based on the congestion label fed back by the network equipment in the access network; and the server adjusts the transmission quality of at least one of the multiple service flows based on the congestion level of the access network and the SLA requirements of the multiple service flows.

[0026] In this way, it can be ensured that the transmission quality of the multiple business flows can adapt to the network conditions of the access network in real time, thereby ensuring that the transmission quality of the multiple business flows is high.

[0027] Optionally, the transmission quality may be characterized by at least one of the following parameters: transmission priority, transmission performance parameters, encoding parameters, rendering parameters, and transmission network type. The transmission performance parameters may include at least one of the following: transmission rate, jitter buffer size, forward error correction (FEC) redundancy rate, and retransmission strategy. The transmission network type may include an overlay network and the Internet (i.e., a physical network).

[0028] Optionally, the method further includes: the server receiving, from a control node in the overlay network, feedback on the network status of the overlay network. Accordingly, the process of the server adjusting the transmission quality of at least one of the multiple service flows based on the congestion level of the access network and the SLA requirements of the multiple service flows may include: the server adjusting the transmission quality of at least one of the multiple service flows based on the congestion level of the access network, the network status of the overlay network, and the SLA requirements of the multiple service flows.

[0029] Since the control node in the overlay network can also feed back the network status of the overlay network to the server, the server can adjust the sending quality of the service flow in real time to adapt to the network status of the overlay network.

[0030] Optionally, the method may further include: the server receiving, from the acceleration node, an identifier of a data packet of at least one target service flow among the multiple service flows, where the data packet of the at least one target service flow is a data packet discarded by the acceleration node after network resources of the overlay network fail to meet SLA requirements for the multiple service flows. The server may then mark the data packet of the at least one target service flow as a data packet that does not need to be retransmitted.

[0031] Optionally, the real-time communication system may further include: an SLA management end; the method may further include: the service end reporting the SLA requirements of at least one type of service to which the multiple service flows belong to to the SLA management end; or, the service end receiving the SLA requirements of at least one type of service to which the multiple service flows belong issued by the SLA management end.

[0032] In a third aspect, a service flow transmission device is provided. The service flow transmission device may include at least one module. The at least one module may be used to implement the service flow transmission method provided in the first aspect or the second aspect.

[0033] In a fourth aspect, a computing device is provided, comprising a processor and a memory, wherein the processor is configured to execute instructions stored in the memory to implement the service flow transmission method provided in the first or second aspect.

[0034] In a fifth aspect, a computing device cluster is provided, comprising at least one computing device, each computing device comprising a processor and a memory. The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster performs the service flow transmission method provided in the first or second aspect.

[0035] In a sixth aspect, a computer-readable storage medium is provided, in which computer program instructions are stored. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the service flow transmission method provided in the first or second aspect above.

[0036] In a seventh aspect, a computer program product comprising instructions is provided. When the instructions are executed by a computing device cluster, the computing device cluster executes the service flow transmission method provided in the first or second aspect above.

[0037] In summary, this application provides a method, device, and system for transmitting service flows. In the solution provided by this application, an acceleration node in an overlay network can receive multiple service flows sent by a server and obtain the SLA requirements of these multiple service flows. Furthermore, upon detecting that the network resources of the overlay network do not meet the SLA requirements of these multiple service flows, the acceleration node can reduce the transmission quality of at least one target service flow with a lower SLA requirement. This ensures that when multiple service flows compete for the network resources of the overlay network, the transmission quality of service flows with higher SLA requirements is prioritized. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] FIG1 is a schematic diagram of an application scenario of a method for transmitting a service flow provided in an embodiment of the present application;

[0039] FIG2 is a schematic diagram of an application scenario of another method for transmitting a service flow provided in an embodiment of the present application;

[0040] FIG3 is a schematic diagram of an application scenario of another method for transmitting a service flow provided in an embodiment of the present application;

[0041] FIG4 is a flowchart of a method for transmitting a service flow provided in an embodiment of the present application;

[0042] FIG5 is a schematic diagram of transmission rate and physical bandwidth in different scenarios provided by an embodiment of the present application;

[0043] FIG6 is a schematic structural diagram of a transmission device for a service flow provided in an embodiment of the present application;

[0044] 7 is a schematic structural diagram of another device for transmitting a service flow according to an embodiment of the present application;

[0045] FIG8 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0046] FIG9 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0047] FIG10 is a schematic diagram of a structure of a network connection between computing devices provided by the present application. DETAILED DESCRIPTION

[0048] The following describes in detail the service flow transmission method, device and system provided by the embodiments of the present application in conjunction with the accompanying drawings.

[0049] In one possible implementation, a real-time communication system can use a multiplexing technology based on the QUIC protocol to transmit data. QUIC refers to quick UDP Internet connection, and UDP refers to user datagram protocol. In this multiplexing technology, multiple data channels share the network bandwidth. The client can measure the packet loss rate and latency within N round trip times (RTT), and measure the available network bandwidth (also called flux) through a software algorithm, and then control the sending rate of each business flow. However, the bandwidth calculated by this method has a lag, cannot guarantee real-time performance, and is not accurate. In addition, after the business flow is submitted to the transport layer, there is no scheduling mechanism, that is, it cannot be forwarded according to the SLA requirements of the business flow.

[0050] In another possible implementation, multiple transmission sessions can be established between a client and a server in a real-time communication system. Each transmission session can transmit a single service flow. Furthermore, the client can pre-set the network bandwidth ratio occupied by each transmission session based on the priority of each service flow. However, this method maintains a fixed network bandwidth ratio for each session, making it impossible to dynamically schedule service flows based on real-time fluctuations in available network bandwidth, nor to forward service flows in accordance with their SLA requirements.

[0051] Figure 1 is a schematic diagram of an application scenario of a method for transmitting a business flow provided in an embodiment of the present application. As shown in Figure 1, the application scenario may include: an application (APP) client deployed in a terminal, an APP server deployed in the cloud, and access to a network and the Internet. The cloud can also be referred to as a cloud platform, which can be a server cluster consisting of multiple servers. The APP client can also be referred to as a client, and the APP server can also be referred to as a server.

[0052] Figure 2 is a schematic diagram of an application scenario for another method for transmitting a service flow provided in an embodiment of the present application. Comparing Figures 1 and 2 shows that the application server can also be deployed in a terminal. Furthermore, in the scenario shown in Figure 2, the application client and application server can be two indistinguishable application terminals, i.e., the two application terminals can serve as both the client and the server of each other.

[0053] As can be seen from Figures 1 and 2 , the end-to-end transmission network between the client and the server includes an access network and the Internet. The access network can be a radio access network (RAN), for example, a fifth-generation mobile communication technology (5G) RAN. Alternatively, the access network can be a wireless local area network (WLAN), for example, a Wi-Fi network.

[0054] The internet can be implemented using an overlay network. An overlay network (also known as an overlapping network or superimposed network) is a logical network running on top of one or more physical networks. It can include a control node (also known as a controller) and multiple accelerate nodes. The control node is used to control link state measurements, also known as quality of service (QoS) measurements, between the accelerate nodes, while the accelerate nodes are used to forward traffic on the data plane.

[0055] In an embodiment of the present application, the real-time communication system can be a deterministic network, which refers to a network that can provide deterministic service assurance capabilities for the services it carries. Among them, the deterministic service assurance capabilities mainly include indicators such as bandwidth, latency, jitter, and packet loss rate. It is understandable that the Internet can achieve transmission determinism based on overlay networks, and access networks can achieve transmission determinism through QoS and explicit congestion notification (ECN) mechanisms.

[0056] FIG3 is a schematic diagram of an application scenario for another method for transmitting a service flow provided in an embodiment of the present application. As shown in FIG3 , the application scenario may also include: an SLA management terminal deployed in the cloud, in which SLA requirements (also referred to as SLA data) for different types of services may be registered, which may include requirements for at least one of the following parameters: end-to-end latency, reliability, and priority. Furthermore, the SLA requirements may also include a path selection policy, which may be used to characterize the service's requirements for a forwarding path.

[0057] The SLA management end can send the SLA requirements of at least one type of service to the acceleration node in the overlay network. For each of the multiple service flows sent by the server, the acceleration node can forward the service flow to the access network so that the access network forwards the service flow to the client. The acceleration node can also determine the SLA requirements of the service flow based on the type of service to which the service flow belongs. In addition, when the acceleration node detects that the network resources of the overlay network do not meet the SLA requirements of the multiple service flows, that is, when there is resource competition among the multiple service flows, it can reduce the transmission quality of at least one target service flow among the multiple service flows. The SLA requirement of the at least one target service flow is lower than the SLA requirements of other service flows among the multiple service flows. That is, the acceleration node in the overlay network can give priority to ensuring the transmission quality of service flows with higher SLA requirements.

[0058] It is understandable that the multiple business flows sent by the server may belong to different types of businesses, that is, the real-time communication system can carry multiple different types of businesses. Each type of business may include multiple different business flows (such as media streams). For example, the multiple types of businesses may include: real-time audio and video, online conferencing, cloud rendering, cloud gaming, and metaverse, etc., which require real-time interactive transmission in the system. Among them, real-time audio and video services can also be called real-time communication (RTC) services.

[0059] It is also understandable that for services such as real-time audio and video and online conferencing, the server can be deployed on the terminal. For services such as cloud rendering, cloud gaming, and the metaverse, the server can be deployed in the cloud.

[0060] FIG4 is a flow chart of a method for transmitting a service flow according to an embodiment of the present application, which can be applied to a real-time communication system such as that shown in FIG1 , FIG2 or FIG3 . As shown in FIG4 , the method includes:

[0061] Step 101: The SLA management terminal sends the SLA requirements of at least one type of service to the acceleration node in the overlay network.

[0062] In an embodiment of the present application, the server can register the SLA requirements of at least one type of business in the SLA management end, that is, the server can report the SLA requirements of at least one type of business to the SLA management end. The SLA management end can then send the SLA requirements of the at least one type of business to the acceleration node in the overlay network. For example, the SLA management end can send the SLA requirements of the at least one type of business to each acceleration node in the overlay network via a REST message. It can be understood that each type of business can include multiple different business flows, and the SLA requirements of the multiple different business flows can be the same or different. If the SLA requirements of different business flows in a type of business are different, the SLA requirements of the business sent by the SLA management end to the acceleration node may include the SLA requirements of some or all business flows in the business.

[0063] Optionally, the SLA requirement may include requirements for at least one of the following parameters: end-to-end delay, reliability, priority, etc. Furthermore, the SLA requirement may also include a path selection policy, which may be used to characterize the requirements of a service flow on a forwarding path.

[0064] The end-to-end (E2E) latency requirement refers to the latency requirements for service flows from the client to the server (e.g., the cloud), and from the server to the client. For example, for conferencing services, the E2E latency requirement for media service flows might be 300 milliseconds, the E2E latency requirement for barrage service flows might be 800ms, and the E2E latency requirement for mouse operation service flows might be as low as possible.

[0065] Reliability requirements can include reliable, semi-reliable, and unreliable. Reliable means that the data packet must be transmitted to the peer end; semi-reliable means that the data packet can be discarded if it cannot be effectively transmitted within a specified time; and unreliable means that the data packet can be actively discarded in abnormal scenarios.

[0066] Priority requirements can include priorities between different types of services, or between different service flows within the same type of service. For example, for conferencing services, the priority of the audio service flow is higher than the priority of the shared screen service flow, and higher than the priority of the avatar service flow. For general video services, the priority of the I-frame service flow is higher than the priority of the large P-frame service flow, and higher than the priority of the small P-frame service flow. An I-frame is also called an intra picture, and a P-frame refers to a predictive-frame.

[0067] The path selection strategy in SLA requirements can be determined based on business operation characteristics. This path selection strategy may include: latency strategy, reliability strategy, cost strategy, multi-flow synchronization strategy, and hybrid strategy. Among them, latency strategy refers to prioritizing forwarding paths with low latency; reliability strategy refers to prioritizing forwarding paths with high reliability; cost strategy refers to prioritizing forwarding paths with low cost; multi-flow synchronization strategy refers to prioritizing forwarding paths that can ensure the synchronous transmission of multiple business flows, that is, multiple business flows prefer to use the same forwarding path; hybrid strategy refers to prioritizing forwarding paths that can simultaneously meet multiple requirements (such as high reliability and low latency).

[0068] For example, a video conferencing service has a high requirement for synchronization of video streams and audio streams, so the path selection strategy in its SLA requirement may include a multi-stream synchronization strategy (ie, video stream and audio stream synchronization strategy).

[0069] Step 102: The acceleration node reports network parameters between itself and other acceleration nodes to the control node in the overlay network.

[0070] In an embodiment of the present application, the control node in the overlay network can issue a network detection task to each acceleration node, and the acceleration node can then detect the network parameters between it and other acceleration nodes. For example, referring to Figure 3, the control node may include a network QoS measurement module, which can issue a network detection task to each acceleration node, and each acceleration node can detect the network parameters between it and other acceleration nodes, that is, each acceleration node can perform QoS measurement. Afterwards, each acceleration node can report the measured network parameters (also referred to as QoS measurement data or link status data) to the control node. Among them, the network parameters reported by the acceleration node may include at least one of the following: bandwidth, delay, jitter, and packet loss rate. For example, the network parameters may include packet loss rate and delay.

[0071] Step 103: The control node sends multiple forwarding paths to the acceleration node.

[0072] After receiving network parameters reported by each acceleration node in the overlay network, the control node can calculate multiple forwarding paths between different acceleration nodes in real time based on these network parameters and distribute these multiple forwarding paths to each acceleration node in the overlay network. For example, referring to Figure 3 , the control node can also include a real-time routing calculation module. This real-time routing calculation module can calculate multiple forwarding paths in real time based on the network parameters and distribute routing tables for these multiple forwarding paths to each acceleration node.

[0073] Optionally, for two acceleration nodes (any two acceleration nodes) in the overlay network, the control node can calculate at least one path group between the two acceleration nodes, where each path group includes at least one forwarding path. For example, each path group can include the optimal K (i.e., top K) forwarding paths that meet a condition, with different path groups meeting different conditions. K can be a positive integer.

[0074] For example, the control node can calculate and deliver the following path groups to the acceleration node: a path group with the lowest latency, a path group with the lowest cost, a path group with the highest reliability, and so on. In other words, the control node can calculate and deliver the top K forwarding paths with the lowest latency, the top K forwarding paths with the lowest cost, and the top K forwarding paths with the highest reliability to the acceleration node.

[0075] Step 104: The server transmits multiple service flows to the acceleration node.

[0076] In an embodiment of the present application, a server can collect data to be sent to a client and perform real-time control encoding of the data to generate a service stream. For example, the service stream can be compressed media data. The server can then send the service stream to the client via an acceleration node in the overlay network. For example, referring again to Figure 3, the server can include a service sending control module that can send the service stream to the client.

[0077] Optionally, the data packets of at least one service flow sent by the server may also carry the SLA requirements for that service flow. For example, the RTP extension header of the data packet may carry the SLA data for that service flow. Based on this, the acceleration node may also obtain the SLA requirements for that service flow from the data packets of the service flow sent by the server.

[0078] It is understood that in step 101 above, the SLA management end may issue SLA requirements to the acceleration node for certain types of services, or for certain service flows within a certain type of service. For services or service flows for which the SLA management end has not issued SLA requirements, the server can directly include the SLA requirements of the service flow in the data packets within the service flow when sending the service flow. This ensures that the acceleration node can accurately schedule different service flows based on their SLA requirements.

[0079] It is also understood that in step 101 above, the SLA requirement issued by the SLA management end to the acceleration node may be the service SLA requirement of the service to which the service flow belongs. This service SLA requirement may be a coarse-grained SLA requirement, i.e., the parameters defined in the SLA requirement may be within a relatively large range. To achieve precise scheduling of the service flow, the server may include the flow SLA requirement for the service flow in the data packets of the service flow. This flow SLA requirement may be a fine-grained SLA requirement, i.e., the parameters defined in the SLA requirement may be within a relatively small range or with precise numerical limits.

[0080] Step 105: For each of the multiple service flows, the acceleration node determines a forwarding path that matches the path selection policy of the service flow from multiple forwarding paths.

[0081] After the acceleration node receives the service flow sent from the server to the client, it can determine the forwarding path that matches the path selection policy of the service flow from the multiple forwarding paths sent by the control node, that is, determine the optimal forwarding path. For example, assuming that the path selection policy in the SLA requirement for the control data service flow is a delay policy, the acceleration node can determine the forwarding path that matches the control data service flow from the top K forwarding paths with the lowest delay. Assuming that the path selection policy in the SLA requirement for the audio and video service flow includes a delay policy and a multi-stream synchronization policy, the acceleration node can select a forwarding path that enables the synchronous transmission of the audio service flow and the video service flow from the top K forwarding paths with the lowest delay.

[0082] Since the multiple forwarding paths issued by the control node are determined in real time based on the network measurement data (i.e., network parameters) of the overlay network, the method provided in the embodiment of the present application can achieve flexible scheduling of business flows based on the network measurement data of the overlay network and the SLA requirements of the business flows.

[0083] It is understood that an acceleration node can also monitor the node status of its surrounding acceleration nodes and determine a matching forwarding path based on the node status of these surrounding acceleration nodes and the path selection policy. For example, if a surrounding acceleration node in the optimal forwarding path among the top K forwarding paths fails or is congested, the acceleration node can select the suboptimal forwarding path among the top K forwarding paths as the matching forwarding path.

[0084] It is also understood that, for multiple service flows sent by the server, the acceleration node can determine the SLA requirement of at least one of the multiple service flows based on the service type of the at least one service flow. Alternatively, the acceleration node can directly obtain the SLA requirement of the at least one service flow from the data packets of the at least one service flow.

[0085] Step 106: For each of the multiple service flows, the acceleration node forwards the service flow based on the matched forwarding path.

[0086] In an embodiment of the present application, after the acceleration node determines the forwarding path that matches each service flow, it can forward the service flow to the client based on the matching forwarding path. For example, referring to Figure 3, the acceleration node can include a forwarding control module that can forward the service flow based on the routing table of the forwarding path that matches the service flow. By forwarding the service flow through the forwarding path that matches the service flow's SLA requirements, the acceleration node can ensure that the overlay network can accurately schedule the service flow based on the service flow's SLA requirements.

[0087] Step 107: If the network resources of the overlay network do not meet the SLA requirements of the multiple service flows, the acceleration node reduces the transmission quality of at least one target service flow among the multiple service flows.

[0088] In an embodiment of the present application, an acceleration node can determine whether the network resources of the overlay network meet the SLA requirements of multiple service flows based on network parameters (e.g., QoS metrics) between it and other acceleration nodes. Network resources may include the acceleration node's computing resources (e.g., storage space and processor processing power), as well as link bandwidth. Failure of the overlay network's network resources to meet the SLA requirements of multiple service flows may mean that the SLA requirements of multiple service flows transmitted in the overlay network exceed the inherent processing power and capacity of the overlay network, i.e., network congestion or competition among multiple service flows in the overlay network.

[0089] If there is network congestion in the overlay network, the acceleration node may reduce the transmission quality of at least one target business flow among the multiple business flows. The at least one target business flow may be part of the multiple business flows, and the SLA requirement of the at least one target business flow is lower than the SLA requirement of other business flows among the multiple business flows. As mentioned above, the SLA requirement of a business flow may include requirements for at least one of the following parameters: end-to-end delay, reliability, and forwarding priority. Accordingly, if the SLA requirement includes end-to-end delay, the end-to-end delay of the at least one target business flow is higher than the end-to-end delay of the other business flows. If the SLA requirement includes reliability, the reliability of the at least one target business flow is lower than the reliability of other business flows. If the SLA requirement includes forwarding priority, the forwarding priority of the at least one target business flow is lower than the forwarding priority of other business flows. That is, the at least one target business flow may refer to a relatively less important or relatively unimportant business flow among multiple business flows.

[0090] By reducing the transmission quality of at least one target service flow, the acceleration node effectively conserves network resources used by that flow, ensuring that the overlay network prioritizes meeting the SLA requirements of other service flows, specifically those with high end-to-end latency requirements, high reliability requirements, and / or high forwarding priority. This ensures that even in the event of transient overlay network congestion, important service flows can be successfully transmitted in one go, reducing the retransmission rate for these flows by 50% and reducing transmission latency by one round-trip time (RTT).

[0091] Optionally, the acceleration node may reduce the transmission quality of the at least one target service flow by delaying the transmission of the at least one target service flow; and / or discarding at least one data packet in the at least one target service flow. For example, the acceleration node may sequentially transmit the data packets of the at least one target service flow in descending order of the SLA requirements of the at least one target service flow. In other words, the acceleration node may sequentially transmit the at least one target service flow in descending order of latency requirements (i.e., in descending order of latency), in descending order of reliability, and / or in descending order of priority.

[0092] It is understandable that if the two target service flows have the same latency requirements, the acceleration node can send the two target service flows in order of reliability from high to low, or priority from high to low. If the two target service flows have the same reliability, the acceleration node can send the two target service flows in order of latency requirements from high to low, or priority from high to low. If the two target service flows have the same priority, the acceleration node can send the two target service flows in order of latency requirements from high to low, or reliability from high to low.

[0093] It is understood that if delaying the sending of data packets of the service flow still fails to alleviate network congestion, the acceleration node may also discard data packets in at least one target service flow. For example, the acceleration node may discard data packets of the at least one target service flow during the congestion period.

[0094] For example, for conferencing services, if the audio service flow has a higher priority than the video service flow, and the screen sharing service flow has a higher priority than the avatar service flow, the acceleration node can reduce the transmission quality of the video service flow and / or the avatar service flow. For cloud rendering services and bullet screen gaming services, if the instruction service flow has a higher priority than the media service flow, the acceleration node can reduce the transmission quality of the media service flow.

[0095] Based on the above description, it can be seen that in embodiments of the present application, if there is no resource competition in the overlay network, the overlay network can match the forwarding path of the service flow in real time based on network measurement data (i.e., network parameters) and the SLA requirements of the service flow to ensure that the forwarding path can meet the SLA requirements of the service flow. If there is resource competition in the overlay network, the overlay network can adjust the transmission priority of each service flow in real time based on the network measurement data (i.e., network parameters) and the SLA requirements of the service flow, and / or discard data packets of some service flows to ensure the transmission quality of important service flows.

[0096] Step 108: The acceleration node feeds back to the server the identifier of the discarded data packet in at least one target service flow.

[0097] After discarding the data packet in the at least one target service flow, the acceleration node may also feed back to the server an identifier of the discarded data packet. The identifier of the data packet may include a flow identifier of the service flow to which the data packet belongs and a sequence number of the data packet.

[0098] Step 109: The server marks the data packets of the at least one target service flow as data packets that do not need to be retransmitted.

[0099] It's understandable that if an acceleration node discards a packet from a target service flow and the client doesn't receive it, it will request the server to retransmit the packet. If the server retransmits the packet, congestion on the overlay network won't be effectively alleviated, and the acceleration node may discard the retransmitted packet again.

[0100] Based on this, after receiving the identifier of a discarded packet from the acceleration node, the server can mark the discarded packet as one that does not need to be retransmitted. Accordingly, upon receiving a retransmission request from the client, the server will not retransmit the packets for the target service flow. This prevents the waste of network resources caused by ineffective packet retransmissions and reduces congestion in the overlay network.

[0101] Step 110: If the network device in the access network detects link congestion, it adds a congestion label to the data packet of the service flow sent to the client.

[0102] In an embodiment of the present application, a network device (also referred to as an access device) in an access network can determine whether a link is congested based on its own queue length when forwarding a service flow. If the network device determines that a link is congested, it can add a congestion tag to the data packet it sends to the client.

[0103] For example, as shown in FIG3 , a network device in an access network may include a link congestion detection module. Upon detecting link congestion, the link congestion detection module may add a congestion label to an Internet Protocol (IP) header of a data packet. The congestion label may be an explicit congestion notification (ECN) label.

[0104] Step 111: The client determines the congestion level of the access network based on the congestion label in the received data packet.

[0105] After receiving a data packet from a service flow forwarded by a network device, the client can parse the IP header of the data packet and calculate the congestion level of the access network based on the congestion label carried in the IP header. For example, referring to Figure 3, the access network congestion measurement module in the client can periodically count the proportion of received data packets that carry congestion labels and determine the congestion level of the access network in the current period based on this proportion.

[0106] Step 112: The client feeds back the congestion level of the access network to the server.

[0107] The client can also provide feedback to the server on the calculated congestion level of the access network. For example, the client can provide feedback on the congestion level of the access network via a Transmission Control Protocol (TCP) acknowledgment (ACK) message, or via an RTP Control Protocol (RTCP) extended message.

[0108] Optionally, in addition to feeding back the congestion level of the access network to the server, the client may also feed back the available bandwidth of the client itself to the server.

[0109] Step 113: The control node in the overlay network feeds back the network status of the overlay network to the server.

[0110] In an embodiment of the present application, the control node in the overlay network can also determine the network status of the overlay network in real time based on the network parameters reported by each acceleration node, and provide feedback to the server. The network status can be characterized by at least one of the following parameters: available bandwidth, average latency, etc.

[0111] Step 114: The server adjusts the transmission quality of at least one of the multiple service flows based on the congestion level of the access network, the network status of the overlay network, and the SLA requirements of the multiple service flows.

[0112] In an embodiment of the present application, after receiving the access network congestion level feedback from the client and the overlay network network status feedback from the control node, the server can also adjust the transmission quality of at least one of the multiple service flows based on the congestion level and network status, as well as the SLA requirements of each service flow. This ensures that the transmission quality of the multiple service flows can adapt to the network conditions of the access network and overlay network in real time, thereby ensuring high transmission quality of the multiple service flows.

[0113] For example, when the access network is highly congested and / or the overlay network is in poor condition, the server may reduce the transmission quality of at least one target service flow with a lower SLA requirement among the multiple service flows. Furthermore, when the access network is less congested and / or the overlay network is in poor condition, the server may increase the transmission quality of the at least one target service flow.

[0114] Among them, the sending quality of the business flow can be characterized by at least one of the following parameters: sending priority, sending performance parameters, encoding parameters, rendering parameters, and the type of transmission network. Accordingly, the server adjusting the sending quality of a target business flow may refer to: adjusting the sending priority of the target business, adjusting the sending performance, adjusting the encoding quality, adjusting the rendering quality, and / or adjusting the type of transmission network of the business flow, etc. The type of transmission network may include overlay network and the Internet (i.e., physical network). It can be understood that the transmission quality of the overlay network is better than that of the physical network. Therefore, if the server detects that the network status of the overlay network is poor, part of the business flow can be allocated to the physical network for transmission.

[0115] Optionally, the sending performance parameters may include at least one of the following: send rate, jitter buffer size, FEC redundancy rate, and retransmission strategy. The encoding parameters may include at least one of the following: frame rate, variable bit rate (VBR), resolution, quantizer parameter (QP), constant rate factor (CRF), and encoding level (profile). The rendering parameters may include at least one of the following: frame rate, refresh rate, resolution, lighting, and shadows. In addition to adjusting the above encoding parameters, the server may also reduce the encoding quality by actively dropping frames.

[0116] It is understood that the parameters characterizing the transmission quality of a service flow may vary depending on the type of service flow. For example, for a video service flow, the parameters characterizing its transmission quality may include: transmission priority, transmission performance parameters, encoding parameters, and rendering parameters. For an audio service flow, the parameters characterizing its transmission quality may include: transmission priority, transmission performance parameters, and encoding parameters. For a command service flow, the parameters characterizing its transmission quality may include: transmission priority and transmission performance parameters.

[0117] It is also understood that for video service flows, the server can be configured with a service policy for that video service flow, and that different service policies can be different for different video service flows. Such service policies can include, for example, image quality priority policies and process priority policies. Furthermore, for service flows with different service policies, the server adjusts different parameters when adjusting the transmission quality of the service flow, thereby ensuring that the service policy of the service flow is met while adjusting the transmission quality of the service flow.

[0118] For example, referring to Table 1, the adjustable rendering parameters corresponding to the quality-first strategy may include: frame rate, refresh rate, and resolution; encoding parameters may include: active frame loss, frame rate, VBR, and resolution. The adjustable rendering parameters corresponding to the smoothness-first strategy may include: lighting, shadows, and resolution; encoding parameters may include: QP, CRF, and encoding profile. Furthermore, the adjustable transmission performance parameters corresponding to these two strategies may be the same.

[0119] Table 1

[0120] Figure 5 is a schematic diagram of the sending rate and physical bandwidth in different scenarios provided by an embodiment of the present application. The sending rate in Figure 5 refers to the rate at which the service flow is sent by the server, and the physical bandwidth (BW) refers to the bandwidth of the access network. Referring to (a) in Figure 5, the server in the traditional solution adjusts the sending rate of the service flow according to a preset fixed period (for example, 10 RTTs), which will cause over-transmission congestion and link idleness in the access network for a long time. Referring to (b) in Figure 5, in the solution provided by an embodiment of the present application, since the server can adjust the sending rate of the service flow in real time based on the congestion level of the access network fed back by the client, the duration of over-transmission congestion and link idleness in the access network can be effectively reduced. For example, the duration can be less than 2 RTTs.

[0121] The above description uses the example of a server deployed in the cloud. It is understood that in scenarios such as Figure 2, where both the client and server are deployed on the terminal, the cloud-based SLA management end can also issue SLA requirements for at least one type of service to both the client and server, allowing the client and server to adjust the delivery quality of the service flow based on the SLA requirements of the service to which the service flow belongs.

[0122] Based on the above analysis, it can be seen that the method provided by the embodiment of the present application can solve the problems of delay and jamming caused by the inability of the application layer to coordinate with the status of the pipeline (i.e., the transmission channel) in traditional solutions. The method provided by the embodiment of the present application transforms the pipeline black box into a business-perceived white box through the measurable characteristics of the overlay network and the congestion measurement mechanism of the wireless access network, thereby achieving collaboration between the business and the pipeline. As a result, the construction of a deterministic network environment is achieved, ensuring that under the same available bandwidth conditions, the data transmission efficiency is effectively improved and the service experience is optimized.

[0123] Furthermore, the method provided in the embodiment of the present application can control the sending strategy of the service flow based on the SLA requirements in a deterministic network. On the one hand, it can realize collaborative control based on the SLA requirements of the service flow in each link of the transmission, that is, it realizes the SLA collaboration of the whole link. As a result, the transmission effect of the service flow is effectively optimized, and the end-to-end delay and jamming rate are reduced. On the other hand, the method provided in the embodiment of the present application can also ensure the forwarding success rate of important service flows, while ensuring the transmission fairness of each service flow.

[0124] For example, in a scenario where the transmission bandwidth of a real-time communication system is limited but the sending bandwidth (also called throughput) of the server is sufficient, if the method provided in the embodiment of the present application is adopted, after the server submits business flows with different SLA requirements at one time, the client can observe that each business flow can arrive in the order of reliable low latency, semi-reliable low latency, reliable medium latency, and unreliable low latency.

[0125] It is understandable that the order of the steps of the service flow transmission method provided in the embodiment of the present application can be adjusted appropriately, and the steps can be increased or decreased accordingly. For example, the above-mentioned step 102 can be performed before step 101; or, steps 110 to 112 can be performed before step 109; or, step 105 can be deleted according to the circumstances; or, step 113 can be performed before step 112, or can be deleted according to the circumstances; or, steps 108 and 109 can be deleted according to the circumstances; or, steps 110 to 112, and step 114 can be deleted according to the circumstances.

[0126] In summary, the embodiments of the present application provide a method for transmitting a service flow, wherein the acceleration node in the overlay network can receive multiple service flows sent by the server and obtain the SLA requirements of the multiple service flows. Furthermore, the acceleration node can forward the service flow based on a forwarding path that matches the SLA requirements of the service flow, and can reduce the transmission quality of at least one target service flow with a lower SLA requirement when it detects that the network resources of the overlay network do not meet the SLA requirements of the multiple service flows. Thus, it can not only ensure that the overlay network can schedule service flows based on the SLA requirements of the service flows, but also ensure that when multiple service flows compete for network resources, the transmission quality of service flows with higher SLA requirements is prioritized.

[0127] Moreover, in the method provided in the embodiment of the present application, the server can also reduce the sending quality of at least one target service flow with a lower SLA requirement based on the congestion level of the access network fed back by the client, so as to ensure that the congestion level of the access network can be effectively alleviated.

[0128] The present application also provides a service flow transmission device, which can be applied to an acceleration node in the coverage network of the real-time communication system shown in Figures 1 to 3, and can be used to implement the steps performed by the acceleration node in the service flow transmission method provided in the above method embodiment. As shown in Figure 6, the service flow transmission device includes:

[0129] The receiving module 201 is configured to receive multiple service flows sent by the server. The functional implementation of the receiving module 201 can refer to the description of step 104 in the above method embodiment.

[0130] The acquisition module 202 is configured to acquire the SLA requirements of the multiple service flows. The functional implementation of the acquisition module 202 can refer to the description of step 101 in the above method embodiment.

[0131] The sending module 203 is configured to forward the multiple service flows to the access network so that the access network can forward the multiple service flows to the client. The implementation of the function of the sending module 203 can refer to the description of step 106 in the above method embodiment.

[0132] Adjustment module 204 is configured to reduce the transmission quality of at least one target service flow among the multiple service flows if the network resources of the overlay network do not meet the SLA requirements of the multiple service flows. The SLA requirement of the at least one target service flow is lower than the SLA requirements of the other service flows among the multiple service flows. The implementation of the functionality of adjustment module 204 can be found in the description of step 107 in the above method embodiment.

[0133] Optionally, the adjustment module 204 may be configured to: delay sending of at least one target service flow among the multiple service flows; and / or discard data packets of at least one target service flow among the multiple service flows.

[0134] Optionally, the sending module 203 may be further configured to: after the adjustment module 204 discards a data packet of at least one target service flow among the multiple service flows, feed back to the server an identifier of the discarded data packet of the at least one target service flow. The functional implementation of the sending module 203 may refer to the description of step 108 in the above method embodiment.

[0135] Optionally, the real-time communication system may further include: an SLA management end, and the acquisition module 202 may be used to: receive the SLA requirements of at least one type of service issued by the SLA management end; and determine the SLA requirements of at least one service flow based on the type of service to which at least one service flow among the multiple service flows belongs.

[0136] Optionally, the acquisition module 202 may be configured to: acquire an SLA requirement of at least one service flow from a data packet of the at least one service flow among the multiple service flows.

[0137] Optionally, the SLA requirement includes requirements for at least one of the following parameters: end-to-end delay, reliability, and forwarding priority;

[0138] The end-to-end delay of the at least one target service flow is higher than the end-to-end delay of the other service flows;

[0139] The reliability of the at least one target service flow is lower than the reliability of the other service flows;

[0140] The forwarding priority of the at least one target service flow is lower than the forwarding priority of the other service flows.

[0141] Optionally, the sending module 203 may be configured to: forward each of the multiple service flows to the access network via a forwarding path that matches the SLA requirements of the service flow. The implementation of the functions of the sending module 203 may refer to the description of step 105 in the above method embodiment.

[0142] Optionally, the SLA requirement includes a path selection policy, where the path selection policy is used to characterize the service flow's requirement for a forwarding path;

[0143] The sending module 203 can also be used to report network parameters between the control node in the overlay network and other acceleration nodes in the overlay network. The implementation of the function of the sending module 203 can refer to the description of step 102 in the above method embodiment.

[0144] The receiving module 201 can also be used to receive multiple forwarding paths sent by the control node, which are determined based on network parameters reported by each acceleration node in the overlay network. The function of the sending module 203 can be implemented by referring to the relevant description of step 103 in the above method embodiment.

[0145] The sending module 203 may also be configured to determine, for each of the multiple service flows, a forwarding path from the multiple forwarding paths that matches the path selection policy of the service flow.

[0146] In summary, an embodiment of the present application provides a service flow transmission device, which is applied to an acceleration node in an overlay network. The device is capable of receiving multiple service flows sent by a server and obtaining the SLA requirements of the multiple service flows. Furthermore, when the device detects that the network resources of the overlay network do not meet the SLA requirements of the multiple service flows, it is capable of reducing the transmission quality of at least one target service flow with a lower SLA requirement. This ensures that when multiple service flows compete for network resources, the transmission quality of service flows with higher SLA requirements is prioritized.

[0147] The present application also provides another service flow transmission device, which can be applied to the server in the real-time communication system shown in Figures 1 to 3, and can be used to implement the steps performed by the server in the service flow transmission method provided in the above method embodiment. As shown in Figure 7, the service flow transmission device includes:

[0148] The sending module 301 is used to send multiple service flows to an acceleration node in the overlay network so that the acceleration node can forward the multiple service flows to the access network, and to reduce the transmission quality of at least one target service flow among the multiple service flows when the network resources of the overlay network do not meet the SLA requirements of the multiple service flows.

[0149] The SLA requirement of the at least one target service flow is lower than the SLA requirements of other service flows in the multiple service flows. After the multiple service flows are forwarded to the access network, the access network forwards the multiple service flows to the client. The functional implementation of the sending module 301 can refer to the relevant description of step 104 in the above method embodiment.

[0150] Optionally, as shown in FIG7 , the device may further include:

[0151] The first receiving module 302 is configured to receive the congestion level of the access network fed back by the client, where the congestion level is determined by the client based on the congestion label fed back by the network device in the access network. The implementation of the function of the first receiving module 302 may refer to the description of step 112 in the above method embodiment.

[0152] The adjustment module 303 is configured to adjust the transmission quality of at least one of the multiple service flows based on the congestion level of the access network and the SLA requirements of the multiple service flows. The functional implementation of the adjustment module 303 can refer to the description of step 114 in the above method embodiment.

[0153] Optionally, the sending quality may be characterized by at least one of the following parameters: sending priority, sending performance parameters, encoding parameters, rendering parameters, and type of transmission network.

[0154] Optionally, the first receiving module 302 may also be configured to receive the network status of the overlay network fed back by a control node in the overlay network. The implementation of the function of the first receiving module 302 may also refer to the description of step 113 in the above method embodiment.

[0155] The adjustment module 303 may be configured to adjust the transmission quality of at least one of the multiple service flows based on the congestion level of the access network, the network status of the overlay network, and the SLA requirements of the multiple service flows.

[0156] Optionally, with continued reference to FIG7 , the apparatus may further include:

[0157] The second receiving module 304 is configured to receive, from the acceleration node, an identifier of a data packet of at least one target service flow among the multiple service flows. The data packet of the at least one target service flow is a data packet discarded by the acceleration node after the network resources of the overlay network fail to meet the SLA requirements of the multiple service flows. The implementation of the functionality of the second receiving module 304 can be found in the description of step 108 in the above method embodiment.

[0158] The sending module 301 can also be used to mark the data packets of the at least one target service flow as data packets that do not need to be retransmitted. The functional implementation of the sending module 301 can also refer to the relevant description of step 109 in the above method embodiment.

[0159] Optionally, the real-time communication system may further include: an SLA management terminal.

[0160] The sending module 301 may also be configured to report the SLA requirements of at least one type of service to which the multiple service flows belong to the SLA management terminal.

[0161] Alternatively, as shown in FIG7 , the apparatus may further include: a third receiving module 305 , which may be configured to receive an SLA requirement of at least one type of service to which the multiple service flows belong, issued by the SLA management terminal.

[0162] In summary, embodiments of the present application provide a service flow transmission device for use on a server. This device can send multiple service flows to an acceleration node in an overlay network for forwarding by the acceleration node to an access network. Furthermore, upon detecting that the overlay network's network resources do not meet the SLA requirements of these multiple service flows, the acceleration node can reduce the transmission quality of at least one target service flow with a lower SLA requirement. This ensures that, when multiple service flows compete for network resources, the transmission quality of service flows with higher SLA requirements is prioritized.

[0163] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the above-described service flow transmission device and the specific working process of each module can refer to the corresponding process in the aforementioned method embodiment and will not be repeated here.

[0164] It is understandable that each module in the transmission device of the service flow (such as the receiving module 201, the acquisition module 202, the sending module 203 and the adjustment module 204, or the sending module 301, the first receiving module 302, the adjustment module 303, the second receiving module 304 and the third receiving module 305, etc.) can be implemented by software or by hardware. For example, the following takes the receiving module 201 as an example to introduce the implementation of the receiving module 201. Similarly, the implementation of the acquisition module 202, the sending module 203 and the adjustment module 204, as well as the sending module 301, the first receiving module 302, the adjustment module 303, the second receiving module 304 and the third receiving module 305 can all refer to the implementation of the receiving module 201.

[0165] As an example of a software functional unit, the receiving module 201 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the receiving module 201 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0166] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0167] As an example of a hardware functional unit, receiving module 201 may include at least one computing device, such as a server. Alternatively, receiving module 201 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0168] The multiple computing devices included in receiving module 201 can be distributed in the same region or in different regions. The multiple computing devices included in receiving module 201 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in receiving module 201 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0169] It is understood that in other embodiments, the receiving module 201 can be used to execute any steps in the aforementioned service flow transmission method performed by the acceleration node, and the acquisition module 202, the sending module 203, and the adjustment module 204 can also be used to execute any steps in the aforementioned service flow transmission method performed by the acceleration node. The steps implemented by the receiving module 201, the acquisition module 202, the sending module 203, and the adjustment module 204 can be specified as needed. By having each of these modules implement different steps in the service flow transmission method, the full functionality of the service flow transmission device is achieved.

[0170] It is also understood that in other embodiments, the sending module 301 can be used to execute any steps in the above-mentioned service flow transmission method performed by the server, and the first receiving module 302, the adjustment module 303, the second receiving module 304, and the third receiving module 305 can also be used to execute any steps in the above-mentioned service flow transmission method performed by the server. The steps that the sending module 301, the first receiving module 302, the adjustment module 303, the second receiving module 304, and the third receiving module 305 are responsible for implementing can be specified as needed. By having each of these modules implement different steps in the service flow transmission method, the full functionality of the service flow transmission device is realized.

[0171] Figure 8 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application. The computing device can be an acceleration node and can implement the steps performed by the acceleration node in the above method embodiment, or the computing device can be a server and can implement the steps performed by the server in the above method embodiment. Referring to Figure 8, the computing device may include: a bus 402, a processor 404, a memory 406, and a communication interface 408. The processor 404, the memory 406, and the communication interface 408 communicate with each other via the bus 402. It should be understood that the embodiment of the present application does not limit the number of processors and memories in the computing device.

[0172] Bus 402 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG8 shows a single bus line, but this does not imply a single bus or type of bus. Bus 404 may include a path for transmitting information between various components of a computing device (e.g., memory 406, processor 404, and communication interface 408).

[0173] The processor 404 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0174] The memory 406 may include volatile memory, such as random access memory (RAM). The processor 404 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0175] Memory 406 stores executable program code, which processor 404 executes to implement the functions of the aforementioned receiving module 201, acquisition module 202, sending module 203, and adjustment module 204, respectively, thereby implementing the steps performed by the acceleration node in the above-mentioned method embodiment. Alternatively, processor 404 executes the executable program code to implement the functions of the aforementioned sending module 301, first receiving module 302, adjustment module 303, second receiving module 304, and third receiving module 305, respectively, thereby implementing the steps performed by the server in the above-mentioned method embodiment. In other words, memory 406 stores instructions for executing the above-mentioned service flow transmission method.

[0176] The communication interface 403 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device and other devices or a communication network.

[0177] Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0178] As shown in Figure 9, the computing device cluster includes at least one computing device. The memory 406 of one or more computing devices in the computing device cluster may store the same instructions for executing the above-mentioned service flow transmission method.

[0179] In some possible implementations, the memory 406 of one or more computing devices in the computing device cluster may also store partial instructions for executing the aforementioned method for transmitting the service flow. In other words, the combination of one or more computing devices may jointly execute instructions for executing the aforementioned method for transmitting the service flow.

[0180] It is understood that the memory 406 in different computing devices in the computing device cluster can store different instructions, each used to perform part of the functions of the service flow transmission device. In other words, the instructions stored in the memory 406 in different computing devices can implement the functions of one or more modules among the receiving module 201, the obtaining module 202, the sending module 203, and the adjustment module 204. Alternatively, the instructions stored in the memory 406 in different computing devices can implement the functions of one or more modules among the sending module 301, the first receiving module 302, the adjustment module 303, the second receiving module 304, and the third receiving module 305.

[0181] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network. The network may be a wide area network or a local area network, etc. FIG10 shows a possible implementation. As shown in FIG10 , two computing devices 400A and 400B are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 406 in different computing devices in the computing device cluster may store different instructions for executing part of the functions of the transmission device of the business flow. That is, the instructions stored in the memory 406 in different computing devices may implement the functions of one or more modules in the transmission device of the business flow.

[0182] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the steps performed by the acceleration node or the server in the method for transmitting the service flow provided in the above method embodiment.

[0183] The present application also provides a computer program product containing instructions. The computer program product may be software or a program product containing instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute the steps performed by the acceleration node or server in the method for transmitting a service flow provided in the above method embodiment.

[0184] In the embodiments of the present application, the terms "first", "second" and "third" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance. In the embodiments of the present application, the term "at least one" refers to one or more, and "a plurality" refers to two or more. In the embodiments of the present application, the term "and / or" is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B may represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the related objects before and after are in an "or" relationship.

[0185] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of the present application, and not to limit them. Although the embodiments of the present application are described in detail with reference to the aforementioned embodiments, ordinary technicians in this field should understand that they can still modify the technical solutions recorded in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for transmitting a service flow, characterized in that: Applied to a real-time communication system, the real-time communication system includes: a client, an access network, an overlay network, and a server; the method includes: The acceleration node in the overlay network receives multiple service flows sent by the server; The acceleration node obtains the service level agreement SLA requirements of the multiple business flows; The acceleration node forwards the multiple service flows to the access network, so that the access network forwards the multiple service flows to the client; If the network resources of the overlay network do not meet the SLA requirements of the multiple service flows, the acceleration node reduces the transmission quality of at least one target service flow among the multiple service flows; The SLA requirement of the at least one target service flow is lower than the SLA requirements of other service flows among the multiple service flows.

2. The method according to claim 1, characterized in that: The acceleration node forwarding the multiple service flows to the access network includes: For each of the multiple service flows, the acceleration node forwards the service flow to the access network through a forwarding path that matches the SLA requirement of the service flow.

3. The method according to claim 2, characterized in that The SLA requirement includes a path selection strategy, and the path selection strategy is used to characterize the demand of the service flow for the forwarding path; Before the acceleration node forwards the service flow to the access network through a forwarding path that matches the SLA requirement of the service flow, the method further includes: The acceleration node reports network parameters between the acceleration node and other acceleration nodes in the overlay network to the control node in the overlay network; The acceleration node receives a plurality of forwarding paths sent by the control node, where the plurality of forwarding paths are determined based on network parameters reported by each acceleration node in the overlay network; For each of the multiple service flows, the acceleration node determines a forwarding path that matches the path selection policy of the service flow from the multiple forwarding paths.

4. The method according to any one of claims 1 to 3, characterized in that: The acceleration node reduces the transmission quality of at least one target service flow among the multiple service flows, including: The acceleration node delays sending at least one target service flow among the multiple service flows; And / or, the acceleration node discards data packets of at least one target service flow among the multiple service flows.

5. The method according to claim 4, characterized in that After the acceleration node discards a data packet of at least one target service flow among the multiple service flows, the method further includes: The acceleration node feeds back to the server an identifier of the discarded data packet of the at least one target service flow.

6. The method according to any one of claims 1 to 5, characterized in that: The real-time communication system further includes: an SLA management terminal, wherein the acceleration node obtains the SLA requirements of the multiple service flows, including: The acceleration node receives an SLA requirement of at least one type of service issued by the SLA management end; The acceleration node determines an SLA requirement of at least one service flow among the multiple service flows based on a type of service to which the at least one service flow belongs.

7. The method according to any one of claims 1 to 6, characterized in that: The acceleration node obtains the SLA requirements of the multiple service flows, including: The acceleration node obtains the SLA requirement of at least one service flow from a data packet of at least one service flow among the multiple service flows.

8. The method according to any one of claims 1 to 7, characterized in that: The SLA requirement includes a requirement for at least one of the following parameters: end-to-end delay, reliability, and forwarding priority; The end-to-end delay of the at least one target service flow is higher than the end-to-end delay of the other service flows; The reliability of the at least one target service flow is lower than the reliability of the other service flows; The forwarding priority of the at least one target service flow is lower than the forwarding priority of the other service flows.

9. A method for transmitting a service flow, characterized in that: Applied to a real-time communication system, the real-time communication system includes: a client, an access network, an overlay network, and a server; the method includes: The server sends a plurality of service flows to an acceleration node in the overlay network, so that the acceleration node forwards the plurality of service flows to the access network, and reduces the transmission quality of at least one target service flow among the plurality of service flows when the network resources of the overlay network do not meet the service level agreement (SLA) requirements of the plurality of service flows; Among them, the SLA requirement of at least one target service flow is lower than the SLA requirements of other service flows among the multiple service flows. After the multiple service flows are forwarded to the access network, the access network forwards the multiple service flows to the client.

10. The method according to claim 9, characterized in that The method further comprises: The server receives the congestion level of the access network fed back by the client, where the congestion level is determined by the client based on a congestion label fed back by a network device in the access network; The service end adjusts the sending quality of at least one of the multiple service flows based on the congestion level of the access network and the SLA requirements of the multiple service flows.

11. The method according to claim 10, characterized in that The sending quality is characterized by at least one of the following parameters: sending priority, sending performance parameters, encoding parameters, rendering parameters, and type of transmission network.

12. The method according to claim 10 or 11, characterized in that: The method further includes: the server receiving a network status of the overlay network fed back by a control node in the overlay network; The server adjusts the sending quality of at least one of the multiple service flows based on the congestion level of the access network and the SLA requirements of the multiple service flows, including: The server adjusts the sending quality of at least one of the multiple service flows based on the congestion level of the access network, the network status of the overlay network, and the SLA requirements of the multiple service flows.

13. The method according to any one of claims 9 to 12, characterized in that: The method further comprises: The server receives an identifier of a data packet of at least one target service flow among the multiple service flows fed back by the acceleration node, where the data packet of the at least one target service flow is a data packet discarded by the acceleration node after the network resources of the overlay network do not meet the SLA requirements of the multiple service flows; The server marks the data packets of the at least one target service flow as data packets that do not need to be retransmitted.

14. The method according to any one of claims 9 to 13, characterized in that: The real-time communication system further includes: an SLA management terminal; the method further includes: The service end reports the SLA requirements of at least one type of service to which the multiple service flows belong to to the SLA management end; Alternatively, the service end receives an SLA requirement of at least one type of service to which the multiple service flows belong, which is issued by the SLA management end.

15. A transmission device for a service flow, characterized in that: The device is applied to an acceleration node in a coverage network in a real-time communication system, wherein the real-time communication system further comprises: a client, an access network, and a server; and the device comprises: A receiving module, used for receiving multiple service flows sent by the server; An acquisition module, used to acquire service level agreement (SLA) requirements of the multiple business flows; A sending module, used for forwarding the multiple service flows to the access network, so that the access network forwards the multiple service flows to the client; an adjustment module, configured to reduce the transmission quality of at least one target service flow among the multiple service flows if the network resources of the overlay network do not meet the SLA requirements of the multiple service flows; The SLA requirement of the at least one target service flow is lower than the SLA requirements of other service flows among the multiple service flows.

16. The device according to claim 15, characterized in that The sending module is used for: For each service flow among the multiple service flows, the service flow is forwarded to the access network through a forwarding path that matches the SLA requirement of the service flow.

17. The device according to claim 16, characterized in that The SLA requirement includes a path selection strategy, and the path selection strategy is used to characterize the demand of the service flow for the forwarding path; The sending module is further used to report network parameters between the control node in the overlay network and other acceleration nodes in the overlay network; The receiving module is further configured to receive multiple forwarding paths sent by the control node, where the multiple forwarding paths are determined based on network parameters reported by each acceleration node in the overlay network; The sending module is further configured to determine, for each of the multiple service flows, a forwarding path from the multiple forwarding paths that matches the path selection strategy of the service flow.

18. The device according to any one of claims 15 to 17, characterized in that The adjustment module is used for: Delaying sending of at least one target service flow among the multiple service flows; And / or, discarding data packets of at least one target service flow among the multiple service flows.

19. The device according to claim 18, characterized in that The sending module is also used for: After the adjustment module discards a data packet of at least one target service flow among the multiple service flows, an identifier of the discarded data packet of the at least one target service flow is fed back to the server.

20. The device according to any one of claims 15 to 19, characterized in that The real-time communication system further includes: an SLA management terminal, and the acquisition module is used to: Receiving an SLA requirement of at least one type of service issued by the SLA management terminal; Based on the type of service to which at least one service flow among the multiple service flows belongs, an SLA requirement of the at least one service flow is determined.

21. The device according to any one of claims 15 to 20, characterized in that The acquisition module is used to: An SLA requirement of at least one service flow among the multiple service flows is obtained from a data packet of the at least one service flow.

22. The device according to any one of claims 15 to 21, characterized in that The SLA requirement includes a requirement for at least one of the following parameters: end-to-end delay, reliability, and forwarding priority; The end-to-end delay of the at least one target service flow is higher than the end-to-end delay of the other service flows; The reliability of the at least one target service flow is lower than the reliability of the other service flows; The forwarding priority of the at least one target service flow is lower than the forwarding priority of the other service flows.

23. A transmission device for a service flow, characterized in that: The server end is applied to a real-time communication system, wherein the real-time communication system further comprises: a client, an access network, and an overlay network; the device comprises: a sending module, configured to send a plurality of service flows to an acceleration node in the overlay network, so that the acceleration node forwards the plurality of service flows to the access network, and to reduce the transmission quality of at least one target service flow among the plurality of service flows when the network resources of the overlay network do not meet the service level agreement (SLA) requirements of the plurality of service flows; Among them, the SLA requirement of at least one target service flow is lower than the SLA requirements of other service flows among the multiple service flows. After the multiple service flows are forwarded to the access network, the access network forwards the multiple service flows to the client.

24. The device according to claim 23, characterized in that The device also includes: A first receiving module, configured to receive a congestion level of the access network fed back by the client, where the congestion level is determined by the client based on a congestion label fed back by a network device in the access network; An adjustment module is used to adjust the sending quality of at least one service flow among the multiple service flows based on the congestion level of the access network and the SLA requirements of the multiple service flows.

25. The device according to claim 24, characterized in that The sending quality is characterized by at least one of the following parameters: sending priority, sending performance parameters, encoding parameters, rendering parameters, and type of transmission network.

26. The device according to claim 24 or 25, characterized in that The first receiving module is further configured to receive a network status of the overlay network fed back by a control node in the overlay network; The adjustment module is used to adjust the transmission quality of at least one of the multiple service flows based on the congestion level of the access network, the network status of the overlay network, and the SLA requirements of the multiple service flows.

27. The device according to any one of claims 23 to 26, characterized in that The device also includes: A second receiving module is configured to receive an identifier of a data packet of at least one target service flow among the multiple service flows fed back by the acceleration node, where the data packet of the at least one target service flow is a data packet discarded by the acceleration node after the network resources of the overlay network do not meet the SLA requirements of the multiple service flows; The sending module is further used to mark the data packets of the at least one target service flow as data packets that do not need to be retransmitted.

28. The device according to any one of claims 23 to 27, characterized in that The real-time communication system further includes: an SLA management terminal; The sending module is further used to report the SLA requirements of at least one type of service to which the multiple service flows belong to to the SLA management terminal; Alternatively, the device further includes a third receiving module, and the third receiving module is used to receive the SLA requirement of at least one type of service to which the multiple service flows belong, which is issued by the SLA management end.

29. A computing device cluster, characterized in that: comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 14.

30. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 14.

31. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 14.

Images