A Method for Detecting Bandwidth Based on the BBR2 Protocol and a Cloud Gaming System

Abstract

The present invention discloses a method for detecting bandwidth based on the BBR2 protocol and a cloud game system. The present invention uses the BBR2 protocol for network transmission optimization. By adjusting data packet transmission and selecting strategies, network latency and packet loss rate are reduced, and network stability is improved. At the same time, for the cloud game scenario, the present invention optimizes game screen rendering and audio-video transmission, enhancing the user's game experience. The advantage of the present invention is that by combining the cloud game scenario and the BBR2 protocol for network transmission optimization, problems such as screen stuttering, high network latency, screen jitter, and video blur existing in cloud games are effectively solved, and the user's game experience is enhanced.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud games, and particularly to a method for detecting bandwidth based on the BBR2 protocol. Background Art

[0002] As an emerging game mode, cloud games have the advantages of not requiring high configuration of local devices, enabling rapid update of game content, and allowing users to play games anytime and anywhere. However, since cloud games need to transmit game screens and audio-visual data to user devices through the network, they are affected by factors such as network latency and insufficient bandwidth, resulting in problems such as screen stuttering, latency, jitter, and video blurring during the game process. The reasons for these problems are diverse, but one of the most important reasons that cannot be ignored is network congestion.

[0003] The earliest supported Cubic congestion control.

[0004] The Cubic congestion control algorithm does not have the concept of smooth transmission, but only judges whether to send or not. It will cause a large impact during burst traffic, and also has disadvantages such as poor packet loss resistance, high latency, easy stuttering, and poor preemption ability.

[0005] The existing relatively good optimization scheme for congestion control is GOOGLE's GCC.

[0006] GCC is a congestion control algorithm based on delay prediction and packet loss. The algorithm is divided into two parts: performing Kalman algorithm prediction at the receiving end and then returning to the sending end for bitrate adjustment. Transport CC is a congestion control algorithm based on linear prediction at the sending end. Like GCC, the main body is based on delay-based congestion control judgment. These two algorithms have defects to varying degrees. They are too academic in the process of implementing the algorithms. For example, GCC has a threshold of 2%-10% for packet loss rate, but in fact, congestion does not necessarily result in packet loss, and packet loss does not necessarily mean congestion occurs. This situation is invalid for GCC. The main body of GCC based on delay estimation has no contention rate with bandwidth memory packet loss at the present stage. The Salsify algorithm proposed by Stanford University estimates the encoding speed of the entire encoder based on the delay between video frames, but it must be executed on the basis of the encoder and cannot meet the requirement of transmitting video to the sever for distribution. If only segmental congestion control is performed, re-decoding and re-encoding are required on the sever, which cannot meet the current application in the real-time video field.

[0007] Problems and difficulties faced by the existing GCC algorithm:

[0008] 1. Bandwidth recovery speed

[0009] The core of the GCC algorithm is slow increase and fast decrease. It exponentially decreases the bandwidth when the network is congested. After the network recovers, the bandwidth increases at a very slow speed. A slow recovery of the bandwidth is a good thing for the network. However, it takes a very long time for the low bandwidth to recover to a high bandwidth, which is not good for the user experience. In addition, it is required to comprehensively slow down the rate of bandwidth increase to maintain bandwidth stability in the bandwidth-limited scenario. Currently, it takes 1 minute for the bandwidth to increase from 300 kbps to 3 Mbps, and 90 seconds to increase to 6 Mbps. This problem cannot be solved at the algorithm level for now. If the recovery speed is increased, it will be more likely to cause bandwidth overestimation and bandwidth fluctuations in some scenarios. It is very difficult for the current algorithm to achieve compatibility between the recovery speed and bandwidth stability.

[0010] 2. Bandwidth accuracy

