Flow control method and apparatus, and system

Abstract

The present application provides a flow control method and apparatus, and a system. The method comprises: obtaining a first delay, the first delay being a round trip time (RTT) between a second device and a third device; on the basis of the first delay, a first rate, and / or a second rate, determining a token-bucket parameter, the token-bucket parameter being used for instructing the third device to perform uplink data transmission, the first rate being a maximum flow bit rate (MFBR) between the second device and the third device, and the second rate being a guaranteed flow bit rate (GFBR) between the second device and the third device; and sending the token-bucket parameter, the third device being in communication with the second device by means of the first device. According to the solution, a process of determining the token-bucket parameter is associated with a link state, so that a messages transmitted on the link can better adapt to the link capacity, thereby achieving flexible flow control.

Description

A flow control method, apparatus and system

[0001] This application claims priority to Chinese Patent Application No. 202411050147.1, filed on July 30, 2024, entitled "A Flow Control Method, Apparatus and System", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communications, and more specifically, to a flow control method, apparatus, and system. Background Technology

[0003] Traditional TCP / IP network communication sends messages through the kernel, resulting in high overhead from data movement and copying. With the development of communication technologies, the TCP / IP hardware and software architecture can no longer meet the demands of applications for high-performance computing, big data analysis, and other applications requiring high concurrency and low latency. To address the latency in server-side data processing during network transmission, Remote Direct Memory Access (RDMA) technology emerged.

[0004] In RDMA-based data transmission, traffic control can be achieved through traffic policing within Quality of Service (QoS) to avoid packet loss and other problems caused by network congestion. QoS traffic policing employs a token bucket mechanism, smoothly controlling traffic based on token bucket parameters such as bucket size duration (BSD) and prioritized bit rate (PBR). However, setting the token bucket parameters too small prevents full utilization of link bandwidth, while setting them too large introduces risks of network congestion, packet loss, and retransmissions.

[0005] Therefore, how to achieve flexible flow control is an urgent problem to be solved. Summary of the Invention

[0006] This application provides a flow control method that enables flexible control of uplink flow, thereby making full use of link bandwidth and avoiding congestion.

[0007] Firstly, a flow control method is provided. This method can be executed by a first device (e.g., a base station device) or by a component of the first device (e.g., a chip or circuit), and this application does not limit the execution of such method.

[0008] The method includes: acquiring a first delay, wherein the first delay is the round-trip time (RTT) between a second device and a third device; determining token bucket parameters based on the first delay, a first rate, and / or a second rate, wherein the token bucket parameters are used to instruct the third device to perform uplink data transmission, wherein the first rate is the maximum flow bit rate (MFBR) between the second device and the third device, and the second rate is the guaranteed flow bit rate (GFBR) between the second device and the third device; and sending the token bucket parameters; wherein the third device communicates with the second device through the first device.

[0009] Based on the above scheme, since the third device allocates uplink data based on the token bucket parameters, which are determined and issued by the first device, linking the token bucket parameter determination process to the link status and determining the token bucket parameters according to the link latency and / or traffic rate guides the third device in uplink data transmission. This allows the packets transmitted on the link to better adapt to the link capacity, achieving flexible traffic control. It avoids situations where the token bucket parameter is set too low, resulting in insufficient packet transmission and underutilization of link bandwidth; or where the token bucket parameter is set too high, leading to excessive packet transmission, network congestion, increased packet waiting latency, or packet loss causing retransmissions.

[0010] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: sending a first message, the first message being used to instruct the activation of latency monitoring between the second device and the third device.

[0011] Optionally, the first message can be sent directly from the first device to the second device; or, it can be sent from the first device to a fourth device (e.g., an SMF network element), and then the fourth device sends a corresponding message to the second device, thereby instructing the second device to enable latency monitoring between the second device and the third device; or, it can be sent from the first device to at least one other device, and then the at least one other device sends corresponding instruction information to the second device. It should be understood that the embodiments of this application only provide functional limitations on the first message and do not constitute a limitation on the receiving end of the first message.

[0012] Based on the above scheme, the first device initiates latency monitoring to obtain network information. The first device can directly send a request to the second device, or it can send a request to the second device through the fourth device, to enable real-time monitoring of the latency of the service flow between the second device and the third device, without having to enable latency monitoring through the operation and maintenance system or external application function (AF) network elements. This improves the flexibility of traffic control while reducing the signaling overhead of having other devices instruct the activation of latency monitoring.

[0013] In conjunction with the first aspect, in some implementations of the first aspect, the token bucket parameters include: Priority Bit Rate (PBR) and Bucket Size Duration (BSD); the step of determining the token bucket parameters based on the first delay, the first rate, and / or the second rate further includes: determining the BSD based on the first delay; determining the PBR based on the first rate or the second rate; or, determining the PBR based on the first delay and the first rate; or, determining the PBR based on the first delay and the second rate.

[0014] In conjunction with the first aspect, in some implementations of the first aspect, obtaining the first delay includes: receiving the first delay; or, determining the first delay based on a second delay, a third delay, and a fourth delay, wherein the second delay is the uplink air interface delay between the third device and the first device, the third delay is the downlink air interface delay between the third device and the first device, and the fourth delay is the RTT between the first device and the second device.

[0015] Optionally, determining the first delay based on the second delay, the third delay, and the fourth delay further includes: the first delay, the second delay, the third delay, and the fourth delay satisfying that: the first delay is the sum of the second delay, the third delay, and the fourth delay.

[0016] Based on the above scheme, the first delay can be determined by the first device itself, or it can be determined by the second device and sent to the first device, which improves the flexibility of the first device in obtaining network information (first delay and / or fourth delay).

[0017] In conjunction with the first aspect, in some implementations of the first aspect, before determining the first delay based on the second delay, the third delay, and the fourth delay, the method further includes: sending a second message, the second message indicating delay information sampling between the first device and the second device; receiving a third message, the third message including a first time point, a second time point, and a third time point, for determining the fourth time point and the fourth delay; wherein the first time point is the time when the first device sends the second message, the second time point is the time when the second device receives the second message, the third time point is the time when the second device sends the third message, and the fourth time point is the time when the first device receives the third message; the relationship between the fourth delay and the first time point, the second time point, the third time point, and the fourth time point satisfies: RTT4=(T4-T3)+(T2-T1)

[0018] Wherein, RTT4 represents the fourth time delay, T1 represents the first time, T2 represents the second time, T3 represents the third time, and T4 represents the fourth time.

[0019] Optionally, before receiving the first delay, the method further includes: receiving a fourth message, the fourth message being used to indicate that delay information sampling is performed between the first device and the second device; sending a fifth message, the fifth message including the second delay, the third delay, a fifth time, a sixth time, and a seventh time, wherein the second device can determine an eighth time and the first delay based on the fifth message; wherein the fifth time is the time when the second device sends the fourth message, the sixth time is the time when the first device receives the fourth message, the seventh time is the time when the first device sends the fifth message, and the eighth time is the time when the second device receives the fifth message.

[0020] Optionally, the relationship between the first and second time delays, the third time delay, the fifth time point, the sixth time point, the seventh time point, and the eighth time point satisfies: RTT1=X1+X2+(T4-T3)+(T2-T1)

[0021] Where RTT1 represents the first delay, X1 represents the second delay, X2 represents the third delay, T5 represents the fifth time point, T6 represents the sixth time point, T7 represents the seventh time point, and T8 represents the eighth time point.

[0022] Based on the above scheme, when the first delay is determined by the first device itself, the first device can trigger the measurement and calculation of the fourth delay to obtain the round-trip delay between the first and second devices. Specifically, the first device determines the first delay based on the obtained second, third, and fourth delays. This approach reduces the signaling overhead caused by the first device needing to send the second and third delays to the second device, and the second device needing to send the determined first delay to the first device, when the second device determines the first delay. This improves the flexibility of the first device in obtaining network information (first delay and / or fourth delay) and further enhances the efficiency of flow control.

[0023] In conjunction with the first aspect, in some implementations of the first aspect, when N QoS flows between the second device and the third device share the same Infinite Resource Bearer (DRB), the first delay is the average RTT of the N QoS flows; or; the first delay is the maximum RTT of the N QoS flows; or; the first delay is the minimum RTT of the N QoS flows; or; the first delay is the weighted average RTT of the N QoS flows.

[0024] Based on the above scheme, since the data of multiple QoS streams can be mapped to a logical channel, the first delay of the logical channel can be determined by measuring the round-trip delay between the third device and the second device corresponding to the multiple QoS streams of the logical channel. This allows for a more accurate determination of the token bucket parameters adapted to the logical channel, thereby guiding uplink data transmission.

[0025] In conjunction with the first aspect, in some implementations of the first aspect, when N QoS flows between the second device and the third device share the same DRB, the BSD is the average RTT of the N QoS flows; or; the BSD is the maximum RTT of the N QoS flows; or; the BSD is the minimum RTT of the N QoS flows; or; the BSD is the weighted average RTT of the N QoS flows.

[0026] Based on the above scheme, since data from multiple QoS flows can be mapped to a single logical channel, determining the BSD of that logical channel based on the round-trip delay between the third and second devices obtained from measurements of the multiple QoS flows corresponding to that logical channel allows the determined BSD to be more accurately adapted to the actual network conditions of the logical channel, achieving flexible flow control. This avoids problems such as underutilization of link bandwidth or network congestion caused by unreasonable BSD settings.

[0027] In conjunction with the first aspect, in some implementations of the first aspect, when N QoS flows between the second device and the third device share the same DRB, the PBR is the average of the first rate or the second rate of the N QoS flows; or; the PBR is the maximum value of the first rate or the second rate of the N QoS flows; or; the PBR is the minimum value of the first rate or the second rate of the N QoS flows; or; the PBR is the weighted average of the first rate or the second rate of the N QoS flows.

[0028] Optionally, when N QoS flows between the second device and the third device share the same DRB, each QoS flow corresponds to an MFBR. i (i∈[1,N], where N is a positive integer). Among them, PBR, BSD, and MFBR... i and RTT1 i satisfy:

[0029] Where N represents the number of QoS flows, N is a positive integer, and RTT1 i MFBR represents the round-trip delay (first delay) between the terminal device and the UPF for the i-th QoS flow in N QoS flows. iThis represents the first rate of the i-th QoS flow in N QoS flows. As mentioned above, BSD is determined based on the round-trip delay (first delay) between the terminal device and the UPF.

[0030] Optionally, when N QoS flows between the second device and the third device share the same DRB, each QoS flow corresponds to a GFBR. i (i∈[1,N], where N is a positive integer). Among them, PBR, BSD, and GFBR... i and RTT1 i satisfy:

[0031] Where N represents the number of QoS flows, N is a positive integer, and RTT1 i GFBR represents the round-trip delay (first delay) between the terminal device and the UPF for the i-th QoS flow in N QoS flows. i This represents the second rate of the i-th QoS flow in N QoS flows. As mentioned above, BSD is determined based on the round-trip delay (first delay) between the terminal device and the UPF.

[0032] Based on the above scheme, since data from multiple QoS flows can be mapped to a single logical channel, the PBR of that logical channel can be determined based on the first or second rate of each QoS flow. Alternatively, the round-trip time (RTT) between the third and second devices can be measured for the multiple QoS flows corresponding to the logical channel, and the PBR can be determined based on the RTT and the first or second rate of each QoS flow. This approach associates PBR determination with link status, enabling the determined PBR to more accurately adapt to the actual network conditions of the logical channel, achieving flexible flow control. It avoids problems such as underutilization of link bandwidth or network congestion caused by unreasonable PBR settings.

[0033] In conjunction with the first aspect, in some implementations of the first aspect, sending the first message includes: sending the first message to a fourth device.

[0034] Based on the above scheme, the first device can initiate a request to the second device through the fourth device to enable real-time monitoring of the latency of the service flow between the second device and the third device, without having to enable latency monitoring through the operation and maintenance system or external AF network element. This improves the flexibility of traffic control while reducing the signaling overhead of having other devices instruct the activation of latency monitoring.

[0035] Secondly, a flow control method is provided. This method can be executed by a second device (e.g., a user plane function (UPF) network element) or by a component of the second device (e.g., a chip or circuit), and this application does not limit the execution of this method.

[0036] The method includes: receiving a second message, the second message indicating that delay information sampling is performed between a first device and a second device; sending a third message, the third message including a first time, a second time, and a third time, for determining a fourth time and a fourth delay; wherein the first time is the time when the first device sends the second message, the second time is the time when the second device receives the second message, the third time is the time when the second device sends the third message, the fourth time is the time when the first device receives the third message, and the fourth delay is the round-trip time (RTT) between the first device and the second device.

[0037] Based on the above scheme, when the first delay is determined by the first device itself, the first device can trigger the measurement and calculation of the fourth delay to obtain the round-trip delay between the first device and the second device. Specifically, the second device only needs to respond to the message sent by the first device, without needing to determine the first delay and send it to the first device. This reduces the overhead of computing resources and signaling to a certain extent, thereby improving the flexibility of the first device in obtaining network information (first delay and / or fourth delay) and improving the efficiency of flow control.

[0038] In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: receiving a first message, the first message being used to instruct the activation of latency monitoring between the second device and the third device; wherein the third device communicates with the second device through the first device.

[0039] Based on the above scheme, the first device initiates latency monitoring to obtain network information. The second device can directly receive the request initiated by the first device, or it can receive the request initiated by the first device through the fourth device, thereby enabling real-time monitoring of the latency of the service flow between the second device and the third device. It is not necessary to enable latency monitoring through the operation and maintenance system or external AF network elements, which can improve the flexibility of traffic control and reduce the signaling overhead of instructing other devices to enable latency monitoring.

[0040] Thirdly, a flow control method is provided. This method can be executed by a second device (e.g., a user plane function (UPF) network element) or by a component of the second device (e.g., a chip or circuit), and this application does not limit the execution of this method.

[0041] The method includes: determining a first delay, the first delay being used to indicate the round-trip time (RTT) between the second device and the third device; sending the first delay to the first device; wherein the third device communicates with the second device through the first device.

[0042] Based on the above scheme, when the second device determines the first delay, the second device can directly reuse the measurement process and indication signaling of the round-trip delay between the second device and the third device during the QoS traffic policing process, which reduces the computational and signaling overhead of the second device in determining the first delay to a certain extent.

[0043] In conjunction with the third aspect, in some implementations of the third aspect, before determining the first delay, the method further includes: sending a fourth message, the fourth message being used to indicate the sampling of delay information between the first device and the second device; and sending a fifth message, the fifth message including the second delay, the third delay, a fifth time point, a sixth time point, and a seventh time point, wherein the second device can determine an eighth time point and the first delay based on the fifth message; wherein the fifth time point is the time when the second device sends the fourth message, the sixth time point is the time when the first device receives the fourth message, the seventh time point is the time when the first device sends the fifth message, and the eighth time point is the time when the second device receives the fifth message.

[0044] In conjunction with the third aspect, in some implementations of the third aspect, the method further includes: receiving a first message, the first message being used to instruct the activation of latency monitoring between the second device and the third device; wherein the third device communicates with the second device through the first device.

[0045] Fourthly, a flow control method is provided. This method can be executed by a third device (e.g., a terminal device) or by a component of the third device (e.g., a chip or circuit), and this application does not limit the scope of the method.

[0046] The method includes: receiving token bucket parameters from a first device, the token bucket parameters being determined based on a first delay, a first rate, and / or a second rate, the first delay being used to indicate the round-trip time (RTT) between a second device and a third device, the first rate being the maximum flow bit rate (MFBR) between the second device and the third device, and the first rate being the guaranteed flow bit rate (GFBR) between the second device and the third device, wherein the third device communicates with the second device through the first device; and performing uplink data transmission according to the token bucket parameters.

