Rate adjustment method and communication apparatus

Abstract

A rate adjustment method and a communication apparatus, relating to the field of communications, and capable of reducing the task response time under a terminal-cloud collaboration architecture. The method comprises: receiving first information from an access network device, acquiring a first packet of a terminal device, and sending a second packet to an application server. The first information is used for indicating that a first quality of service (QoS) requirement corresponding to a first QoS flow needs to be adjusted to a second QoS requirement; the first QoS requirement and the second QoS requirement correspond to different data transmission rates; the second packet carries second information; the second information is determined on the basis of the first information and the following information in the first packet: a first number of packets having experienced congestion, a first number of packets having not experienced congestion, and the number of packets that do not support explicit congestion notification (ECN) feedback; the second information is used for determining a first congestion ratio when the first QoS flow is transmitted on the basis of the first QoS requirement; the first congestion ratio is used for adjusting the data transmission rate of the first QoS flow.

Description

Speed ​​regulation method and communication device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on November 30, 2023, with application number 202311632497.4 and application name “Speed ​​Control Method and Communication Device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communications, and in particular to a speed regulation method and a communication device. Background Art

[0003] In an end-cloud collaborative business architecture, terminal devices and the cloud collaborate interactively to complete computing tasks, such as video rendering and deep neural network training / inference, to achieve task division and data exchange, optimizing system efficiency. In this architecture, both the terminal device and the cloud participate in computing tasks simultaneously, and there is information exchange between the two. Therefore, it is necessary to consider the response time for completing computing tasks, that is, the time elapsed from task initiation to completion. In order to meet the task response time requirements, it is usually necessary to consider the computing power status and wireless communication status of the terminal device, and adjust the transmission rate at the application layer of the cloud based on changes in these states. However, how to ensure that the task response time under the end-cloud collaborative architecture meets the requirements has become an urgent problem to be solved. Summary of the Invention

[0004] The embodiments of the present application provide a speed regulation method and a communication device, which can improve the response speed of completing computing tasks in an end-cloud collaborative architecture and reduce task response time.

[0005] To achieve the above objectives, this application adopts the following technical solutions:

[0006] In a first aspect, a speed adjustment method is provided. The method can be executed by a user plane network element, or by a component of the user plane network element, such as a processor, chip, or chip system of the user plane network element. It can also be implemented by a logic module or software that implements all or part of the user plane network element. The method includes: receiving first information from an access network device. The first information indicates that a first QoS requirement corresponding to a first quality of service (QoS) flow needs to be adjusted to a second QoS requirement, where the first QoS requirement and the second QoS requirement correspond to different data transmission rates. A first message from a terminal device is obtained, the first message including a first number of packets experiencing congestion, a first number of packets not experiencing congestion, and a number of packets that do not support explicit congestion notification (ECN) feedback. A second message is sent to an application server, the second message carrying second information, the second information being determined based on the first information, the first number of packets experiencing congestion, the first number of packets not experiencing congestion, and the number of packets that do not support ECN feedback. The second information is used to determine a first congestion ratio when the first QoS flow is transmitted at the first QoS requirement, and the first congestion ratio is used to adjust the data transmission rate of the first QoS flow.

[0007] Based on this speed adjustment method, the user-plane network element obtains the latest network status changes and congestion conditions in real time based on the QoS requirement changes indicated by the first information sent by the access network device. The user-plane network element updates the ECN feedback information in the first message obtained based on the first information to obtain second information, and then feeds the second information back to the application server via the second message, allowing the application server to adjust the data transmission rate based on the second information. Thus, on the one hand, the user-plane network element does not need to bypass the terminal device twice through the air interface to obtain ECN feedback information, and there is no interval for the terminal device to count ECN feedback information, which can increase the ECN feedback rate and thus reduce task response time. On the other hand, the user-plane network element feeds back the ECN feedback information adjusted by the first information to the application server via the second message, so that the data transmission rate adjusted by the application server is more consistent with the real-time status of the network, thereby also reducing task response time.

[0008] In one possible design scheme, the first information may include one of the following: the second congestion ratio when the first QoS flow is transmitted with the first QoS requirement, the identifier of the second QoS requirement, or the QoS parameters in the second QoS requirement, wherein the second congestion ratio is determined based on the first QoS requirement and the second QoS requirement. Thus, the user-plane network element can obtain the latest network status changes in real time based on the congestion ratio information, the identifier of the QoS requirement that needs to be adjusted, or the QoS parameters in the QoS requirement that needs to be adjusted, adjust the ECN feedback information obtained from the terminal device according to the network status changes, and feed it back to the application server, so that the data transmission rate adjusted by the application server is more consistent with the real-time status of the network, thereby reducing the task response time. It should be understood that the QoS parameters in the second QoS requirement included in the first information may be one or more QoS parameters selected by the access network device from the second QoS requirement.

[0009] In one possible design, the QoS parameters may include at least one of the following: guaranteed flow bit rate (GFBR), packet delay budget (PDB), or packet error rate (PER). It should be understood that in addition to the three aforementioned QoS parameters, the QoS requirements in the embodiments of the present application may also include other QoS parameters for providing feedback on network status.

[0010] In one possible design, the first information may be carried in a message sent by the access network device, for example, in a message header of a General Packet Radio Tunneling Protocol-User Plane GTP-U message.

[0011] In one possible design, the second information may include a second number of packets experiencing congestion, a second number of packets not experiencing congestion, and a number of packets that do not support ECN feedback. The second number of packets experiencing congestion is determined based on the total number of statistical packets and the first information, and the second number of packets not experiencing congestion is determined based on the total number of statistical packets, the second number of packets experiencing congestion, and the number of packets that do not support ECN feedback. The total number of statistical packets is equal to the sum of the first number of packets experiencing congestion, the first number of packets not experiencing congestion, and the number of packets that do not support ECN feedback. Thus, the user-plane network element can update the number of packets experiencing congestion and the number of packets not experiencing congestion based on the ECN feedback information obtained in the first message and the first information, so that the ECN feedback information fed back to the application server better matches the real-time status changes of the network, thereby reducing task response time.

[0012] In one possible design, determining the second number of packets experiencing congestion based on the total number of packets counted and the first information may include: determining the second number of packets experiencing congestion based on the total number of packets counted and a second congestion ratio when the first QoS flow is transmitted with the first QoS requirement, wherein the second congestion ratio is determined based on the first information. Thus, the user-plane network element may determine the first congestion ratio based on the first information, and adjust the number of packets experiencing congestion based on the first congestion ratio and ECN feedback information in the first packet, so that the ECN feedback information fed back to the application server better matches real-time network status changes, thereby improving and reducing response time.

[0013] In one possible design, the second number of non-congested packets is the maximum value of the third number and zero, and the third number is equal to the difference between the total number of statistical packets, the second number of congested packets, and the number of packets that do not support ECN feedback. Thus, the user-plane network element adjusts the number of non-congested packets based on the adjusted number of congested packets, thereby ensuring that the data transmission rate adjusted by the application server matches real-time network status changes.

[0014] In a possible design scheme, the second message can be obtained by modifying the first number of messages that experienced congestion in the first message to the second number of messages that experienced congestion, and by modifying the first number of messages that did not experience congestion in the first message to the second number of messages that did not experience congestion. For example, the first message is a real-time transport layer feedback message RTPFB message that supports ECN feedback and is being sent by the terminal device. The user-side network element can modify the number of messages that experienced congestion and the number of messages that did not experience congestion in the received first message to obtain the second message. Thus, the RTCP transmission scheme of L4S is reused, so that the application server can adjust the sending rate without special adaptation and adjustment, which improves the compatibility of dynamic QoS for speed regulation with existing equipment and helps to evolve to a system that supports dynamic QoS.

[0015] In one possible design, the payload in the second message is empty, the message sequence number in the second message is the message sequence number in the first message plus one, the sender identifier and the receiver identifier in the second message are respectively the same as the sender identifier and the receiver identifier in the first message, the sender identifier is used to identify the terminal device, and the receiver identifier is used to identify the application server. For example, the user-plane network element can locally generate a continuous real-time transport layer feedback message RTPFB message that supports explicit congestion notification (ECN) feedback for transmission with the terminal device, and reuse the L4S RTCP transmission scheme, so that the application server can adjust the sending rate without special adaptation and adjustment, thereby improving the compatibility of dynamic QoS for speed regulation with existing equipment and facilitating the evolution to a system that supports dynamic QoS.

[0016] In one possible design scheme, the second message can be a real-time transport layer feedback message RTPFB message or a fast user datagram protocol network connection confirmation QUIC ACK message.

[0017] In a second aspect, a speed regulation method is provided. The method can be performed by an access network device, or by a component of the access network device, such as a processor, chip, or chip system of the access network device, or can be implemented by a logic module or software that can implement all or part of the access network device. The method includes: determining that a first QoS requirement corresponding to a first quality of service (QoS) flow needs to be adjusted to a second QoS requirement, where the first QoS requirement and the second QoS requirement correspond to different data transmission rates. First information is sent to a user plane network element. The first information is used to indicate that the first QoS requirement needs to be adjusted to the second QoS requirement.

[0018] In one possible design scheme, determining the need to adjust the first QoS requirement corresponding to the first QoS flow to a second QoS requirement may include: determining the need to adjust the first QoS requirement to a second QoS requirement based on the channel status, the air interface transmission status of the first QoS flow, and the first QoS requirement corresponding to the first QoS flow.

[0019] In one possible design scheme, the first information may include one of the following items: the second congestion ratio when the first QoS flow is transmitted with the first QoS requirement, the identifier of the second QoS requirement, or the QoS parameters in the second QoS requirement, wherein the second congestion ratio is determined based on the first QoS requirement and the second QoS requirement.

[0020] In one possible design, the QoS parameters may include at least one of the following: a guaranteed flow bit rate (GFBR), a packet delay budget (PDB), or a packet error rate (PER).

[0021] In one possible design scheme, the first information can be carried in a message sent by the access network device.

[0022] In one possible design, the speed adjustment method provided in the embodiment of the present application may further include: receiving third information from the application server, wherein the third information is used to indicate a third QoS requirement, which is a QoS requirement corresponding to the data transmission rate of the first QoS flow adjusted by the application server.

[0023] Among them, the technical effects of the method described in the second aspect can refer to the technical effects described in the method described in the first aspect above, and will not be repeated here.

[0024] In a third aspect, a speed adjustment method is provided. This method can be executed by an application server, or by a component of the application server, such as a processor, chip, or chip system of the application server, or by a logic module or software that implements all or part of the application server. The method includes: receiving a second message from a user-plane network element. The second message carries second information used to determine a first congestion ratio when a first quality of service (QoS) flow is transmitted with a first QoS requirement. The data transmission rate of the first QoS flow is adjusted based on the second information.

[0025] In one possible design, adjusting the data transmission rate of the first QoS flow based on the second information may include: determining a third QoS requirement based on the second information and a first QoS requirement corresponding to the first QoS flow, the first QoS requirement and the third QoS requirement corresponding to different data transmission rates; and adjusting the data transmission rate of the first QoS flow based on the third QoS requirement.

[0026] In a possible design solution, the speed adjustment method provided in the embodiment of the present application may further include: sending third information to the access network device, wherein the third information is used to indicate a third QoS requirement.

[0027] In one possible design, the second information may include a second number of packets that experience congestion, a second number of packets that do not experience congestion, and a number of packets that do not support explicit congestion notification (ECN) feedback.

[0028] In one possible design, the payload in the second message is empty.

[0029] Among them, the technical effects of the method described in the third aspect can refer to the technical effects described in the method described in the first aspect above, and will not be repeated here.

[0030] In a fourth aspect, a communication device is provided for implementing the various methods described above. The communication device may be the user plane network element described in the first aspect, or a device including the user plane network element, or a device included in the user plane network element, such as a chip. The communication device includes corresponding modules, units, or means for implementing the method described in the first aspect. The modules, units, or means may be implemented by hardware, software, or by executing corresponding software implementations in hardware. The hardware or software includes one or more modules or units corresponding to the above functions.