[0011] There is still a hard problem with the GCC algorithm in terms of bandwidth accuracy. First of all, in the GCC algorithm, bandwidth stability is strongly related to the accuracy of the sending bitrate, and is also strongly related to the packet loss rate and latency. The GCC algorithm is very sensitive to network congestion. Slight congestion will cause bandwidth fluctuations, and the fluctuation range is large. If it is necessary to adapt to network change scenarios such as high jitter and high latency, the native GCC algorithm will easily drop to an unacceptable range, and in some fixed packet loss scenarios, the bandwidth accuracy of GCC will become very poor.

[0012] 3. Bandwidth stability

[0013] Stability is a point that is very difficult to optimize. The bandwidth is originally dynamically changing and quite frequently. In the bandwidth-limited scenario, the bandwidth tolerates some up and down fluctuations. However, this fluctuation range cannot deviate too much. In the case of fluctuations with the native GCC algorithm, the fluctuation range will change very greatly.

[0014] Therefore, the existing technology has defects and needs to be improved. Summary of the invention

[0015] The technical problem to be solved by the present invention is to provide a method for detecting bandwidth based on the BBR2 protocol and a cloud game system, which solves the problems of frame freezing, high network latency, frame jitter, and video blur existing in traditional cloud games.

[0016] The technical solution of the present invention is as follows: Provide a method for detecting bandwidth based on the BBR2 protocol, which is divided into 4 stages, namely the STARTUP stage, which is the startup stage, the DRAIN stage, which is the drain stage, the PROBE_BW stage, which is the bandwidth detection stage, and the PROBE_RTT stage, which is the RTT detection stage; specifically includes the following steps.

[0017] S1: Enter the STARTUP phase. Perform bitrate gain and bandwidth growth according to a bandwidth gain parameter greater than 1 times. If the bandwidth increase does not exceed 25% after at least 3 RTT (Round-Trip Time) cycles, it is determined that the bandwidth has reached the maximum value at this time. There is already queued data at this time, and the fifo (First-In-First-Out queue) is overloaded. Immediately enter the DRAIN phase; preferably, perform bitrate gain and bandwidth growth according to a bandwidth gain parameter ≥1.5 times. If the bandwidth increase does not exceed 25% after at least 3 RTT cycles.

[0018] S2: Enter the DRAIN phase. Send data by the reciprocal of the bitrate gain multiple in the STARTUP phase to clear the queued data. When emptied, there is no queued data and the fifo is not overloaded; immediately enter the PROBE_BW phase.

[0019] S3: Enter the PROBE_BW phase. Measure the maximum bandwidth by cyclically adjusting the sending speed periodically. Detect the actual bandwidth by adjusting the sending speed in 3 steps in each cycle; S31: Send at a speed greater than 1 times, S32: Send at a speed less than 1 times, S33: Send at 1 times speed randomly for several times to obtain the RTT (Round-Trip Time) of each cycle; Continuously observe a first time period. If the RTT within this first time period does not have an RTT ≤ the minimum RTT in all test cycles, that is, the RTT no longer decreases and the bandwidth channel is in a filled state, the maximum bandwidth is detected. Immediately enter the PROBE_RTT phase; The first time period is 5 - 15 s, preferably, the first time period is 10 seconds. The advantage of using steps S31 - S33 to detect the actual bandwidth is to ensure the stability of the bandwidth. Continuously observe for 10 seconds. The advantage of 10 seconds is that it is neither too long nor too short, improving the robustness of the detection and also ensuring the bandwidth recovery speed. In this step, the sum of the speed greater than 1 times in S31 and the speed less than 1 times in S32 is 2 times the speed; The number of random times in S33 is 1 - 6 times. Preferably, the speed greater than 1 times in S31 is 1.25 times the speed, and the speed less than 1 times in S32 is 0.75 times the speed.

[0020] S4: Enter the PROBE_RTT phase. Transmit data in the form of data packets. Send data using half of the maximum data packet that can be sent. Continuously for several second time periods. At this time, the bandwidth channel is in a filled state but there is no queue, and the minimum RTT is detected. The second time period is 100 - 300 milliseconds. In an optimal embodiment, the second time period is 200 milliseconds. After detecting the bandwidth, if it is in a full bandwidth state at this time, switch to the PROBE_BW phase. If it is not in a full bandwidth state at this time, switch to the STARTUP phase.