[0047] Based on the above scheme, the token bucket parameter is determined in association with the link status. By determining the token bucket parameter according to the link latency and / or traffic rate, the token bucket parameter can be more accurately adapted to the actual network conditions of the logical channel. This better guides the third-party device in uplink data transmission, allowing the transmitted packets to better match the link capacity and achieve flexible traffic control. This avoids situations where the token bucket parameter is set too low, resulting in insufficient packet transmission and underutilization of link bandwidth; or when the token bucket parameter is set too high, excessive packet transmission leads to network congestion, increased packet waiting latency, or packet loss causing retransmissions.

[0048] Fifthly, a flow control method is provided. This method can be executed by a fourth device (e.g., a session management function (SMF) network element) or by a component of the fourth device (e.g., a chip or circuit), and this application does not limit the execution of this method.

[0049] The method includes: receiving a first message from a first device, the first message indicating the activation of latency monitoring between a second device and a third device, wherein the third device communicates with the second device through the first device; and sending the first message.

[0050] Based on the above scheme, when the first device initiates a request to enable real-time monitoring of the latency of the service flow between the second device and the third device, the request can be sent to the second device through the fourth device, without having to enable latency monitoring through the operation and maintenance system or external AF network element. This improves the flexibility of traffic control while reducing the signaling overhead of having other devices instruct the activation of latency monitoring.

[0051] Sixthly, a communication device is provided, which has the functions described in the first aspect above. For example, the communication device includes modules, units, or means corresponding to the operations involved in the first aspect above. These modules, units, or means can be implemented in software, hardware, or a combination of software and hardware. Examples include processing units and transceiver units.

[0052] In one implementation, the transceiver unit can be a transceiver or an input / output interface; the processing unit can be at least one processor. Optionally, the transceiver can be a transceiver circuit. Optionally, the input / output interface can be an input / output circuit.

[0053] In another implementation, the transceiver unit can be an input / output interface, interface circuit, output circuit, input circuit, pin, or related circuit on the chip, chip system, or circuit; the processing unit can be at least one processor, processing circuit, or logic circuit.

[0054] For example, if the communication device is the first device described above or a component of the first device (e.g., a chip or circuit), then the communication device includes:

[0055] The processing unit is used to perform processing-related operations on the first device side in the above method embodiment, such as obtaining a first delay, which is the round-trip time (RTT) between the second device and the third device; and determining token bucket parameters based on the first delay, a first rate, and / or a second rate, where the first rate is the maximum flow bit rate (MFBR) between the second device and the third device, and the second rate is the guaranteed flow bit rate (GFBR) between the second device and the third device.

[0056] Optionally, the processing unit is further configured to determine the BSD based on the first delay; determine the PBR based on the first rate or the second rate; or determine the PBR based on the first delay and the first rate; or determine the PBR based on the first delay and the second rate.

[0057] Optionally, the processing unit is further configured to determine the first delay based on the second delay, the third delay, and the fourth delay, wherein the second delay is the uplink air interface delay between the third device and the first device, the third delay is the downlink air interface delay between the third device and the first device, and the fourth delay is the RTT between the first device and the second device.

[0058] The transceiver unit is used to send the token bucket parameters, which are used to instruct the third device to perform uplink data transmission.

[0059] Optionally, the transceiver unit is also configured to send a first message, the first message being used to instruct the activation of latency monitoring between the second device and the third device.

[0060] Optionally, the transceiver unit is also configured to receive the first delay.

[0061] Optionally, the transceiver unit is further configured to send a second message, the second message being used to instruct the sampling of delay information between the first device and the second device; and to receive a third message, the third message including a first time point, a second time point, and a third time point, for determining a fourth time point and the fourth delay.

[0062] Optionally, the transceiver unit is also configured to send the first message to a fourth device.

[0063] In a seventh aspect, a communication device is provided, which has the functions of implementing the second or third aspect described above. For example, the communication device includes modules, units, or means corresponding to the operations involved in the second or third aspect. These modules, units, or means can be implemented in software, hardware, or a combination of software and hardware. Examples include processing units and transceiver units.

[0064] In one implementation, the transceiver unit can be a transceiver or an input / output interface; the processing unit can be at least one processor. Optionally, the transceiver can be a transceiver circuit. Optionally, the input / output interface can be an input / output circuit.

[0065] In another implementation, the transceiver unit can be an input / output interface, interface circuit, output circuit, input circuit, pin, or related circuit on the chip, chip system, or circuit; the processing unit can be at least one processor, processing circuit, or logic circuit.

[0066] For example, if the communication device is the second device described above or a component of the second device (e.g., a chip or circuit), then the communication device includes:

[0067] A transceiver unit is configured to receive a second message, which instructs the sampling of delay information between a first device and a second device; and to send a third message, which includes a first time, a second time, and a third time, for determining a fourth time and a fourth delay; wherein the first time is the time when the first device sends the second message, the second time is the time when the second device receives the second message, the third time is the time when the second device sends the third message, the fourth time is the time when the first device receives the third message, and the fourth delay is the round-trip time (RTT) between the first device and the second device.

[0068] Optionally, the transceiver unit is further configured to receive a first message, the first message being used to instruct the activation of latency monitoring between the second device and the third device; wherein the third device communicates with the second device through the first device.

[0069] For example, if the communication device is the second device described above or a component of the second device (e.g., a chip or circuit), then the communication device includes:

[0070] The transceiver unit is used to send the first delay to the first device.

[0071] The processing unit is configured to determine a first delay, which is used to indicate the round-trip time (RTT) between the second device and the third device.

[0072] Eighthly, a communication device is provided, which has the functions of the fourth aspect described above. For example, the communication device includes modules, units, or means corresponding to the operations involved in the fourth aspect. These modules, units, or means can be implemented in software, hardware, or a combination of both. Examples include processing units and transceiver units.

[0073] In one implementation, the transceiver unit can be a transceiver or an input / output interface; the processing unit can be at least one processor. Optionally, the transceiver can be a transceiver circuit. Optionally, the input / output interface can be an input / output circuit.

[0074] In another implementation, the transceiver unit can be an input / output interface, interface circuit, output circuit, input circuit, pin, or related circuit on the chip, chip system, or circuit; the processing unit can be at least one processor, processing circuit, or logic circuit.

[0075] For example, if the communication device is the aforementioned third device or a component of the third device (e.g., a chip or circuit), then the communication device includes:

[0076] The transceiver unit receives token bucket parameters from a first device, the token bucket parameters being determined based on a first delay, a first rate, and / or a second rate. The first delay is used to indicate the round-trip time (RTT) between the second device and the third device. The first rate is the maximum flow bit rate (MFBR) between the second device and the third device, and the first rate is the guaranteed flow bit rate (GFBR) between the second device and the third device. The third device communicates with the second device through the first device.

[0077] The processing unit performs uplink data transmission based on the token bucket parameters.

[0078] Ninthly, a communication device is provided, which has the functions of the fifth aspect described above. For example, the communication device includes modules, units, or means corresponding to the operations involved in the fifth aspect. These modules, units, or means can be implemented in software, hardware, or a combination of software and hardware. Examples include processing units and transceiver units.

[0079] In one implementation, the transceiver unit can be a transceiver or an input / output interface; the processing unit can be at least one processor. Optionally, the transceiver can be a transceiver circuit. Optionally, the input / output interface can be an input / output circuit.

[0080] In another implementation, the transceiver unit can be an input / output interface, interface circuit, output circuit, input circuit, pin, or related circuit on the chip, chip system, or circuit; the processing unit can be at least one processor, processing circuit, or logic circuit.

[0081] For example, if the communication device is the aforementioned fourth device or a component of the fourth device (e.g., a chip or circuit), then the communication device includes:

[0082] The transceiver unit receives a first message from a first device, the first message being used to instruct the activation of latency monitoring between a second device and a third device, wherein the third device communicates with the second device through the first device; and sends the first message.

[0083] In a tenth aspect, a communication device is provided, comprising a processor coupled to a memory for storing a computer program, the processor for running the computer program such that the communication device performs a method as described in any possible implementation of the first aspect; or, performs a method as described in any possible implementation of the second or third aspect; or, performs a method as described in any possible implementation of the fourth aspect; or, performs a method as described in any possible implementation of the fifth aspect.

[0084] Eleventhly, a computer-readable storage medium is provided that stores program code for execution by a device, the program code including a method for performing any implementation of the first aspect above; or a method for performing any implementation of the second or third aspect above; or a method for performing any implementation of the fourth aspect above; or a method for performing any implementation of the fifth aspect above.

[0085] In a twelfth aspect, a chip is provided, comprising a processor and a communication interface, wherein the processor reads instructions stored in a memory through the communication interface and executes the method provided by any implementation of the first aspect; or, executes the method provided by any implementation of the second or third aspect; or, executes the method provided by any implementation of the fourth aspect; or, is used to execute the method provided by any implementation of the fifth aspect.

[0086] Optionally, as one implementation, the chip further includes a memory storing computer programs or instructions. The processor executes the computer programs or instructions stored in the memory. When the computer programs or instructions are executed, the processor executes the method provided by any of the implementations of the first aspect above; or, executes the method provided by any of the implementations of the second or third aspect above; or, executes the method provided by any of the implementations of the fourth aspect above; or, executes the method provided by any of the implementations of the fifth aspect above.

[0087] In a thirteenth aspect, a communication system is provided, comprising a first device for performing the method provided in the first aspect, a second device for performing the method provided in the second or third aspect, a third device for performing the method provided in the fourth aspect, and a fourth device for performing the method provided in the fifth aspect.

[0088] In a fourteenth aspect, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to perform the method provided in any implementation of the first aspect; or, perform the method provided in any implementation of the second or third aspect; or, perform the method provided in any implementation of the fourth aspect; or, perform the method provided in any implementation of the fifth aspect. Attached Figure Description

[0089] Figure 1 is a schematic diagram of the network architecture applicable to an embodiment of this application.

[0090] Figure 2 is a schematic diagram of data acquisition based on TCP / IP and RDMA, respectively.

[0091] Figure 3 is a schematic diagram of the network types applicable to the embodiments of this application for RDMA.

[0092] Figure 4 is a schematic diagram of connection-based and packet-based data transmission applicable to embodiments of this application.

[0093] Figure 5 is a schematic diagram of a flow control method 500 applicable to an embodiment of this application.

[0094] Figure 6 is a schematic diagram of a flow control method 600 applicable to an embodiment of this application.

[0095] Figure 7 is a schematic diagram of a flow control method 700 applicable to an embodiment of this application.

[0096] Figure 8 is a schematic diagram of a communication device 800 applicable to an embodiment of this application.

[0097] Figure 9 is a structural schematic diagram of a communication device 900 applicable to an embodiment of this application.

[0098] Figure 10 is a schematic diagram of the structure of a chip system 1000 applicable to an embodiment of this application. Detailed Implementation

[0099] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0100] The technical solutions provided in this application can be applied to various communication systems, such as: 5th generation (5G) systems (or New Radio (NR) systems), beyond 5G (B5G) mobile communication systems, long term evolution (LTE) systems, LTE frequency division duplex (FDD) systems, LTE time division duplex (TDD) systems, narrowband internet of things (NB-IoT) systems, global system for mobile communications (GSM), enhanced data rate for GSM evolution (EDGE) systems, wideband code division multiple access (WCDMA) systems, code division multiple access 2000 (CDMA2000) systems, and time division-synchronization code division multiple access (TD-SCDMA) systems. The technical solutions provided in this application can also be applied to future communication networks. The technical solutions provided in this application can also be applied to device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, machine-to-machine (M2M) communication, machine-type communication (MTC), satellite communication systems, Internet of Things (IoT) communication systems, or other communication systems.

[0101] Figure 1 is a schematic diagram of the network architecture applicable to an embodiment of this application.

[0102] Taking the 5G network architecture based on service-based architecture (SBA) in a non-roaming scenario as defined in the 3GPP standardization process as an example, as shown in Figure 1, this network architecture can include a terminal equipment part, a data network (DN) part, and an operator network PLMN part. The operator network PLMN part may include, but is not limited to, the radio access network (RAN)120 and the core network (CN) parts.

[0103] The functions of each network element are briefly explained below.

[0104] The terminal equipment portion may include terminal equipment 110, which is a device that provides voice and / or data connectivity to users. Terminal equipment 110 may also be referred to as user equipment (UE). In this application, terminal equipment 110 is a device with wireless transceiver capabilities, capable of communicating with one or more core network (CN) devices via access network equipment (or access devices) in the (wireless) access network (RAN) 120. Terminal equipment 110 may also be referred to as an access terminal, terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, user agent, or user device, etc. Terminal equipment 110 can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; it can also be deployed on water (e.g., on ships); and it can also be deployed in the air (e.g., on airplanes, balloons, and satellites). Terminal device 110 can be a cellular phone, cordless phone, session initiation protocol (SIP) phone, smartphone, mobile phone, wireless local loop (WLL) station, personal digital assistant (PDA), etc. Alternatively, terminal device 110 can also be a handheld device with wireless communication capabilities, a computing device or other device connected to a wireless modem, in-vehicle device, wearable device, drone device, or a terminal in the Internet of Things (IoT), vehicle-to-everything (V2X) network, 5G network, or any form of terminal in future networks, relay user equipment, or a terminal in future communication networks. Relay user equipment can be, for example, a 5G residential gateway (RG). For example, terminal device 110 can be a virtual reality (VR) terminal, an augmented reality (AR) terminal, a wireless terminal in industrial control, a wireless terminal in autonomous driving, a wireless terminal in telemedicine, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, etc. Here, "terminal device" refers to a 3GPP terminal. The embodiments of this application do not limit the type or category of terminal devices.