[0031] In some possible designs, the communication device includes: a processing module and a transceiver module. The transceiver module receives first information from an access network device. The first information indicates that a first QoS requirement corresponding to a first quality of service (QoS) flow needs to be adjusted to a second QoS requirement, and the first QoS requirement and the second QoS requirement correspond to different data transmission rates. The processing module is configured to obtain a first message from a terminal device, the first message including a first number of messages experiencing congestion, a first number of messages not experiencing congestion, and a number of messages that do not support explicit congestion notification (ECN) feedback. The transceiver module is further configured to send a second message to an application server, the second message carrying second information, the second information being determined based on the first information, the first number of messages experiencing congestion, the first number of messages not experiencing congestion, and the number of messages that do not support ECN feedback, wherein the second information is used to determine a first congestion ratio when the first QoS flow is transmitted at the first QoS requirement, and the first congestion ratio is used to adjust the data transmission rate of the first QoS flow.

[0032] In one possible design scheme, the first information may include one of the following items: the second congestion ratio when the first QoS flow is transmitted with the first QoS requirement, the identifier of the second QoS requirement, or the QoS parameters in the second QoS requirement, wherein the second congestion ratio is determined based on the first QoS requirement and the second QoS requirement.

[0033] In one possible design, the QoS parameters may include at least one of the following: a guaranteed flow bit rate (GFBR), a packet delay budget (PDB), or a packet error rate (PER).

[0034] In one possible design scheme, the first information can be carried in a message sent by the access network device.

[0035] In one possible design scheme, the second information may include a second number of packets that experienced congestion, a second number of packets that did not experience congestion, and a number of packets that do not support ECN feedback; wherein, the second number of packets that experienced congestion is determined based on the statistical total number of packets and the first information, and the second number of packets that did not experience congestion is determined based on the statistical total number of packets, the second number of packets that experienced congestion, and the number of packets that do not support ECN feedback, wherein the statistical total number of packets is the sum of the first number of packets that experienced congestion, the first number of packets that did not experience congestion, and the number of packets that do not support ECN feedback.

[0036] In one possible design scheme, the second number of packets experiencing congestion is determined based on the statistical total number of packets and the first information, which may include: the second number of packets experiencing congestion is determined based on the statistical total number of packets and the second congestion ratio when the first QoS flow is transmitted with the first QoS requirement, wherein the second congestion ratio is determined based on the first information.

[0037] In one possible design scheme, the second number of packets that are not congested is the maximum value of the third number and zero, and the third number is equal to the difference between the total number of statistical packets and the second number of packets that experience congestion and the number of packets that do not support ECN feedback.

[0038] In one possible design scheme, the second message can be obtained by modifying the first number of messages that experienced congestion in the first message to the second number of messages that experienced congestion, and modifying the first number of messages that did not experience congestion in the first message to the second number of messages that did not experience congestion.

[0039] In one possible design scheme, the payload in the second message is empty, the message sequence number in the second message is the message sequence number in the first message plus one, the sender identifier and the receiver identifier in the second message are respectively the same as the sender identifier and the receiver identifier in the first message, the sender identifier is used to identify the terminal device, and the receiver identifier is used to identify the application server.

[0040] In a possible design solution, the second message may be a real-time transport layer feedback message RTPFB message.

[0041] In one possible design solution, the transceiver module may include a receiving module and a sending module, wherein the sending module is used to implement the sending function of the communication device described in the first aspect, and the receiving module is used to implement the receiving function of the communication device described in the first aspect.

[0042] In one possible design solution, the communication device described in the fourth aspect may further include a storage module, wherein the storage module stores a program or instruction. When the processing module executes the program or instruction, the communication device described in the fourth aspect may execute the method described in the first aspect.

[0043] In a fifth aspect, a communication device is provided for implementing the various methods described above. The communication device may be the access network device described in the second aspect, or a device including the access network device, or a device included in the access network device, such as a chip. The communication device includes corresponding modules, units, or means for implementing the method described in the second aspect. The modules, units, or means may be implemented in hardware, software, or by executing corresponding software implementations in hardware. The hardware or software includes one or more modules or units corresponding to the above functions.

[0044] In some possible designs, the communication device includes: a processing module and a transceiver module. The processing module is configured to determine that a first QoS requirement corresponding to a first quality of service (QoS) flow needs to be adjusted to a second QoS requirement, where the first QoS requirement and the second QoS requirement correspond to different data transmission rates. The transceiver module is configured to send first information to a user plane network element. The first information indicates that the first QoS requirement needs to be adjusted to the second QoS requirement.

[0045] In one possible design scheme, a processing module is used to determine whether the first QoS requirement corresponding to the first QoS flow needs to be adjusted to a second QoS requirement, specifically including: a processing module is used to determine whether the first QoS requirement needs to be adjusted to a second QoS requirement based on the channel status, the air interface transmission status of the first QoS flow, and the first QoS requirement corresponding to the first QoS flow.

[0046] In one possible design scheme, the first information may include one of the following items: the second congestion ratio when the first QoS flow is transmitted with the first QoS requirement, the identifier of the second QoS requirement, or the QoS parameters in the second QoS requirement, wherein the second congestion ratio is determined based on the first QoS requirement and the second QoS requirement.

[0047] In one possible design, the QoS parameters may include at least one of the following: a guaranteed flow bit rate (GFBR), a packet delay budget (PDB), or a packet error rate (PER).

[0048] In one possible design scheme, the first information can be carried in a message sent by the access network device.

[0049] In one possible design, the transceiver module is further configured to receive third information from the application server, wherein the third information is configured to indicate a third QoS requirement, which is a QoS requirement corresponding to the data transmission rate of the first QoS flow adjusted by the application server.

[0050] In a sixth aspect, a communication device is provided for implementing the various methods described above. The communication device may be the application server described in the third aspect, or a device comprising the application server, or a device included in the application server, such as a chip. The communication device includes corresponding modules, units, or means for implementing the method described in the third aspect. The modules, units, or means may be implemented in hardware, software, or by executing corresponding software implementations in hardware. The hardware or software includes one or more modules or units corresponding to the above functions.

[0051] In some possible designs, the communication device includes: a processing module and a transceiver module. The transceiver module is configured to receive a second message from a user-plane network element. The second message carries second information used to determine a first congestion ratio when a first quality of service (QoS) flow is transmitted with a first QoS requirement. The processing module is configured to adjust a data transmission rate of the first QoS flow based on the second information.

[0052] In one possible design, a processing module configured to adjust a data transmission rate of a first QoS flow based on the second information specifically includes: a processing module configured to determine a third QoS requirement based on the second information and a first QoS requirement corresponding to the first QoS flow, wherein the first QoS requirement and the third QoS requirement correspond to different data transmission rates. The processing module is further configured to adjust the data transmission rate of the first QoS flow based on the third QoS requirement.

[0053] In one possible design solution, the transceiver module is further configured to send third information to the access network device, wherein the third information is configured to indicate a third QoS requirement.

[0054] In one possible design, the second information may include a second number of packets that experience congestion, a second number of packets that do not experience congestion, and a number of packets that do not support explicit congestion notification (ECN) feedback.

[0055] In one possible design, the payload in the second message is empty.

[0056] In a seventh aspect, a speed adjustment method is provided, comprising: an access network device sending first information to a user-plane network element. The first information indicates that a first QoS requirement corresponding to a first quality of service (QoS) flow needs to be adjusted to a second QoS requirement, where the first QoS requirement and the second QoS requirement correspond to different data transmission rates. The user-plane network element receives the first information from the access network device and obtains a first message from a terminal device. The first message includes a first number of packets experiencing congestion, a first number of packets not experiencing congestion, and a number of packets that do not support explicit congestion notification (ECN) feedback. The user-plane network element sends a second message to an application server, the second message carrying second information determined based on the first information, the first number of packets experiencing congestion, the first number of packets not experiencing congestion, and the number of packets that do not support ECN feedback. The second information is used to determine a first congestion ratio when the first QoS flow is transmitted at the first QoS requirement, and the first congestion ratio is used to adjust the data transmission rate of the first QoS flow.

[0057] In an eighth aspect, a communication device (for example, the communication device may be a chip or a chip system) is provided. The communication device includes: a processor configured to implement the functions involved in the first aspect, the second aspect, or the third aspect.

[0058] In one possible design, the communication device may further include a memory for storing necessary program instructions and data. A processor is coupled to the memory, and the processor is configured to execute the computer program or instructions stored in the memory, causing the communication device to perform the method described in the first, second, or third aspects.

[0059] In one possible design solution, the communication device described in the eighth aspect may further include a transceiver. The transceiver may be a transceiver circuit or an interface circuit. The transceiver may be used for the communication device described in the eighth aspect to communicate with other communication devices.

[0060] In one possible design, the processor can be integrated with the memory.

[0061] In some possible designs, when the device is a chip system, it can be composed of a chip or include a chip and other discrete devices.

[0062] In the ninth aspect, a communication device is provided, which includes a processor and an interface circuit, the interface circuit being used to receive signals from other communication devices outside the communication device and transmit them to the processor or send signals from the processor to other communication devices outside the communication device, and the processor being used to implement the method described in the first aspect, the second aspect, or the third aspect through logic circuits or executing code instructions.

[0063] In the tenth aspect, a communication device is provided. The communication device can be a user-plane network element, or a module or unit (for example, a chip, or a chip system, or a circuit) in the user-plane network element that corresponds one-to-one to the method / operation / step / action described in the first aspect, or can be used in conjunction with an access network device. Alternatively, the communication device can be an access network device, or a module or unit (for example, a chip, or a chip system, or a circuit) in the access network device that corresponds one-to-one to the method / operation / step / action described in the second aspect, or can be used in conjunction with an access network device. Alternatively, the communication device can be an application server, or a module or unit (for example, a chip, or a chip system, or a circuit) in the application server that corresponds one-to-one to the method / operation / step / action described in the third aspect, or can be used in conjunction with an access network device.

[0064] It can be understood that when the communication device provided in either the eighth aspect or the tenth aspect is a chip, the above-mentioned sending action / function can be understood as output, and the above-mentioned receiving action / function can be understood as input.

[0065] In the eleventh aspect, a computer-readable storage medium is provided, which stores a computer program or instruction. When the computer-readable storage medium is run on a communication device, the communication device can execute the method described in the first aspect, the second aspect, or the third aspect above.

[0066] In the twelfth aspect, a computer program product containing instructions is provided, including computer program code, which, when the computer program code is run on a communication device, enables the communication device to execute the method described in the first aspect, the second aspect, or the third aspect above.

[0067] In the thirteenth aspect, a communication system is provided, comprising: a communication device for implementing the method described in the first aspect, a communication device for implementing the method described in the second aspect, and a communication device for implementing the method described in the third aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] Figure 1 shows the system architecture for performing video rendering in pure cloud mode and end-cloud collaborative mode;

[0069] FIG2 is a schematic diagram of the architecture of an L4S speed regulation mechanism;

[0070] FIG3 is a schematic diagram of the architecture of a speed regulation mechanism based on dynamic QoS;

[0071] FIG4 is a schematic diagram of the architecture of a communication system provided in an embodiment of the present application;

[0072] FIG5 is a schematic flow chart of a speed regulation method provided in an embodiment of the present application;

[0073] FIG6 is a schematic diagram of the structure of an RTPFB message supporting ECN feedback provided in an embodiment of the present application;

[0074] FIG7 is a schematic flow chart of another speed regulation method provided in an embodiment of the present application;

[0075] FIG8 is a schematic flow chart of another speed regulation method provided in an embodiment of the present application;

[0076] FIG9 is a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0077] FIG10 is a schematic diagram of the structure of another communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0078] The embodiments of the present application will present various aspects, embodiments, or features around a system that may include multiple devices, components, modules, etc. It should be understood and appreciated that each system may include additional devices, components, modules, etc., and / or may not include all of the devices, components, modules, etc. discussed in conjunction with the figures. Furthermore, combinations of these solutions may also be used.

[0079] The technical solutions of the embodiments of the present application can be applied to various communication systems, such as wireless fidelity (Wi-Fi) systems, vehicle to everything (V2X) communication systems, device-to-device (D2D) communication systems, Internet of Vehicles communication systems, 4th generation (4G) mobile communication systems, such as long term evolution (LTE) systems, world-wide interoperability for microwave access (WiMAX) communication systems, 5th generation (5G) mobile communication systems, such as new radio (NR) systems, and future communication systems, such as 6th generation (6G) mobile communication systems.

[0080] The following introduces the communication system and applicable network elements involved in the embodiments of the present application, as well as related terms.

[0081] 1. End-to-end collaboration