[0021] Adopting the BBR2 protocol, when probing the bandwidth, it will not cause large changes in RTT and avoid the increase of transmission delay. At the same time, optimize the bandwidth probing strategy of the BBR algorithm. When detecting the minimum RTT, keep sending data to ensure the stable transmission of media data. During the bandwidth detection process, adopt a fast convergence strategy, optimize the maximum bandwidth calculation method and shorten the feedback time of bandwidth estimation to quickly detect the bandwidth.

[0022] This solution adopts the BBR2 protocol to detect the maximum bandwidth and minimum delay of the network by adjusting the transmission volume. The maximum bandwidth is obtained by sending data exceeding the network capacity. When the delay starts to increase after increasing the transmission volume, this is the maximum bandwidth. The minimum delay is calculated by sending data lower than the network capacity. When the delay does not decrease after reducing the transmission volume, the RTT at this time is the minimum delay. Different from the traditional congestion control using the packet loss feedback mechanism, the BBR2 protocol continuously obtains the minimum RTT and maximum bandwidth of the current changing network, automatically detects the delay feedback bandwidth and the actual network status, and has better real-time performance. Use the strategy of raising and lowering the transmission speed to detect the real-time bandwidth, and the bandwidth is more accurate, stable, and has a faster recovery speed.

[0023] A cloud game system includes: a cloud game server and a cloud game client; the cloud game server is used to collect game screens, encode game screens, and send game screen data to the cloud game client through a network sending module. The cloud game client receives the game screen data sent by the cloud game server through a network receiving module, decodes the game screen, and renders the game screen; the method of detecting bandwidth based on the BBR2 protocol is adopted between the network sending module and the network receiving module to detect the bandwidth.

[0024] Adopting the above solution, the present invention provides a method for detecting bandwidth based on the BBR2 protocol and a cloud game system. The BBR2 protocol is used for network transmission optimization. By adjusting the packet transmission and strategy selection, the network delay and packet loss rate are reduced, and the network stability is improved. At the same time, for the cloud game scenario, the present invention optimizes the game screen rendering and audio-video transmission, enhancing the user's game experience. The advantages of the present invention are that by combining the cloud game scenario and the BBR2 protocol for network transmission optimization, the problems of frame freezing, high network delay, frame jitter, video blur, etc. existing in cloud games are effectively solved, and the user's game experience is improved. Description of the Drawings

[0025] Figure 1 It is the flowchart of the method for detecting bandwidth based on the BBR2 protocol of the present invention. Detailed Embodiments

[0026] The following combines the drawings and specific embodiments to elaborate on the present invention in detail.

[0027] Please refer to Figure 1 , this embodiment provides a cloud game system, including: a cloud game server and a cloud game client; the cloud game server is used to collect game screens, encode game screens, and send game screen data to the cloud game client through a network sending module, and the cloud game client receives the game screen data sent by the cloud game server through a network receiving module, decodes the game screen, and renders the game screen; a method of detecting bandwidth based on the BBR2 protocol is adopted between the network sending module and the network receiving module to detect bandwidth.

[0028] The method of detecting bandwidth based on the BBR2 protocol is divided into 4 stages, namely the STARTUP stage is the startup stage, the DRAIN stage is the drain stage, the PROBE_BW stage is the bandwidth detection stage, and the PROBE_RTT stage is the RTT detection stage; the specific steps are as follows.

[0029] S1: Enter the STARTUP stage, perform bitrate gain and bandwidth growth according to a bandwidth gain parameter greater than 1 time. If the bandwidth increase does not exceed 25% after at least 3 RTT (round-trip delay) cycles, it is determined that the bandwidth has reached the maximum value at this time. There is already queued data at this time, and the fifo (first-in-first-out queue) is overloaded, and immediately enter the DRAIN stage; preferably, perform bitrate gain and bandwidth growth according to a bandwidth gain parameter ≥1.5 times. If the bandwidth increase does not exceed 25% after at least 3 RTT cycles.