[0105] (R)AN 120 may include one or more access network elements or access network devices. The interface between the access network device and the terminal device can be a Uu interface (or air interface, i.e., the messages exchanged between the access network device and the terminal device can be called air interface messages). Of course, in future communication, the interface name may remain unchanged or be replaced by other names, and this application is not limited in this regard. (R)AN 120 is a device that provides wireless communication functions for terminal device 110, and can connect the terminal device to a node or device of a wireless network, and can also be called a network device. (R)AN 120 can be regarded as a sub-network of the operator network, and is the implementation system between the service node and the terminal device 110 in the operator network. For example, the terminal device 110 can connect to the service node of the operator network through (R)AN 120 to obtain the services provided by the service node. (R)AN 120 includes, but is not limited to: next-generation node base station (gNB) in 5G systems, evolved node B (eNB) in long-term evolution (LTE), radio network controller (RNC), node B (NB), base station controller (BSC), base transceiver station (BTS), home base station (e.g., home evolved node B, or home node B (HNB), base band unit (BBU), transmitting and receiving point (TRP), transmitting point (TP), small cell equipment, mobile switching center, or network equipment in future networks.

[0106] In some deployments, a gNB can include a centralized unit (CU) and a distributed unit (DU). A gNB can also include an active antenna unit (AAU). The CU implements some of the gNB's functions, and the DU implements others. For example, the CU can support communication under protocols such as radio resource control (RRC), packet data convergence protocol (PDCP), and service data adaptation protocol (SDAP). The DU is responsible for handling physical layer protocols and real-time services, implementing functions at the radio link control (RLC), medium access control (MAC), and physical (PHY) layers. The CU and DU can be placed in different locations; for example, in a remote DU deployment scenario, the DU is placed in a high-traffic area, while the CU is placed in the central equipment room; alternatively, the CU and DU can be placed in the same equipment room; or they can be different components within the same rack. The AAU implements some physical layer processing functions, radio frequency processing, and related functions of the active antenna. Since information from the RRC layer ultimately becomes information from the PHY layer, or is derived from information from the PHY layer, in this architecture, higher-layer signaling, such as RRC layer signaling, can also be considered as being sent by the DU, or by the DU+AAU. It is understood that network devices can be one or more of the following: CU nodes, DU nodes, and AAU nodes. Furthermore, the CU can be classified as a network device in the radio access network (RAN), or it can be classified as a network device in the core network (CN); this application does not limit this classification.

[0107] Network equipment provides services to cells. Terminal devices communicate with cells through transmission resources (e.g., frequency domain resources, or spectrum resources) allocated by the network equipment. The cell can belong to a macro base station (e.g., macro eNB or macro gNB) or to a base station corresponding to a small cell. Small cells can include: metro cells, micro cells, pico cells, femto cells, etc. These small cells have the characteristics of small coverage area and low transmission power, and are suitable for providing high-speed data transmission services.

[0108] This application does not limit the specific technology or device form used in the access network equipment. In systems employing different wireless access technologies, the names of devices with access network equipment functions may differ. For ease of description, in all embodiments of this application, the apparatus that provides wireless communication functions for terminal device 110 is collectively referred to as access network equipment or simply RAN. It should be understood that this document does not limit the specific type of access network equipment.

[0109] The CN part may include, but is not limited to, the following network functions (NFs): User plane function (UPF)130, Network exposure function (NEF)131, Network function repository function (NRF)132, Policy control function (PCF)133, Unified data management function (UDM)134, Unified data repository function (UDR)135, Application function (AF)136, Authentication server function (AUSF)137, Access and mobility management function (AMF)138, Session management function (SMF)139.

[0110] Data network DN 140, also known as packet data network (PDN), is typically a network located outside the carrier's network, such as a third-party network.

[0111] The following is a brief explanation of the NF functions included in CN.

[0112] 1. The UPF 130 is a gateway provided by the operator, serving as the gateway for communication between the operator's network and the DN 140. UPF130 network functions include user plane-related functions such as packet routing and transmission, packet inspection, service usage reporting, Quality of Service (QoS) processing, lawful operation monitoring, uplink packet inspection, and downlink packet storage.

[0113] 2. NEF 131 is a control plane function provided by the operator, which mainly enables third parties to use the services provided by the network, supports the network to open its capabilities, events and data analysis, provides security configuration information to the PLMN from external applications, and converts information between the PLMN and external parties.

[0114] 3. NRF 132 is a control plane function provided by the operator, which can be used to maintain real-time information on network functions and services in the network.

[0115] 4. PCF 133 is a control plane function provided by the operator. Its main function is to provide a unified policy framework to control network behavior, provide policy rules to the control layer network functions, and acquire user subscription information related to policy decisions. For example, PCF 133 can be divided into two types of PCFs with different functions: UE-PCF and AMF-PCF.

[0116] 5. UDM 134 is a control plane function provided by the operator, responsible for storing information such as the subscriber permanent identifier (SUPI), generic public subscriber identifier (GPSI), and letter of trust of subscribed users in the operator's network. The SUPI is encrypted during transmission, and the encrypted SUPI is called the subscription concealed identifier (SUCI). This information stored in UDM network function 134 can be used for authentication and authorization of terminal device 110 accessing the operator's network. Specifically, the subscribed users of the aforementioned operator's network can be users of services provided by the operator's network, such as users of China Telecom's subscriber identity module (SIM) card or China Mobile's SIM card. The letter of trust of the subscribed user can be a long-term key stored in the SIM card or a small file containing information related to SIM card encryption, used for authentication and / or authorization. It should be noted that the permanent identifier, letter of trust, security context, authentication data, and token are equivalent to verification / authentication and authorization-related information, and for the sake of convenience in this embodiment, they are not distinguished or limited.

[0117] 6. UDR 135 is a control plane function provided by the operator, which provides UDM with the function of saving and retrieving subscription data, PCF with the function of saving and retrieving policy data, and saving and retrieving NF group ID information of terminal device 110, etc.

[0118] 7. AF 136 is a control plane function provided by the operator. It mainly provides corresponding services by interacting with other NFs in the PLMN, such as providing roaming terminal equipment 110 to visit network selection information, guiding data flow routing, and accessing NEF131.

[0119] 8. AUSF 137 is a control plane function provided by the operator, usually used for Level 1 authentication, that is, authentication between terminal device 110 (subscribed user) and operator network.

[0120] 9. AMF 138 is a control plane network function provided by the operator network, which is responsible for access control and mobility management of terminal device 110 accessing the operator network. This includes functions such as mobility state management, assigning temporary user identity identifiers, and authenticating and authorizing terminal device 110.

[0121] 10. SMF 139 is a control plane network function provided by the operator's network, responsible for managing the Protocol Data Unit (PDU) sessions of terminal equipment 110 (including session establishment, modification, and release). It is used for user plane function element selection and reselection, Internet Protocol (IP) address allocation for terminal equipment, and Quality of Service (QoS) control. A PDU session is a channel for transmitting PDUs; terminal equipment 110 and DN 140 exchange PDUs through PDU sessions. SMF network function 139 is responsible for establishing, maintaining, and deleting PDU sessions. SMF network function 139 includes session management (e.g., session establishment, modification, and release, including tunnel maintenance between user plane function UPF 130 and (R)AN 120), selection and control of UPF network function 130, service and session continuity (SSC) mode selection, roaming, and other session-related functions.

[0122] It should be understood that the aforementioned network element or NF can be a physical entity in a hardware device, a software instance running on dedicated hardware, or a virtualization function instantiated on a shared platform (e.g., a cloud platform). Simply put, an NF can be implemented by hardware or software. Furthermore, the hardware (or software) that implements all the functions of an NF can be one or multiple.

[0123] It should be understood that AMF, SMF, UPF, NEF, AUSF, NRF, PCF, and UDM shown in Figure 1 can be understood as network elements in the core network used to implement different functions. These network elements can be combined into network slices as needed. They can be independent devices or integrated into the same device to implement different functions. This application does not limit the specific form of the above network elements.

[0124] It should also be understood that the above naming is defined solely for the purpose of distinguishing different functions and should not constitute any limitation on this application. This application does not preclude the possibility of using other naming conventions in 5G networks and other future networks. For example, in future communication networks, some or all of the above-mentioned network elements may use the terminology from 5G, or they may use other names, etc.

[0125] It should also be understood that Nnef, Nnrf, Npcf, Nudm, Nudr, Nausf, Namf, Nsmf, Naf, N1, N2, N3, N4, and N6 in Figure 1 are interface sequence numbers. For example, the meaning of the above interface sequence numbers can be found in the definitions in the 3GPP standard protocols, and this application does not limit the meaning of the above interface sequence numbers. Furthermore, the interface names between the various network functions in Figure 1 are merely examples; in specific implementations, the interface names of this system architecture may be other names, and this application does not limit them.

[0126] It should be understood that the embodiments of this application do not limit the specific form of the access network device, terminal device, and core network device. Furthermore, in the embodiments of this application, the core network device can communicate with the terminal device through the access network device. For example, it can receive information from the terminal device through the access network device.

[0127] It should be understood that the aforementioned network element can be a physical entity within a hardware device, a software instance running on dedicated hardware, or a virtualized function instantiated on a shared platform (e.g., a cloud platform). Simply put, a network element can be implemented by hardware or software. Furthermore, the hardware (or software) that implements all the functions of a network element can be one or multiple.

[0128] It should be understood that the aforementioned network elements are used to implement different functions in the core network and can be combined into network slices as needed. They can be independent devices or integrated into the same device to implement different functions. This application does not limit the specific form of the aforementioned network elements. The above naming is defined only to facilitate the distinction of different functions and should not constitute any limitation on this application. This application does not exclude the possibility of using other naming conventions in 5G networks and future communication networks. For example, in future communication networks, some or all of the aforementioned network elements may use the terminology from 5G, or they may use other names, etc.

[0129] It should be understood that the network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating 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. As those skilled in the art will know, 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.

[0130] To facilitate understanding of the embodiments of this application, the terms involved in this application will be briefly explained below.

[0131] It should be understood that the basic concepts introduced below are illustrated using the basic concepts specified in the NR protocol as examples, but do not limit the embodiments of this application to be applied only to NR systems. Therefore, the standard names that appear when describing NR systems are functional descriptions, and the specific names are not limited, but only indicate the functions of the device, and can be extended to other future systems accordingly.

[0132] 1. Remote Direct Memory Access (RDMA) technology

[0133] Figure 2 is a schematic diagram of data acquisition based on TCP / IP and RDMA, respectively.

[0134] As shown in Figure 2(a), traditional TCP / IP network communication sends messages through the kernel. Specifically, the CPU needs to move the data to the kernel, and then the kernel moves it to the network card. This communication method has high overhead for data movement and data copying.

[0135] Unlike TCP / IP, as shown in Figure 2(b), RDMA technology was developed to address the latency in server-side data processing during network transmission. In RDMA, memory data can be accessed directly through the network interface without the intervention of the operating system kernel. That is, data does not need to be moved from the CPU to the kernel and then from the kernel to the network card; instead, data can be read directly from memory through the network card. Therefore, RDMA enables high-throughput, low-latency network communication and can be widely used in large-scale parallel computer clusters. At a transmission rate of 40Gbps, the CPU utilization rate of TCP / IP-based transmission is 100%, while the CPU utilization rate of RDMA-based transmission is only 5%.

[0136] Figure 3 is a schematic diagram of the network types applicable to the embodiments of this application for RDMA.

[0137] As shown in Figure 3, the network protocols that currently support RDMA include: Infiniband (IB), RDMA over converged ethernet (RoCE), and iWARP, which will be introduced below.

[0138] (1) IB: This is a network specifically designed for RDMA. The IB architecture provides a channel-based point-to-point message queue forwarding model, ensuring reliable transmission at the hardware level. Each application can directly obtain its own data messages through the created virtual channel without the intervention of other operating systems and protocol stacks. The application layer of the IB architecture adopts RDMA technology, which can provide RDMA read and write access between remote nodes, completely offloading the CPU workload. The network transmission uses high-bandwidth transmission, and the link layer sets up a specific retransmission mechanism to ensure service quality, without the need for data buffering.

[0139] (2) RoCE: The RoCE protocol is divided into two versions: RoCE v1 protocol and RoCE v2 protocol.

[0140] The RoCE v1 protocol, based on Ethernet carrying RDMA, can only be deployed in Layer 2 networks. Its message structure adds a Layer 2 Ethernet header to the existing IB architecture message, identifying the RoCE message through Ethertype 0x8915. The RoCE v2 protocol, based on UDP / IP carrying RDMA, can be deployed in Layer 3 networks. Its message structure adds a UDP header, an IP header, and a Layer 2 Ethernet header to the existing IB architecture message, identifying the RoCE message through the UDP destination port number 4791.

[0141] (3) iWARP: This is an RDMA technology based on Ethernet and TCP / IP protocols, which can run on standard Ethernet infrastructure. iWARP does not specify physical layer information, so it can work on any network layer using the TCP / IP protocol. iWARP allows many transport types to share the same physical connection, such as network, I / O, file system, block storage, and message communication between processors.

[0142] For the message format of RDMA, please refer to the relevant content in the prior art; this application will not elaborate on it here.

[0143] Based on RDMA, in order to achieve flexible traffic control and avoid congestion, current technologies have related mechanisms for traffic control and / or congestion control in different protocol architectures.

[0144] For example, priority-based flow control (PFC) buffers the ingress ports of nodes and can be applied to both the PFC RoCE v1 and RoCE v2 protocols. When a downstream device's lossless queue becomes congested, the downstream device notifies the upstream device that it will stop sending traffic from that queue, thus achieving zero packet loss transmission.

[0145] For example, each communication entity has logical outgoing and incoming ports, corresponding to outgoing and incoming traffic, respectively. Each port has eight queues with different priorities, and data packets of different priorities are buffered in different queues. During communication, when a buffer at one of the receiving end's incoming ports becomes congested, it sends a message instructing the sending end to suspend transmission of the corresponding queue. Upon receiving this message, the sending end stops transmitting traffic for the queue corresponding to its priority.

[0146] For example, explicit congestion notification (ECN) for node outgoing port caching can be applied to the RoCE v2 protocol. When congestion occurs on a network device, the network device sends a message carrying a congestion flag to the receiving server. Upon receiving the message with the congestion flag, the receiving server sends congestion notification packets (CNPs) to the sending server to notify the sending server to reduce the rate at which it sends messages, thereby alleviating congestion.

[0147] For example, a forward explicit congestion notification (FECN) is transmitted from the sender to the receiver to instruct the receiver to reduce the data transmission rate. A backward explicit congestion notification (BECN) is transmitted from the receiver to the sender to instruct the sender to reduce the data transmission rate.

[0148] It should be noted that both FECN and BECN minimize the possibility of packets being dropped (which would then have to be retransmitted) when the number of arriving packets exceeds the number of packets that can be processed.

[0149] It should be understood that the embodiments of this application are applicable to RDMA-based architectures. The above technologies are merely examples and do not constitute a limitation on the embodiments of this application. In addition, for the specific implementation methods of PFC, ECN, FECN and BECN, please refer to the relevant descriptions in the prior art, which will not be repeated here.

[0150] 2. RDMA service types

[0151] The basic communication unit of RDMA is the queue pair (QP). In the RDMA domain, the communication model based on QP is called a service type. Specifically, in the IB protocol, a service type is described through two dimensions: "reliability" and "connectivity".

[0152] Reliability refers to the use of mechanisms to ensure that sent data packets can be received normally. That is, a reliable service guarantees that information will be transmitted between the sender and receiver at most once, and that it will be received completely in the order it was sent.

[0153] RDMA can guarantee reliability through the following mechanisms:

[0154] (1) Acknowledgment Mechanism: In the reliable service type of the IB protocol, the reception of data packets is guaranteed through an acknowledgment mechanism. Specifically, after receiving a data packet, the receiving end will send an acknowledgement (ACK) message to the sending end indicating that the data packet has been received.

[0155] It should be understood that the receiving end can reply with an ACK for each received data packet individually, or it can reply with an ACK for multiple data packets at once.

[0156] (2) Data verification mechanism: The sending end determines the checksum #1 based on the data packet header and payload using a verification algorithm, and sends the checksum #1 in the data packet to the receiving end. After receiving the data packet, the receiving end determines the checksum #2 based on the data packet header and payload, and compares the checksum #1 and checksum #2. If the two are inconsistent, it means that the data received by the receiving end is incorrect, and the data packet is discarded; otherwise, it means that the data received by the receiving end is accurate, and the data packet is retained.

[0157] (3) Order Preservation Mechanism: The implementation of some services depends on the order of data packets. For example, in voice or video services, data packets need to be received in sequence to ensure accurate data presentation. The order preservation mechanism is used to ensure that the data packets sent first are received by the receiving end before the data packets sent later.

[0158] For example, in the IB protocol, packet loss is detected by packet sequence number (PSN). If the PSN of the data packets received by the receiver is not continuous, it means that an error occurred in the data packets during transmission. The receiver can send a negative acknowledgment (NAK) message to the sender, instructing the sender to retransmit the lost data packets.

[0159] Figure 4 is a schematic diagram of connection-based and packet-based data transmission applicable to embodiments of this application, with data transmission between 5 nodes as an example for illustration.

[0160] A connection refers to the one-to-one data transmission channel established between the sender and receiver for communication. As shown in Figure 4(a), when 5 nodes communicate with each other, each node needs a different QP to establish connections with the QPs of other nodes. Therefore, 20 (5*(5-1)) QPs are needed to maintain the communication channel between the 5 nodes. Context maintenance between QPs consumes network card resources, resulting in significant resource overhead.

[0161] Unlike connections, datagrams do not require a data transmission channel between the sender and receiver, and QPs are not bound to a single remote node. As shown in Figure 4(b), only 5 QPs are needed to enable communication between 5 nodes.

[0162] Therefore, based on the combination of reliable or unreliable connections or messages, RDMA can support various service types as shown in Table 1. Similarly, the service types applicable to the embodiments of this application include all of the following service types.

[0163] Table 1

[0164] 3. Token Bucket Algorithm

[0165] When a terminal device needs to send uplink data, it can inform the network device through a buffer status report (BSR) how much data is in its uplink buffer that needs to be sent. This allows the network device to allocate uplink resources to the terminal device. To reduce the number of bits transmitted over the air interface, the protocol specifies that each logical channel group (LCG) corresponds to a BSR value, and each LCG includes one or more logical channels. The division of LCGs varies depending on the vendor's implementation. Generally, the services carried on logical channels within the same LCG have similar QoS requirements. This means that a single LCG may include logical channels from different network slices, making it impossible for the network device to obtain data volume information for each network slice based on the BSR. After the terminal device reports its BSR, the network device can allocate uplink resources to the terminal device based on the BSR, but it does not specify which logical channels will use the allocated uplink resources. After obtaining the uplink resources, the terminal device can multiplex the MAC SDUs from each logical channel into MAC PDUs according to the priority of the logical channels, and then send them out through the physical layer.

[0166] In one possible implementation, the terminal device can allocate uplink resources using the token bucket algorithm.

[0167] The token bucket algorithm is a commonly used rate limiting method, which can be figuratively compared to the operation of a bucket containing "tokens". The basic idea of ​​this algorithm is to determine whether to send data to a certain logical channel (LCH) based on whether there are tokens in the token bucket and how many tokens there are, and to control the amount of data multiplexed into the MAC PDU for that logical channel.

[0168] After the transmitting device is allocated physical transmission resources, it determines which logical channels to transmit data on through the logical channel prioritization (LCP) process. The LCP process generally uses the token bucket algorithm. Specifically, network devices can configure the following parameters for each logical channel by sending configuration information (e.g., LogicalChannelConfig cells) to the terminal devices:

[0169] (1) Priority: The larger this parameter is, the lower the priority of LCH.

[0170] (2) Prioritized Bit Rate (PBR): The rate at which tokens are added to the token bucket. To avoid the problem of low-priority logical channels being unable to receive service, network devices set a PBR for each logical channel of the terminal device, with the unit being kB / s. This ensures that the terminal device limits the transmission rate of high-priority logical channels among all logical channels, so that low-priority logical channels with data transmission can receive service. In other words, if the data transmission rate of a high-priority logical channel is greater than or equal to its PBR, even if the high-priority logical channel still has data to be transmitted, the terminal device will allocate uplink resources to low-priority logical channels that have not reached their PBR.

[0171] (3) Bucket size duration (BSD): The product of BSD and PBR represents the maximum capacity of the token bucket.

[0172] The aforementioned priority, also known as logical channel priority, determines the order in which uplink resources are allocated (i.e., the order of multiplexing) when multiple logical channels are multiplexed. PBR represents the number of bytes injected into the bucket per second; BSD represents the bucket depth in milliseconds (ms). Therefore, the maximum capacity of the token bucket is PBR × BSD, which limits the total amount of data that each logical channel can cache, but this does not represent the maximum uplink bit rate of that logical channel. It should be understood that the above configuration information is for logical channels; that is, one configuration information corresponds to one logical channel, and each logical channel has its own priority, PBR, and BSD, as well as its own token bucket.

[0173] The terminal device receives the configuration information sent by the network device, determines the priority, PBR, and BSD of each logical channel, and allocates uplink resources based on the token bucket algorithm according to the priority from high to low. It should be understood that this application only illustrates one possible implementation; the specific implementation and steps may differ, and this application does not limit the scope of the implementation.

[0174] For example, the terminal device can allocate uplink resources to each logical channel based on its priority bit rate, in descending order of priority, until one of the following conditions is met: all logical channels are allocated uplink resources, or uplink resources are exhausted. Assume there are M logical channels, where M is an integer greater than or equal to 1. Each of these M logical channels corresponds to a token bucket, meaning each logical channel has its own priority, PBR, and BSD.

[0175] Taking logical channel j as an example, j∈{1,2,…,M}, logical channel j corresponds to token bucket j, and the terminal device can maintain a variable B for logical channel j. j This variable indicates the number of tokens currently available in token bucket j, with each token corresponding to 1 byte of data. j Initialize to 0 when logical channel j is established, B j The value cannot exceed the maximum capacity of the token bucket (PBR). j ×BSD j (assuming PBR) j 8kBps, BSD j =500ms, maximum capacity is 8kBps × 500ms = 4k Bytes). When there is uplink data to be transmitted, the terminal device can execute the token bucket algorithm to allocate uplink resources, that is, multiplex the SDU into the PDU.