[0082] With the continuous evolution of communication networks, improvements in the computing performance of terminal devices, and the development of machine learning algorithms, terminal devices are gradually participating in services that were previously handled by servers, such as cloud gaming and machine vision, and other computing-intensive services. This has gradually evolved from centralized cloud processing to a working model where processing is jointly performed by the terminal device and the cloud (central cloud or edge cloud). This has led to the emergence of a service architecture that supports device-cloud collaboration.

[0083] The end-cloud collaborative business architecture is mainly used in video rendering and deep neural network businesses. Among them, typical applications of video rendering businesses are virtual reality (VR) / augmented reality (AR) and cloud games. On the one hand, since this type of emerging video rendering business has high requirements for computing power, for example, at a 4K resolution and a frame rate of 60 frames per second (FPS), the computing power requirement for device video rendering is 13+ trillion (10 12) floating-point operations per second (TFLOPS), while the computing power of current mainstream terminal devices is only about 1.3 TFLOPS. It is difficult to meet the computing power requirements of this type of video rendering business through local processing of the terminal device. At the same time, the power consumption of the terminal device is limited, and it does not support long-term high-computing power calculations. On the other hand, although the cloud side has powerful computing power, this type of video rendering business has strong real-time interaction requirements. The terminal device sends operation instructions or posture information to the cloud to complete the video rendering, and then sends the rendering results to the terminal device, and finally displays them on the screen of the terminal device. That is, the motion-to-photons (MTP) delay is required to be within 50ms. In mobile networks, due to the fluctuations in the communication quality of the wireless channel, it is difficult for video rendering performed purely on the cloud to meet the MTP delay requirements. Therefore, it is necessary to make full use of the computing power on the terminal device side and the communication link between the end and the cloud to achieve task division and interaction, thereby optimizing system efficiency.

[0084] As shown in Figure 1, (a) shows the system architecture of video rendering in pure cloud mode, and (b) shows the system architecture of joint video rendering in end-cloud collaborative mode. Comparing the two, it can be seen that in end-cloud collaborative mode, the terminal device uses local storage and algorithm models to perform part of the video rendering task. Tasks with insufficient computing power or that cannot be processed quickly locally are transmitted to the cloud for processing by a highly powerful cluster, and the rendered data stream is transmitted back to the terminal device. In this way, both the terminal device and the cloud participate in the computing task and exchange information through the communication link between the two, thereby achieving joint processing of the computing task.

[0085] In addition, with the emergence of large language models and artificial intelligence (AI) generative models, such as the chat generative pre-trained transformer (Chat GPT), there has been considerable interest in providing services with large model capabilities to terminal devices. The most intuitive approach is to deploy small models on the device side and collaborate with large models on the cloud side for learning. The connection between the end-cloud models is similar to the architecture shown in (b) of Figure 1 above. The large and small models on the end-cloud are assigned to different tasks, and joint training and inference are performed through the interaction of intermediate data or models, thus enabling end-cloud collaborative intelligent services.

[0086] In the end-cloud collaboration model, the key metric of interest is task response time, which is the elapsed time from task initiation to completion, including the combined time consumed by end-cloud computing and transmission. To meet the response time requirements of computing tasks, it is necessary to consider the computing power and wireless communication status of the terminal device side, and adjust task division or transmission rates at the application layer based on changes in these states. Because wireless channels are time-varying and highly volatile, timely sensing of wireless communication status changes and notification to the application layer is crucial to ensuring timely completion of computing tasks. To this end, the following two mechanisms are currently proposed to adjust the transmission rate to meet the response time requirements of computing tasks.

[0087] 2. Low latency, low loss, scalable throughput (L4S) speed control mechanism

[0088] As a speed regulation mechanism suitable for end-cloud collaboration, L4S has good ecological support and implements congestion control and application server (APP service, AS) sending rate adjustment through explicit congestion notification (ECN).

[0089] For example, FIG2 is a schematic diagram of the architecture of an L4S speed regulation mechanism. As shown in FIG2, the access network device performs congestion detection on the downlink Internet Protocol (IP) message sent by the AS through the user plane function (UPF). The IP message header includes an ECN field, which has four status values: 00 indicates that ECN is not supported, marked as non-ECT (not ECN-capable transport), 10 indicates that ECN is supported, marked as ECT (0), 01 indicates that ECN is supported, marked as ECT (1), and 11 indicates that congestion occurs, marked as congestion experienced (CE). When an access network device detects congestion, it marks downstream IP packets in the congested state with CE. This allows the terminal device to count received downstream IP packets with the CE tag and feedback congestion information through the Explicit Congestion Echo (ECE) field in the header of upstream Transmission Control Protocol (TCP) acknowledgment (ACK) or Real-time Transport Control Protocol (RTCP) packets. This ECE field is used for congestion control. If the ECN field in the received IP packet header is 1, the ECE field is set to 1, indicating that there is congestion on the network from the other end to this end. The AS then adjusts the application layer sending rate based on the received congestion information, completing the entire speed regulation process.

[0090] However, the aforementioned L4S-based speed regulation mechanism suffers from shortcomings in response speed and feedback accuracy. Specifically, congestion information generated at the access network device requires two air interface transmissions before being fed back to the AS. Furthermore, the reporting interval for congestion statistics on terminal devices is typically greater than 20ms, resulting in a slow response. Furthermore, the granularity of the feedback congestion information is relatively coarse, making it difficult for the AS to accurately determine network status. Furthermore, the AS typically makes rate adjustment decisions based on multiple congestion feedback reports, which introduces cumulative decision delays. This not only leads to inaccurate speed regulation but also to slower response times.

[0091] To address the above issues, a dynamic quality of service (QoS) speed regulation mechanism has been proposed. Please refer to the following description for details.

[0092] 3. Speed ​​regulation mechanism based on dynamic QoS

[0093] Figure 3 shows an architectural diagram of a speed regulation mechanism based on dynamic QoS. During the initial configuration phase, the AS, 5G core (5G core, 5GC)-control plane (C), and access network equipment negotiate QoS configurations, allowing the access network equipment to obtain multiple sets of QoS configurations (QoS profiles) corresponding to the application and configure one of the QoS profiles as the initial QoS profile. Different QoS profiles correspond to different transmission delays or transmission bandwidth requirements. During the speed regulation phase, the access network equipment performs congestion detection on downlink IP packets and determines whether the QoS profile needs to be switched. When the QoS profile needs to be switched, the index (index) corresponding to the new QoS profile or the guaranteed flow bit rate (GFBR) is fed back to the UPF through the N3 interface between the access network equipment and the UPF. Specifically, the access network device carries the index or GFBR corresponding to the new QoS profile in the header of an uplink General Packet Radio Service (GPRS) Tunneling Protocol-User Plane (GTP-U) message and sends it to the UPF. Accordingly, upon receiving the uplink GTP-U message carrying the index or GFBR corresponding to the new QoS profile, the UPF feeds back the index or GFBR corresponding to the new QoS profile to the AS through the application programming interface (API) or in a user-plane piggyback manner. The AS then adjusts the application layer sending rate based on the received index or GFBR, completing the entire speed regulation process.

[0094] The aforementioned dynamic QoS-based speed regulation mechanism reduces the latency of feedback paths detouring through terminal devices, the latency of terminal devices waiting for reports, and the cumulative decision-making latency of the AS. This results in faster speed regulation and clearer feedback adjustment targets. However, while the dynamic QoS-based speed regulation scheme largely addresses issues such as feedback path detours and delayed feedback and decision-making in L4S speed regulation, the current standard does not support feedback to the AS as QoS index or GFBR, making cross-vendor implementation difficult and presenting an ecosystem issue.

[0095] To this end, in order to solve the problems under the above two speed regulation mechanisms, the embodiment of the present application provides a speed regulation method, which not only improves the response speed and speed regulation accuracy, but also has good ecological support.

[0096] In order to better understand the embodiments of the present application, the following explanations are made before introducing the embodiments of the present application.

[0097] First, in the embodiments of the present application, "used to indicate" can include being used for direct indication and being used for indirect indication. When describing a certain "indication information" as being used to indicate A, it can include the indication information directly indicating A or indirectly indicating A, and does not necessarily mean that the indication information carries A.

[0098] The information indicated by the indication information is called the information to be indicated. In the specific implementation process, there are many ways to indicate the information to be indicated, such as but not limited to, directly indicating the information to be indicated, such as the information to be indicated itself or the index of the information to be indicated. The information to be indicated can also be indirectly indicated by indicating other information, wherein there is an association between the other information and the information to be indicated. It is also possible to indicate only a part of the information to be indicated, while the other parts of the information to be indicated are known or agreed in advance. For example, it is also possible to use the arrangement order of each piece of information agreed in advance (such as specified in the protocol) to achieve the indication of specific information, thereby reducing the indication overhead to a certain extent. At the same time, it is also possible to identify the common parts of each piece of information and indicate them uniformly to reduce the indication overhead caused by indicating the same information separately.

[0099] In addition, the specific indication method can also be various existing indication methods, such as but not limited to the above-mentioned indication methods and various combinations thereof. The specific details of the various indication methods can be referred to the prior art and will not be repeated herein. As can be seen from the above, for example, when it is necessary to indicate multiple information of the same type, there may be a situation where the indication methods for different information are different. In the specific implementation process, the required indication method can be selected according to specific needs. The embodiment of the present application does not limit the selected indication method. In this way, the indication method involved in the embodiment of the present application should be understood to cover various methods that can enable the party to be indicated to obtain the information to be indicated.

[0100] The information to be indicated can be sent as a whole, or divided into multiple sub-information and sent separately, and the sending period and / or sending time of these sub-information can be the same or different. The specific sending method is not limited in this application. Among them, the sending period and / or sending time of these sub-information can be predefined, for example, predefined according to the protocol, or configured by the transmitting device by sending configuration information to the receiving device. Among them, the configuration information can, for example, but not limited to, include one or a combination of at least two of radio resource control (RRC) signaling, MAC layer signaling and physical layer signaling. Among them, MAC layer signaling, for example, includes MAC-CE; physical (PHY) layer signaling, for example, includes downlink control information (DCI).

[0101] Second, in the embodiments of the present application, the first, second, and various numerical numbers are merely distinctions made for ease of description and are not intended to limit the scope of the embodiments of the present application. For example, different indication information is used to distinguish one from another. For another example, the first indication information and the second indication information are merely used to distinguish different areas and do not limit their order of precedence. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and order of execution, and words such as "first" and "second" do not necessarily limit them to be different.

[0102] Third, in the embodiments of the present application, descriptions such as "when...", "in the case of...", "if" and "if" all mean that the device (such as a terminal device or an access network device) will make corresponding processing under certain objective circumstances. It does not limit the time, and does not require the device (such as a terminal device or an access network device) to have a judgment action when implementing it, nor does it mean that there are other limitations.

[0103] At the same time, in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner to facilitate understanding.

[0104] Finally, the network architecture and business scenarios described in the embodiments of this application are intended to more clearly illustrate the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. Ordinary technicians in this field can know that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0105] Please refer to Figure 4, which is a schematic diagram of the architecture of a communication system used in an embodiment of the present application. As an example, as shown in Figure 4, the communication system includes access network equipment, user plane network elements and application servers, and each of them can communicate directly or indirectly.

[0106] Optionally, the communication system may also include a terminal device. In an embodiment of the present application, the terminal device can realize end-cloud collaborative processing through the access network device, the user-side network element and the application server. The application server can provide applications that require end-cloud collaboration, such as real-time video rendering (extended reality, XR) / cloud gaming) or end-cloud joint AI model training / inference, etc. The terminal device can use its own computing power to complete the processing of part of the task based on local data, and the remaining tasks or tasks that require higher computing power are handed over to the application server in the cloud for execution. The application server will then transmit the processed tasks to the terminal device, thereby realizing end-cloud collaborative processing. The devices or network elements involved in end-cloud collaborative processing are described below.

[0107] 1. Terminal equipment

[0108] The terminal device may be one or more, such as a first terminal device, a second terminal device, a third terminal device, etc. The terminal device may be a terminal device with transceiver functions, or may be a chip or chip system provided in the terminal device. The terminal device may also be referred to as user equipment (UE), access terminal, subscriber unit (subscriber unit), subscriber station, mobile station (MS), mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent or user device. The terminal device in the embodiments of the present application can be a mobile phone, a cellular phone, a smart phone, a tablet computer, a wireless data card, a personal digital assistant (PDA), a wireless modem, a handheld device (handset), a laptop computer, a machine type communication (MTC) terminal, a computer with wireless transceiver function, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a smart home device (for example, a refrigerator, a television, an air conditioner, an electric meter, etc.), an intelligent robot, a robotic arm, a workshop equipment, a wireless terminal in unmanned driving, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical care, a wireless terminal in smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, a vehicle-mounted terminal, a roadside unit with terminal function, a roadside control unit (ROU), ... The terminal device of the present application may also be an onboard module, onboard module, onboard component, onboard chip or onboard unit built into a vehicle as one or more components or units. The terminal device may also be other devices with terminal functions, for example, a terminal device may also be a device that functions as a terminal in D2D communication.