[0030] S2: Enter the DRAIN stage, send through the reciprocal of the bitrate gain multiple in the STARTUP stage, clear the queued data. When drained, there is no queued data and the fifo is not overloaded; immediately enter the PROBE_BW stage.

[0031] S3: Enter the PROBE_BW phase. Measure the maximum bandwidth by cyclically adjusting the transmission speed. Detect the actual bandwidth by adjusting the transmission speed in three steps in each cycle; S31: Transmit at a speed greater than 1 times; S32: Transmit at a speed less than 1 times; S33: Transmit at 1 times speed for a number of randomized times to obtain the RTT (round-trip time delay) for each cycle. Continuously observe a first time period. If the RTT within this first time period does not have an RTT ≤ the minimum RTT among all test cycles, that is, the RTT no longer decreases, the bandwidth channel is in a filled state, the maximum bandwidth is detected, and immediately enter the PROBE_RTT phase; the first time period is 5 - 15 s. In this embodiment, the first time period is 10 seconds. The advantage of using steps S31 - S33 to detect the actual bandwidth is to ensure the stability of the bandwidth. Continuously observe for 10 seconds. The advantage of 10 seconds is that it is neither too long nor too short, improving the robustness of detection and ensuring the bandwidth recovery speed. In this step, the sum of the speed greater than 1 times in S31 and the speed less than 1 times in S32 is 2 times speed; the number of randomized times in S33 is 1 - 6 times. Preferably, the speed greater than 1 times in S31 is 1.25 times speed, and the speed less than 1 times in S32 is 0.75 times speed.

[0032] S4: Enter the PROBE_RTT phase. Transmit data in the form of data packets, and transmit data using half of the maximum data packet that can be sent. Continuously observe for a number of second time periods. At this time, the bandwidth channel is in a filled state but there is no queuing, and the minimum RTT is detected. The second time period is 100 - 300 milliseconds. In this embodiment, the second time period is 200 milliseconds. After detecting the bandwidth, if it is in a full bandwidth state at this time, switch to the PROBE_BW phase; if it is not in a full bandwidth state at this time, switch to the STARTUP phase.

[0033] The specific parameter values in the above four phases of BBR2 are not limited to the values that have been used, and the value range can be appropriately adjusted according to the specific network status.

[0034] Compared with the existing method, this solution has the following technical effects.

[0035] 1. Picture stuttering:

[0036] Compared with Cubic congestion control, when the code rate fluctuates greatly, picture stuttering is inevitable when using Cubic congestion control, while picture stuttering hardly ever occurs when using BBR2 congestion control.

[0037] 2. Average network delay

[0038] Compared with Cubic congestion control, at the same 5 Mb code rate, the average network delay is reduced from 50 milliseconds to 40 milliseconds.

[0039] 3. Network delay jitter:

[0040] Compared with Cubic congestion control, at the same 5Mb bitrate, the delay range changes from 30 - 200 milliseconds to 30 - 80 milliseconds

[0041] 4. Bandwidth recovery time

[0042] Compared with GCC congestion control, the detection time of BBR2 is 10 seconds and can be further optimized to reduce the time. The core of the GCC algorithm is slow increase and fast decrease. When congestion occurs, the bitrate drops quickly and rises slowly. It takes more than 1 minute to recover to 5Mb bitrate after the drop.

[0043] 5. Bandwidth accuracy

[0044] Compared with GCC congestion control, the error between the bandwidth detected by BBR2 and the actual bandwidth is basically within 20%, while when congestion occurs in GCC, the detected bandwidth value is generally less than 50% of the actual value.