[0176] In the token bucket algorithm, B j The value of B reflects the relative relationship between the actual data transmission rate of the LCH and the PBR. j When B is negative, it indicates that the actual rate of the LCH is greater than that of the PBR; when B j Reaching the maximum indicates token overflow, meaning the actual rate of the LCH is less than that of the PBR.

[0177] 4. Round-trip time (RTT)

[0178] RTT (Round-Trip Time) refers to the time elapsed from when the sender transmits data to when the sender receives an acknowledgment message from the receiver. RTT latency is typically determined by three factors: the propagation time of the link, the processing time of the end system, and the buffering and queuing time of intermediate network nodes such as routers. Under normal circumstances, the transmission time and application processing time of a message are relatively fixed, but RTT fluctuations occur under network congestion. It should be understood that RTT reflects the speed and stability of data transmission in the network. A shorter RTT indicates faster data transmission and better network performance. Conversely, a longer RTT may indicate network congestion or performance problems.

[0179] Based on the communication system architecture shown in Figure 1, in data transmission based on RDMA technology, traffic control can be achieved through traffic policing in QoS to avoid problems such as packet loss caused by network congestion. QoS traffic policing uses a token bucket, smoothly controlling traffic based on token bucket parameters (such as BSD and PBR). However, if the token bucket parameter is set too small, the link bandwidth cannot be fully utilized; if the token bucket parameter is set too large, it will bring network congestion, packet loss, and retransmission risks.

[0180] In view of this, embodiments of this application provide a flow control method that can achieve flexible control of uplink flow, thereby making full use of link bandwidth and avoiding congestion.

[0181] The technical solution provided in this application will be described in detail below with reference to the accompanying drawings.

[0182] Figure 5 is a schematic diagram of a flow control method 500 applicable to an embodiment of this application.