[0109] The embodiments of this application do not limit the device form factor of the terminal. The device used to implement the functions of the terminal device can be the terminal device; it can also be a device that supports the terminal device to implement the functions, such as a chip system. The device can be installed in the terminal device or used in conjunction with the terminal device. In the embodiments of this application, the chip system can be composed of chips or include chips and other discrete devices.

[0110] 2. Access network equipment

[0111] There may be multiple access network devices, such as a first access network device, a second access network device, a third access network device, etc. The access network device may also be referred to as an access network node, a radio access network (RAN) node, a RAN entity or an access node, etc., which is located on the network side of the above-mentioned communication system to help the terminal device achieve wireless access, and has a device with wireless transceiver function or a chip or chip system that can be set in the device. The access network device includes but is not limited to: a base station, an evolved NodeB (eNodeB), an access point (AP), a transmission reception point (TRP or transmission point, TP), a next generation NodeB (gNB), a next generation base station in a 6G mobile communication system, a base station in a future mobile communication system, or an access node in a Wi-Fi system, etc. The access network device may be a macro base station, a micro base station or an indoor station, a relay node or a donor node, an open radio access network (ORAN) or a wireless controller in a centralized radio access network (CRAN) scenario. The access network device may also be one or a group of antenna panels (including multiple antenna panels) of a base station in 5G, or it may also be a network node constituting a gNB, TRP or TP or transmission measurement function (TMF), such as a centralized unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU), a road side unit (RSU) with base station functions. Optionally, the access network device may also be a server, a wearable device, a vehicle or an on-board device, etc. For example, the access network device in V2X technology may be an RSU. All or part of the functions of the network device in this application may also be implemented by software functions running on hardware, or by virtualization functions instantiated on a platform (such as a cloud platform). The access network device in this application may also be a logical node, a logical module or software that can implement all or part of the functions of the access network device.

[0112] Among them, the CU and DU can be set separately, or can also be included in the same network element, such as a baseband unit (BBU). The RU can be included in a radio frequency device or a radio frequency unit, for example, a remote radio unit (RRU), an active antenna unit (AAU) or a remote radio head (RRH). It can be understood that the access network device can be a CU node, a DU node, or a device including a CU node and a DU node. In addition, the CU can be divided into a network device in the access network RAN, or the CU can be divided into a network device in the CN, which is not limited here.

[0113] In different systems, CU (or CU-CP and CU-UP), DU or RU may also have different names, but those skilled in the art can understand their meanings. For example, in the ORAN system, CU may also be called O-CU (Open CU), DU may also be called O-DU, CU-CP may also be called O-CU-CP, CU-UP may also be called O-CU-UP, and RU may also be called O-RU. For the convenience of description, this application uses CU, CU-CP, CU-UP, DU and RU as examples for description. Any unit of CU (or CU-CP, CU-UP), DU and RU in this application can be implemented by a software module, a hardware module, or a combination of a software module and a hardware module.

[0114] The embodiments of this application do not limit the form of the access network device. The device used to implement the functions of the access network device can be the access network device; it can also be a device that supports the access network device to implement the functions, such as a chip system. The device can be installed in the access network device or used in conjunction with the access network device.

[0115] 3. User plane network element

[0116] In the embodiments of the present application, the user plane network element is used for packet routing and forwarding, as well as QoS processing of user plane data. The user plane network element can forward user data packets according to the routing rules of the session management network element, such as sending uplink data to the data network or other user plane network elements, and forwarding downlink data to other user plane network elements or access network devices. The user plane network element can be the UPF in 5G communication.

[0117] 4. Application Server

[0118] The application server is located in the cloud and is used to provide application services to terminal devices and collaborate with terminal devices to complete computing tasks. It can be an application (APP). The application server can also include application layer business processing service modules and application functions (AF). In other words, the AF can be deployed in the application server. In the embodiment of the present application, the application server can be called AS.

[0119] It should be understood that the communication system shown in Figure 4 may also include other core network elements, other terminal devices or other access network devices, such as access and mobility management network elements, data management network elements, policy control network elements, etc., without limitation. Among them, the access and mobility management network element may be the access and mobility management function (AMF) in the 5G system, the data management network element may be the unified data management (UDM) in the 5G system, and the policy control network element may be the policy control function (PCF) in the 5G system.

[0120] It should be noted that the solutions in the embodiments of the present application can also be applied to other communication systems, and the corresponding names can also be replaced by the names of corresponding functions in other communication systems.

[0121] The speed regulation method provided in the embodiment of the present application will be described in detail below with reference to FIG5-FIG8.

[0122] For example, FIG5 is a flow chart of a speed regulation method provided in an embodiment of the present application. The speed regulation method is illustrated by taking the communication between the terminal device, access network device, user plane network element and application server shown in FIG4 as an example. Of course, the subject that executes the terminal device action in the method can also be a device / module in the terminal device, such as a chip, processor, processing unit, etc. in the terminal device; the subject that executes the access network device action in the method can also be a device / module in the access network device, such as a chip, processor, processing unit, etc. in the access network device; the subject that executes the user plane network element action in the method can also be a device / module in the user plane network element, such as a chip, processor, processing unit, etc. in the user plane network element; the subject that executes the application server action in the method can also be a device / module in the application server, such as a chip, processor, processing unit, etc. in the application server, and the embodiment of the present application does not make specific limitations on this.

[0123] Exemplarily, as shown in FIG5 , the speed regulation method includes:

[0124] S501: An access network device sends first information to a user plane network element. Correspondingly, the user plane network element receives the first information from the access network device.

[0125] In an embodiment of the present application, the first information is used to indicate that the first QoS requirement corresponding to the first QoS flow needs to be adjusted to the second QoS requirement, and the first QoS requirement and the second QoS requirement correspond to different data transmission rates. Among them, the first QoS flow refers to a service data flow that meets the QoS requirements and is provided by the application server to the terminal device. One service corresponds to one QoS flow, and different services correspond to different QoS flows. The service that the application server interacts with the terminal device can be a computing service-related service, such as video rendering, AI model training, etc., or a data service-related service, such as perception data, positioning data, measurement data, etc., without limitation.

[0126] For each QoS flow, such as the first QoS flow, multiple QoS requirements can be configured, and each QoS requirement corresponds to an identifier, and different identifiers correspond to different QoS requirements. The identifier of the QoS requirement can be the 5G QoS identifier (5G QoS identifier, 5GQI) in 5G, or it can be the index (index) of the QoS requirement in multiple QoS requirements. In addition, each QoS requirement also corresponds to a data transmission rate, and different QoS requirements correspond to different data transmission rates. The data transmission rate refers to the data transmission rate at which the application server sends the first QoS flow, that is, the rate at which the application server sends downlink data. In the embodiment of the present application, the higher the QoS requirement, the higher the corresponding data transmission rate.

[0127] Each QoS requirement includes different types of QoS parameters, including at least one of the following: GFBR, packet delay budget (PDB), or packet error rate (PER). It should be understood that the QoS parameters in the multiple QoS requirements configured for the first QoS flow have the same number and type, but different values ​​to represent different requirements for delay, bandwidth, etc., for transmitting the first QoS flow. For example, the first QoS requirement includes GFBR1, PDB1, and PER1, and the second QoS requirement includes GFBR2, PDB2, and PER2. GFBR1 and GFBR2 have different values, PDB1 and PDB2 have different values, and PER1 and PER2 have different values.

[0128] In one possible scenario, the identification of a QoS requirement can also be considered a QoS parameter. In other words, the QoS requirement includes the identification of the QoS requirement. It should also be understood that in addition to the three types of QoS parameters described above, QoS requirements may also include other types of QoS parameters used to characterize transmission requirements such as latency and bandwidth, without limitation.

[0129] In the embodiments of the present application, QoS requirements, in addition to data transmission QoS requirement parameters, may also include computing QoS requirement parameters, such as computing latency requirements, computing load requirements, computing accuracy requirements, or computing energy consumption requirements, without limitation. Furthermore, in the embodiments of the present application, QoS requirements may also be referred to as QoS profiles, QoS information, QoS requirements, etc., without limitation.

[0130] It should be understood that the QoS requirements described in the embodiments of the present application are also applicable to uplink transmission and are not limited to this.

[0131] For multiple QoS requirements corresponding to the first QoS flow, the application server can be configured or negotiated to the access network device through the core network control plane. In one possible implementation, the application server can send the first correspondence to the access network device through the core network control plane, and accordingly, the access network device can receive the first correspondence from the application service through the core network control plane. The first correspondence includes an identifier of the QoS requirement corresponding to the first QoS flow, a correspondence between the QoS requirement corresponding to the first QoS flow and the data transmission rate, or the first correspondence includes an identifier of the QoS requirement corresponding to the first QoS flow and the QoS requirement corresponding to the first QoS flow, and a correspondence between the QoS requirement corresponding to the first QoS flow and the data transmission rate. The first correspondence can be configured in the form of a table. Exemplarily, the first correspondence is shown in Table 1 below:

[0132] Table 1

[0133] During initial configuration, the access network device may default to the QoS requirement initially used as the QoS requirement corresponding to the highest transmission rate among multiple QoS requirements, or the application server may indicate which QoS requirement among multiple QoS requirements to be initially used, without limitation. In addition, during initial configuration, the application server may also send a quantized congestion notification (QCN) configuration to the access network device. The QCN configuration is used to configure the access network device for congestion feedback. The QCN configuration may include a notification method configuration. The notification method configuration is used to configure the access network device to notify the feedback of congestion information. In an embodiment of the present application, the notification method of the access network device is configured to be notified via the user plane.

[0134] Optionally, the QCN configuration may further include a notification parameter configuration, which is used to configure the notification parameters sent by the access network device to the user plane network element for feedback on congestion. The notification parameters may be a congestion ratio, an identifier of the adjusted QoS requirement, or a QoS parameter in the adjusted QoS requirement, etc., without limitation. In one possible implementation, the notification parameters may also be protocol-agreed or pre-configured, in which case the QCN configuration may not include the notification parameter configuration.

[0135] In the embodiments of the present application, the first QoS requirement is the QoS requirement currently used by the access network device. The first QoS requirement may be an initially configured QoS requirement or an adjusted QoS requirement, without limitation. In other words, the application server currently sends downlink data to the terminal device via the user plane network element and the access network device at the data transmission rate corresponding to the first QoS requirement.

[0136] Accordingly, the access network device monitors the network status according to the first QoS requirement and determines whether the first QoS requirement currently in use needs to be adjusted. Exemplarily, the access network device can determine that the first QoS requirement needs to be adjusted to the second QoS requirement based on the channel status between the terminal device and the access network device, the air interface transmission status of the first QoS flow, and the first QoS requirement corresponding to the first QoS flow. Among them, the channel status between the terminal device and the access network device can be fed back through the signal to interference plus noise ratio (SINR), and the air interface transmission status of the first QoS flow can be fed back through the cache queue status or the air interface transmission rate. In other words, the access network device can determine whether the current QoS requirement needs to be adjusted based on the detected channel status and the air interface transmission speed. If adjustment is required, it can determine which QoS requirement needs to be adjusted to based on the channel status and the air interface transmission status, that is, whether to adjust to a QoS requirement with higher latency requirements or a QoS requirement with lower latency requirements. For example, if the channel state is good and the queue has no cache, indicating that the air interface transmission is fast, the access network device determines that the QoS requirement needs to be adjusted to a QoS requirement with a higher delay requirement than the first QoS requirement (i.e., the second QoS requirement), indicating that the application server needs to increase the data transmission rate; if the channel state is poor and the queue has a large cache, indicating that the air interface transmission is slow, the access network device determines that the QoS requirement needs to be adjusted to a QoS requirement with a lower delay requirement than the first QoS requirement (i.e., the second QoS requirement), indicating that the application server needs to reduce the data transmission rate.