[0045] In summary, the present invention provides a method for detecting bandwidth based on the BBR2 protocol and a cloud game system. By using the BBR2 protocol for network transmission optimization, through the adjustment of data packet transmission and strategy selection, network latency and packet loss rate are reduced, and network stability is improved. At the same time, for the cloud game scenario, the present invention optimizes game screen rendering and audio - video transmission, enhancing the user's game experience. The advantages of the present invention are that by combining the cloud game scenario and the BBR2 protocol for network transmission optimization, problems such as screen freezing, high network latency, screen jitter, and video blurring existing in cloud games are effectively solved, and the user's game experience is enhanced.

[0046] The above are only the preferred embodiments of the present invention and are not used to limit the present invention. Any modifications, equivalent replacements, and improvements made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.

Claims

1. A method for detecting bandwidth based on the BBR2 protocol, characterized in that, It is divided into 4 stages, namely: STARTUP stage, DRAIN stage, PROBE_BW stage, and PROBE_RTT stage; specifically including the following steps; S1: Enter the STARTUP stage, perform bitrate gain and bandwidth growth according to a bandwidth gain parameter greater than 1 time. If the bandwidth increase does not exceed 25% after at least 3 RTT cycles, it is determined that the bandwidth has reached the maximum value at this time. At this time, there is queued data and the fifo is overloaded, and immediately enter the DRAIN stage; S2: Enter the DRAIN stage, send data by the reciprocal of the bitrate gain multiple in the STARTUP stage to clear the queued data. When emptied, there is no queued data and the fifo is not overloaded; immediately enter the PROBE_BW stage; S3: Enter the PROBE_BW stage, measure the maximum bandwidth by cyclically adjusting the sending speed in each cycle. The sending speed is detected for the actual bandwidth through 3 steps in each cycle; S31: Send at a speed greater than 1 time, S32: Send at a speed less than 1 time, S33: Randomly send at a speed of 1 time for several times to obtain the RTT of each cycle; Continuously observe a first time period. If the RTT in this first time period does not have RTT ≤ the minimum RTT in all test cycles, that is, the RTT no longer becomes smaller and the bandwidth channel is in a filled state, the maximum bandwidth is detected, and immediately enter the PROBE_RTT stage; S4: Enter the PROBE_RTT stage, send data with half of the maximum data packet that can be sent, and continue for several second time periods. At this time, the bandwidth channel is in a filled state but there is no queue, and the minimum RTT is detected.

2. The method for detecting bandwidth based on the BBR2 protocol according to claim 1, wherein In step S4, it also includes: after detecting the bandwidth, if it is in a full bandwidth state at this time, switch to the PROBE_BW stage; if it is not in a full bandwidth state at this time, switch to the STARTUP stage.

3. A method for detecting bandwidth based on the BBR2 protocol according to claim 1, wherein In step S1, perform bitrate gain and bandwidth growth according to a bandwidth gain parameter ≥ 1.5 times. The bandwidth increase does not exceed 25% after at least 3 RTT cycles.

4. A method for detecting bandwidth based on the BBR2 protocol according to claim 1, characterized in that, In step S3, the sum of the speed greater than 1 time in S31 and the speed less than 1 time in S32 is 2 times the speed; the number of random times in S33 is 1 - 6 times.

5. The method for detecting bandwidth based on the BBR2 protocol according to claim 4, wherein The speed greater than 1 time in S31 is 1.25 times the speed, and the speed less than 1 time in S32 is 0.75 times the speed.

6. A method for detecting bandwidth based on the BBR2 protocol according to claim 1, wherein In step S3, the first time period is 5 - 15 s.

7. A method for detecting bandwidth based on the BBR2 protocol according to claim 1, characterized in that The second time period is 100 - 300 milliseconds.

8. A cloud gaming system, characterized in that, It includes: A cloud game server and a cloud game client; the cloud game server is used to collect game screens, encode game screens, and send game screen data to the cloud game client through a network sending module. The cloud game client receives the game screen data sent by the cloud game server through a network receiving module, decodes the game screen, and renders the game screen; the network sending module and the network receiving module use the method for detecting bandwidth based on the BBR2 protocol described in any one of claims 1 - 7 to detect bandwidth.

Images