[0183] The flow control method of this application can be applied between network devices, as well as between terminal devices and network devices. The network device can be a base station device, or a component within a base station device (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the base station device; the network device can also be a UPF network element, or a component within a UPF network element (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the UPF network element; the network device can also be an SMF network element, or a component within an SMF network element (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the SMF network element. The terminal device can be a terminal device, or a component within a terminal device (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the terminal device.

[0184] Without loss of generality, the communication method provided in the embodiments of this application will be described in detail below, taking the first device as the executing entity.

[0185] For example, in method 500, the first device is a base station device, the second device is a UPF network element, the third device is a terminal device, and the fourth device is an SMF network element.

[0186] Method 500 may include the following steps:

[0187] S501: Obtain the first delay.

[0188] Wherein, the first delay is the round-trip delay between the second device and the third device, and the third device communicates with the second device through the first device.

[0189] Specifically, the first delay can be obtained in the following way:

[0190] Method 1

[0191] The first device can determine the first delay based on the second delay, the third delay, and the fourth delay.

[0192] Wherein, the second delay is the uplink air interface delay between the third device and the first device, the third delay is the downlink air interface delay between the third device and the first device, and the fourth delay is the round-trip delay between the first device and the second device.

[0193] For example, the first delay = the second delay + the third delay + the fourth delay.

[0194] Optionally, before determining the first delay based on the second delay, the third delay, and the fourth delay, the method 500 may further include steps S501b and S501c:

[0195] S501b: Send the second message.

[0196] Specifically, the first device can send a second message to the second device; correspondingly, the second device receives the second message from the first device. The second message is used to instruct the sampling of delay information between the first device and the second device.

[0197] It should be noted that the specific content of the second message will be further explained in step S605 of method 600 in conjunction with Table 2, and will not be detailed here.

[0198] S501c: Receive third message.

[0199] Specifically, the second device can send a third message to the first device; correspondingly, the first device receives the third message from the second device. The first device can determine the statistical results of the time delay information between the first device and the second device based on the third message.

[0200] It should be noted that the specific content of the third message will be further explained in step S606 of method 600 in conjunction with Table 3, and will not be detailed here.

[0201] Specifically, the third message may include a first moment, a second moment, and a third moment, and the first device may determine a fourth moment and the fourth delay based on the third message.

[0202] The first moment is when the first device sends the second message, the second moment is when the second device receives the second message, the third moment is when the second device sends the third message, and the fourth moment is when the first device receives the third message.

[0203] Optionally, the relationship between the fourth time delay and the first, second, third, and fourth time points satisfies: RTT4=(T4-T3)+(T2-T1)

[0204] Where RTT4 represents the fourth time delay, T1 represents the first time point, T2 represents the second time point, T3 represents the third time point, and T4 represents the fourth time point.

[0205] In this scenario, the first delay is determined by the first device itself, which triggers the measurement and calculation of the fourth delay to obtain the round-trip delay between the first and second devices. Specifically, the first device determines the first delay based on the acquired second, third, and fourth delays. This approach reduces the signaling overhead incurred when the second device determines the first delay, as the first device needs to send the second and third delays to the second device, and the second device also needs to send the determined first delay to the first device. This improves the flexibility of the first device in obtaining network information (first and / or fourth delays) and further enhances the efficiency of flow control.

[0206] Method 2

[0207] The first device can receive the first delay.

[0208] Specifically, the first device can receive a first delay from the second device; correspondingly, the second device can send the first delay to the first device.

[0209] Optionally, before receiving the first delay, the method may further include steps S501d and S501e:

[0210] S501d: Receive the fourth message.

[0211] Specifically, the second device can send a fourth message to the first device; correspondingly, the first device receives the fourth message from the second device. The fourth message is used to instruct the sampling of delay information between the first device and the second device.

[0212] It should be noted that the specific content of the fourth message will be further explained in step S705 of method 700 in conjunction with Table 4, and will not be detailed here.

[0213] S501e: Send the fifth message.

[0214] Specifically, the first device can send a fifth message to the second device; correspondingly, the second device receives the fifth message from the first device. The second device can determine the statistical results of the latency information between the first device and the second device based on the fifth message.

[0215] It should be noted that the specific content of the fifth message will be further explained in step S706 of method 700 in conjunction with Table 5, and will not be detailed here.

[0216] Specifically, the fifth message includes the second delay, the third delay, the fifth moment, the sixth moment, and the seventh moment. The second device can determine the eighth moment and the first delay based on the fifth message.

[0217] The fifth moment is when the second device sends the fourth message, the sixth moment is when the first device receives the fourth message, the seventh moment is when the first device sends the fifth message, and the eighth moment is when the second device receives the fifth message.

[0218] Optionally, the relationship between the first and second time delays, the third time delay, the fifth time point, the sixth time point, the seventh time point, and the eighth time point satisfies: RTT1=(X1+X2)+(T4-T3)+(T2-T1)

[0219] Where RTT1 represents the first delay, X1 represents the second delay, X2 represents the third delay, T5 represents the fifth time point, T6 represents the sixth time point, T7 represents the seventh time point, and T8 represents the eighth time point.

[0220] In this scenario, the first delay is determined by the second device. The second device can directly reuse the measurement process and indication signaling used in the QoS traffic policing process to determine the round-trip delay between the second device and the third device, which reduces the computational and signaling overhead of the second device in determining the first delay to a certain extent.

[0221] It should be noted that, for the above two implementation methods, when the N QoS flows between the second device and the third device share the same Infinite Resource Bearer (DRB), the first delay can be the average, maximum, minimum, or weighted average of the round-trip delays of the N QoS flows.

[0222] In this scenario, since data from multiple QoS streams can be mapped to a single logical channel, determining the first delay of the logical channel based on the round-trip delay between the third and second devices measured from the multiple QoS streams corresponding to that logical channel allows for a more accurate determination of the token bucket parameters adapted to that logical channel, thereby guiding uplink data transmission.

[0223] In addition, based on the above two methods, the first delay can be determined by the first device itself, or it can be determined by the second device and sent to the first device, which improves the flexibility of the first device in obtaining network information (first delay and / or fourth delay).

[0224] Optionally, before the base station device performs step S501, method 500 may further include step S501a: sending a first message.

[0225] The first message is used to instruct the activation of latency monitoring between the second device and the third device.

[0226] It should be noted that the first message can be sent directly from the first device to the second device; alternatively, it can be sent from the first device to a fourth device (e.g., an SMF network element), and then the fourth device sends a corresponding message to the second device, thereby instructing the second device to enable latency monitoring between the second device and the third device; or, it can be sent from the first device to at least one other device, and then the at least one other device sends corresponding instruction information to the second device. It should be understood that the embodiments of this application only provide functional limitations on the first message and do not constitute a limitation on the receiving end of the first message.

[0227] In this scenario, the first device initiates latency monitoring to obtain network information. The first device can directly request the second device, or it can request the second device through the fourth device, to enable real-time monitoring of the latency of the service flow between the second device and the third device. This eliminates the need to enable latency monitoring through the operation and maintenance system or external AF network elements, thereby improving the flexibility of traffic control and reducing the signaling overhead of having other devices instruct the activation of latency monitoring.

[0228] S502: Determine the token bucket parameters based on the first delay, the first rate, and / or the second rate.

[0229] The token bucket parameter is used to instruct the third device to perform uplink data transmission. The first rate is the maximum flow bit rate (MFBR) between the second device and the third device, and the second rate is the guaranteed flow bit rate (GFBR) between the second device and the third device.

[0230] Optionally, the token bucket parameters include: Priority Bit Rate (PBR) and Bucket Size Duration (BSD).

[0231] In addition, the determination of the token bucket parameters based on the first delay, the first rate, and / or the second rate may also include the following determination methods:

[0232] In one possible implementation, the BSD is determined based on the first delay.

[0233] For example, when N QoS flows between the second device and the third device share the same DRB, the BSD is the average, maximum, minimum, or weighted average of the round-trip delay (first delay) of the N QoS flows.

[0234] In this scenario, since data from multiple QoS flows can be mapped to a single logical channel, determining the BSD (Block Default Speed) of that logical channel based on the round-trip delay between the third and second devices measured from the multiple QoS flows corresponding to that logical channel allows for a more accurate adaptation of the determined BSD to the actual network conditions of that logical channel, enabling flexible flow control. This avoids problems such as underutilization of link bandwidth or network congestion caused by improper BSD settings.

[0235] In one possible implementation, the PBR is determined based on either the first rate or the second rate.

[0236] For example, when N QoS flows between the second device and the third device share the same DRB, the PBR is the average, maximum, minimum, or weighted average of the first or second rate of the N QoS flows.

[0237] In one possible implementation, the PBR is determined based on the first delay and the first rate.

[0238] For example, when N QoS flows between the second device and the third device share the same DRB, each QoS flow corresponds to an MFBR. i (i∈[1,N], where N is a positive integer). Among them, PBR, BSD, and MFBR... i and RTT1 i satisfy:

[0239] Where N represents the number of QoS flows, N is a positive integer, and RTT1 i MFBR represents the round-trip delay (first delay) between the terminal device and the UPF for the i-th QoS flow in N QoS flows. i This represents the first rate of the i-th QoS flow in N QoS flows. As mentioned above, BSD is determined based on the round-trip delay (first delay) between the terminal device and the UPF.

[0240] In one possible implementation, the PBR is determined based on the first delay and the second rate.

[0241] For example, when N QoS flows between the second device and the third device share the same DRB, each QoS flow corresponds to a GFBR. i (i∈[1,N], where N is a positive integer). Among them, PBR, BSD, and GFBR... i and RTT1 i satisfy:

[0242] Where N represents the number of QoS flows, N is a positive integer, and RTT1 i GFBR represents the round-trip delay (first delay) between the terminal device and the UPF for the i-th QoS flow in N QoS flows. i This represents the second rate of the i-th QoS flow in N QoS flows. As mentioned above, BSD is determined based on the round-trip delay (first delay) between the terminal device and the UPF.

[0243] In this scenario, since data from multiple QoS flows can be mapped to a single logical channel, the PBR of that logical channel can be determined based on the first or second rate of each QoS flow. Alternatively, the round-trip time (RTT) between the third and second devices can be measured using the multiple QoS flows corresponding to the logical channel, and the PBR can be determined based on the RTT and the first or second rate of each QoS flow. This approach associates PBR determination with link status, enabling the determined PBR to more accurately adapt to the actual network conditions of the logical channel, thus achieving flexible flow control. It avoids problems such as underutilization of link bandwidth or network congestion caused by improper PBR settings.

[0244] S503: Send the token bucket parameters.

[0245] Specifically, the first device sends token bucket parameters to the third device; correspondingly, the third device receives token bucket parameters from the first device, which are determined based on a first delay, a first rate, and / or a second rate. After receiving the token bucket parameters, the third device can determine which logical channels to place data on, and how much data to place on each logical channel, based on the number of shared logical channels in the uplink resource grant indication, the token bucket parameters of the logical channels, and the priority of the logical channels, combined with the token bucket algorithm. That is, the third device can perform uplink data transmission based on the token bucket algorithm and the token bucket parameters, where the token bucket parameters can be used by the terminal device to determine the amount of data that can be transmitted on a logical channel based on the uplink grant. For details on the token bucket algorithm, please refer to relevant descriptions in the prior art; this application does not limit the scope of the embodiments.

[0246] In this scenario, the third device allocates uplink data based on token bucket parameters, which are determined and distributed by the first device. Therefore, linking the token bucket parameter determination process to the link status, and determining the token bucket parameters based on link latency and / or traffic rate, guides the third device in uplink data transmission. This enables flexible flow control, allowing transmitted packets to better match link capacity. It avoids situations where the token bucket parameter is set too low, resulting in insufficient packet transmission and underutilization of link bandwidth; or when the token bucket parameter is set too high, leading to excessive packet transmission, network congestion, increased packet waiting latency, or packet loss causing retransmissions.

[0247] Figure 6 is a schematic diagram of a flow control method 600 applicable to an embodiment of this application.

[0248] S601: The base station device sends message #1 to the SMF; correspondingly, the SMF receives message #1 from the base station device.

[0249] Specifically, message #1 is used to instruct the SMF to start latency monitoring (or, it can also be understood as message #1 being used to send a request to the SMF to start latency monitoring), and the latency monitoring refers to real-time monitoring of the latency of the service flow between the terminal device and the UPF.

[0250] It should be understood that after receiving message #1, the SMF initiates the latency monitoring. Specifically, the process of initiating latency monitoring may include steps S602 and S603.

[0251] S602: The SMF sends message #2 to the base station device; correspondingly, the base station device receives message #2 from the SMF.

[0252] Specifically, message #2 is used to instruct the base station equipment to start latency monitoring (or, it can also be understood as message #2 being used to send a request to the base station equipment to start latency monitoring), and the latency monitoring means real-time monitoring of the latency of the service flow between the terminal equipment and the UPF.

[0253] Optionally, message #2 can be sent by the SMF to the base station device via the AMF. For example, message #2 can be included in the response message sent to the base station device when the SMF creates a session.

[0254] For example, when a terminal device initiates a PDU session establishment request, the request first reaches the AMF through the base station equipment. After receiving the request, the AMF can select a suitable SMF instance to handle the session request according to the PCF's policy. After receiving the session establishment request from the AMF, the SMF will perform processing such as verifying the request information, determining session parameters, and selecting a UPF. After processing, it will notify the AMF of the session establishment result (e.g., whether the session establishment was successful, session ID, IP address allocation, etc.). The AMF then transmits the session establishment result to the base station so that the base station can correctly configure the data forwarding path. Applicable to the embodiments of this application, the session establishment result may also include message #2.

[0255] S603: SMF sends message #3 to UPF; correspondingly, UPF receives message #3 from SMF.

[0256] Specifically, message #3 is used to instruct the UPF to start latency monitoring (or, it can also be understood as message #3 being used to send a request to the UPF to start latency monitoring), and the latency monitoring means real-time monitoring of the latency of the service flow between the terminal device and the UPF.

[0257] It should be noted that the embodiments of this application only provide functional limitations for messages #1, #2 and #3, and do not limit the specific message structure of the messages. That is, messages #1, #2 and #3 can be completely identical messages, or they can be messages with different signaling formats or contents, but with the same function (all used to indicate the activation of latency monitoring between the terminal device and the UPF).

[0258] It should be noted that step S603 may occur after step S602; or simultaneously with step S602; or before step S602. The timing of step S603 is not limited in this embodiment.

[0259] S604: Base station equipment determines delay #1 and delay #2.

[0260] Specifically, delay #1 is the air interface uplink delay between the terminal device and the base station device, and delay #2 is the air interface downlink delay between the terminal device and the base station device.

[0261] For example, the delay #1 and delay #2 can be measured using the timestamps of radio frames, subframes, and their time slot offsets. For instance, when the various protocol layers (such as PDCP, RLC, MAC, etc.) of a base station device are located within the same site as the physical layer and can sense each other's time information, timestamps can be recorded during data packet transmission and reception, and the difference between the timestamps can be used to obtain delay #1 and delay #2. For specific methods of determining delay #1 and delay #2, relevant content in the prior art can be referenced, and this application does not limit them here.

[0262] It should be noted that in step S602, after the base station device receives the message from the SMF, it can start sampling delay #1 and delay #2. In other words, step S604 is located after step S602, but the order of steps S603 and S604 is not limited in this embodiment.

[0263] It should be understood that after both the base station equipment and the UPF have enabled latency monitoring of the service flow between the terminal equipment and the UPF, the base station equipment can interact with the UPF through the N3 interface. The base station equipment encapsulates uplink data packets using GTP-U and sends them to the UPF. The UPF processes the data packets and then encapsulates downlink data packets using GTP-U and sends them back to the base station equipment. During this process, the base station equipment can monitor the performance of the GTP-U tunnel (such as latency).

[0264] Specifically, refer to steps S605 to S608.

[0265] S605: The base station device sends message #4 to the UPF; correspondingly, the UPF receives message #4 from the base station device.

[0266] Specifically, message #4 is used to instruct the sampling of delay information between the base station equipment and the UPF.

[0267] For example, message #4 transmits PDU session information for uplink data packets. The information element fields involved in its PDU session information frame are shown in Table 2. The GTPU header carries a QoS flow monitoring packet (QMP) tag and adds uplink PDU session information (UL PDU session information).

[0268] The following descriptions can be used to refer to the contents of each field in Table 2:

[0269] (1) PDU Type: The PDU type can be located in bits 4 to 7 of the first octet of the PDU session information frame, used to indicate the structure of the PDU session UP frame. This field uses the value of the PDU type it identifies (for example, in existing protocols, PDU type (=0) represents downlink PDU session information, and PDU type (=1) represents uplink PDU session information). Applicable to the embodiments of this application, PDU type (=3) represents uplink PDU session information.

[0270] (2) QMP tag: The QMP tag can be located in the 3rd bit of the first octet of the PDU session information frame, indicating that the information frame is used to monitor QoS flow.

[0271] (3) Reserved bits: Bits 0 to 2 of the first octet and bits 6 to 7 of the second octet of the PDU session information frame can be reserved bits.

[0272] Optionally, the base station device can set this field to "0", and the UPF may choose not to interpret this field and reserve it for use in subsequent versions.

[0273] (4) QoS flow identifier (QFI): The QFI can be located in the 0th to 5th bits of the second octet of the PDU session information frame. It is used to indicate the QoS flow to which the transmitted data packet belongs. The QoS flow is uniquely determined by the QoS flow identifier.

[0274] (5) Uplink transmission timestamp: The uplink transmission timestamp can occupy 0 or 8 octets to represent the 64-bit timestamp generated by the base station equipment when encoding the uplink data packet.

[0275] (6) Uplink QFI sequence number: The uplink QFI sequence number can occupy 0 or 3 octets to represent the sequence number assigned by the UPF or base station equipment.

[0276] (7) Padding bits: Padding bits can occupy 0 to 3 octets to fill the end of the frame to ensure that the PDU session user plane protocol PDU length (including padding and future extension) is (n×4-2) octets, where n is a positive integer.

[0277] Table 2

[0278] It should be understood that the names of the above fields are only used to indicate the corresponding functions, and the specific names of the above fields are not limited in the embodiments of this application.

[0279] S606: The UPF sends message #5 to the base station equipment; correspondingly, the base station equipment receives message #5 from the UPF.

[0280] Specifically, the base station equipment can use message #5 to determine the statistical results of the latency information between the base station equipment and the UPF.

[0281] For example, message #5 transmits PDU session information for downlink data packets. The information element fields involved in its PDU session information frame are shown in Table 3. The GTPU header carries the QMP flag and adds downlink PDU session information.

[0282] For information about the fields in Table 3, please refer to the following description:

[0283] (1) PDU Type: The PDU type can be located in bits 4 to 7 of the first octet of the PDU session information frame, used to indicate the structure of the PDU session UP frame. This field uses the value of the PDU type it identifies (for example, in existing protocols, PDU type (=0) represents downlink PDU session information, and PDU type (=1) represents uplink PDU session information). Applicable to the embodiments of this application, PDU type (=2) represents downlink PDU session information.

[0284] (2) QMP tag: The QMP tag can be located in the 3rd bit of the first octet of the PDU session information frame, indicating that the information frame is used to monitor QoS flow.

[0285] (3) Sequence number presence (SNP): SNP can be located in the 0th and 2nd bits of the first octet of the PDU session information frame. It is used to indicate whether a downlink QFI sequence number exists in the downlink PDU session information frame or whether an uplink QFI sequence number exists in the uplink PDU session information frame.

[0286] (4) Multimedia Broadcast Service (MBS) sequence number presence (MSNP): MSNP can be located in the first bit of the first octet of the PDU session information frame and is used to indicate whether a downlink MBS QFI sequence number exists in the downlink PDU session information frame.

[0287] (5) Paging policy presence (PPP): PPP can be located in the 7th bit of the second octet of the PDU session information frame to indicate support for the paging policy indicator (PPI).

[0288] (6) Reflective QoS indicator (RQI): RQI can be located in the 6th bit of the second octet of the PDU session information frame to indicate that downlink packets support reflective QoS.

[0289] (7) QoS Flow Identifier: The QoS Flow Identifier can be located in the 0th to 5th bits of the second octet of the PDU session information frame. It is used to indicate the QoS flow to which the transmitted data packet belongs. The QoS flow is uniquely determined by the QoS Flow Identifier.

[0290] (8) PPI: PPI can occupy 0 or 1 octets to set the parameters for distinguishing the paging strategy to be applied.

[0291] Optionally, when the QFI field contains an indicator object, the PPI occupies bits 6 and 7 of an octet.

[0292] (9) Downlink N3 / N9 Delay Ind.: It can occupy 0 or 1 octet (when occupying 1 octet, it can occupy one of the 0th to 5th bits of the octet) to indicate whether the PDU session information frame indicates downlink N3 / N9 delay information.

[0293] (10) Uplink N3 / N9 Delay Ind.: It can occupy 0 or 1 octet (when occupying 1 octet, it can occupy one of the 0th to 5th bits of the octet) to indicate whether the PDU session information frame indicates uplink N3 / N9 delay information.

[0294] (11) Reserved bits: can occupy 0 or 1 octet (when occupying 1 octet, three of the 0th to 5th bits of the octet can be occupied).

[0295] (12) Uplink retransmission timestamp: The uplink retransmission timestamp can occupy 0 or 8 octets to represent the 64-bit timestamp generated when the base station equipment encodes the uplink data packet.

[0296] Specifically, the timestamps for encoding uplink data packets by the base station equipment can be generated periodically, so this field can include multiple timestamp information.

[0297] (13) Uplink receive timestamp: The uplink receive timestamp can occupy 0 or 8 octets to represent the 64-bit timestamp generated when the UPF receives a data packet.

[0298] (14) Downlink transmission timestamp: The downlink transmission timestamp can occupy 0 or 8 octets to represent the 64-bit timestamp generated when the UPF encoded data packet is sent.

[0299] (15) Downlink N3 / N9 delay results: The downlink N3 / N9 delay results can occupy 0 or 4 octets to represent the downlink delay measurement results of N3 / N9.

[0300] Specifically, when the "Downlink N3 / N9 Delay Indication Information" field indicates that the PDU session information frame indicates downlink N3 / N9 delay information, the "Downlink N3 / N9 Delay Result" field indicates the downlink delay measurement result of N3 / N9 (occupying 4 octets); when the "Downlink N3 / N9 Delay Indication Information" field indicates that the PDU session information frame does not indicate downlink N3 / N9 delay information, the "Downlink N3 / N9 Delay Result" field occupies 0 octets.

[0301] (16) Uplink N3 / N9 delay results: can occupy 0 or 4 octets to represent the uplink delay measurement results of N3 / N9.

[0302] Specifically, when the "Uplink N3 / N9 Delay Indication Information" field indicates that the PDU session information frame indicates uplink N3 / N9 delay information, the "Uplink N3 / N9 Delay Result" field indicates the uplink delay measurement result of N3 / N9 (occupying 4 octets); when the "Uplink N3 / N9 Delay Indication Information" field indicates that the PDU session information frame does not indicate uplink N3 / N9 delay information, the "Uplink N3 / N9 Delay Result" field occupies 0 octets.

[0303] (17) Downlink QFI sequence number: The downlink QFI sequence number can occupy 0 or 3 octets to represent the sequence number assigned by the UPF or base station equipment.

[0304] (18) New IE Flags: Can occupy 0 or 1 octet, used to indicate which new IE flags exist after the new IE flag IE. The last bit of the new IE flag is used as an extension flag to allow for future extensions of the new IE flags. For example, new IE flag 0 indicates whether new IE 1 exists, and new IE flag 1 indicates whether new IE 2 exists.

[0305] Table 3

[0306] It should be understood that the names of the above fields are only used to indicate the corresponding functions, and the specific names of the above fields are not limited in the embodiments of this application.

[0307] As shown in the table above, the base station equipment can obtain time #1, time #2 and time #3 from message #5. After receiving message #5, the base station equipment can also determine time #4 based on message #5 (that is, the statistical results of the delay information between the base station equipment and the UPF include time #1, time #2, time #3 and time #4).

[0308] In this context, time #1 represents the time when the base station device sends message #4 to the UPF, time #2 represents the time when the UPF receives message #4, time #3 represents the time when the UPF sends message #5 to the base station device, and time #4 represents the time when the base station device receives message #5.

[0309] Optionally, since the "uplink retransmission timestamp" field can include multiple timestamp information, the base station equipment also needs to determine which time #1 in the "uplink retransmission timestamp" field is associated with time #2 and time #3.

[0310] S607: Base station equipment determines the round-trip delay between the terminal equipment and the UPF #1.

[0311] Specifically, the round-trip delay #1 between the terminal device and the UPF can be determined based on the round-trip delay #2 between the terminal device and the base station device and the round-trip delay #3 between the UPF and the base station device.

[0312] For example, round-trip delay #1 = round-trip delay #2 + round-trip delay #3.

[0313] Optionally, the round-trip delay #1 between the terminal device and the base station device can be determined based on delay #1 and delay #2.

[0314] For example, round-trip delay #1 = delay #1 + delay #2.

[0315] Optionally, the round-trip delay #3 between the UPF and the base station equipment can be determined based on time #1, time #2, time #3 and time #4.

[0316] For example, round-trip time delay #3 = (time #4 - time #3) + (time #2 - time #1).

[0317] Optionally, the round-trip delay #1 between the terminal device and the UPF can be determined based on delay #1, delay #2, time #1, time #2, time #3 and time #4.

[0318] For example, the relationship between the round-trip time #1, delay #1, delay #2, time #1, time #2, time #3, and time #4 between the terminal device and the UPF satisfies: RTT#1=X1+X2+(T4-T3)+(T2-T1)

[0319] Where RTT#1 represents round-trip delay #1, X1 represents delay #1, X2 represents delay #2, T1 represents time #1, T2 represents time #2, T3 represents time #3, and T4 represents time #4.

[0320] S608: The base station equipment determines the token bucket parameters of the terminal based on the round-trip delay #1.

[0321] Specifically, the token bucket parameters include Priority Bit Rate (PBR) and Bucket Size Duration (BSD). The meanings of PBR and BSD can be found in the terminology section above, and are not limited herein.

[0322] Optionally, when N QoS flows are mapped to one DRB (i.e., N QoS flows share the same DRB, where N is a positive integer), since the base station equipment can determine the latency information statistics for each QoS flow separately (i.e., the base station equipment can determine the time #1, time #2, time #3, and time #4 corresponding to each QoS flow separately), the round-trip time (RTT #1) between the terminal device and the UPF corresponding to the i-th QoS flow among the N QoS flows can be obtained. i (i∈[1,N]), the round-trip time #1 between the terminal device and the UPF can be determined according to the RTT#1. i Sure.

[0323] For example, the round-trip time #1 between the terminal device and the UPF can be the RTT #1 of the N QoS flows. i The average, maximum, minimum, or weighted average, etc.

[0324] Alternatively, BSD can determine the round-trip time #1 between the terminal device and the UPF.

[0325] For example, when N QoS flows are mapped to 1 DRB (N is a positive integer), the base station device can determine the BSD based on the round-trip delay #1 of the N QoS flows associated with the logical channel.

[0326] For example, the round-trip latency #1 for BSD and N QoS streams can satisfy:

[0327] Where N represents the number of QoS flows, N is a positive integer, and RTT#1 i #1 represents the round-trip delay between the terminal device and the UPF in the i-th QoS flow of N QoS flows.

[0328] For example, the round-trip latency #1 of BSD and N QoS flows can also satisfy: BSD = max{RTT#11, RTT#12, ..., RTT#1 N}

[0329] For example, the round-trip latency #1 of BSD and N QoS streams can also satisfy: BSD = min{RTT#11, RTT#12, ..., RTT#1} N}

[0330] For example, BSD can be the RTT#1 for the N QoS streams. i The weighted average and other calculation results.

[0331] Optionally, the PBR can be determined based on the MFBR. Since the MFBR limits the highest bit rate that can be expected to be provided by QoS flows, when data traffic exceeds the MFBR, the network may take measures such as dropping excess traffic or delaying transmission to avoid network congestion. Therefore, when N QoS flows are mapped to one DRB (N is a positive integer), each QoS flow corresponds to an MFBR. i (i∈[1,N]), the base station equipment can determine the PBR based on the MFBR of N QoS flows.

[0332] For example, PBR can be the MFBR of the N QoS flows. i The average, maximum, minimum, or weighted average, etc.

[0333] Alternatively, the PBR can also be determined based on the GFBR.

[0334] For example, when N QoS flows are mapped to one DRB (N is a positive integer), the PBR can be the average, maximum, minimum, or weighted average of the GFBRi of the N QoS flows.

[0335] Alternatively, PBR can also be determined based on round-trip delay #1 and MFBR.

[0336] For example, when N QoS flows are mapped to one DRB (N is a positive integer), PBR, BSD, and MFBR... i and RTT#1 i satisfy:

[0337] Where N represents the number of QoS flows, N is a positive integer, and RTT#1 i #1 represents the round-trip delay between the terminal device and the UPF in the i-th QoS flow of N QoS flows, MFBR i This represents the MFBR of the i-th QoS flow in N flows. The BSD, as mentioned above, is determined based on the round-trip delay #1 between the terminal device and the UPF.

[0338] Alternatively, PBR can also be determined based on round-trip delay #1 and GFBR.

[0339] For example, when N QoS flows are mapped to one DRB (N is a positive integer), PBR, BSD, and GFBR... i and RTT#1 i satisfy:

[0340] Where N represents the number of QoS flows, N is a positive integer, and RTT#1 i #1 represents the round-trip delay between the terminal device and the UPF in the i-th QoS flow of N QoS flows. i This represents the GFBR of the i-th QoS flow in N QoS flows. The BSD, as mentioned above, is determined based on the round-trip delay #1 between the terminal device and the UPF.

[0341] S609: The base station device sends token bucket parameters to the terminal; correspondingly, the terminal device receives the token bucket parameters sent by the base station device.

[0342] The token bucket parameter is used to instruct the terminal device to perform uplink data transmission.

[0343] Specifically, after receiving the token bucket parameters, the terminal device can determine which logical channels to place data on, and how much data to place on each logical channel, based on the number of shared logical channels in the uplink resource grant indication, the token bucket parameters of the logical channels, and the priority of the logical channels, in conjunction with the token bucket algorithm. That is, the terminal device can perform uplink flow control based on the token bucket algorithm and the token bucket parameters, whereby the token bucket parameters can be used by the terminal device to determine the amount of data that a logical channel can transmit based on the uplink grant. For details on the token bucket algorithm, please refer to relevant descriptions in the prior art; this application does not limit its implementation.

[0344] Based on the above scheme, the token bucket parameter is determined in association with the link status. By determining the token bucket parameter according to the link latency and / or traffic rate, the token bucket parameter can be more accurately adapted to the actual network conditions of the logical channel. This better guides the terminal device in uplink data transmission, allowing the transmitted packets to better match the link capacity and achieve flexible flow control. It avoids situations where the token bucket parameter is set too low, resulting in insufficient packet transmission and underutilization of link bandwidth; or where the token bucket parameter is set too high, leading to excessive packet transmission, network congestion, increased packet waiting latency, or packet loss causing retransmissions.

[0345] Figure 7 is a schematic diagram of a flow control method 700 applicable to an embodiment of this application.

[0346] S701: The base station device sends message #1 to the SMF; correspondingly, the SMF receives message #1 from the base station device.

[0347] It should be understood that after receiving message #1, the SMF initiates the latency monitoring. Specifically, the process of initiating latency monitoring may include steps S702 and S703.

[0348] S702: The SMF sends message #2 to the base station equipment; correspondingly, the base station equipment receives message #2 from the SMF.

[0349] S703: SMF sends message #3 to UPF; correspondingly, UPF receives message #3 from SMF.

[0350] It should be noted that step S703 may occur after step S702; or simultaneously with step S702; or before step S702. The timing of step S703 is not limited in the embodiments of this application.

[0351] S704: Base station equipment determines delay #1 and delay #2.

[0352] It should be noted that in step S702, after the base station equipment receives the message from the SMF, it can start sampling delay #1 and delay #2. In other words, step S704 is located after step S702, but the order of steps S703 and S704 is not limited in this embodiment.

[0353] It should be noted that the specific content of steps S701 to S704 can be found in the relevant description of steps S601 to S604 in method 600, and will not be repeated here.

[0354] It should be understood that after both the base station equipment and the UPF have enabled latency monitoring of the service flow between the terminal equipment and the UPF, the UPF can interact with the base station equipment through the N3 interface. The UPF encapsulates downlink data packets using GTP-U and sends them to the network equipment. The network equipment processes the data and then encapsulates uplink data packets using GTP-U and sends them to the UPF. During this process, the UPF can monitor the performance of the GTP-U tunnel (such as latency).

[0355] Specifically, refer to steps S705 to S708.

[0356] S705: The UPF sends message #6 to the base station equipment; correspondingly, the base station equipment receives message #6 from the UPF.

[0357] Specifically, message #6 is used to sample latency information between the base station equipment and the UPF.

[0358] For example, message #6 transmits PDU session information for downlink data packets. The information element fields involved in its PDU session information frame are shown in Table 4. The GTPU message header carries the QMP tag.

[0359] For information about the fields in Table 4, please refer to the following description:

[0360] (1) PDU Type: The PDU type can be located in bits 4 to 7 of the first octet of the PDU session information frame, used to indicate the structure of the PDU session UP frame. This field uses the value of the PDU type it identifies. Applicable to the embodiments of this application, the PDU type (=0) indicates downlink PDU session information.

[0361] (2) QMP tag: The QMP tag can be located in the 3rd bit of the first octet of the PDU session information frame, indicating that the information frame is used to monitor QoS flow.

[0362] (3) SNP: SNP can be located in the second bit of the first octet of the PDU session information frame, and is used to indicate whether there is a downlink QFI sequence number in the downlink PDU session information frame or whether there is an uplink QFI sequence number in the uplink PDU session information frame.

[0363] (4) Reserved bits: Bits 0 to 1 of the first octet of the PDU session information frame can be reserved bits.

[0364] Optionally, the base station device can set this field to "0", and the UPF may choose not to interpret this field and reserve it for use in subsequent versions.

[0365] (5) PPP: PPP can be located in the 7th bit of the second octet of the PDU session information frame to indicate support for the paging policy indicator (PPI).

[0366] (6) RQI: RQI can be located in the 6th bit of the second octet of the PDU session information frame to indicate that the downlink data packet supports reflection QoS.

[0367] (7) QoS flow identifier (QFI): The QFI can be located in the 0th to 5th bits of the second octet of the PDU session information frame. It is used to indicate the QoS flow to which the transmitted data packet belongs. The QoS flow is uniquely determined by the QoS flow identifier.

[0368] (8) Downlink transmission timestamp: The downlink transmission timestamp can occupy 0 or 8 octets to represent the 64-bit timestamp generated by the base station equipment when encoding the downlink data packet.

[0369] (6) Downlink QFI sequence number: The downlink QFI sequence number can occupy 0 or 3 octets to represent the sequence number assigned by the UPF or base station equipment.

[0370] (7) Padding bits: Padding bits can occupy 0 to 3 octets to fill the end of the frame to ensure that the PDU session user plane protocol PDU length (including padding and future extension) is (n×4-2) octets, where n is a positive integer.

[0371] Table 4

[0372] It should be understood that the names of the above fields are only used to indicate the corresponding functions, and the specific names of the above fields are not limited in the embodiments of this application.

[0373] S706: The base station device sends message #7 to the UPF; correspondingly, the UPF receives message #7 from the base station device.

[0374] Specifically, message #7 is used to indicate the statistical results of latency information between the terminal device and the UPF.

[0375] For example, message #7 transmits PDU session information for uplink data packets. The information element fields involved in its PDU session information frame are shown in Table 5. The GTPU message header carries the QMP tag.

[0376] For information about the fields in Table 4, please refer to the following description:

[0377] (1) PDU type: The PDU type can be located in bits 4 to 7 of the first octet of the PDU session information frame, and is used to indicate the structure of the PDU session UP frame. This field uses the value of the PDU type it identifies. Applicable to the embodiments of this application, the PDU type (=1) indicates uplink PDU session information.

[0378] (2) QMP tag: The QMP tag can be located in the 3rd bit of the first octet of the PDU session information frame, indicating that the information frame is used to monitor QoS flow.

[0379] (3) Downlink Delay Indication: The downlink delay indication information can be located in the second bit of the first octet of the PDU session information frame, and is used to indicate whether the PDU session information frame indicates downlink delay information.

[0380] (4) Uplink Delay Indication: The uplink delay indication information can be located in the first bit of the first octet of the PDU session information frame, and is used to indicate whether the PDU session information frame indicates uplink delay information.

[0381] (5) SNP: SNP can be located in the 0th bit of the first octet of the PDU session information frame, and is used to indicate whether there is a downlink QFI sequence number in the downlink PDU session information frame or whether there is an uplink QFI sequence number in the uplink PDU session information frame.

[0382] (6) Reserved bits: The 6th to 7th bits of the second octet of the PDU session information frame can be reserved bits.

[0383] (7) QoS flow identifier (QFI): The QFI can be located in the 0th to 5th bits of the second octet of the PDU session information frame. It is used to indicate the QoS flow to which the transmitted data packet belongs. The QoS flow is uniquely determined by the QoS flow identifier.

[0384] (8) Downlink retransmission timestamp: can occupy 0 or 8 octets to represent the 64-bit timestamp generated when UPF-encoded downlink data packets.

[0385] Specifically, the timestamps of UPF-encoded downlink data packets can be generated periodically, so this field can include multiple timestamp information.

[0386] (9) Downlink receive timestamp: The downlink receive timestamp can occupy 0 or 8 octets to represent the 64-bit timestamp generated when the base station equipment receives data packets.

[0387] (10) Downlink transmission timestamp: The downlink transmission timestamp can occupy 0 or 8 octets to represent the 64-bit timestamp generated when the base station equipment encodes the data packet.

[0388] (11) Downlink delay result: The downlink delay result can occupy 0 or 4 octets to represent the downlink delay measurement result.

[0389] Specifically, when the "Downlink Delay Indication Information" field indicates that the PDU session information frame indicates downlink delay information, the "Downlink Delay Result" field indicates the downlink delay measurement result (occupying 4 octets); when the "Downlink Delay Indication Information" field indicates that the PDU session information frame does not indicate downlink delay information, the "Downlink Delay Result" field occupies 0 octets.

[0390] (12) Uplink delay result: It can occupy 0 or 4 octets to represent the uplink delay measurement result.

[0391] Specifically, when the "Uplink Delay Indication Information" field indicates that the PDU session information frame indicates uplink delay information, the "Uplink Delay Result" field indicates the uplink delay measurement result (occupying 4 octets); when the "Uplink Delay Indication Information" field indicates that the PDU session information frame does not indicate uplink delay information, the "Uplink Delay Result" field occupies 0 octets.

[0392] (13) Uplink QFI sequence number: The uplink QFI sequence number can occupy 0 or 3 octets to represent the sequence number assigned by the UPF or base station equipment.

[0393] (14) Padding bits: Padding bits can occupy 0 to 3 octets to fill the end of the frame to ensure that the PDU session user plane protocol PDU length (including padding and future extension) is (n×4-2) octets, where n is a positive integer.

[0394] Table 5

[0395] It should be understood that the names of the above fields are only used to indicate the corresponding functions, and the specific names of the above fields are not limited in the embodiments of this application.

[0396] As shown in the table above, the UPF can obtain delay #1, delay #2, time #5, time #6 and time #7 from message #7. After the base station equipment receives message #7, it can also determine time #8 based on message #7 (that is, the statistical results of the delay information between the base station equipment and the UPF include delay #1, delay #2, time #5, time #6, time #7 and time #8).

[0397] In this context, time #5 represents the time when the UPF sends message #6 to the base station device, time #6 represents the time when the base station device receives message #6, time #7 represents the time when the base station device sends message #7 to the UPF, and time #8 represents the time when the UPF receives message #7.

[0398] Optionally, since the "uplink retransmission timestamp" field can include multiple timestamp information, the base station equipment also needs to determine which time #1 in the "uplink retransmission timestamp" field is associated with time #2 and time #3.

[0399] S707: UPF determines the round-trip time between the terminal device and the UPF #4.

[0400] Specifically, the round-trip delay #4 between the terminal device and the UPF can be determined based on the round-trip delay #5 between the terminal device and the base station device and the round-trip delay #6 between the UPF and the base station device.

[0401] For example, round-trip delay #4 = round-trip delay #5 + round-trip delay #6.

[0402] Optionally, the round-trip delay #5 between the terminal device and the base station device can be determined based on delay #1 and delay #2.

[0403] For example, round-trip delay #5 = delay #1 + delay #2.

[0404] Optionally, the round-trip delay #6 between the UPF and the base station equipment can be determined based on time #5, time #6, time #7 and time #8.

[0405] For example, round-trip time delay #6 = (time #8 - time #7) + (time #6 - time #5).

[0406] Optionally, the round-trip delay #1 between the terminal device and the UPF can be determined based on delay #1, delay #2, time #5, time #6, time #7 and time #8.

[0407] For example, the relationship between the round-trip time delays #4, #1, #2, #5, #6, #7, and #8 between the terminal device and the UPF satisfies: RTT#4=X1+X2+(T8–T7)+(T6–T5)

[0408] Where RTT#4 represents round-trip delay #4, X1 represents delay #1, X2 represents delay #2, T5 represents time #5, T6 represents time #6, T7 represents time #7, and T8 represents time #8.

[0409] S708: The UPF sends the round-trip delay #4 between the terminal device and the UPF to the base station equipment; correspondingly, the base station equipment receives the round-trip delay #4 between the terminal device and the UPF sent by the UPF.

[0410] S709: The base station equipment determines the token bucket parameters of the terminal based on the round-trip delay #4.

[0411] Specifically, the base station equipment can determine the token bucket parameters of the terminal based on the round-trip delay #4. The token bucket parameters include the priority bit rate (PBR) and the bucket size duration (BSD). The meanings of PBR and BSD can be found in the terminology section above, and are not limited herein.

[0412] Optionally, when N QoS flows are mapped to one DRB (i.e., N QoS flows share the same DRB, where N is a positive integer), since the UPF can determine the latency information statistics for each QoS flow separately (i.e., the UPF can determine the time #5, time #6, time #7, and time #8 corresponding to each QoS flow separately), the round-trip time (RTT) #4 between the terminal device and the UPF corresponding to the i-th QoS flow among the N QoS flows can be obtained.i (i∈[1,N]), the round-trip time #4 between the terminal device and the UPF can be determined according to the RTT #4. i Sure.

[0413] For example, the round-trip time #4 between the terminal device and the UPF can be the RTT #4 of the N QoS flows. i The average, maximum, minimum, or weighted average, etc.

[0414] Alternatively, BSD can determine the round-trip time #4 between the terminal device and the UPF.

[0415] For example, when N QoS flows are mapped to 1 DRB (N is a positive integer), the base station device can determine the BSD based on the round-trip delay #4 of the N QoS flows associated with the logical channel.

[0416] For example, the round-trip latency #4 for BSD and N QoS streams can satisfy:

[0417] Where N represents the number of QoS flows, N is a positive integer, and RTT#4 i #4 represents the round-trip delay between the terminal device and the UPF in the i-th QoS flow of N QoS flows.

[0418] For example, the round-trip time #4 of BSD and N QoS streams can also satisfy: BSD = max{RTT#41, RTT#42, ..., RTT#4 N}

[0419] For example, the round-trip latency #4 of BSD and N QoS flows can also satisfy: BSD = min{RTT#41, RTT#42, ..., RTT#4} N}

[0420] For example, BSD can be the RTT#4 for the N QoS streams. i The weighted average and other calculation results.

[0421] Alternatively, the PBR can be determined based on the MFBR.

[0422] For example, when N QoS flows are mapped to one DRB (N is a positive integer), the PBR can be the MFBR of the N QoS flows. i The average, maximum, minimum, or weighted average, etc.

[0423] Alternatively, the PBR can also be determined based on the GFBR.

[0424] For example, when N QoS flows are mapped to one DRB (N is a positive integer), the PBR can be the GFBR of the N QoS flows. i The average, maximum, minimum, or weighted average, etc.

[0425] Alternatively, PBR can also be determined based on round-trip delay #1 and MFBR.

[0426] For example, when N QoS flows are mapped to one DRB (N is a positive integer), PBR, BSD, and MFBR... i and RTT#4 i satisfy:

[0427] Where N represents the number of QoS flows, N is a positive integer, and RTT#4 i #4, MFBR, represents the round-trip delay between the terminal device and the UPF for the i-th QoS flow in N QoS flows. i This represents the MFBR of the i-th QoS flow in N flows. The BSD, as mentioned above, is determined based on the round-trip delay #4 between the terminal device and the UPF.

[0428] Alternatively, PBR can also be determined based on round-trip delay #4 and GFBR.

[0429] For example, when N QoS flows are mapped to one DRB (N is a positive integer), PBR, BSD, and GFBR... i and RTT#4 i satisfy:

[0430] Where N represents the number of QoS flows, N is a positive integer, and RTT#4 i #4, GFBR, represents the round-trip delay between the terminal device and the UPF in the i-th QoS flow of N QoS flows. i This represents the GFBR of the i-th QoS flow in N flows. The BSD, as mentioned above, is determined based on the round-trip delay #4 between the terminal device and the UPF.

[0431] S710: The base station equipment sends token bucket parameters to the terminal; correspondingly, the terminal equipment receives the token bucket parameters sent by the base station equipment.

[0432] The token bucket parameter is used to instruct the terminal device to perform uplink data transmission.

[0433] It should be understood that the processing of the terminal device after receiving the token bucket parameters can refer to step S609 in method 600 above, and will not be repeated here.

[0434] In addition, it should be noted that in both methods 600 and 700, the base station equipment instructs the SMF, and the SMF indirectly instructs the UPF to enable latency monitoring of the service flow between the terminal equipment and the UPF (such as steps S601 to S603 in method 600 and steps S701 to S703 in method 700).

[0435] In one possible implementation, the base station equipment can also directly send message #8 to the UPF through the N3 interface. Message #8 is used to instruct the UPF to start latency monitoring (or, it can also be understood as the message #8 is used to send a request to the UPF to start latency monitoring). The latency monitoring means real-time monitoring of the latency of the service flow between the terminal equipment and the UPF.

[0436] In other words, steps S601 to S603 in method 600 and steps S701 to S703 in method 700 can be replaced by "the base station equipment directly sends message #8 to the UPF". This eliminates the need to indirectly instruct the UPF to start latency monitoring through the SMF, reducing signaling overhead and improving latency measurement efficiency.

[0437] To facilitate understanding of the above embodiments provided in this application, the following points are made.

[0438] (1) In the embodiments of this application, "instruction" may include direct instruction, indirect instruction, explicit instruction, and implicit instruction. When describing a certain instruction information for the purpose of indicating A, it can be understood that the instruction information carries A, directly indicates A, or indirectly indicates A.

[0439] In this application, the information indicated by the instruction information is called the information to be instructed. In specific implementations, there are many ways to indicate the information to be instructed, such as, but not limited to, directly indicating the information to be instructed, such as the information to be instructed itself or its index. It can also indirectly indicate the information to be instructed by indicating other information, where there is a relationship between the other information and the information to be instructed. It can also indicate only a part of the information to be instructed, while the other parts are known or pre-agreed upon. For example, the instruction of specific information can be achieved by using a pre-agreed (e.g., protocol-defined) arrangement of various pieces of information, thereby reducing instruction overhead to some extent. Furthermore, the information to be instructed can be sent as a whole or divided into multiple sub-information pieces, and the sending period and / or timing of these sub-information pieces can be the same or different.

[0440] (2) In this application, "send" and "receive" indicate the direction of signal transmission. For example, "send information to XX" can be understood as the destination of the information being XX, which may include direct transmission via the air interface or indirect transmission via the air interface by other units or modules. "Receive information from YY" can be understood as the source of the information being YY, which may include direct reception from YY via the air interface or indirect reception from YY via the air interface by other units or modules. "Send" can also be understood as the "output" of the chip interface, and "receive" can also be understood as the "input" of the chip interface. In other words, sending and receiving can occur between devices, such as between network devices and terminal devices, or within a device, such as between components, modules, chips, software modules, or hardware modules within the device via a bus, wiring, or interface. In this application, descriptions relating to network element A sending messages, information, or data to network element B, and network element B receiving messages, information, or data from network element A, are intended to indicate which network element the message, information, or data is to be sent to, without specifying whether the transmission is direct or indirect via other network elements. Descriptions such as "when," "under the circumstances," "if," and "if" all indicate that the device will take corresponding actions under certain objective circumstances, not that they limit the time frame, nor do they require the device to perform a judgment action during implementation, nor do they imply any other limitations.

[0441] (3) In the various embodiments of this application, unless otherwise specified or logically conflicting, the terms and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0442] (4) In this application, "first" and "second" are used for descriptive convenience only to distinguish objects and are not intended to limit the scope of the embodiments of this application. They are not used to describe the order or sequence of features. It should be understood that the objects described in this way can be interchanged where appropriate so as to describe solutions other than those in the embodiments of this application.

[0443] (5) In this application, “predefined” can be achieved by pre-storing the corresponding code, table or other means that can be used to indicate relevant information in the device. This application does not limit the specific implementation method.

[0444] (6) In this application, the “protocol” may refer to standard protocols in the field of communications, such as the Long Term Evolution (LTE) protocol, the New Radio (NR) protocol, and related protocols applied to future communication systems. This application does not limit the scope of the term.

[0445] (7) In this application, the words “exemplary,” “for example,” “exemplary,” “as another example,” etc., are used to indicate that they are examples, illustrations, or descriptions. Any embodiment or design that is described as an “exemplary” in this application should not be construed as being more preferred or advantageous than other embodiments or designs.

[0446] (8) In this application, “comprising,” “including,” “having,” and variations thereof mean “including but not limited to,” unless otherwise specifically emphasized. “At least one” means one or more, and “more” means two or more.

[0447] (9) In this application, "and / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, or B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the related objects before and after are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, and c can mean: a, or, b, or, c, or, a and b, or, a and c, or, b and c, or, a, b, and c. Where a, b, and c can be single or multiple.

[0448] (10) In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terms and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0449] (11) Some optional features in the various embodiments of this application may not depend on other features in some scenarios, or may be combined with other features in some scenarios, without limitation.

[0450] The methods of the embodiments of this application have been described in detail above with reference to Figures 5 to 7. In order to implement the functions of the methods provided in this application, the first device, the second device, the third device, and the fourth device may all include hardware structures and / or software modules, and implement the above functions in the form of hardware structures, software modules, or hardware structures plus software modules. Whether a certain function is executed in the form of hardware structures, software modules, or hardware structures plus software modules depends on the specific application and design constraints of the technical solution.

[0451] The communication device of the present application embodiment is described below with reference to Figures 8 to 10.

[0452] Figure 8 is a schematic diagram of a communication device 800 applicable to an embodiment of this application.

[0453] The device 800 includes a transceiver unit 810 and a processing unit 820. The transceiver unit 810 can communicate with the outside world, and the processing unit 820 is used for data processing. The transceiver unit 810 can also be referred to as a communication interface or a communication unit.

[0454] Optionally, the transceiver unit 810 may also be referred to as a communication interface or communication unit, including a transmitting unit and / or a receiving unit. The transceiver unit 810 may be a transceiver (including a transmitter and / or receiver), an input / output interface (including input and / or output interfaces), or pins or circuits, etc. The transceiver unit 810 can be used to perform the transmitting and / or receiving steps in the above method embodiments.

[0455] Optionally, the processing unit 820 may be a processor (which may include one or more) or a processing circuit with processor functions, and may be used to perform other steps in the above method embodiments besides sending and receiving.

[0456] Optionally, the device 800 further includes a storage unit, which may be a memory, an internal storage unit (e.g., a register or cache), or an external storage unit (e.g., a read-only memory or a random access memory). The storage unit stores instructions, and the processing unit 820 executes the instructions stored in the storage unit to cause the communication device to perform the aforementioned method.

[0457] In addition, the transceiver unit 810 may also be a transceiver circuit (for example, it may include a receiving circuit and a transmitting circuit), and the processing unit 820 may be a processing circuit.

[0458] It should be noted that the device in Figure 8 can also be a chip or a chip system, such as a system-on-a-chip (SoC). The transceiver unit can be an input / output circuit or a communication interface; the processing unit is a processor, microprocessor, or integrated circuit integrated on the chip. This application does not impose any limitations on this.

[0459] In one design, the device 800 can be used to perform the actions performed by the first device in the above method embodiments. In this case, the device 800 can be the first device or a component configurable on the first device.

[0460] The transceiver unit 810 is used to perform transceiver-related operations on the first device side in the above method embodiment, for example, to send the token bucket parameter, which is used to instruct the third device to perform uplink data transmission.

[0461] Optionally, the transceiver unit 810 is further configured to send a first message, the first message being configured to instruct the activation of latency monitoring between the second device and the third device.

[0462] Optionally, the transceiver unit 810 is also configured to receive the first delay.

[0463] Optionally, the transceiver unit 810 is further configured to send a second message, the second message being used to instruct the sampling of delay information between the first device and the second device; and to receive a third message, the third message including a first time moment, a second time moment, and a third time moment, for determining a fourth time moment and the fourth delay.

[0464] Optionally, the transceiver unit 810 is also configured to send the first message to a fourth device.

[0465] The processing unit 820 is used to perform processing-related operations on the first device side in the above method embodiment, for example, to obtain a first delay, which is the round-trip time (RTT) between the second device and the third device; and to determine token bucket parameters based on the first delay, a first rate, and / or a second rate, where the first rate is the maximum flow bit rate (MFBR) between the second device and the third device, and the second rate is the guaranteed flow bit rate (GFBR) between the second device and the third device.

[0466] Optionally, the processing unit 820 is further configured to determine the BSD based on the first delay; determine the PBR based on the first rate or the second rate; or determine the PBR based on the first delay and the first rate; or determine the PBR based on the first delay and the second rate.

[0467] Optionally, the processing unit 820 is further configured to determine the first delay based on the second delay, the third delay, and the fourth delay, wherein the second delay is the uplink air interface delay between the third device and the first device, the third delay is the downlink air interface delay between the third device and the first device, and the fourth delay is the RTT between the first device and the second device.

[0468] It should be understood that the transceiver unit 810 and the processing unit 820 may also perform other operations performed by the first device in any of the methods 500, 600 or 700 described above, which will not be detailed here.

[0469] A more detailed description of the transceiver unit 810 and the processing unit 820 can be obtained directly from the relevant descriptions in the method embodiments shown in Figures 5, 6 or 7, and will not be repeated here.

[0470] Alternatively, the device 800 can be used to perform the actions performed by the second device in the above method embodiments. In this case, the device 800 can be the second device or a component that can be configured on the second device.

[0471] The transceiver unit 810 is used to perform transceiver-related operations on the second device side in the above method embodiment, for example, to receive a second message, which is used to indicate the sampling of delay information between the first device and the second device; and to send a third message, which includes a first time, a second time, and a third time, for determining a fourth time and a fourth delay; wherein, the first time is the time when the first device sends the second message, the second time is the time when the second device receives the second message, the third time is the time when the second device sends the third message, the fourth time is the time when the first device receives the third message, and the fourth delay is the round-trip time (RTT) between the first device and the second device.

[0472] Optionally, the transceiver unit 810 is further configured to receive a first message, the first message being used to instruct the activation of latency monitoring between the second device and the third device; wherein the third device communicates with the second device through the first device.

[0473] It should be understood that the transceiver unit 810 and the processing unit 820 may also perform other operations performed by the second device in any of the methods 500, 600 or 700 described above, which will not be detailed here.

[0474] A more detailed description of the transceiver unit 810 and the processing unit 820 can be obtained directly from the relevant descriptions in the method embodiments shown in Figures 5, 6 or 7, and will not be repeated here.

[0475] Alternatively, the device 800 can be used to perform the actions performed by the second device in the above method embodiments. In this case, the device 800 can be the second device or a component that can be configured on the second device.

[0476] The transceiver unit 810 is used to perform transceiver-related operations on the second device side in the above method embodiment, for example, to send the first delay to the first device.

[0477] The processing unit 820 is used to perform processing-related operations on the second device side in the above method embodiment, for example, to determine a first delay, which is used to indicate the round-trip time (RTT) between the second device and the third device.

[0478] It should be understood that the transceiver unit 810 and the processing unit 820 may also perform other operations performed by the second device in any of the methods 500, 600 or 700 described above, which will not be detailed here.

[0479] A more detailed description of the transceiver unit 810 and the processing unit 820 can be obtained directly from the relevant descriptions in the method embodiments shown in Figures 5, 6 or 7, and will not be repeated here.

[0480] Alternatively, the device 800 can be used to perform the actions performed by the third device in the above method embodiments. In this case, the device 800 can be the third device or a component that can be configured on the third device.

[0481] The transceiver unit 810 is used to perform transceiver-related operations on the third device side in the above method embodiment. For example, it is used to receive token bucket parameters from the first device. The token bucket parameters are determined based on a first delay, a first rate, and / or a second rate. The first delay is used to indicate the round-trip time (RTT) between the second device and the third device. The first rate is the maximum flow bit rate (MFBR) between the second device and the third device. The first rate is the guaranteed flow bit rate (GFBR) between the second device and the third device. The third device communicates with the second device through the first device.

[0482] The processing unit 820 is used to perform processing-related operations on the third device side in the above method embodiment, for example, to perform uplink data transmission according to the token bucket parameters.

[0483] It should be understood that the transceiver unit 810 and the processing unit 820 may also perform other operations performed by the third device in any of the methods 500, 600 or 700 described above, which will not be detailed here.

[0484] A more detailed description of the transceiver unit 810 and the processing unit 820 can be obtained directly from the relevant descriptions in the method embodiments shown in Figures 5, 6 or 7, and will not be repeated here.

[0485] Alternatively, the device 800 can be used to perform the actions performed by the fourth device in the above method embodiments. In this case, the device 800 can be the fourth device or a component that can be configured on the fourth device.

[0486] The transceiver unit 810 is used to perform transceiver-related operations on the fourth device side in the above method embodiment, for example, to receive a first message from the first device, the first message being used to indicate the activation of latency monitoring between the second device and the third device, the third device communicating with the second device through the first device; and to send the first message.

[0487] It should be understood that the transceiver unit 810 and the processing unit 820 may also perform other operations performed by the fourth device in any of the methods 500, 600 or 700 described above, which will not be detailed here.

[0488] A more detailed description of the transceiver unit 810 and the processing unit 820 can be obtained directly from the relevant descriptions in the method embodiments shown in Figures 5, 6 or 7, and will not be repeated here.

[0489] It should be understood that the device 800 here is embodied in the form of a functional unit. The term "unit" here may refer to application-specific integrated circuits (ASICs), electronic circuits, processors (e.g., shared processors, proprietary processors, or group processors) and memories for executing one or more software or firmware programs, combined logic circuits, and / or other suitable components that support the described functions.

[0490] The apparatus 800 of each of the above-described schemes has the function of implementing the corresponding steps performed by the communication device (such as the first device, the second device, the third device, or the fourth device) in the above-described methods. The function can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions; for example, the transceiver unit can be replaced by a transceiver (e.g., the transmitting unit in the transceiver unit can be replaced by a transmitter, and the receiving unit in the transceiver unit can be replaced by a receiver), and other units, such as processing units, can be replaced by processors, each performing the transceiver operations and related processing operations in the respective method embodiments.

[0491] Figure 9 is a structural schematic diagram of a communication device 900 applicable to an embodiment of this application.

[0492] As shown in Figure 9, the device 900 includes a processor 910 and a transceiver 920. The processor 910 and the transceiver 920 communicate with each other through an internal connection path. The processor 910 is used to execute instructions to control the transceiver 920 to send and / or receive signals.

[0493] Optionally, the device 900 may further include a memory 930, which communicates with the processor 910 and the transceiver 920 via an internal connection. The memory 930 is used to store instructions, and the processor 910 can execute the instructions stored in the memory 930.

[0494] In one possible implementation, the device 900 can be used to implement the various processes and steps corresponding to the first device (e.g., base station device) in the above method embodiments.

[0495] It should be understood that the device 900 may specifically be the first device in the above embodiments, or it may be a chip or a chip system. Correspondingly, the transceiver 920 may be the transceiver circuit of the chip, and is not limited here. For example, the device 900 may be used to execute the various steps and / or processes corresponding to the first device in the above method embodiments.

[0496] In one possible implementation, the device 900 can be used to implement the various processes and steps corresponding to the second device (e.g., UPF network element) in the above method embodiments.

[0497] It should be understood that the device 900 can be specifically the second device in the above embodiments, or it can be a chip or a chip system. Correspondingly, the transceiver 920 can be the transceiver circuit of the chip, which is not limited here. For example, the device 900 can be used to execute the various steps and / or processes corresponding to the second device in the above method embodiments.

[0498] In one possible implementation, the device 900 can be used to implement the various processes and steps corresponding to the third device (e.g., terminal device) in the above method embodiments.

[0499] It should be understood that the device 900 can specifically be the third device in the above embodiments, or it can be a chip or a chip system. Correspondingly, the transceiver 920 can be the transceiver circuit of the chip, which is not limited here. For example, the device 900 can be used to execute the various steps and / or processes corresponding to the third device in the above method embodiments.

[0500] In one possible implementation, the device 900 can be used to implement the various processes and steps corresponding to the fourth device (e.g., SMF network element) in the above method embodiments.

[0501] It should be understood that the device 900 can specifically be the fourth device in the above embodiments, or it can be a chip or a chip system. Correspondingly, the transceiver 920 can be the transceiver circuit of the chip, which is not limited here. For example, the device 900 can be used to execute the various steps and / or processes corresponding to the fourth device in the above method embodiments.

[0502] Optionally, the memory 930 may include read-only memory and random access memory, and provide instructions and data to the processor. A portion of the memory may also include non-volatile random access memory. For example, the memory may also store device type information. The processor 910 may be used to execute instructions stored in the memory, and when the processor 910 executes instructions stored in the memory, the processor 910 is used to perform the various steps and / or processes of the method embodiments corresponding to the first device, second device, third device, or fourth device described above.

[0503] In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are omitted here.

[0504] It should be noted that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The processor in the embodiments of this application can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above methods.

[0505] It is understood that the memory in the embodiments of this application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory, dynamic random access memory, synchronous dynamic random access memory, double data rate synchronous dynamic random access memory, enhanced synchronous dynamic random access memory, synchronous linked dynamic random access memory, and direct memory bus random access memory. It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0506] Figure 10 is a schematic diagram of the structure of a chip system 1000 applicable to an embodiment of this application.

[0507] As shown in Figure 10, the chip system 1000 (or processing system) includes logic circuits 1010 and input / output interface 1020.

[0508] The logic circuit 1010 can be a processing circuit in the chip system 1000. The logic circuit 1010 can be coupled to a storage unit, calling instructions from the storage unit, enabling the chip system 1000 to implement the functions of the first, second, third, or fourth device in the various embodiments of this application. The input / output interface 1020 can be an input / output circuit in the chip system 1000, outputting processed information from the chip system 1000, or inputting data or signaling information to be processed into the chip system 1000 for processing.

[0509] As one option, the chip system 1000 is used to implement the operations performed by the first device, the second device, the third device, or the fourth device in the various method embodiments described above.

[0510] This application also provides a computer-readable medium having a computer program stored thereon, which, when executed by a computer, performs the functions of the first device, second device, third device, or fourth device in any of the above method embodiments.

[0511] This application also provides a computer program product that, when executed by a computer, implements the functions of the first device, second device, third device, or fourth device in any of the above method embodiments.

[0512] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this 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. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0513] Those skilled in the art will recognize that the units and algorithm steps of the various examples 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 implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art 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.

[0514] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0515] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0516] The units described as separate components may or may not be physically separate. 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 the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0517] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0518] If the aforementioned functions are implemented as 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 this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0519] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A flow control method, applied to a first device, characterized in that, include: Obtain the first delay, which is the round-trip time (RTT) between the second and third devices; The token bucket parameters are determined based on the first delay, the first rate, and / or the second rate. The token bucket parameters are used to instruct the third device to perform uplink data transmission. The first rate is the maximum flow bit rate (MFBR) between the second device and the third device, and the second rate is the guaranteed flow bit rate (GFBR) between the second device and the third device. Send the token bucket parameters; The third device communicates with the second device through the first device.