[0137] Therefore, the access network device determines that the first QoS requirement needs to be adjusted to the second QoS requirement, and indicates it to the user-side network element through the first information. At this time, the first information is the above-mentioned notification parameter. The first information may include the following items: the second congestion ratio when the first QoS flow is transmitted with the first QoS requirement, the identifier of the second QoS requirement, or the QoS parameters in the second QoS requirement. The specific parameters included in the first information can be pre-configured for the application service, or can be agreed or pre-configured by the protocol, and there is no limitation on this. In other words, the access network device can feedback the second congestion ratio, the identifier of the second QoS requirement, or the QoS parameters in the second QoS requirement to the user-side network element to indicate that the current QoS requirement needs to be adjusted. It should be understood that the QoS parameters in the second QoS requirement included in the first information can be one or more QoS parameters selected from the second QoS requirement.

[0138] The second congestion ratio is determined based on the first QoS requirement and the second QoS requirement. That is, the access network device determines the second congestion ratio based on the first QoS requirement and the second QoS requirement. In one possible implementation, the access network device may determine the second congestion ratio based on changes in one or more QoS parameters in the first QoS requirement and the second QoS requirement.

[0139] In a specific example 1, the access network device can calculate the second congestion ratio according to GFBR1 in the first QoS requirement and GFBR2 in the second QoS requirement, such as the second congestion ratio 0≤|k2|≤1. When GFBR2 is less than GFBR1, it indicates that there is congestion in the network and the data transmission rate needs to be reduced. When GFBR2 is greater than or equal to GFBR1, it indicates that there is no congestion in the network and the data transmission rate needs to be increased. In this case, the second congestion ratio k2 is a negative value, and the access network device can set the second congestion ratio k2 to zero, that is, k2=0. The second congestion ratio can be further expressed as

[0140] Alternatively, the access network device may calculate the second congestion ratio according to PDB1 in the first QoS requirement and PDB2 in the second QoS requirement, such as the second congestion ratio When PDB2 is greater than or equal to PDB1, it indicates that there is congestion in the network and the data transmission rate needs to be reduced; when PDB2 is less than PDB1, it indicates that there is no congestion in the network and the data transmission rate needs to be increased.

[0141] Alternatively, the access network device may calculate the second congestion ratio by using the PER2 in the second QoS requirement, such as the second congestion ratio PER TH The PER threshold is set when PER2 is greater than or equal to PER TH In the case of PER2 being less than PER TH In the case of , it means that there is no congestion in the network and the data transmission rate needs to be increased.

[0142] In a specific example 2, the access network device can calculate the second congestion ratio according to GFBR1, PDB1, PER1 in the first QoS requirement and GFBR2, PDB2, PER2 in the second QoS requirement, such as k2=k′2+Δk2, Δk2=a·Δ GFBR +b·Δ PER +c·Δ PDB +d, where k′2 is the reference value of the second congestion ratio, Δk2 is the change in the second congestion ratio, and ΔGFBR =GFBR2-GFBR1, Δ PER =PER2-PER1, Δ PDB =PDB2-PDB1, a, b, c are Δ GFBR , Δ PER , Δ PDB The weight value of the impact on the second congestion ratio, d is a constant. That is, the access network device can establish a fitting relationship between the change in the second congestion ratio and the change in each parameter in the new and old QoS requirements to determine the second congestion ratio.

[0143] The aforementioned k'2, a, b, c, and d can be a set of pre-set values ​​that can be adjusted in real time by the access network device based on network status. They can also be a set selected from multiple pre-set sets based on network status by the access network device, or can be set in real time by the access network device based on network status, without limitation. It should be understood that a, b, and c can have a value of 0, but cannot all be 0. If any of the three weights is 0, it can be assumed that the QoS parameter corresponding to the 0 weight is not included in the calculation of the second congestion ratio, or it can be assumed that the second congestion ratio is calculated based on at least one QoS parameter.

[0144] It should also be understood that in the embodiments of the present application, the conversion algorithm used by the access network device or user-plane network element to convert the identifier of the second QoS requirement or QoS parameter into the second congestion ratio can have multiple designs. In addition to the simple conversion method and linear fitting method for the above-mentioned single QoS parameter change, it can also include but is not limited to preset deterministic algorithms, statistical historical data, nonlinear fitting, machine learning methods, etc. The network status input involved in the algorithm is not limited to the aforementioned indicators such as GFBR, PER, and PDB. For any conversion algorithm that can be implemented in the embodiments of the present application, it can satisfy the following relationship: The input may include one or more QoS parameters and combinations thereof, which are not specifically limited.

[0145] In one possible design, the access network device may carry the first information in a message to be sent to the user plane network element. For example, the access network device may carry the first information in a message header of a GTP-U message to be sent.

[0146] Furthermore, after receiving the first information, the user-plane network element can determine that the current QoS requirement needs to be adjusted based on the first information, and then instruct the application server to adjust the data transmission rate. For specific implementation, please refer to the relevant description in S503 below, which will not be repeated here. In an embodiment of the present application, the application server will also configure the user-plane network element with multiple QoS requirements corresponding to the first QoS flow, as well as which QoS requirement is currently in use. In other words, both the application server and the access network device store multiple QoS requirements corresponding to the first QoS flow and know which QoS requirement is currently in use.

[0147] S502: The user plane network element obtains a first message from the terminal device.

[0148] The first message includes a first number of messages that experience congestion, a first number of messages that do not experience congestion, and a number of messages that do not support ECN feedback. In this embodiment of the present application, the first message can be a message that supports feedback of ECN information. It should be understood that the first message carries uplink data.

[0149] In a possible implementation, the first message may adopt the RTCP feedback message structure defined in request for comments (RFC) 4585, that is, the type of the first message is a real-time transport layer feedback message (RTPFB) message in the RTCP protocol. As shown in FIG6 , it is a schematic diagram of the structure of an RTPFB message supporting ECN feedback, wherein the PT field is used to identify the type of the message, the FMT field is used to identify the specific subtype of the feedback message, the synchronous source (SSRC) of the packet sender field identifies the sender of the RTPFB message supporting ECN feedback, that is, the sender identifier; the SSRC of the media source field identifies the receiver of the RTPFB message supporting ECN feedback, that is, the receiver identifier; the feedback control information (FCI) field is used to indicate the specific content of the feedback, and the FCI field includes an ECN-CE number field for indicating the number of packets experiencing congestion, an ECT(0) number field or an ECT(1) number field for indicating the number of packets not experiencing congestion, a not-ECT number field for indicating the number of packets not supporting ECN feedback, a lost packets counter field, and a duplication counter field, etc.

[0150] In the embodiment of the present application, the first message adopts the message structure shown in Figure 6, and the specific values ​​of each field in the first message have the following meanings: the PT field has a value of 205, expressed as PT=205, which is used to identify that the type of the first message is an RTPFB message; the FMT field has a value of 8, expressed as FMT=8, which is used to identify that the specific subtype of the first message whose message type is an RTPFB message is an ECN feedback message; the specific value of the SSRC field of the packet sender is used to identify the terminal device that sends the first message; the specific value of the SSRC field of the media source is used to identify the application server that receives the first message; in the FCI field, the specific value of the ECN-CE number field is equal to the first number of messages that experience congestion, expressed as ECN-CE Counter1, the specific value of the ECT(0) number field or the ECT(1) number field is equal to the first number of messages that do not experience congestion, expressed as ECT Counter1, and the specific value of the not-ECT number field is equal to the number of messages that do not support ECN feedback, expressed as not-ECT Counter.

[0151] In one possible design, the sum of the first number of packets experiencing congestion, the first number of packets not experiencing congestion, and the number of packets not supporting ECN feedback in the first packet, that is, the total number of statistical packets is equal to the sum of the first number of packets experiencing congestion, the first number of packets not experiencing congestion, and the number of packets not supporting ECN feedback, expressed as S-Counter = ECN-CE Counter1 + ECT Counter1 + not-ECT Counter. This is typically pre-configured or specified based on implementation, and the number of packets not supporting ECN feedback is typically unchanged.

[0152] It should be understood that in addition to the above fields, the first message also includes a base sequence number field, which is used to identify the sending sequence number of the message. In an embodiment of the present application, this field is used to identify that the first message is the Lth RTPFB message supporting ECN feedback sent by the terminal device, where L is a positive integer and is less than or equal to M, and M is the maximum number of RTPFB messages supporting ECN feedback that the terminal device supports sending.

[0153] In addition to the RTPFB message that supports ECN feedback, the first message can also be a quick user datagram protocol (UDP) network connection (QUIC) ACK message. This type of message also contains ECT(0), ECT(1) and ECN-CE counting information, which is not described in detail.

[0154] In one possible implementation, the terminal device sends a first message to the user plane network element, and accordingly, the user plane network element receives the first message from the terminal device. That is, the first message is sent by the terminal device to the application server via the user plane network element. The first message can be an uplink message currently being sent by the terminal device and received by the user plane network element, or can be the most recently sent uplink message by the terminal device and stored by the user plane network element, without limitation.

[0155] It should be understood that the execution order of S501 and S502 is not limited in the embodiment of the present application. S501 may be executed first and then S502, or S501 may be executed first and then S502. There is no limitation on this.

[0156] S503: The user plane network element sends a second message to the application server. Correspondingly, the application server receives the second message from the user plane network element.

[0157] In this embodiment of the present application, the second message carries second information, which is used to determine a first congestion ratio for the first QoS flow when it is transmitted with a first QoS requirement. The first congestion ratio is used to adjust the transmission rate of the first QoS flow. The second information is determined based on the first information, a first number of messages experiencing congestion, a first number of messages not experiencing congestion, and a number of messages that do not support ECN feedback.

[0158] That is, after the user-side network element obtains the first message and the first information, it can determine the second information based on the first information and the first number of messages that experience congestion, the first number of messages that do not experience congestion, and the number of messages that do not support ECN feedback in the first message, and then carry the second information in the second message to the application server, so that the application server can determine the second congestion ratio according to the second information and adjust the data transmission rate.

[0159] In a possible implementation, the second information may include a second number of packets that experience congestion, a second number of packets that do not experience congestion, and a number of packets that do not support ECN feedback.

[0160] The second number of packets experiencing congestion can be determined based on the total number of packets counted and the first information. That is, the user plane network element can determine the second number of packets experiencing congestion based on the first information and the total number of packets counted.

[0161] Furthermore, the second number of packets experiencing congestion is determined based on the total number of statistical packets and a second congestion ratio when the first QoS flow is transmitted with the first QoS requirement, wherein the second congestion ratio is determined based on the first information. In other words, the user-plane network element determines, based on the acquired first information, a second congestion ratio that exists when the first QoS flow is transmitted with the first QoS requirement, and determines the second number of packets experiencing congestion based on the second congestion ratio and the total number of statistical packets.

[0162] The following description uses the second number of packets experiencing congestion represented by ECN-CE Counter2 and the second number of packets not experiencing congestion represented by ECT Counter2 as an example. For the representation of the second congestion ratio (i.e., k2), the total number of statistical packets (i.e., S-Counter), the first number of packets experiencing congestion (i.e., ECN-CE Counter1), the first number of packets not experiencing congestion (i.e., ECT Counter1), and the number of packets that do not support ECN feedback (i.e., not-ECT Counter), refer to the above description.

[0163] In a specific example 1, the first information includes the second congestion ratio, which can be understood as the first information directly indicating the second congestion ratio k2. Thus, the user-plane network element sums the first number of packets experiencing congestion, the first number of packets not experiencing congestion, and the number of packets that do not support ECN feedback in the first message to obtain the total number of statistical packets, i.e., S-Counter = ECN-CE Counter1 + ECT Counter1 + not-ECT Counter. Then, based on the second congestion ratio k2 in the first information and the total number of statistical packets, the user-plane network element calculates the second number of packets experiencing congestion, i.e., ECN-CE Counter2 = k2 × S-Counter.