2. The method according to claim 1, characterized in that, The method further includes: Send a first message, which is used to instruct the activation of latency monitoring between the second device and the third device.

3. The method according to claim 1 or 2, characterized in that, The token bucket parameters include: Priority Bit Rate (PBR) and Bucket Size Duration (BSD). The step of determining the token bucket parameters based on the first delay, the first rate, and / or the second rate further includes: The BSD is determined based on the first delay; The PBR is determined based on the first rate or the second rate; Alternatively, the PBR can be determined based on the first delay and the first rate; Alternatively, the PBR can be determined based on the first delay and the second rate.

4. The method according to any one of claims 1 to 3, characterized in that, The acquisition of the first delay includes: Receive the first delay; Alternatively, the first delay can be determined based on the second delay, the third delay, and the fourth delay, wherein the second delay is the uplink air interface delay between the third device and the first device, the third delay is the downlink air interface delay between the third device and the first device, and the fourth delay is the RTT between the first device and the second device.

5. The method according to claim 4, characterized in that, Before determining the first delay based on the second delay, the third delay, and the fourth delay, the method further includes: Send a second message, which instructs to sample the delay information between the first device and the second device; Receive a third message, the third message including a first moment, a second moment and a third moment, used to determine a fourth moment and the fourth time delay; Wherein, the first moment is the moment when the first device sends the second message, the second moment is the moment when the second device receives the second message, the third moment is the moment when the second device sends the third message, and the fourth moment is the moment when the first device receives the third message; The relationship between the fourth time delay and the first time point, the second time point, the third time point, and the fourth time point satisfies: RTT4=(T4-T3)+(T2-T1) Wherein, RTT4 represents the fourth time delay, T1 represents the first time, T2 represents the second time, T3 represents the third time, and T4 represents the fourth time.

6. The method according to any one of claims 1 to 5, characterized in that, When N QoS flows between the second device and the third device share the same Infinite Resource Bearer (DRB), the first delay is the average RTT of the N QoS flows; Alternatively; the first delay is the maximum RTT of the N QoS streams; Alternatively; the first delay is the minimum RTT of the N QoS streams; Alternatively; the first delay is the weighted average of the RTT of the N QoS streams.

7. The method according to any one of claims 1 to 6, characterized in that, When N QoS flows between the second device and the third device share the same DRB, the BSD is the average RTT of the N QoS flows; Alternatively; the BSD is the maximum RTT of the N QoS flows; Alternatively; the BSD is the minimum RTT of the N QoS flows; Alternatively; the BSD is the weighted average of the RTT of the N QoS flows.

8. The method according to any one of claims 1 to 7, characterized in that, When N QoS flows between the second device and the third device share the same DRB, the PBR is the average of the first rate or the second rate of the N QoS flows; Alternatively; the PBR is the maximum value of the first rate or the second rate of the N QoS flows; Alternatively; the PBR is the minimum of the first or second rate of the N QoS flows; Alternatively; the PBR is the weighted average of the first or second rate of the N QoS flows.

9. The method according to any one of claims 2 to 8, characterized in that, Sending the first message includes sending the first message to the fourth device.