[0164] In a specific example 2, the first information includes an identifier of the second QoS requirement. Thus, the user plane network element can compare the identifier of the second QoS requirement with the identifier of the stored first QoS requirement. If an inconsistency is found, it can be determined that the QoS requirement needs to be adjusted, and the specific QoS parameter value of the second QoS requirement can be determined from the multiple stored QoS requirements based on the identifier of the second QoS requirement, so that the second congestion ratio can be calculated based on the QoS parameters in the first QoS requirement and the QoS parameters in the second QoS requirement. At this time, the user plane network element can calculate the second congestion ratio based on the change of the same QoS parameter in the first QoS requirement and the second QoS requirement, such as the change of the GFBR parameter. The specific calculation process of the user plane network element can refer to the relevant description of the access network device calculating the second congestion ratio in Example 1 in S501 above, which will not be repeated here. Alternatively, the user plane network element can calculate the second congestion ratio based on the change of multiple QoS parameters in the first QoS requirement and the second QoS requirement. The specific calculation process of the user plane network element can refer to the relevant description of the access network device calculating the second congestion ratio in Example 2 in S501 above, which will not be repeated here. Thus, the user-side network element can calculate the second number of packets experiencing congestion based on the second congestion ratio and the total number of statistical packets. For specific implementation, please refer to the calculation method of the second number of packets experiencing congestion in Example 1 in S503, which will not be elaborated on.

[0165] In a specific example 3, the first information includes the QoS parameters in the second QoS requirement. If the QoS parameter in the second QoS requirement is one, such as the GFBR parameter, the specific implementation process of the user-plane network element calculating the second congestion ratio can refer to the relevant description of the access network device calculating the second congestion ratio in Example 1 in S501 above, which will not be repeated here. If there are multiple QoS parameters in the second QoS requirement, the specific implementation process of the user-plane network element calculating the second congestion ratio can refer to the relevant description of the access network device calculating the second congestion ratio in Example 2 in S501 above, which will not be repeated here. Thus, the user-plane network element can calculate the second number of packets experiencing congestion based on the second congestion ratio and the total number of statistical packets. The specific implementation can refer to the calculation method of the second number of packets experiencing congestion in Example 1 in S503, which will not be repeated here.

[0166] The second number of packets that are not congested can be determined based on the total number of statistical packets, the second number of packets that experience congestion, and the number of packets that do not support ECN feedback.

[0167] Furthermore, since the re-determined number of packets that are not congested may be a negative value, the second number of packets that are not congested may be the maximum value between the third number and zero, and the third number is equal to the difference between the total number of statistical packets, the second number of packets that have experienced congestion, and the number of packets that do not support ECN feedback. In other words, the user-plane network element determines the difference between the total number of statistical packets, the second number of packets that have experienced congestion, and the number of packets that do not support ECN feedback as the third number, and determines the maximum value between the third number and zero as the second number of packets that are not congested.

[0168] Exemplarily, ECT Counter2=max{S-Counter-ECN-CE Counter2-not-ECT Counter, 0}, that is, S-Counter-ECN-CE Counter2-not-ECT Counter is equal to the third number.

[0169] That is to say, the user-side network element updates the number of messages that experienced congestion and the number of messages that did not experience congestion reported by the terminal device in combination with the first information fed back by the access network device (the fed back network status change), and feeds back the updated number of messages that experienced congestion and the number of messages that did not experience congestion, as well as the unchanged number of messages that do not support ECN feedback, to the application server through a second message.

[0170] In one possible implementation, the second message may be an RTPFB message or a QUIC ACK message that supports ECN feedback.

[0171] In one possible design, the second message may be obtained by modifying the first number of messages that experienced congestion in the first message to the second number of messages that experienced congestion, and by modifying the first number of messages that did not experience congestion in the first message to the second number of messages that did not experience congestion. In this case, the first message is a message being sent by a terminal device and received by a user-plane network element. The user-plane network element modifies the number of messages that experienced congestion and the number of messages that did not experience congestion in the first message to obtain the second message.

[0172] Exemplarily, the first message is an RTPFB message that supports ECN feedback. The user-plane network element modifies the specific value of the ECN-CE quantity field in the first message from ECN-CE Counter1 to ECN-CE Counter2, and modifies the specific value of the ECT(0) quantity field or the ECT(1) quantity field from ECT Counter1 to ECT Counter2, to obtain a second message.

[0173] In one possible design scheme, the user plane network element can locally generate a second message, and the payload in the second message is empty. At this time, the first message can be the most recent uplink message sent by the terminal device received by the user plane network element. It can be understood that when the user plane network element currently feeds back the second information, it does not receive the most recent uplink message sent by the terminal device in time, and locally generates a second message as the most recent uplink message sent by the terminal device to carry the second information, and the locally generated second message does not contain the uplink service data sent by the terminal device. Therefore, the second information in the second message locally generated by the user plane network element is determined based on the first information, and the number of non-congested messages in the most recent uplink message received from the terminal device, the number of non-congested messages, and the number of messages that do not support ECN feedback. At the same time, to ensure the continuity of message transmission, the message sequence number in the second message is the message sequence number in the first message plus one. The sender identifier and receiver identifier in the second message are the same as those in the first message, respectively. The sender identifier is used to identify the terminal device, and the receiver identifier is used to identify the application server. For example, if the base sequence number in the first message is L, the base sequence number in the second message is L+1, and the specific values ​​of the SSRC field of the packet sender and the specific values ​​of the SSRC field of the media source in the second message are the same as those in the first message.

[0174] In the embodiments of the present application, in addition to the above implementations, the user-plane network element may also add a new field to the second message to indicate the second information, or reuse an existing field to indicate the second information, without limitation. Furthermore, in addition to indicating the second information by the number of messages in the three states described above, other methods may also be used, such as the second information directly indicating the first congestion ratio, without limitation.

[0175] Therefore, the user-plane network element improves the compatibility of dynamic QoS for speed regulation with existing equipment by modifying or generating ECN messages and reusing the L4S RTCP transmission solution. This allows the application server to adjust the sending rate without special adaptation and adjustment. It has ecological support and helps evolve to a system that supports dynamic QoS.

[0176] S504: The application server adjusts the data transmission rate of the first QoS flow according to the second information.

[0177] In an embodiment of the present application, after the application server obtains the second message, it parses the second message to obtain second information, and determines the first congestion ratio based on the second information, so that the data transmission rate of the first QoS flow can be adjusted according to the first congestion ratio.

[0178] In one possible implementation, the application server determines a third QoS requirement based on the second information and the first QoS requirement corresponding to the first QoS flow, and adjusts the data transmission rate of the first QoS flow based on the third QoS requirement. The third QoS requirement is one of the multiple configured QoS requirements other than the first QoS requirement. The third QoS requirement may be the same as or different from the second QoS requirement, and the first and third QoS requirements also correspond to different data transmission rates.

[0179] Illustratively, the second information includes a second number of packets experiencing congestion (ECN-CE Counter2), a second number of packets not experiencing congestion (ECT Counter2), and a number of packets that do not support ECN feedback (not-ECT Counter). The first congestion ratio is represented by k1, and the first congestion ratio satisfies the following relationship:

[0180] Thus, after calculating the first congestion ratio based on the second information, the application server determines which QoS requirement to adjust to, namely, the third QoS requirement, based on the first congestion ratio and the currently used first QoS requirement. For example, the application server calculates the GFBR value to be adjusted, namely, GFBR X (which can be called a reference GFBR value), based on the first congestion ratio and GFBR1 in the first QoS requirement using the following formula: GFBR X = GFBR1 × (1-k1). The QoS requirement with the GFBR value closest to and smaller than GFBR X among the multiple configured QoS requirements is selected as the third QoS requirement. The data transmission rate corresponding to the third QoS requirement is the adjusted data transmission rate. In other words, the application server adjusts the data transmission rate from the data transmission rate corresponding to the first QoS requirement (e.g., V1) to the data transmission rate corresponding to the third QoS requirement (e.g., V3) to transmit the first QoS flow.

[0181] It should be understood that the adjustment formula in the above example is based on reducing the data transmission rate. GFBRX (equivalent to GFBR3) is at most equal to GFBR1. That is, when GFBRX or GFBR3 is less than GFBR1, the data transmission rate can be reduced. In addition, there are possible situations where GFBRX or GFBR3 can be greater than or equal to GFBR1, indicating that the data transmission rate can be increased.

[0182] Furthermore, after completing the speed adjustment, the application server can inform the user plane network element and the access network device of the QoS requirement (i.e., the third QoS requirement) corresponding to the adjusted data transmission rate. Exemplarily, the application server sends the third information to the access network device and the user plane network element respectively, and accordingly, the access network device receives the third information from the application server, and the user plane network element receives the third information from the application server. The third information is used to indicate the third QoS requirement. Thus, the access network device can switch the first QoS requirement to the third QoS requirement based on the third information to ensure the transmission of the first QoS flow, and the user plane network element can learn from the third information that the currently used QoS requirement is switched to the third QoS requirement, so as to facilitate the execution of the next speed adjustment feedback.

[0183] Based on the speed adjustment method shown in Figure 5, the user-plane network element obtains the latest network status changes and congestion status in real time based on the QoS requirement changes indicated by the first information sent by the access network device, and obtains second information based on the ECN feedback information in the first message obtained by updating the first information. The second information is then fed back to the application server via the second message, allowing the application server to adjust the data transmission rate based on the second information. As a result, on the one hand, the user-plane network element does not need to bypass the terminal device twice through the air interface to obtain ECN feedback information, and there is no interval for the terminal device to count ECN feedback information, which can increase the ECN feedback rate and thus reduce task response time. On the other hand, the user-plane network element feeds back the ECN feedback information adjusted by the first information to the application server via the second message, so that the data transmission rate that the application server can adjust is more consistent with the real-time status of the network, thereby also reducing task response time.

[0184] The speed regulation method shown in FIG5 is described in detail below with reference to a specific scenario. The method is described using an example in which the application server is an AS, the user plane network element is a UPF, the access network device is a gNB, the first QoS requirement is QoS requirement 1, and the second QoS requirement is QoS requirement 2.

[0185] For example, FIG7 is a flow chart of a speed regulation method provided in an embodiment of the present application. As shown in FIG7 , the speed regulation method includes the following steps:

[0186] S701: AS, UPF, and gNB perform initial QoS configuration.

[0187] For example, the AS can negotiate with the UPF and gNB to configure multiple QoS requirements for the first QoS flow it transmits, such as QoS requirements 1 to 6. Different QoS requirements correspond to different data transmission rates for the first QoS flow, and each QoS requirement includes QoS parameters such as GFBR, PDB, and PER. Furthermore, QoS requirement 1 among QoS requirements 1 to 6 is used as the initial QoS requirement, meaning that the AS currently transmits the first QoS flow at the data transmission rate corresponding to QoS requirement 1.

[0188] In one possible implementation, the AS may trigger the 5GC to send a protocol data unit (PDU) session resource establishment request or adjustment message to the gNB. The PDU session resource establishment request or adjustment message carries multiple QoS requirements corresponding to the first QoS flow. Optionally, the PDU session resource establishment request or adjustment message may also carry a QCN configuration. The specific description of the QoS requirements and QCN configuration can be found in the relevant description in S501 above and is not repeated here.

[0189] S702. The gNB monitors the network status and air interface transmission status of the first QoS flow.

[0190] While transmitting the first QoS flow with QoS requirement 1, the gNB monitors changes in network status and the air interface transmission status when transmitting the first QoS flow with QoS requirement 1 in real time, and determines whether the current network status and air interface transmission status match QoS requirement 1. If not, the gNB determines a matching QoS requirement, such as QoS requirement 2, from among multiple configured QoS requirements based on the current network status and air interface transmission status. For example, if the gNB detects poor network status and air interface congestion, the gNB may select a QoS requirement with a lower latency requirement than QoS requirement 1. If the gNB detects good network status and no air interface congestion, the gNB may select a QoS requirement with a higher latency requirement than QoS requirement 1. The specific implementation of S702 can be found in the description of S501 above and is not repeated here.

[0191] S703: The gNB sends a GTP-U message to the UPF. Accordingly, the UPF receives the GTP-U message from the gNB.

[0192] The header of the GTP-U message carries first information, and the first information is used to indicate a congestion ratio 1 for the first QoS flow transmitted with QoS requirement 1. That is, after the gNB determines that the QoS requirement needs to be adjusted according to S702, it can determine the congestion ratio 1 based on the determined new QoS requirement (i.e., QoS requirement 2) and the old QoS requirement (i.e., QoS requirement 1), and send the congestion ratio 1 to the UPF in the form of the first information carried in the header of the GTP-U message.

[0193] For example, GFBR1 in QoS requirement 1 = 6 kb / s, and GFBR2 in QoS requirement 1 = 4 kb / s. The gNB can calculate the congestion ratio 1 based on GFBR1 and GFBR2, that is, the congestion ratio Indicates that there may be congestion and the data transmission rate needs to be reduced.