10. A flow control method applied to a second device, characterized in that, include: Receive a second message, the second message being used to instruct the sampling of delay information between the first device and the second device; Send a third message, which includes a first moment, a second moment, and a third moment, to determine a fourth moment and a fourth time delay; Wherein, the first moment is the moment when the first device sends the second message, the second moment is the moment when the second device receives the second message, the third moment is the moment when the second device sends the third message, the fourth moment is the moment when the first device receives the third message, and the fourth delay is the round-trip time (RTT) between the first device and the second device.

11. The method according to claim 10, characterized in that, The method further includes: Receive a first message, which is used to instruct the activation of latency monitoring between the second device and the third device; The third device communicates with the second device through the first device.

12. A flow control method applied to a second device, characterized in that, include: A first delay is determined, which is used to indicate the round-trip time (RTT) between the second device and the third device; Send the first delay to the first device; The third device communicates with the second device through the first device.

13. A flow control method applied to a third device, characterized in that, include: The device receives token bucket parameters from a first device, which are determined based on a first delay, a first rate, and / or a second rate. The first delay is used to indicate the round-trip time (RTT) between the second device and the third device. The first rate is the maximum flow bit rate (MFBR) between the second device and the third device, and the first rate is the guaranteed flow bit rate (GFBR) between the second device and the third device. The third device communicates with the second device through the first device. Uplink data transmission is performed based on the token bucket parameters.

14. A flow control method applied to a fourth device, characterized in that, include: Receive a first message from a first device, the first message being used to instruct the activation of latency monitoring between a second device and a third device, wherein the third device communicates with the second device through the first device; Send the first message.

15. A flow control device, characterized in that, The apparatus includes a unit for performing the method as claimed in any one of claims 1 to 9; or, the apparatus includes a unit for performing the method as claimed in claim 10 or 11; or, the apparatus includes a unit for performing the method as claimed in claim 12; or, the apparatus includes a unit for performing the method as claimed in claim 13; or, the apparatus includes a unit for performing the method as claimed in claim 14.

16. A flow control system, characterized in that, Includes the flow control device as described in claim 15.

17. A flow control device, characterized in that, The device includes a processor coupled to a memory for storing computer programs or instructions, and the processor is configured to execute the computer programs or instructions in the memory, causing the device to perform the method as described in any one of claims 1 to 14.

18. A communication device, characterized in that, Includes a processor for running computer programs or instructions to cause the communication device to perform the method as described in any one of claims 1 to 14.

19. The communication device according to claim 18, characterized in that, The communication device further includes a memory for storing the computer program or instructions.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program or instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 14.

21. A chip or chip system, characterized in that, Includes: a processor for retrieving and running a computer program from memory, causing a communication device equipped with the chip system to perform the method of any one of claims 1 to 14.

22. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1 to 14.

Images