[0194] For example, if GFBR1 in QoS requirement 1 is 4 kb / s and GFBR2 in QoS requirement 1 is 6 kb / s, the gNB can calculate the congestion ratio 1 based on GFBR1 and GFBR2, i.e., the congestion ratio This indicates that there is no congestion and the data transmission rate needs to be increased. In this case, the congestion ratio 1 can be set to zero, that is, the congestion ratio 1 = 0.

[0195] S704. UPF obtains RTPFB message 1.

[0196] Among them, RTPFB message 1 includes ECN feedback information of the UE, and the ECN feedback information includes the first number of messages experiencing congestion, such as ECN-CE Counter1=150, the first number of messages not experiencing congestion, such as ECT Counter1=200, and the number of messages that do not support ECN feedback, such as not-ECT Counter=50. That is, the value of the ECN-CE number field in RTPFB message 1 is 150, the value of the ECT(1) number field is 200, and the value of the not-ECT number field is 50.

[0197] Exemplarily, the UPF receives RTPFB message 1 from the UE, where the RTPFB message 1 is the message currently sent by the UE to the AS.

[0198] It should be understood that the embodiment of the present application does not limit the execution order of S703 and S704.

[0199] S705: The UPF sends RTPFB message 2 to the AS. Correspondingly, the AS receives the RTPFB message 2 from the UPF.

[0200] RTPFB message 2 includes second information, which is determined based on the first information in the GTP-U message and the ECN feedback information in RTPFB message 1. The second information includes a second number of messages that experience congestion (ECN-CE Counter2), a second number of messages that do not experience congestion (ECT Counter2), and a number of messages that do not support ECN feedback (not-ECT Counter).

[0201] Exemplarily, after receiving the ECN feedback information from RTPFB message 1, UPF sums the first number of messages that experienced congestion, the first number of messages that did not experience congestion, and the number of messages that do not support ECN feedback in the ECN feedback information to obtain the total number of statistical messages 1, that is, S_Counter1=150+200+50=400.

[0202] Furthermore, the UPF calculates the second number of packets experiencing congestion based on the total number of statistical packets 1 and the congestion ratio 1 (such as 33% in the above example). For example, the congestion ratio 1 = 33%, the ECN-CE Counter2 = 400 × 33% = 132, and then the ECT Counter2 = max{S_Counter1-ECN-CE Counter2-not-ECT Counter, 0} = max{400-132-50, 0} = 218 is calculated. Thus, in the case where the RTPFB message 1 is the message currently sent by the UE to the AS, the UPF can directly modify the value of the ECN-CE number field in the RTPFB message 1 from 150 to 132, and modify the value of the ECT(1) number field in the RTPFB message 1 from 200 to 218. The modified RTPFB message 1 is sent to the AS as the RTPFB message 2.

[0203] For another example, referring to the above example, congestion ratio 1 = 0, ECN-CE Counter2 = 400 × 0 = 0, and ECT Counter2 = max{S_Counter1 - ECN-CE Counter2 - not-ECT Counter, 0} = max{400 - 0 - 50, 0} = 350. Therefore, when RTPFB message 1 is the message currently sent by the UE to the AS, the UPF can directly modify the value of the ECN-CE quantity field in the RTPFB message 1 from 150 to 0, and modify the value of the ECT(1) quantity field in the RTPFB message 1 from 200 to 350. The modified RTPFB message 1 is then sent to the AS as RTPFB message 2.

[0204] S706. The AS adjusts the data transmission rate of the first QoS flow according to the second information.

[0205] After receiving RTPFB message 2, the AS calculates congestion ratio 2 according to the second information in RTPFB message 2, including ECN-CE Counter2 indicated by the ECN-CE quantity field, ECT Counter2 indicated by the ECT(1) quantity field, and not-ECT Counter indicated by the not-ECT quantity field, and selects the QoS requirement to be adjusted according to the congestion ratio 2 to adjust the data transmission rate of the first QoS flow.

[0206] Continuing with the above example, GFBR1 = 6 kb / s, ECN-CE Counter2 = 132, ECT Counter2 = 218, not-ECT Counter = 50, and congestion ratio Therefore, AS calculates the reference value of the adjusted GFBR based on the congestion ratio 2 and GFBR1 in QoS requirement 1, such as the reference value of GFBR = 6×(1-33%) = 4.02kb / s, and takes the QoS requirement with the GFBR value closest to and smaller than the reference value of GFBR among the multiple configured QoS requirements as the adjusted QoS requirement, such as GFBR2 = 4kb / s in QoS requirement 2 is closest to 4.02kb / s, then AS adjusts the data transmission rate corresponding to QoS requirement 1 to the data transmission rate corresponding to QoS requirement 2.

[0207] Continuing with the other example mentioned above, GFBR1 = 4 kb / s, ECN-CE Counter2 = 0, ECT Counter2 = 350, not-ECT Counter = 50, and congestion ratio 2 = 0%. Thus, the AS calculates the reference value of the adjusted GFBR based on the congestion ratio 2 and the GFBR1 in the QoS requirement 1, such as the reference value of GFBR = 4×(1-0%) = 4 kb / s. At this time, the reference value of the adjusted GFBR is equal to the GFBR1 in the QoS requirement 1. The AS can continue to transmit the first QoS flow at the data transmission rate corresponding to the QoS requirement 1, or select a QoS requirement with a GFBR value higher than the reference value of GFBR from multiple QoS requirements as the QoS requirement for adjusting the data transmission rate, such as GFBR2 = 6 kb / s in the QoS requirement 2, that is, the AS adjusts the data transmission rate corresponding to the QoS requirement 1 to the data transmission rate corresponding to the QoS requirement 2.

[0208] In the above example, the adjusted QoS requirements determined by the AS and the gNB are the same. It should be understood that in some cases, the adjusted QoS requirements determined by the AS and the gNB may also be different.

[0209] S707. The AS sends the third information to the gNB. In response, the gNB receives the third information from the AS.

[0210] The third information indicates the QoS requirement corresponding to the adjusted data transmission rate. That is, after determining the adjusted data transmission rate, the AS notifies the gNB of the QoS requirement corresponding to the adjusted data transmission rate, such as QoS requirement 2, so that the gNB transmits the first QoS flow with QoS requirement 2. It should be understood that the AS may also send the third information to the UPF.

[0211] In the scenario shown in Figure 7, the gNB monitors network conditions and switches gears based on QoS requirements, promptly feeding back congestion information to the UPF. The UPF then processes the UE's ECN feedback based on the congestion information and transmits it along with the ECN feedback message to the application server for rate control. This eliminates the need for the UPF to detour around the UE or wait for the UE to collect data packet congestion statistics over a specific time window to obtain congestion information. The UPF also rewrites or directly generates the ECN feedback information uploaded by the UE, making it compatible with the existing L4S application ecosystem. This enables a more immediate, accurate, and compatible rate control mechanism.

[0212] As another example, FIG8 is a flow chart of a speed regulation method provided in an embodiment of the present application. As shown in FIG8 , the speed regulation method includes the following steps:

[0213] S801, AS, UPF, and gNB perform initial QoS configuration.

[0214] S802. The gNB monitors the network status and air interface transmission status of the first QoS flow.

[0215] The specific implementation process of S801 and S802 can refer to the relevant description in the above S701 and S702, which will not be repeated here.

[0216] S803: The gNB sends a GTP-U message to the UPF. Accordingly, the UPF receives the GTP-U message from the gNB.

[0217] The header of the GTP-U message carries first information, and the first information is used to indicate the identifier of QoS requirement 2. That is, after the gNB determines that the QoS requirement (i.e., QoS requirement 2) needs to be adjusted according to S802 above, it sends the identifier of the QoS requirement to be adjusted to the UPF in the form of the first information carried in the header of the GTP-U message.

[0218] S804. UPF obtains RTPFB message 1.

[0219] Among them, RTPFB message 1 includes ECN feedback information of the UE, and the ECN feedback information includes the first number of messages experiencing congestion, such as ECN-CE Counter1=150, the first number of messages not experiencing congestion, such as ECT Counter1=200, and the number of messages that do not support ECN feedback, such as not-ECT Counter=50. That is, the value of the ECN-CE number field in RTPFB message 1 is 150, the value of the ECT(1) number field is 200, and the value of the not-ECT number field is 50.

[0220] Exemplarily, RTPFB message 1 is a message that the UE has most recently sent to the AS and stored in the UPF, and the message sequence number of RTPFB message 1 is 4.

[0221] S805: The UPF sends RTPFB message 2 to the AS. Correspondingly, the AS receives the RTPFB message 2 from the UPF.

[0222] RTPFB message 2 includes second information, which is determined based on the first information in the GTP-U message and the ECN feedback information in RTPFB message 1. The second information includes a second number of messages that experience congestion (ECN-CE Counter2), a second number of messages that do not experience congestion (ECT Counter2), and a number of messages that do not support ECN feedback (not-ECT Counter).

[0223] Exemplarily, RTPFB message 2 is a message generated locally by the UPF, which does not carry uplink data sent by the UE, that is, the load is empty. The value of the ECN-CE quantity field and the value of the ECT(1) quantity field in RTPFB message 2 are determined and calculated by the UPF based on the first information in the GTP-U message and the ECN feedback information in the RTPFB message 1. Specifically, the UPF determines QoS requirement 2 from multiple QoS requirements based on the identifier of QoS requirement 2 indicated by the first information, and calculates the congestion ratio 1 using GFBR1 in QoS requirement 1 and GFBR2 in QoS requirement 2. Furthermore, the UPF calculates a second number of packets experiencing congestion (ECN-CE Counter2) and a second number of packets not experiencing congestion (ECT Counter2) based on the congestion ratio 1, the first number of packets experiencing congestion, the first number of packets not experiencing congestion, and the number of packets that do not support ECN feedback. For the specific implementation process, refer to the relevant description in S705 above and are not repeated here.

[0224] Therefore, the UPF writes ECN-CE Counter2 into the ECN-CE quantity field in RTPFB message 2, writes ECT Counter2 into the ECT(1) quantity field, and writes not-ECT Counter into the not-ECT quantity field.

[0225] Since RTPFB message 2 is a message generated locally by UPF, in order to ensure the continuity of the RTPFB message, the RTPFB message generated locally by UPF needs to be continuous with the RTPFB message sent by the UE. For example, the RTPFB message sent by the UE that the UPF last received is RTPFB message 1, and the message sequence number of RTPFB message 1 is 4, then the message sequence number of RTPFB message 2 is 5, and the specific value of the SSRC field of the packet sender in RTPFB message 2 and RTPFB message 1 is consistent with the specific value of the SSRC field of the media source.

[0226] S806. The AS adjusts the data transmission rate of the first QoS flow according to the second information.

[0227] S807. The AS sends the third information to the gNB. In response, the gNB receives the third information from the AS.

[0228] The third information is used to indicate the QoS requirement corresponding to the adjusted data transmission rate.

[0229] The specific implementation process of the above S806 and S807 can refer to the relevant description of the above S706 and S707, which will not be repeated here.

[0230] In the scenario shown in Figure 8, the difference from the scenario shown in Figure 7 above is that the gNB transmits the identifier of the QoS requirement to be updated to the UPF, and then the UPF uses the new and old QoS requirements and the corresponding changes in various QoS parameter indicators to more comprehensively perceive the network status and fluctuations. By designing an algorithm or training with historical data, the mapping relationship between the changes in various QoS parameter indicators and the congestion ratio is obtained, so that the congestion ratio can be determined, the ECN feedback information obtained from the UE can be processed, and the processed ECN feedback information can be transmitted to the application server through the ECN feedback message for speed adjustment.

[0231] It should be understood that the scenarios in FIG. 7 and FIG. 8 simply illustrate how a QoS parameter change in the new and old QoS requirements is converted into a congestion ratio. The embodiments of the present application do not limit the conversion algorithm and the setting of the QoS parameters. The conversion algorithm can satisfy the following relationship: Its input may include one or more QoS parameters and their combinations. In addition, in the scenario shown in Figure 8, the first information is used to indicate the identifier of QoS requirement 2. Alternatively, the first information may be used to indicate at least one QoS parameter in QoS requirement 2, such as GFBR2, PER2, and PDB2. The way the UPF converts the QoS parameters of QoS requirement 2 into congestion ratios is similar to the way it converts the identifier of QoS requirement 2 into congestion ratios, and this will not be described in detail.

[0232] It should also be understood that, in addition to the downlink transmission described in the embodiments, the embodiments of the present application are also applicable to the adjustment of the uplink data rate. In addition, the embodiments of the present application are not limited to the adjustment of the data transmission rate on the application server side, and can be compatible with specific end-cloud collaborative applications, such as the application server adjusting the video rendering frame rate or the AI ​​application model splitting interaction.

[0233] In each of the above embodiments, the methods and / or steps implemented by the user plane network element may also be implemented by components that can be used for the user plane network element (such as a processor, chip, chip system, circuit, logic module, or software); the methods and / or steps implemented by the access network device may also be implemented by components that can be used for the access network device (such as a processor, chip, chip system, circuit, logic module, DU or software). For example, when the execution subject of each of the above embodiments is the DU in the access network device, the sending or receiving steps performed by the access network device may be replaced by the sending or receiving of the DU, and further, it may be the sending of the DU to the RU or the receiving of the DU from the RU; the methods and / or steps implemented by the application server may also be implemented by components that can be used for the application server (such as a processor, chip, chip system, circuit, logic module, or software).

[0234] The above mainly introduces the solution provided by the present application. Accordingly, the present application also provides a communication device, which is used to implement the various methods in the above method embodiments. The communication device can be the user plane network element in the above method embodiments, or a device including the user plane network element, or a component that can be used for the user plane network element, such as a chip or a chip system. Alternatively, the communication device can be the access network device in the above method embodiments, or a device including the access network device, or a component that can be used for the access network device, such as a chip or a chip system. Alternatively, the communication device can be the application server in the above method embodiments, or a device including the application server, or a component that can be used for the application server, such as a chip or a chip system.

[0235] In some embodiments, in order to implement the above functions, the communication device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily appreciate that, in combination with the units and algorithm steps of the various examples described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0236] The embodiment of the present application can divide the functional modules of the communication device according to the above method embodiment. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical functional division. In actual implementation, there may be other division methods.

[0237] Taking the communication device as the user plane network element, access network device, or application server in the above-mentioned method embodiment as an example, Figure 9 is a structural schematic diagram of a communication device provided in an embodiment of the present application. As shown in Figure 9, the communication device 900 includes: a processing module 901 and a transceiver module 902. Among them, the processing module 901 is used to perform the processing function of the user plane network element, access network device, or application server in the above-mentioned method embodiment. The transceiver module 902 is used to perform the transceiver function of the user plane network element, access network device, or application server in the above-mentioned method embodiment.

[0238] Among them, all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0239] Since the communication device 900 provided in this embodiment can execute the above method, the technical effects that can be obtained can refer to the above method embodiments and will not be repeated here.

[0240] In one possible design, in an embodiment of the present application, the transceiver module 902 may include a receiving module and a sending module (not shown in FIG9 ), wherein the sending module and the receiving module are used to implement the sending function and the receiving function of the communication device 900 , respectively.

[0241] In one possible design, the communication device 900 may further include a storage module (not shown in FIG. 9 ) storing a program or instruction. When the processing module 901 executes the program or instruction, the communication device 900 may perform the functions of the user plane network element, access network device, or application server in the method shown in FIG. 5 .

[0242] In some embodiments, the processing module 901 involved in the communication device 900 can be implemented by a processor or a processor-related circuit component, which can be a processor or a processing unit; the transceiver module 902 can be implemented by a transceiver or a transceiver-related circuit component, which can be a transceiver or a transceiver unit.

[0243] For example, Figure 10 is a schematic diagram of the structure of another communication device provided in an embodiment of the present application. The communication device may be a user plane network element, an access network device, or an application server, or may be a chip (system) or other parts or components that can be set in a user plane network element, an access network device, or an application server. As shown in Figure 10, the communication device 1000 may include a processor 1001. In one possible design scheme, the communication device 1000 may further include a memory 1002 and / or a transceiver 1003. The processor 1001 is coupled to the memory 1002 and the transceiver 1003, such as by being connected via a communication bus.

[0244] The following is a detailed introduction to the various components of the communication device 1000 in conjunction with FIG10 :

[0245] The processor 1001 is the control center of the communication device 1000 and can be a single processor or a collective term for multiple processing elements. For example, the processor 1001 includes one or more central processing units (CPUs), can be an application-specific integrated circuit (ASIC), or can be one or more integrated circuits configured to implement the embodiments of the present application, such as one or more microprocessors (digital signal processors, DSPs) or one or more field programmable gate arrays (FPGAs).

[0246] In one possible design, the processor 1001 may execute various functions of the communication device 1000 by running or executing software programs stored in the memory 1002 and calling data stored in the memory 1002 .

[0247] In a specific implementation, as an embodiment, the processor 1001 may include one or more CPUs, such as CPU0 and CPU1 shown in FIG10 .

[0248] In a specific implementation, as an embodiment, the communication device 1000 may also include multiple processors, such as the processor 1001 and the processor 1004 shown in Figure 10. Each of these processors may be a single-core processor or a multi-core processor. The processor here may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0249] The memory 1002 is used to store the software program for executing the solution of the present application, and the execution is controlled by the processor 1001. The specific implementation method can refer to the above method embodiment and will not be repeated here.

[0250] In one possible design, the memory 1002 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, an optical disc storage (including a compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 1002 may be integrated with the processor 1001 or exist independently and be coupled to the processor 1001 via an interface circuit (not shown in FIG. 10 ) of the communication device 1000. This embodiment of the present application does not specifically limit this.

[0251] Transceiver 1003 is used for communication with other communication devices. For example, if communication device 1000 is a terminal device, transceiver 1003 can be used to communicate with an access network device or another terminal device. For another example, if communication device 1000 is a network device, transceiver 1003 can be used to communicate with a terminal device or another network device.

[0252] In one possible design, transceiver 1003 may include a receiver and a transmitter (not separately shown in FIG10 ), wherein the receiver is configured to implement a receiving function, and the transmitter is configured to implement a transmitting function.

[0253] In one possible design scheme, the transceiver 1003 can be integrated with the processor 1001, or it can exist independently and be coupled to the processor 1001 through the interface circuit of the communication device 1000 (not shown in Figure 10). This embodiment of the present application does not specifically limit this.

[0254] It should be noted that the structure of the communication device 1000 shown in FIG10 does not constitute a limitation on the communication device. An actual communication device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0255] In addition, the technical effects of the communication device 1000 can refer to the technical effects of the methods described in the above method embodiments, and will not be repeated here.

[0256] An embodiment of the present application further provides a computer-readable storage medium on which a computer program or instruction is stored. When the computer program or instruction is executed by a computer, the functions of the above-mentioned method embodiment are realized.

[0257] The embodiments of the present application also provide a computer program product, which implements the functions of the above method embodiments when executed by a computer.

[0258] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented using a software program, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more media integrated therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (eg, a solid state disk (SSD)).

[0259] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0260] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0261] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0262] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0263] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0264] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or an access network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0265] Although the present application is described herein in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art may understand and implement other variations of the disclosed embodiments by reviewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple situations. A single processor or other unit may implement several functions listed in the claims. Certain measures are recorded in different dependent claims, but this does not mean that these measures cannot be combined to produce good results.

[0266] Although the present application has been described with reference to specific features and embodiments thereof, it is apparent that various modifications and combinations may be made thereto without departing from the spirit and scope of the present application. Accordingly, this specification and the drawings are merely illustrative of the present application as defined by the appended claims and are deemed to cover any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, those skilled in the art may make various modifications and variations to the present application without departing from the spirit and scope of the present application. Thus, the present application is intended to include such modifications and variations as fall within the scope of the claims of the present application and their equivalents.

Claims

1. A speed regulation method, characterized in that: The method comprises: receiving first information from an access network device, the first information being used to indicate that a first QoS requirement corresponding to a first quality of service QoS flow needs to be adjusted to a second QoS requirement, the first QoS requirement and the second QoS requirement corresponding to different data transmission rates; Acquire a first message of a terminal device, wherein the first message includes a first number of messages that experience congestion, a first number of messages that do not experience congestion, and a number of messages that do not support explicit congestion notification (ECN) feedback; Send a second message to the application server, the second message carrying second information, the second information being determined based on the first information, the first number of messages that experienced congestion, the first number of messages that did not experience congestion, and the number of messages that do not support ECN feedback, wherein the second information is used to determine a first congestion ratio when the first QoS flow is transmitted with the first QoS requirement, and the first congestion ratio is used to adjust the data transmission rate of the first QoS flow.

2. A speed regulation method, characterized in that: The method comprises: The access network device sends first information to the user plane network element, wherein the first information is used to indicate that a first QoS requirement corresponding to a first quality of service QoS flow needs to be adjusted to a second QoS requirement, and the first QoS requirement and the second QoS requirement correspond to different data transmission rates; The user plane network element receives the first information from the access network device, and obtains a first message of the terminal device, wherein the first message includes a first number of messages that experience congestion, a first number of messages that do not experience congestion, and a number of messages that do not support explicit congestion notification ECN feedback; The user plane network element sends a second message to the application server, the second message carrying second information, the second information being determined based on the first information, the first number of messages that have experienced congestion, the first number of messages that have not experienced congestion, and the number of messages that do not support ECN feedback, wherein the second information is used to determine a first congestion ratio when the first QoS flow is transmitted with the first QoS requirement, and the first congestion ratio is used to adjust the data transmission rate of the first QoS flow.

3. The method according to claim 1 or 2, characterized in that: The first information includes one of the following: a second congestion ratio when the first QoS flow is transmitted with the first QoS requirement, an identifier of the second QoS requirement, or a QoS parameter in the second QoS requirement, wherein the second congestion ratio is determined based on the first QoS requirement and the second QoS requirement.

4. The method according to claim 3, characterized in that The QoS parameter includes at least one of the following: a guaranteed flow bit rate GFBR, a packet delay budget PDB, or a packet error rate PER.

5. The method according to any one of claims 1 to 4, characterized in that The first information is carried in a message sent by the access network device.

6. The method according to any one of claims 1 to 5, characterized in that The second information includes a second number of packets experiencing congestion, a second number of packets not experiencing congestion, and the number of packets that do not support ECN feedback; wherein the second number of packets experiencing congestion is determined according to a statistical total number of packets and the first information, the second number of packets not experiencing congestion is determined according to the statistical total number of packets, the second number of packets experiencing congestion, and the number of packets that do not support ECN feedback, and the statistical total number of packets is equal to the sum of the first number of packets experiencing congestion, the first number of packets not experiencing congestion, and the number of packets that do not support ECN feedback.

7. The method according to claim 6, characterized in that The second number of packets experiencing congestion is determined according to the total number of statistical packets and the first information, including: The second number of packets experiencing congestion is determined based on the total number of statistical packets and a second congestion ratio when the first QoS flow is transmitted with the first QoS requirement, wherein the second congestion ratio is determined based on the first information.

8. The method according to claim 6 or 7, characterized in that: The second number of packets that are not congested is the maximum value of the third number and zero, and the third number is equal to the difference between the total number of statistical packets and the second number of packets that experience congestion and the number of packets that do not support ECN feedback.

9. The method according to any one of claims 6 to 8, characterized in that: The second message is obtained by modifying the first number of the messages experiencing congestion in the first message to the second number of the messages experiencing congestion, and modifying the first number of the messages not experiencing congestion in the first message to the second number of the messages not experiencing congestion.

10. The method according to any one of claims 1 to 8, characterized in that The load in the second message is empty, the message sequence number in the second message is the message sequence number in the first message plus one, the sender identifier and the receiver identifier in the second message are respectively the same as the sender identifier and the receiver identifier in the first message, the sender identifier is used to identify the terminal device, and the receiver identifier is used to identify the application server.

11. The method according to any one of claims 1 to 10, characterized in that The second message is a real-time transport layer feedback message RTPFB message.

12. A communication device, characterized in that: The method comprises a module for executing the method as claimed in any one of claims 1, 3-11.

13. A communication device, characterized in that: include: processor; The processor is configured to execute a computer program or instruction so that the method according to any one of claims 1, 3-11 is implemented.

14. A communication chip, characterized in that: Instructions are stored therein, and when the chip runs on a communication device, the method according to any one of claims 1, 3-11 is implemented.

15. A computer-readable storage medium, characterized in that: The storage medium stores a computer program or instruction. When the computer program or instruction is executed by the communication device, the method according to any one of claims 1, 3-11 is implemented.

16. A computer program product, characterized in that The device comprises a computer program code, and when the computer program code is executed on a communication device, the communication device implements the method according to any one of claims 1, 3-11.

Images