Congestion control method and apparatus, and readable storage medium

Abstract

The present application relates to the technical field of communications, and particularly to a congestion control method and apparatus, and a readable storage medium. The method comprises: a data sender sends a data packet 1, wherein the data packet 1 carries window information 1 that is used for requesting to adjust a transmission window of data; a base station determines window information 2 on the basis of the window information 1 and a sensed air interface resource, wherein the window information 2 is used for indicating a transmission window of data; the base station sends the window information 2 to the data sender; the data sender determines the transmission window of the data on the basis of the window information 2. Use of the embodiments of the present application can reduce packet loss in a network, and can reduce the time delay of data transmission and improve the reliability of the data transmission.

Description

Congestion control method, device and readable storage medium

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on December 29, 2023, with application number 202311866285.2, and priority to the Chinese patent application entitled “A Congestion Control Method, Device and Readable Storage Medium”, all contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to a congestion control method, device, and readable storage medium. Background Art

[0003] With the development of machine learning algorithms, smart applications, and terminal computing capabilities, distributed computing with end-cloud collaboration (such as distributed artificial intelligence (AI) computing) is gradually becoming a future trend. In distributed AI computing, real-time model or data interaction is required. In traditional distributed computing based on transmission control protocol / internet protocol (TCP / IP) communication, the network is responsible for transmitting data, and the computing devices on both sides copy and encapsulate the data. However, data copying and protocol encapsulation require the frequent participation of computing units such as the central processing unit (CPU), which increases the load on the device and the delay in service completion, resulting in reduced performance of distributed computing.

[0004] Remote direct memory access (RDMA) technology can be used to address the performance degradation of distributed computing based on TCP / IP communications. By implementing kernel bypass, RDMA provides a mechanism for direct memory access between remote nodes through the network interface card (NIC), thereby offloading the workload from processing units (such as CPUs).

[0005] Because RDMA technology is extremely sensitive to packet loss, a packet loss rate of one thousandth can result in a 30% performance degradation, making it impossible for distributed computing tasks to proceed normally. Therefore, it is worth considering how to implement congestion control during data transmission to reduce packet loss in the network. Summary of the Invention

[0006] The embodiments of the present application provide a congestion control method, device, and readable storage medium, which can reduce packet loss in the network, reduce the delay of data transmission, and improve the reliability of data transmission.

[0007] The present application is introduced below from different aspects. It should be understood that the implementation methods and beneficial effects of the following different aspects can be referenced to each other.

[0008] In a first aspect, the present application provides a congestion control method, which is applied to a first communication device, such as a base station. The method includes: the first communication device receiving a data packet 1 from a second communication device, the data packet 1 including window information 1, the window information 1 being used to request adjustment of a data sending window; and the first communication device sending a data packet 2 to a third communication device, the data packet 2 including window information 2, the window information 2 being used to indicate a data sending window. Window information 2 can be determined based on air interface resources and the aforementioned window information 1.

[0009] The "transmission window" in this application can be understood as the amount of data that a sender can continuously send. In TCP, the send window refers to the size of a buffer maintained by the sender to store data packets that have been sent but for which no acknowledgement has been received. In other words, the send window can also be understood as the buffer size of the send data queue. This will not be further explained below.

[0010] In this application, unless otherwise specified, various operations on the "send window" can be understood as operations on the size of the transmission window, and will not be further described below. For example, adjusting (e.g., increasing or decreasing) the data send window can be understood as adjusting (e.g., increasing or decreasing) the data send window size. For another example, indicating the data send window can be understood as indicating the data send window size. For another example, determining the data send window can be understood as determining the data send window size.

[0011] Exemplarily, the source address (sourceaddress) of the data message 1 is the address of the second communication device, and the destination address (targetaddress) of the data message 1 is the address of the third communication device.

[0012] Exemplarily, the second communication device is an in-network computing node, and the third communication device is a terminal. Alternatively, the second communication device is a terminal, and the third communication device is an in-network computing node. Alternatively, the second communication device is a terminal, and the third communication device is an off-network computing node (such as an edge server / cloud server); or, the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal.

[0013] It can be understood that the in-network computing node in this application may refer to a computing node introduced in a wireless network, which is usually connected to a base station and can be responsible for the in-network computing of AI tasks. Exemplarily, the in-network computing node in this application can be understood as a computing node within the scope of a wireless network or 3GPP (3rd generation partnership project) standard discussion. The off-network computing node (such as an edge server or a cloud server) in this application can be a computing server or computing cluster deployed at the edge or in the cloud, which has strong computing power and can be responsible for the off-network computing of AI tasks. The terminal can be connected to the off-network computing node through a user plane function (UPF). Exemplarily, the off-network computing node in this application can be understood as a computing node outside a wireless network or 3GPP.

[0014] After the first communication device (such as a base station) of the present application receives a data packet containing window information 1 (the window information 1 is used to request adjustment of the data sending window), it determines a sending window size for the second communication device (data sending end) by sensing the usage and / or remaining status of the air interface resources and combining the window information 1, and indicates it to the third communication device (data receiving end) so that the third communication device feeds back the sending window size indicated by the first communication device (i.e., window information 2) to the second communication device along with the data stream, thereby making the size of the sending window actually used by the second communication device more compatible with the transmission capability of the first communication device (such as a base station), and reducing packet loss in the network (or achieving no packet loss) and data transmission delay, thereby improving the reliability and throughput of data transmission, and thus achieving low-latency, high-throughput data transmission.

[0015] In conjunction with the first aspect, in one possible implementation, the method further includes: the first communication device determining window information 2 based on the window information 1 in the data packet 1 and the air interface resources. Alternatively, the first communication device determines window information 2 based on the window information 1 in the data packet 1, the air interface resources, and the cache resources of the first communication device. The specific implementation of the first communication device determining window information 2 is described in the following method embodiment and is not detailed here.

[0016] Exemplarily, the air interface resources include one or more of the following: air interface channel status / channel quality (e.g., wireless channel gain or path loss), or air interface bandwidth conditions (e.g., system bandwidth allocation or remaining bandwidth resources within the first communication device). Exemplarily, the buffer resources of the first communication device include, but are not limited to, the lengths of various buffer queues for shared air interface resources (e.g., time-frequency resources) within the first communication device.

[0017] Exemplarily, the size of the sending window indicated by the window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0018] After the first communication device (such as a base station) of the present application receives a data packet containing window information 1, it determines whether its own transmission capacity can meet the needs of the second communication device (data sending end) (i.e., the size of the sending window requested to be adjusted by window information 1) by sensing the usage and / or remaining status of the air interface resources, and / or the current cache resources. This can make the size of the sending window more compatible with the transmission capacity of the first communication device (such as a base station), thereby reducing packet loss in the network (or achieving no packet loss) and data transmission delay, and improving the reliability of data transmission.

[0019] In combination with the first aspect, in a possible implementation, the above-mentioned window information 1 may include one or more of the following: an increase intent value (increase intent, II), a buffer queue length in the second communication device, or a link bandwidth capacity of the second communication device. Based on the window information 1, the sending window size (or the expected sending window size) requested to be adjusted by the second communication device can be determined. Among them, the increase intent value can indicate the sending window size that the second communication device expects to increase. For example, the sending window size at the current moment is 2048 bytes, and the increase intent value is also 2048 bytes, then the sending window size expected by the second communication device is 4096 (i.e., 2048+2048) bytes. The buffer queue length in the second communication device can be the buffer queue length of all data to be sent that belongs to the same quality of service (QoS) flow as the above-mentioned data packet 1, or it can be the buffer queue length of all data to be sent in the second communication device, and this application does not limit it.

[0020] It is understood that the above-mentioned window information 2 and the above-mentioned window information 1 can be information of the same dimension. For example: Window information 1 is an increase intention value, and window information 2 is also a value; or, Window information 1 is the buffer queue length within the second communication device, and window information 2 is also a buffer queue length; or, Window information 1 is the link bandwidth capacity of the second communication device, and window information 2 is also a link bandwidth capacity. It is also understood that the specific value of window information 2 can be determined by the internal policy of the first communication device, and this application does not impose any restrictions.

[0021] In combination with the first aspect, in a possible implementation, the window information 1 may be carried in a frame header of the data link layer, a packet header of the network layer, or a message header of the transport layer of the data message 1 .

[0022] In combination with the first aspect, in a possible implementation, the window information 2 may be carried in a frame header of the data link layer, a packet header of the network layer, or a message header of the transport layer of the data message 2 .

[0023] It is understood that the data message of the present application can have different representations in different protocol layers. For example, at the physical layer, the data message can be a binary bit sequence (bit); at the data link layer, the data message can be a data frame (frame); at the network layer, the data message can be a data packet (packet); at the transport layer, the data message can be a data segment (segment); at the application layer, the data message can be data (data). The present application does not limit the representation of the data message.

[0024] In conjunction with the first aspect, in one possible implementation, the data in the data message 2 (which may also be referred to as a payload, which will not be described in detail below) may be the same as the data (or payload) in the data message 1. It is understood that when the size of the sending window indicated by the window information 2 is equal to the size of the sending window requested to be adjusted by the window information 1, the data message 2 may be the same as the data message 1, and the value of the window information 2 may be the same as the value of the window information 1. It is also understood that when the size of the sending window indicated by the window information 2 is smaller than the size of the sending window requested to be adjusted by the window information 1, the data message 2 may be obtained by replacing / updating the window information 1 in the data message 1 with the window information 2. In short, the data message 2 may be determined / generated based on the data message 1.

[0025] When the first communication device of the present application forwards data sent from the second communication device to the third communication device, it carries the window information 2 in the data message 2 containing the data and sends it to the third communication device along with the data stream, without the need for additional notification, which can save overhead.

[0026] In the second aspect, the present application provides a congestion control method, which includes: the second communication device sends a data packet 1 (to the first communication device), and the data packet 1 includes window information 1, and the window information 1 is used to request adjustment of the data sending window; the second communication device receives a data packet 3 from a third communication device, and the data packet 3 includes window information 2, and the window information 2 is used to indicate the data sending window; the second communication device determines the data sending window based on the window information 2 in the data packet 3.

[0027] Exemplarily, the source address (sourceaddress) of the data message 1 is the address of the second communication device, and the destination address (targetaddress) of the data message 1 is the address of the third communication device.

[0028] Exemplarily, the first communication device is a base station.

[0029] Exemplarily, the second communication device is an in-network computing node, and the third communication device is a terminal. Alternatively, the second communication device is a terminal, and the third communication device is an in-network computing node. Alternatively, the second communication device is a terminal, and the third communication device is an off-network computing node (such as an edge server / cloud server); or, the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal.

[0030] The second communication device of the present application actively requests to adjust the data sending window according to its own cache situation and internal strategy, and feeds back congestion control information (i.e., window information 2) to the second communication device through the third communication device. This can not only reduce packet loss and data transmission delay in the network and provide data transmission reliability; it can also maximize the use of existing congestion control mechanisms and adapt them to mobile networks, which is easy to implement and has high compatibility.

[0031] In conjunction with the second aspect, in a possible implementation, the size of the sending window indicated by the window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0032] In conjunction with the second aspect, in one possible implementation, the second communication device determines the data sending window based on the window information 2 in the data message 3, including: if the size of the sending window indicated by the window information 2 is equal to the size of the sending window requested to be adjusted by the window information 1, the second communication device may adjust (for example, increase) the sending window at the next moment to its own desired sending window size (i.e., the size of the sending window requested to be adjusted by the window information 1, or the size of the sending window indicated by the window information 2). If the size of the sending window indicated by the window information 2 is smaller than the size of the sending window requested to be adjusted by the window information 1, the second communication device may adjust (possibly increase or decrease) the sending window at the next moment to the sending window size indicated by the window information 2. The specific adjustment method is described in the embodiment below and is not detailed here.

[0033] The second communication device of the present application adjusts the size of its own sending window based on the received indication (i.e., window information 2). Since the window information 2 matches the transmission capability of the first communication device (such as a base station), that is, the size of the sending window actually used by the second communication device matches the transmission capability of the first communication device (such as a base station), it can reduce packet loss in the network (or achieve no packet loss) and data transmission delay, improve the reliability and throughput of data transmission, and thus achieve low-latency, high-throughput data transmission.

[0034] In combination with the second aspect, in a possible implementation, the above-mentioned window information 1 may include one or more of the following: an increase intent value (increase intent, II), a buffer queue length in the second communication device, or a link bandwidth capacity of the second communication device. Based on the window information 1, the sending window size (or the expected sending window size) requested to be adjusted by the second communication device can be determined. Among them, the increase intent value can indicate the sending window size that the second communication device expects to increase. For example, the sending window size at the current moment is 2048 bytes, and the increase intent value is also 2048 bytes, then the sending window size expected by the second communication device is 4096 (i.e., 2048+2048) bytes. The buffer queue length in the second communication device can be the buffer queue length of all data to be sent that belongs to the same QoS flow as the above-mentioned data packet 1, or it can be the buffer queue length of all data to be sent in the second communication device, and this application does not limit it.

[0035] It is understood that the above-mentioned window information 2 and the above-mentioned window information 1 can be information of the same dimension. For example: Window information 1 is an increase intention value, and window information 2 is also a value; or, Window information 1 is the buffer queue length within the second communication device, and window information 2 is also a buffer queue length; or, Window information 1 is the link bandwidth capacity of the second communication device, and window information 2 is also a link bandwidth capacity. It is also understood that the specific value of window information 2 can be determined by the internal policy of the first communication device, and this application does not impose any restrictions.

[0036] In combination with the second aspect, in a possible implementation, the window information 1 may be carried in a frame header of the data link layer, a packet header of the network layer, or a message header of the transport layer of the data message 1.

[0037] In combination with the second aspect, in a possible implementation, the data packet 3 may include layer 3 or layer 4 feedback information of RDMA, and the layer 3 or layer 4 feedback information of RDMA may carry the window information 2.

[0038] It is understandable that the data (or payload) in the data message 3 is different from the data (or payload) in the data message 1. However, the data message 3 and the data message 1 belong to the same QoS flow or the same session.

[0039] This application feeds back the window information 2 along with the data stream, which eliminates the need for additional notifications and saves overhead.

[0040] In a third aspect, the present application provides a congestion control method, which includes: a third communication device receives a data packet 2 from a first communication device, wherein the data packet 2 includes the window information 2, and the window information 2 is used to indicate a data sending window; the third communication device sends a data packet 3 to the second communication device, wherein the data packet 3 includes the window information 2.

[0041] Exemplarily, the first communication device is a base station.

[0042] Exemplarily, the second communication device is an in-network computing node, and the third communication device is a terminal. Alternatively, the second communication device is a terminal, and the third communication device is an in-network computing node. Alternatively, the second communication device is a terminal, and the third communication device is an off-network computing node (such as an edge server / cloud server); or, the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal.

[0043] The third communication device of the present application feeds back the window information 2 to the second communication device via a data message, which can utilize the existing congestion control mechanism to the greatest extent and adapt it to the mobile network, making it easy to implement and highly compatible.

[0044] In combination with the third aspect, in a possible implementation, the window information 2 may be carried in a frame header of the data link layer, a packet header of the network layer, or a message header of the transport layer of the data message 2 .

[0045] In combination with the third aspect, in a possible implementation, the data packet 3 may include layer 3 or layer 4 feedback information of RDMA, and the layer 3 or layer 4 feedback information of RDMA may carry the window information 2.

[0046] It is understandable that the data (or payload) in the data message 3 is different from the data (or payload) in the above data message 2. However, the data message 3 and the data message 2 belong to the same QoS flow or the same session.

[0047] In a fourth aspect, the present application provides a communication device, which may be a first communication device or a chip or functional module configured in the first communication device, and the communication device includes a processing unit and a transceiver unit. The transceiver unit is configured to receive a data packet 1 from a second communication device, where the data packet 1 includes window information 1, where the window information 1 is used to request adjustment of a data sending window; and the transceiver unit is further configured to send a data packet 2 to a third communication device, where the data packet 2 includes the window information 2, where the window information 2 is used to indicate a data sending window, where the window information 2 can be determined based on air interface resources and the above-mentioned window information 1.

[0048] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0049] In conjunction with the fourth aspect, in one possible implementation, the processing unit is configured to determine window information 2 based on the window information 1 and the air interface resources in the data packet 1. Alternatively, the processing unit is configured to determine window information 2 based on the window information 1 in the data packet 1, the air interface resources, and the cache resources of the first communication device.

[0050] Exemplarily, the air interface resources include one or more of the following: air interface channel status / channel quality (e.g., wireless channel gain or path loss), or air interface bandwidth conditions (e.g., system bandwidth allocation or remaining bandwidth resources within the first communication device). Exemplarily, the buffer resources of the first communication device include, but are not limited to, the lengths of various buffer queues for shared air interface resources (e.g., time-frequency resources) within the first communication device.

[0051] Exemplarily, the size of the sending window indicated by the window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0052] In combination with the fourth aspect, in a possible implementation, the above-mentioned window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length in the second communication device, or a link bandwidth capacity of the second communication device.

[0053] In combination with the fourth aspect, in a possible implementation, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0054] In combination with the fourth aspect, in a possible implementation, the window information 2 may be carried in a frame header of the data link layer, a packet header of the network layer, or a message header of the transport layer of the data message 2.

[0055] In combination with the fourth aspect, in a possible implementation, the data (or payload) in the above-mentioned data message 2 may be the same as the data (or payload) in the above-mentioned data message 1.

[0056] In a fifth aspect, the present application provides a communication device, which may be a second communication device or a chip or functional module configured in the second communication device, and the communication device includes a processing unit and a transceiver unit. The transceiver unit is used to send a data message 1, wherein the data message 1 includes window information 1, and the window information 1 is used to request adjustment of the data sending window; the transceiver unit is also used to receive a data message 3 from a third communication device, wherein the data message 3 includes window information 2, and the window information 2 is used to indicate the data sending window; the processing unit is used to determine the data sending window based on the window information 2 in the data message 3.

[0057] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0058] In conjunction with the fifth aspect, in a possible implementation, the size of the sending window indicated by the window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0059] In combination with the fifth aspect, in a possible implementation method, the above-mentioned processing unit is specifically used to: when the size of the sending window indicated by the above-mentioned window information 2 is equal to the size of the sending window requested to be adjusted by the above-mentioned window information 1, adjust the data sending window to the size of the sending window requested to be adjusted by the above-mentioned window information 1; when the size of the sending window indicated by the above-mentioned window information 2 is smaller than the size of the sending window requested to be adjusted by the above-mentioned window information 1, adjust the data sending window to the sending window size indicated by the window information 2.

[0060] In combination with the fifth aspect, in a possible implementation, the above-mentioned window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length in the second communication device, or a link bandwidth capacity of the second communication device.

[0061] In combination with the fifth aspect, in a possible implementation, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0062] In combination with the fifth aspect, in a possible implementation, the data packet 3 may include layer 3 or layer 4 feedback information of RDMA, and the layer 3 or layer 4 feedback information of RDMA may carry the window information 2.

[0063] It is understandable that the data (or payload) in the data message 3 is different from the data (or payload) in the data message 1. However, the data message 3 and the data message 1 belong to the same QoS flow or the same session.

[0064] In a sixth aspect, the present application provides a communication device, which may be a third communication device or a chip or functional module configured in the third communication device, and includes a processing unit and a transceiver unit. The transceiver unit is configured to receive a data message 2 from a first communication device, the data message 2 including the window information 2, the window information 2 being used to indicate a data sending window; and the transceiver unit is further configured to send a data message 3 to a second communication device, the data message 3 including the window information 2.

[0065] Exemplarily, the processing unit 20 is configured to generate a data packet 3 .

[0066] In combination with the sixth aspect, in a possible implementation, the above-mentioned window information 2 can be carried in the frame header of the data link layer of the above-mentioned data message 2, or the packet header of the network layer, or the message header of the transport layer.

[0067] In combination with the sixth aspect, in a possible implementation, the data packet 3 may include layer 3 or layer 4 feedback information of RDMA, and the layer 3 or layer 4 feedback information of RDMA may carry the window information 2.

[0068] In a seventh aspect, the present application provides a congestion control method, which is applied to a first communication device, such as a base station. The method includes: the first communication device receives a data packet 1 from a second communication device, where the data packet 1 includes window information 1, where the window information 1 is used to request adjustment of a data sending window; and the first communication device sends a data packet 3 to the second communication device, where the data packet 3 includes window information 2, where the window information 2 is used to indicate a data sending window. The window information 2 can be determined based on air interface resources and the aforementioned window information 1.

[0069] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0070] Exemplarily, the second communication device is an in-network computing node, and the third communication device is a terminal. Alternatively, the second communication device is a terminal, and the third communication device is an in-network computing node. Alternatively, the second communication device is a terminal, and the third communication device is an off-network computing node (such as an edge server / cloud server); or, the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal.

[0071] After the first communication device (such as a base station) of the present application receives a data packet containing window information 1 (the window information 1 is used to request adjustment of the data sending window), it determines a sending window size for the second communication device (data sending end) by sensing the usage and / or remaining status of the air interface resources and combining the window information 1, and indicates the sending window size (i.e., window information 2) to the second communication device; the size of the sending window actually used by the second communication device can be made more compatible with the transmission capability of the first communication device (such as a base station), and packet loss in the network can be reduced (or no packet loss) and data transmission delay, thereby improving the reliability and throughput of data transmission, thereby achieving low-latency, high-throughput data transmission.

[0072] In combination with the seventh aspect, in a possible implementation, after the first communication device receives the data message 1 from the second communication device, the method further includes: the first communication device sends a data message 2 to the third communication device, and the data message 2 includes the window information 2.

[0073] Exemplarily, the window information 2 may be carried in a frame header of the data link layer, a packet header of the network layer, or a message header of the transport layer of the data message 2 .

[0074] Exemplarily, the data (or payload) in the data message 2 may be the same as the data (or payload) in the above-mentioned data message 1.

[0075] This application carries window information 2 in data message 2, so that the third communication device can know the sending window size of the second communication device at the next moment, so as to prepare for receiving data.

[0076] In conjunction with the seventh aspect, in one possible implementation, the method further includes: the first communication device determining window information 2 based on the window information 1 in the data packet 1 and the air interface resources. Alternatively, the first communication device determines window information 2 based on the window information 1 in the data packet 1, the air interface resources, and the cache resources of the first communication device. The specific implementation of the first communication device determining window information 2 is described in the following method embodiment and is not detailed here.

[0077] Exemplarily, the air interface resources include one or more of the following: air interface channel status / channel quality (e.g., wireless channel gain or path loss), or air interface bandwidth conditions (e.g., system bandwidth allocation or remaining bandwidth resources within the first communication device). Exemplarily, the buffer resources of the first communication device include, but are not limited to, the lengths of various buffer queues for shared air interface resources (e.g., time-frequency resources) within the first communication device.

[0078] Exemplarily, the size of the sending window indicated by the window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0079] In combination with the seventh aspect, in a possible implementation, the data packet 3 includes layer 3 or layer 4 feedback information of RDMA, and the layer 3 or layer 4 feedback information of RDMA includes the window information 2.

[0080] Exemplarily, the data packet 3 and the data packet 1 belong to the same QoS flow or the same session.

[0081] In conjunction with the seventh aspect, in one possible implementation, the data packet 3 includes a user plane General Packet Radio Service (GPRS) Tunneling Protocol (GTP-u) header, and the GTP-u header includes the window information 2. Exemplarily, the data packet 3 and the data packet 1 belong to the same QoS flow or the same session. Alternatively, the data in the data packet 3 is dummy data.

[0082] In combination with the seventh aspect, in a possible implementation, the data message 3 includes a Uu layer 2 header or a layer 2 control protocol data unit (PDU), and the UuL2 header or L2 control PDU includes the window information 2.

[0083] The first communication device of the present application directly sends window information 2 (the window information 2 is used to indicate the data sending window) to the second communication device, which can reduce the window information 2 (or congestion control information) from bypassing the air interface, thereby making congestion control (or adjustment of the sending window) more timely and achieving low latency and high throughput of data transmission.

[0084] In conjunction with the seventh aspect, in one possible implementation, the window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device. It is understood that the window information 2 and the window information 1 may be information of the same dimension.

[0085] In combination with the seventh aspect, in a possible implementation, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0086] In an eighth aspect, the present application provides a congestion control method, which includes: a second communication device sends a data packet 1 (to a first communication device), the data packet 1 including window information 1, and the window information 1 is used to request adjustment of a data sending window; the second communication device receives a data packet 3 from the first communication device, the data packet 3 including window information 2, and the window information 2 is used to indicate a data sending window; the second communication device determines the data sending window based on the window information 2 in the data packet 3.

[0087] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0088] Exemplarily, the first communication device is a base station.

[0089] Exemplarily, the second communication device is an in-network computing node, and the third communication device is a terminal. Alternatively, the second communication device is a terminal, and the third communication device is an in-network computing node. Alternatively, the second communication device is a terminal, and the third communication device is an off-network computing node (such as an edge server / cloud server); or, the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal.

[0090] The second communication device of the present application actively requests to adjust the data sending window according to its own cache situation and internal strategy, and the first communication device feeds back congestion control information (i.e., window information 2) to the second communication device, which can not only reduce packet loss and data transmission delay in the network and provide data transmission reliability; it can also reduce the detour of window information 2 through the air interface, thereby making congestion control (or adjustment of the sending window) more timely and achieving low latency and high throughput of data transmission.

[0091] In combination with the eighth aspect, in a possible implementation manner, the size of the sending window indicated by the above-mentioned window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the above-mentioned window information 1.

[0092] In conjunction with the eighth aspect, in one possible implementation, the second communication device determines the data sending window based on the window information 2 in the data message 3, including: if the size of the sending window indicated by the window information 2 is equal to the size of the sending window requested to be adjusted by the window information 1, the second communication device can adjust (for example, increase) the sending window at the next moment to its own desired sending window size (i.e., the size of the sending window requested to be adjusted by the window information 1, or the size of the sending window indicated by the window information 2). If the size of the sending window indicated by the window information 2 is smaller than the size of the sending window requested to be adjusted by the window information 1, the second communication device can adjust (possibly increase or decrease) the sending window at the next moment to the sending window size indicated by the window information 2. The specific adjustment method is described in the embodiment below and is not described in detail here.

[0093] In conjunction with the eighth aspect, in one possible implementation, the data packet 3 includes RDMA layer 3 or layer 4 feedback information, and the RDMA layer 3 or layer 4 feedback information includes the window information 2. Exemplarily, the data packet 3 and the data packet 1 belong to the same QoS flow or the same session.

[0094] In conjunction with the eighth aspect, in one possible implementation, the data packet 3 includes a GTP-u header, which includes the window information 2. Exemplarily, the data packet 3 and the data packet 1 belong to the same QoS flow or the same session. Alternatively, the data in the data packet 3 is dummy data.

[0095] In combination with the eighth aspect, in a possible implementation, the data message 3 includes a Uu layer 2 header or a layer 2 control PDU, and the UuL2 header or L2 control PDU includes the window information 2.

[0096] In conjunction with the eighth aspect, in one possible implementation, the window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device. It is understood that the window information 2 and the window information 1 may be information of the same dimension.

[0097] In combination with the eighth aspect, in a possible implementation, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0098] In a ninth aspect, the present application provides a congestion control method, which includes: a third communication device receives a data packet 2 from a first communication device, where the data packet 2 includes the window information 2, and the window information 2 is used to indicate a data sending window.

[0099] Exemplarily, the first communication device is a base station.

[0100] In combination with the ninth aspect, in a possible implementation, the above-mentioned window information 2 can be carried in the frame header of the data link layer of the above-mentioned data message 2, or the packet header of the network layer, or the message header of the transport layer.

[0101] In conjunction with the ninth aspect, in one possible implementation, after the third communication device receives data packet 2 from the first communication device, the method further includes: the third communication device sending a feedback message to the second communication device. The data carried in the feedback message is different from the data carried in data packet 2, but the feedback message and data packet 2 may belong to the same QoS flow or the same session.

[0102] It is understood that the "feedback message" in this application can be understood as a data message carrying feedback information, which will not be described in detail below. Exemplarily, the feedback information can be carried in the header of the data message.

[0103] In a tenth aspect, the present application provides a communication device, which may be a first communication device or a chip or functional module configured in the first communication device, and the communication device includes a processing unit and a transceiver unit. The transceiver unit is configured to receive a data message 1 from a second communication device, where the data message 1 includes window information 1, where the window information 1 is used to request adjustment of a data sending window; the transceiver unit is further configured to send a data message 3 to the second communication device, where the data message 3 includes window information 2, where the window information 2 is used to indicate a data sending window, where the window information 2 is determined based on air interface resources and the above-mentioned window information 1.

[0104] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0105] In combination with the tenth aspect, in a possible implementation, the above-mentioned transceiver unit is further used to send a data message 2 to a third communication device, where the data message 2 includes the window information 2.

[0106] Exemplarily, the window information 2 may be carried in a frame header of the data link layer, a packet header of the network layer, or a message header of the transport layer of the data message 2 .

[0107] Exemplarily, the data (or payload) in the data message 2 may be the same as the data (or payload) in the above-mentioned data message 1.

[0108] In conjunction with the tenth aspect, in one possible implementation, the processing unit is configured to determine window information 2 based on the window information 1 and the air interface resources in the data packet 1. Alternatively, the processing unit is configured to determine window information 2 based on the window information 1 in the data packet 1, the air interface resources, and the cache resources of the first communication device.

[0109] Exemplarily, the air interface resources include one or more of the following: air interface channel status / channel quality (e.g., wireless channel gain or path loss), or air interface bandwidth conditions (e.g., system bandwidth allocation or remaining bandwidth resources within the first communication device). Exemplarily, the buffer resources of the first communication device include, but are not limited to, the lengths of various buffer queues for shared air interface resources (e.g., time-frequency resources) within the first communication device.

[0110] Exemplarily, the size of the sending window indicated by the window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0111] In conjunction with the tenth aspect, in one possible implementation, the data packet 3 includes RDMA layer 3 or layer 4 feedback information, and the RDMA layer 3 or layer 4 feedback information includes the window information 2. Exemplarily, the data packet 3 and the data packet 1 belong to the same QoS flow or the same session.

[0112] In conjunction with the tenth aspect, in one possible implementation, the data packet 3 includes a GTP-u header, which includes the window information 2. Exemplarily, the data packet 3 and the data packet 1 belong to the same QoS flow or the same session. Alternatively, the data in the data packet 3 is dummy data.

[0113] In combination with the tenth aspect, in a possible implementation manner, the above-mentioned data message 3 includes a Uu layer 2 header or an L2 control PDU, and the UuL2 header or the L2 control PDU includes the above-mentioned window information 2.

[0114] In conjunction with the tenth aspect, in one possible implementation, the window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device. It is understood that the window information 2 and the window information 1 may be information of the same dimension.

[0115] In combination with the tenth aspect, in a possible implementation, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0116] In an eleventh aspect, the present application provides a communication device, which may be a second communication device or a chip or functional module configured in the second communication device, and the communication device includes a processing unit and a transceiver unit. The transceiver unit is configured to send a data message 1, wherein the data message 1 includes window information 1, and the window information 1 is used to request adjustment of the data sending window; the transceiver unit is also configured to receive a data message 3 from the first communication device, wherein the data message 3 includes window information 2, and the window information 2 is used to indicate the data sending window; the processing unit is configured to determine the data sending window based on the window information 2 in the data message 3.

[0117] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0118] In conjunction with the eleventh aspect, in a possible implementation manner, the size of the sending window indicated by the above-mentioned window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the above-mentioned window information 1.

[0119] In combination with the eleventh aspect, in a possible implementation method, the above-mentioned processing unit is specifically used to: when the size of the sending window indicated by the above-mentioned window information 2 is equal to the size of the sending window requested to be adjusted by the above-mentioned window information 1, adjust the sending window of the data to the size of the sending window requested to be adjusted by the above-mentioned window information 1 that it expects; when the size of the sending window indicated by the above-mentioned window information 2 is smaller than the size of the sending window requested to be adjusted by the above-mentioned window information 1, adjust the sending window of the data to the sending window size indicated by the window information 2.

[0120] In conjunction with the eleventh aspect, in one possible implementation, the data packet 3 includes RDMA layer 3 or layer 4 feedback information, and the RDMA layer 3 or layer 4 feedback information includes the window information 2. Exemplarily, the data packet 3 and the data packet 1 belong to the same QoS flow or the same session.

[0121] In conjunction with the eleventh aspect, in one possible implementation, the data packet 3 includes a GTP-u header, which includes the window information 2. Exemplarily, the data packet 3 and the data packet 1 belong to the same QoS flow or the same session. Alternatively, the data in the data packet 3 is dummy data.

[0122] In combination with the eleventh aspect, in a possible implementation manner, the above-mentioned data message 3 includes a Uu layer 2 header or a layer 2 control PDU, and the UuL2 header or L2 control PDU includes the above-mentioned window information 2.

[0123] In conjunction with the eleventh aspect, in one possible implementation, the window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device. It is understood that the window information 2 and the window information 1 may be information of the same dimension.

[0124] In combination with the eleventh aspect, in a possible implementation, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0125] In a twelfth aspect, the present application provides a communication device, which may be a third communication device or a chip or functional module configured in the third communication device, wherein the communication device includes a processing unit and a transceiver unit. The transceiver unit is configured to receive a data message 2 from a first communication device, wherein the data message 2 includes the window information 2, and the window information 2 is configured to indicate a data sending window.

[0126] In conjunction with the twelfth aspect, in one possible implementation, the transceiver unit is further configured to send a feedback message to the second communication device. The data carried by the feedback message is different from the data carried by the data message 2, but the feedback message and the data message 2 may belong to the same QoS flow or the same session.

[0127] In a thirteenth aspect, the present application provides a congestion control method, which is applied to a first communication device, such as a base station. The method includes: the first communication device receiving a data packet 2 from a UPF, the data packet 2 including a downlink GTP-u header, the downlink GTP-u header including window information 1, the window information 1 being used to request adjustment of a data send window; and the first communication device sending a data packet 4 to the UPF, the data packet 4 including an uplink GTP-u header, the uplink GTP-u header including window information 2, the window information 2 being used to indicate a data send window. Window information 2 can be determined based on air interface resources and the aforementioned window information 1.

[0128] The first communication device of the present application receives a data message 2 from the UPF. By carrying the window information 1 in the downlink GTP-u header of the data message 2, the first communication device (such as a base station) does not need to perform deep packet inspection on the received data message, which can reduce the complexity of the first communication device (such as a base station) and reduce the changes to the existing base station equipment. In addition, the first communication device of the present application determines a sending window size for the second communication device (data sending end) by sensing the usage and / or remaining status of the air interface resources and combining the window information 1, and informs the UPF so that the UPF notifies the second communication device of the sending window size indicated by the first communication device (i.e., window information 2), thereby making the size of the sending window actually used by the second communication device more compatible with the transmission capacity of the first communication device (such as a base station), and reducing packet loss in the network (or achieving no packet loss) and data transmission delay, improving the reliability and throughput of data transmission, and thus achieving low-latency, high-throughput data transmission.

[0129] In conjunction with the thirteenth aspect, in one possible implementation, after the first communication device receives the data packet 2 from the UPF, the method further includes: the first communication device sending a data packet 3 to a third communication device, where the data packet 3 includes the above-mentioned window information 2. Exemplarily, the window information 2 may be carried in a frame header of the data link layer, a packet header of the network layer, or a message header of the transport layer of the data packet 3.

[0130] Exemplarily, the data (or payload) in the data message 3 may be the same as the data (or payload) in the above-mentioned data message 2.

[0131] In conjunction with the thirteenth aspect, in one possible implementation, the method further includes: the first communication device determining window information 2 based on the window information 1 and air interface resources. Alternatively, the first communication device determines window information 2 based on the window information 1, air interface resources, and cache resources of the first communication device. The specific implementation of the first communication device determining window information 2 is described in the method embodiment below and is not detailed here.

[0132] Exemplarily, the air interface resources include one or more of the following: air interface channel status / channel quality (e.g., wireless channel gain or path loss), or air interface bandwidth conditions (e.g., system bandwidth allocation or remaining bandwidth resources within the first communication device). Exemplarily, the buffer resources of the first communication device include, but are not limited to, the lengths of various buffer queues for shared air interface resources (e.g., time-frequency resources) within the first communication device.

[0133] Exemplarily, the size of the sending window indicated by the window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0134] In conjunction with the thirteenth aspect, in one possible implementation, the data (or payload) in the data packet 4 and the data (or payload) in the data packet 2 belong to the same QoS flow or the same session. Alternatively, the data in the data packet 4 is dummy data.

[0135] In conjunction with the thirteenth aspect, in one possible implementation, the window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device. It is understood that the window information 2 and the window information 1 may be information of the same dimension.

[0136] In the fourteenth aspect, the present application provides a congestion control method, which includes: UPF receives a data packet 1 from a second communication device, and the data packet 1 includes window information 1, and the window information 1 is used to request adjustment of the data sending window; UPF sends a data packet 2 to the first communication device, and the data packet 2 includes a downlink GTP-u header, and the downlink GTP-u header includes the window information 1, and the data packet 2 is generated based on the data packet 1; UPF receives a data packet 4 from the first communication device, and the data packet 4 includes an uplink GTP-u header, and the uplink GTP-u header includes window information 2, and the window information 2 is used to indicate the data sending window; UPF sends a data packet 5 to the second communication device, and the data packet 5 includes the window information 2.

[0137] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0138] Exemplarily, the first communication device is a base station.

[0139] Exemplarily, the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal.

[0140] After receiving data packet 1 containing window information 1, the UPF of the present application carries the window information 1 in the downlink GTP-u header and sends it to the first communication device. The first communication device does not need to perform deep packet inspection on the received data packet, which can reduce the complexity of the first communication device (such as a base station) and reduce the changes to the existing base station equipment. In addition, the UPF of the present application notifies the second communication device of the sending window size (i.e., window information 2) indicated by the first communication device, so that the size of the sending window actually used by the second communication device can be more closely matched with the transmission capacity of the first communication device (such as a base station), and can reduce packet loss in the network (or achieve no packet loss) and data transmission delay, improve the reliability and throughput of data transmission, and thus achieve low-latency, high-throughput data transmission.

[0141] In conjunction with the fourteenth aspect, in one possible implementation, the method further includes: the UPF generating data message 2 based on the data message 1. Exemplarily, the UPF adds a downlink GTP-u header to the data message 1 to obtain data message 2, where the downlink GTP-u header carries the window information 1.

[0142] In combination with the fourteenth aspect, in a possible implementation, the size (size) of the sending window indicated by the above-mentioned window information 2 is smaller than or equal to the size (size) of the sending window requested to be adjusted by the above-mentioned window information 1.

[0143] In combination with the fourteenth aspect, in a possible implementation, the data packet 5 includes layer 3 or layer 4 feedback information of RDMA, and the layer 3 or layer 4 feedback information of RDMA includes the window information 2.

[0144] Exemplarily, the data packet 5 and the data packet 1 belong to the same QoS flow or the same session.

[0145] Illustratively, the data message 5 may not include data.

[0146] In combination with the fourteenth aspect, in a possible implementation method, the UPF sends the data packet 5 to the second communication device, including: the UPF sends the data packet 5 to the second communication device through an application programming interface (API).

[0147] In conjunction with the fourteenth aspect, in one possible implementation, the data (or payload) in data packet 4 and the data (or payload) in data packet 2 or data packet 1 belong to the same QoS flow or the same session. Alternatively, the data in data packet 4 is dummy data.

[0148] In conjunction with the fourteenth aspect, in one possible implementation, the window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device. It is understood that the window information 2 and the window information 1 may be information of the same dimension.

[0149] In combination with the fourteenth aspect, in a possible implementation, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0150] In a fifteenth aspect, the present application provides a congestion control method, comprising: a second communication device sending a data packet 1 (to a UPF), the data packet 1 including window information 1, the window information 1 being used to request adjustment of a data send window; the second communication device receiving a data packet 5 from the UPF, the data packet 5 including window information 2, the window information 2 being used to indicate a data send window; and the second communication device determining the data send window based on the window information 2 in the data packet 5. Regarding the implementation of the second communication device determining the data send window based on the window information 2, refer to the previous description and are not repeated here.

[0151] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0152] Exemplarily, the first communication device is a base station.

[0153] Exemplarily, the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal.

[0154] The second communication device of the present application actively requests to adjust the data sending window according to its own cache situation and internal strategy, and feeds back congestion control information (i.e., window information 2) to the second communication device through UPF, which can not only reduce packet loss and data transmission delay in the network and provide data transmission reliability; it can also reduce the detour of window information 2 through the air interface, thereby making congestion control (or adjustment of the sending window) more timely and achieving low latency and high throughput of data transmission.

[0155] In combination with the fifteenth aspect, in a possible implementation, the size (size) of the sending window indicated by the above-mentioned window information 2 is less than or equal to the size (size) of the sending window requested to be adjusted by the above-mentioned window information 1.

[0156] In combination with the fifteenth aspect, in a possible implementation, the data packet 5 includes layer 3 or layer 4 feedback information of RDMA, and the layer 3 or layer 4 feedback information of RDMA includes the window information 2.

[0157] Exemplarily, the data packet 5 and the data packet 1 belong to the same QoS flow or the same session.

[0158] Illustratively, the data message 5 may not include data.

[0159] In combination with the fifteenth aspect, in a possible implementation method, the second communication device receives the data message 5 from the UPF, including: the second communication device receives the data message 5 from the UPF through the API.

[0160] In conjunction with the fifteenth aspect, in one possible implementation, the window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device. It is understood that the window information 2 and the window information 1 may be information of the same dimension.

[0161] In combination with the fifteenth aspect, in a possible implementation, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0162] In a sixteenth aspect, the present application provides a communication device, which may be a first communication device or a chip or functional module configured in the first communication device, and includes a processing unit and a transceiver unit. The transceiver unit is configured to receive a data packet 2 from a UPF, where the data packet 2 includes a downlink GTP-u header, where the downlink GTP-u header includes window information 1, where the window information 1 is used to request adjustment of a data sending window; and the transceiver unit is further configured to send a data packet 4 to the UPF, where the data packet 4 includes an uplink GTP-u header, where the uplink GTP-u header includes window information 2, where the window information 2 is used to indicate a data sending window.

[0163] In conjunction with the sixteenth aspect, in one possible implementation, the transceiver unit is further configured to send a data message 3 to a third communication device, where the data message 3 includes the window information 2. Exemplarily, the window information 2 may be carried in a frame header of a data link layer, a packet header of a network layer, or a message header of a transport layer of the data message 3.

[0164] Exemplarily, the data (or payload) in the data message 3 may be the same as the data (or payload) in the above-mentioned data message 2.

[0165] In conjunction with the sixteenth aspect, in one possible implementation, the processing unit is configured to determine window information 2 based on the window information 1 and the air interface resources. Alternatively, the processing unit is configured to determine window information 2 based on the window information 1, the air interface resources, and the cache resources of the first communication device.

[0166] Exemplarily, the air interface resources include one or more of the following: air interface channel status / channel quality (e.g., wireless channel gain or path loss), or air interface bandwidth conditions (e.g., system bandwidth allocation or remaining bandwidth resources within the first communication device). Exemplarily, the buffer resources of the first communication device include, but are not limited to, the lengths of various buffer queues for shared air interface resources (e.g., time-frequency resources) within the first communication device.

[0167] Exemplarily, the size of the sending window indicated by the window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0168] In conjunction with the sixteenth aspect, in one possible implementation, the data (or payload) in the data packet 4 and the data (or payload) in the data packet 2 belong to the same QoS flow or the same session. Alternatively, the data in the data packet 4 is dummy data.

[0169] In conjunction with the sixteenth aspect, in one possible implementation, the window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device. It is understood that the window information 2 and the window information 1 may be information of the same dimension.

[0170] In a seventeenth aspect, the present application provides a communication device, which may be a UPF or a chip or functional module configured in a UPF, and the communication device includes a processing unit and a transceiver unit. The transceiver unit is used to receive a data message 1 from a second communication device, the data message 1 including window information 1, the window information 1 being used to request adjustment of a data sending window; the transceiver unit is also used to send a data message 2 to a first communication device, the data message 2 including a downlink GTP-u header, the downlink GTP-u header including the window information 1, the data message 2 being generated based on the data message 1; the transceiver unit is also used to receive a data message 4 from the first communication device, the data message 4 including an uplink GTP-u header, the uplink GTP-u header including window information 2, the window information 2 being used to indicate a data sending window; the transceiver unit is also used to send a data message 5 to the second communication device, the data message 5 including the window information 2.

[0171] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0172] In conjunction with the seventeenth aspect, in one possible implementation, the processing unit is configured to generate data message 2 based on the data message 1. Exemplarily, the processing unit is specifically configured to add a downlink GTP-u header to the data message 1 to obtain data message 2, where the downlink GTP-u header carries the window information 1.

[0173] In combination with the seventeenth aspect, in a possible implementation, the size (size) of the sending window indicated by the above-mentioned window information 2 is less than or equal to the size (size) of the sending window requested to be adjusted by the above-mentioned window information 1.

[0174] In combination with the seventeenth aspect, in a possible implementation, the data packet 5 includes layer 3 or layer 4 feedback information of RDMA, and the layer 3 or layer 4 feedback information of RDMA includes the window information 2.

[0175] Exemplarily, the data packet 5 and the data packet 1 belong to the same QoS flow or the same session.

[0176] Illustratively, the data message 5 may not include data.

[0177] In combination with the seventeenth aspect, in a possible implementation method, the above-mentioned transceiver unit is specifically used to: API sends data message 5 to the second communication device.

[0178] In conjunction with the seventeenth aspect, in one possible implementation, the data (or payload) in data packet 4 and the data (or payload) in data packet 2 or data packet 1 belong to the same QoS flow or the same session. Alternatively, the data in data packet 4 is dummy data.

[0179] In conjunction with the seventeenth aspect, in one possible implementation, the window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device. It is understood that the window information 2 and the window information 1 may be information of the same dimension.

[0180] In combination with the seventeenth aspect, in a possible implementation, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0181] In an eighteenth aspect, the present application provides a communication device, which may be a second communication device or a chip or functional module configured in the second communication device, and includes a processing unit and a transceiver unit. The transceiver unit is configured to send a data message 1, wherein the data message 1 includes window information 1, and the window information 1 is used to request adjustment of a data sending window; the transceiver unit is further configured to receive a data message 5 from a UPF, wherein the data message 5 includes window information 2, and the window information 2 is used to indicate a data sending window; and the processing unit is configured to determine the data sending window based on the window information 2 in the data message 5.

[0182] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0183] In combination with the eighteenth aspect, in a possible implementation, the size of the sending window indicated by the above-mentioned window information 2 is less than or equal to the size of the sending window requested to be adjusted by the above-mentioned window information 1.

[0184] In combination with the eighteenth aspect, in a possible implementation, the data packet 5 includes layer 3 or layer 4 feedback information of RDMA, and the layer 3 or layer 4 feedback information of RDMA includes the window information 2.

[0185] Exemplarily, the data packet 5 and the data packet 1 belong to the same QoS flow or the same session.

[0186] Illustratively, the data message 5 may not include data.

[0187] In combination with the eighteenth aspect, in a possible implementation method, the above-mentioned transceiver unit is specifically used to: receive the data message 5 from the UPF through the API.

[0188] In a nineteenth aspect, the present application provides a congestion control method, comprising: a UPF receiving a data packet 1 from a second communication device, the data packet 1 including window information 1, the window information 1 being used to request adjustment of a data sending window; the UPF sending a data packet 2 to a first communication device, the data packet 2 including window information 2, the window information 2 being used to indicate a data sending window, the window information 2 being determined based on the window information 1 and a cache resource of the UPF; the UPF receiving a data packet 4 from the first communication device, the data packet 4 including an uplink GTP-u header, the uplink GTP-u header including window information 3; the UPF sending a data packet 5 to the second communication device, the data packet 5 including the window information 3. The window information 3 is used to indicate a data sending window, and a size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window indicated by the window information 2.

[0189] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0190] Exemplarily, the first communication device is a base station.

[0191] Exemplarily, the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal.

[0192] After the UPF of the present application receives a data packet containing window information 1, it can determine window information 2 based on its own cache resources and the window information 1, and then inform the first communication device (such as a base station) of the window information 2 so that the first communication device also participates in the adjustment of the sending window. The UPF returns the window information 3 finally determined by the first communication device to the second communication device; the size of the sending window used by the second communication device can be better matched with the transmission capacity of the intermediate network element (such as the UPF and the first communication device), thereby reducing packet loss in the network (or achieving no packet loss) and data transmission delay, improving the reliability and throughput of data transmission, and thus achieving low-latency, high-throughput data transmission. In addition, since the intermediate network elements (UPF and base stations) in the mobile network are involved in congestion control, the transmission capacity of all bottleneck nodes (such as UPF and base stations) is taken into account, thereby improving the service quality of RDMA.

[0193] In conjunction with the nineteenth aspect, in one possible implementation, the method further includes: the UPF determining window information 2 based on the window information 1 and the UPF's cache resources, where the window information 2 indicates a data sending window. The implementation of the UPF determining window information 2 is described in the following embodiments and is not detailed here.

[0194] Exemplarily, the size of the sending window indicated by the window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0195] In combination with the nineteenth aspect, in a possible implementation method, the UPF sends the data packet 5 to the second communication device, including: the UPF sends the data packet 5 to the second communication device through the API.

[0196] In the twentieth aspect, the present application provides a communication device, which may be a UPF or a chip or functional module configured in the UPF, and the communication device includes a processing unit and a transceiver unit. The transceiver unit is used to receive a data message 1 from a second communication device, wherein the data message 1 includes window information 1, and the window information 1 is used to request adjustment of the data sending window; the transceiver unit is also used to send a data message 2 to the first communication device, wherein the data message 2 includes window information 2, and the window information 2 is used to indicate the data sending window, and the window information 2 is determined based on the window information 1 and the cache resources of the UPF; the transceiver unit is also used to receive a data message 4 from the first communication device, wherein the data message 4 includes an uplink GTP-u header, and the uplink GTP-u header includes window information 3; the transceiver unit is also used to send a data message 5 to the second communication device, wherein the data message 5 includes the window information 3. The window information 3 is used to indicate the data sending window, and the size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window indicated by the above-mentioned window information 2.

[0197] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0198] In combination with the twentieth aspect, in a possible implementation, the processing unit is used to determine window information 2 based on the above-mentioned window information 1 and the cache resources of the UPF, and the window information 2 is used to indicate the data sending window.

[0199] Exemplarily, the size of the sending window indicated by the window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0200] In combination with the twentieth aspect, in a possible implementation, the above-mentioned transceiver unit is specifically used to: send a data message 5 to the second communication device through the API.

[0201] In combination with the nineteenth aspect or the twentieth aspect, in a possible implementation, the data packet 5 includes layer 3 or layer 4 feedback information of RDMA, and the layer 3 or layer 4 feedback information of RDMA includes the window information 3.

[0202] Exemplarily, the data packet 5 and the data packet 1 belong to the same QoS flow or the same session.

[0203] Illustratively, the data message 5 may not include data.

[0204] In combination with the nineteenth aspect or the twentieth aspect, in one possible implementation, the data (or payload) in the data packet 4 and the data (or payload) in the data packet 2 or the data packet 1 belong to the same QoS flow or the same session. Alternatively, the data in the data packet 4 is dummy data.

[0205] In conjunction with the nineteenth aspect or the twentieth aspect, in one possible implementation, the window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device. It is understood that the window information 2 and the window information 1 may be information of the same dimension.

[0206] In combination with the nineteenth aspect or the twentieth aspect, in a possible implementation method, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0207] In combination with the nineteenth aspect or the twentieth aspect, in a possible implementation, the above-mentioned window information 2 can be carried in the frame header of the data link layer of the above-mentioned data message 2, or the packet header of the network layer, or the message header of the transport layer.

[0208] In the twenty-first aspect, the present application provides a congestion control method, which is applied to a first communication device, such as a base station. The method includes: the first communication device receives a data packet 2 from the UPF, and the data packet 2 includes window information 2, and the window information 2 is used to indicate the sending window of the data; the first communication device sends a data packet 4 to the UPF, and the data packet 4 includes an uplink GTP-u header, and the uplink GTP-u header includes window information 3, and the window information 3 is used to indicate the sending window of the data. The window information 3 can be determined based on the air interface resources and the above-mentioned window information 2. The size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window indicated by the above-mentioned window information 2. It can be understood that the window information 3 and the window information 2 are information of the same dimension.

[0209] After the first communication device of the present application receives a data packet containing window information 2, it determines window information 3 based on the perceived air interface resources and the window information 2, and returns the window information 3 to the UPF, so that the UPF notifies the second communication device of the window information 3, thereby making the size of the sending window actually used by the second communication device better match the transmission capacity of the intermediate network element (such as the UPF and the first communication device), thereby reducing packet loss in the network (or achieving no packet loss) and data transmission delay, improving data transmission reliability and throughput, and thus achieving low-latency, high-throughput data transmission. In addition, the first communication device of the present application informs the UPF of "window information 3 (or congestion control information)" through the GTP-u header, which can reduce the detour of window information 3 (or congestion control information) in the air interface, thereby making congestion control (or adjustment of the sending window) more timely and achieving faster adjustment of the data transmission rate.

[0210] In conjunction with the twenty-first aspect, in one possible implementation, the method further includes: the first communication device determines window information 3 based on the window information 2 and the air interface resources, where the window information 3 is used to indicate the data sending window. Alternatively, the first communication device determines window information 3 based on the window information 2, the air interface resources, and the cache resources of the first communication device, where the window information 3 is used to indicate the data sending window. The implementation method for the first communication device to determine window information 3 is described in the following embodiment and is not described in detail here. For specific descriptions of the air interface resources and / or the cache resources of the first communication device, please refer to the previous description and are not repeated here.

[0211] In conjunction with the twenty-first aspect, in one possible implementation, after the first communication device receives the data packet 2 from the UPF, the method further includes: the first communication device sending a data packet 3 to a third communication device, where the data packet 3 includes the above-mentioned window information 2. Exemplarily, the window information 2 may be carried in a frame header of the data link layer, a packet header of the network layer, or a message header of the transport layer of the data packet 3.

[0212] Exemplarily, the data (or payload) in the data message 3 may be the same as the data (or payload) in the above-mentioned data message 2.

[0213] In the twenty-second aspect, the present application provides a communication device, which may be a first communication device or a chip or functional module configured in the first communication device, etc. The communication device includes a processing unit and a transceiver unit. The transceiver unit is used to receive a data message 2 from the UPF, and the data message 2 includes window information 2, and the window information 2 is used to indicate the sending window of the data; the transceiver unit is also used to send a data message 4 to the UPF, and the data message 4 includes an uplink GTP-u header, and the uplink GTP-u header includes window information 3, and the window information 3 is used to indicate the sending window of the data. The window information 3 can be determined based on the air interface resources and the above-mentioned window information 2. The size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window indicated by the above-mentioned window information 2.

[0214] In conjunction with the twenty-second aspect, in one possible implementation, the processing unit is configured to determine window information 3 based on the window information 2 and air interface resources, where window information 3 is used to indicate a data sending window. The processing unit is configured to determine window information 3 based on the window information 2, the air interface resources, and the cache resources of the first communication device, where window information 3 is used to indicate a data sending window.

[0215] In conjunction with the twenty-second aspect, in one possible implementation, the transceiver unit is further configured to send a data message 3 to a third communication device, where the data message 3 includes the window information 2. Exemplarily, the window information 2 may be carried in a frame header of a data link layer, a packet header of a network layer, or a message header of a transport layer of the data message 3.

[0216] Exemplarily, the data (or payload) in the data message 3 may be the same as the data (or payload) in the above-mentioned data message 2.

[0217] In combination with the twenty-first aspect or the twenty-second aspect, in one possible implementation, the data (or payload) in the data packet 4 and the data (or payload) in the data packet 2 belong to the same QoS flow or the same session. Alternatively, the data in the data packet 4 is dummy data.

[0218] In combination with aspect 21 or aspect 22, in a possible implementation, the above-mentioned window information 2 can be carried in the frame header of the data link layer of the above-mentioned data message 2, or the packet header of the network layer, or the message header of the transport layer.

[0219] In a twenty-third aspect, the present application provides a congestion control method, comprising: a second communication device sending a data packet 1 (to a UPF), the data packet 1 including window information 1, the window information 1 being used to request adjustment of a data send window; the second communication device receiving a data packet 5 from the UPF, the data packet 5 including window information 3, the window information 3 being used to indicate a data send window; and the second communication device determining the data send window based on the window information 3 in the data packet 5. The implementation of determining the data send window by the second communication device is described in the following embodiments and is not further elaborated here.

[0220] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0221] Exemplarily, the first communication device is a base station.

[0222] Exemplarily, the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal.

[0223] The second communication device of the present application actively requests to adjust the data sending window according to its own cache situation and internal strategy, and feeds back congestion control information (i.e., window information 3) to the second communication device through UPF, which can not only reduce packet loss and data transmission delay in the network and provide data transmission reliability; it can also reduce the detour of window information 3 through the air interface, thereby making congestion control (or adjustment of the sending window) more timely and achieving low latency and high throughput of data transmission.

[0224] In combination with the twenty-third aspect, in a possible implementation method, the second communication device receives the data message 5 from the UPF, including: the second communication device receives the data message 5 from the UPF through the API.

[0225] In a twenty-fourth aspect, the present application provides a communication device, which may be a second communication device or a chip or functional module configured in the second communication device, and includes a processing unit and a transceiver unit. The transceiver unit is configured to send a data message 1, wherein the data message 1 includes window information 1, and the window information 1 is used to request adjustment of a data sending window; the transceiver unit is further configured to receive a data message 5 from a UPF, wherein the data message 5 includes window information 3, and the window information 3 is used to indicate a data sending window; and the processing unit is configured to determine the data sending window based on the window information 3 in the data message 5.

[0226] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0227] In combination with the twenty-fourth aspect, in a possible implementation method, the transceiver unit is specifically used to receive the data message 5 from the UPF through the API.

[0228] In combination with the twenty-third aspect or the twenty-fourth aspect, in a possible implementation, the size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window requested to be adjusted by the window information 1.

[0229] In combination with the twenty-third aspect or the twenty-fourth aspect, in a possible implementation, the data packet 5 includes layer 3 or layer 4 feedback information of RDMA, and the layer 3 or layer 4 feedback information of RDMA includes the window information 3.

[0230] Exemplarily, the data packet 5 and the data packet 1 belong to the same QoS flow or the same session.

[0231] Illustratively, the data message 5 may not include data.

[0232] In conjunction with aspect 23 or aspect 24, in one possible implementation, the window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device. It is understood that the window information 3 and the window information 1 may be information of the same dimension.

[0233] In combination with aspect 23 or aspect 24, in a possible implementation, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0234] In aspect 25, the present application provides a congestion control method, which includes: UPF receives a data packet 1 from a second communication device, and the data packet 1 includes window information 1, and the window information 1 is used to request adjustment of the data sending window; UPF sends a data packet 2 to the first communication device, and the data packet 2 includes window information 2, and the window information 2 is used to indicate the data sending window, and the window information 2 is determined based on the window information 1 and the cache resources of the UPF.

[0235] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0236] Exemplarily, the first communication device is a base station.

[0237] Exemplarily, the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal.

[0238] After the UPF of the present application receives a data packet containing window information 1, it can determine window information 2 based on its own cache resources and the window information 1, and then inform the first communication device (such as a base station) of the window information 2, so that the first communication device can also participate in the adjustment of the sending window, so that the size of the sending window can be better matched with the transmission capacity of the intermediate network element (such as the UPF and the first communication device), thereby reducing packet loss in the network (or achieving no packet loss) and data transmission delay, improving data transmission reliability and throughput, and thus achieving low-latency, high-throughput data transmission. In addition, since the intermediate network elements (UPF and base stations) in the mobile network are involved in congestion control, the transmission capacity of all bottleneck nodes (such as UPF and base stations) is taken into account, thereby improving the service quality of RDMA.

[0239] In conjunction with the twenty-fifth aspect, in one possible implementation, the method further includes: the UPF determining window information 2 based on the window information 1 and the UPF's cache resources, where the window information 2 indicates a data sending window. The implementation of the UPF determining window information 2 is described in the following embodiments and is not detailed here.

[0240] Exemplarily, the size of the sending window indicated by the window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0241] In a twenty-sixth aspect, the present application provides a communication device, which may be a UPF or a chip or functional module configured in the UPF, and includes a processing unit and a transceiver unit. The transceiver unit is configured to receive a data packet 1 from a second communication device, where the data packet 1 includes window information 1, where the window information 1 is used to request adjustment of a data sending window; and the transceiver unit is further configured to send a data packet 2 to a first communication device, where the data packet 2 includes window information 2, where the window information 2 is used to indicate a data sending window, where the window information 2 is determined based on the window information 1 and the cache resources of the UPF.

[0242] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0243] In conjunction with the twenty-sixth aspect, in one possible implementation, the processing unit is configured to determine window information 2 based on the window information 1 and a cache resource of the UPF, where the window information 2 is used to indicate a data sending window. Exemplarily, the size of the sending window indicated by the window information 2 is less than or equal to the size of the sending window requested to be adjusted in the window information 1.

[0244] In conjunction with aspect 25 or aspect 26, in one possible implementation, the window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device. It will be appreciated that the window information 2 and the window information 1 may be information of the same dimension.

[0245] In combination with aspect 25 or aspect 26, in a possible implementation, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0246] In combination with aspect 25 or aspect 26, in a possible implementation, the above-mentioned window information 2 can be carried in the frame header of the data link layer of the above-mentioned data message 2, or the packet header of the network layer, or the message header of the transport layer.

[0247] In aspect 27, the present application provides a congestion control method, which is applied to a first communication device, such as a base station. The method includes: the first communication device receives a data packet 2 from a UPF, the data packet 2 including window information 2, the window information 2 being used to indicate a data sending window; the first communication device sends a data packet 3 to a third communication device, the data packet 3 including window information 3, the window information 3 being used to indicate a data sending window, the window information 3 being determined based on air interface resources and the window information 2. The size of the sending window indicated by the window information 3 is less than or equal to the size of the sending window indicated by the window information 2.

[0248] It can be understood that the window information 3 and the window information 2 are information of the same dimension.

[0249] After the first communication device of the present application receives a data packet containing window information 2, it determines window information 3 based on the perceived air interface resources and the window information 2, and sends the window information 3 to the third communication device, so that the third communication device can feed back the window information 3 to the second communication device. This not only reduces packet loss and data transmission delay in the network and provides data transmission reliability; it also allows the existing congestion control mechanism to be used to the greatest extent and adapted to the mobile network, which is easy to implement and has high compatibility.

[0250] In conjunction with aspect 27, in one possible implementation, the method further includes: the first communication device determines window information 3 based on the window information 2 and the air interface resources, where the window information 3 is used to indicate the data sending window. Alternatively, the first communication device determines window information 3 based on the window information 2, the air interface resources, and the cache resources of the first communication device, where the window information 3 is used to indicate the data sending window. The implementation method for determining window information 3 by the first communication device is described in the following embodiment and is not described in detail here. For specific descriptions of the air interface resources and / or the cache resources of the first communication device, please refer to the previous description and are not repeated here.

[0251] In aspect 28, the present application provides a communication device, which may be a first communication device or a chip or functional module configured in the first communication device, and the communication device includes a processing unit and a transceiver unit. The transceiver unit is used to receive a data message 2 from the UPF, and the data message 2 includes window information 2, and the window information 2 is used to indicate the sending window of the data; the transceiver unit is also used to send a data message 3 to a third communication device, and the data message 3 includes window information 3, and the window information 3 is used to indicate the sending window of the data. The window information 3 can be determined based on the air interface resources and the above-mentioned window information 2. The size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window indicated by the above-mentioned window information 2.

[0252] It can be understood that the window information 3 and the window information 2 are information of the same dimension.

[0253] In conjunction with aspect 28, in one possible implementation, the processing unit is configured to determine window information 3 based on the window information 2 and air interface resources, where window information 3 is used to indicate a data sending window. Alternatively, the processing unit is configured to determine window information 3 based on the window information 2, air interface resources, and cache resources of the first communication device, where window information 3 is used to indicate a data sending window.

[0254] In combination with the twenty-seventh aspect or the twenty-eighth aspect, the data (or payload) in the above-mentioned data message 3 may be the same as the data (or payload) in the above-mentioned data message 2.

[0255] In combination with the twenty-seventh aspect or the twenty-eighth aspect, the above-mentioned window information 2 can be carried in the frame header of the data link layer of the above-mentioned data message 2, or the packet header of the network layer, or the message header of the transport layer.

[0256] In combination with the twenty-seventh aspect or the twenty-eighth aspect, the above-mentioned window information 3 can be carried in the frame header of the data link layer of the above-mentioned data message 3, or the packet header of the network layer, or the message header of the transport layer.

[0257] In a twenty-ninth aspect, the present application provides a congestion control method, comprising: a second communication device sending a data packet 1 (to a UPF), the data packet 1 including window information 1, the window information 1 being used to request adjustment of a data sending window; the second communication device receiving a data packet 4 from a third communication device, the data packet 4 including window information 3, the window information 3 being used to indicate a data sending window; and the second communication device determining the data sending window based on the window information 3 in the data packet 4. The implementation method for determining the data sending window by the second communication device is described in the following embodiment and is not repeated here. It is understood that the window information 3 and the window information 1 are information of the same dimension.

[0258] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0259] Exemplarily, the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal.

[0260] The second communication device of the present application adjusts the size of its own sending window based on the received indication (i.e., window information 3). Since the window information 3 matches the transmission capability of the first communication device (such as a base station) and the UPF, that is, the size of the sending window actually used by the second communication device matches the transmission capability of the first communication device (such as a base station) and the UPF, it can reduce packet loss in the network (or achieve no packet loss) and data transmission delay, improve the reliability and throughput of data transmission, and thereby achieve low-latency, high-throughput data transmission.

[0261] In the thirtieth aspect, the present application provides a communication device, which may be a second communication device or a chip or functional module configured in the second communication device, and the communication device includes a processing unit and a transceiver unit. The transceiver unit is used to send a data message 1, wherein the data message 1 includes window information 1, and the window information 1 is used to request adjustment of the data sending window; the transceiver unit is also used to receive a data message 4 from a third communication device, wherein the data message 4 includes window information 3, and the window information 3 is used to indicate the data sending window; the processing unit is used to determine the data sending window based on the window information 3 in the data message 4. It can be understood that the window information 3 and the window information 1 belong to the same dimension of information.

[0262] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0263] In combination with the twenty-ninth aspect or the thirtieth aspect, in a possible implementation, the size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window requested to be adjusted by the window information 1.

[0264] In combination with the twenty-ninth aspect or the thirtieth aspect, in a possible implementation, the above-mentioned data message 4 includes layer 3 or layer 4 feedback information of RDMA, and the layer 3 or layer 4 feedback information of RDMA includes the above-mentioned window information 3.

[0265] In combination with the twenty-ninth aspect or the thirtieth aspect, in a possible implementation, the above-mentioned data packet 4 and the above-mentioned data packet 1 belong to the same QoS flow or the same session.

[0266] In combination with aspect 29 or aspect 30, in one possible implementation, the above-mentioned window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device.

[0267] In combination with the twenty-ninth aspect or the thirtieth aspect, in a possible implementation method, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0268] In a thirty-first aspect, the present application provides a congestion control method, which is applied to a first communication device, such as a base station. The method includes: the first communication device receiving a data packet 1 from a second communication device, the data packet 1 including window information 1, the window information 1 being used to request adjustment of a data sending window; and the first communication device sending a data packet 2 to a UPF, the data packet 2 including window information 2, the window information 2 being used to indicate a data sending window, the window information 2 being determined based on the window information 1 and air interface resources.

[0269] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0270] Exemplarily, the second communication device is a terminal, and the third communication device is an off-network computing node (such as an edge server / cloud server).

[0271] After the first communication device of the present application receives a data packet containing window information 1, it can determine window information 2 based on its own cache resources and the window information 1, and then inform the UPF of the window information 2 so that the UPF can also participate in the adjustment of the sending window. This can make the size of the sending window better match the transmission capacity of the intermediate network element (such as the UPF and the first communication device), thereby reducing packet loss in the network (or achieving no packet loss) and data transmission delay, improving the reliability and throughput of data transmission, and thus achieving low-latency, high-throughput data transmission. In addition, since the intermediate network elements (UPF and base stations) in the mobile network are involved in congestion control, the transmission capacity of all bottleneck nodes (such as UPF and base stations) is taken into account, thereby improving the service quality of RDMA.

[0272] In conjunction with the thirty-first aspect, in one possible implementation, the method further includes: the first communication device determining window information 2 based on the window information 1 and the air interface resources. Alternatively, the first communication device determines window information 2 based on the window information 1, the air interface resources, and the cache resources of the first communication device. The implementation of the first communication device determining window information 2 is described in the following embodiments and is not detailed here. Specific descriptions of the air interface resources and / or the cache resources of the first communication device are described above and are not repeated here.

[0273] Exemplarily, the size of the sending window indicated by the window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0274] In a thirty-second aspect, the present application provides a communication device, which may be a first communication device or a chip or functional module configured in the first communication device, and includes a processing unit and a transceiver unit. The transceiver unit is configured to receive a data packet 1 from a second communication device, where the data packet 1 includes window information 1, where the window information 1 is used to request adjustment of a data sending window; and the transceiver unit is further configured to send a data packet 2 to a UPF, where the data packet 2 includes window information 2, where the window information 2 is used to indicate a data sending window, where the window information 2 is determined based on the window information 1 and air interface resources.

[0275] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0276] In conjunction with the thirty-second aspect, in one possible implementation, the processing unit is configured to determine window information 2 based on the window information 1 and the air interface resources. Alternatively, the processing unit is configured to determine window information 2 based on the window information 1, the air interface resources, and the cache resources of the first communication device.

[0277] Exemplarily, the size of the sending window indicated by the window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0278] In conjunction with aspect 31 or aspect 32, in one possible implementation, the window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device. It will be appreciated that the window information 2 and the window information 1 may be information of the same dimension.

[0279] In combination with the thirty-first aspect or the thirty-second aspect, in a possible implementation method, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0280] In combination with the thirty-first aspect or the thirty-second aspect, in a possible implementation method, the above-mentioned window information 2 can be carried in the frame header of the data link layer of the above-mentioned data message 2, or the packet header of the network layer, or the message header of the transport layer.

[0281] In the thirty-third aspect, the present application provides a congestion control method, the method comprising: UPF receives a data packet 2 from a first communication device, the data packet 2 includes window information 2, and the window information 2 is used to indicate a sending window for the data; UPF sends a data packet 3 to a third communication device, the data packet 3 includes window information 3, and the window information 3 is used to indicate a sending window for the data, and the window information 3 is determined based on the window information 2 and the cache resources of the UPF. The size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window indicated by the above-mentioned window information 2. It can be understood that the window information 3 and the window information 2 are information of the same dimension.

[0282] After the UPF of the present application receives a data packet containing window information 2, it determines window information 3 based on its own cache resources and the window information 2, and sends the window information 3 to the third communication device, so that the third communication device can feed back the window information 3 to the second communication device. This not only reduces packet loss and data transmission delay in the network and provides reliability of data transmission; it can also maximize the use of existing congestion control mechanisms and adapt them to mobile networks, which is easy to implement and has high compatibility.

[0283] In conjunction with the thirty-third aspect, in one possible implementation, the method further includes: the UPF determining window information 3 based on the window information 2 and the UPF's cache resources. The implementation of the UPF determining window information 3 is described in the following embodiment and is not detailed here.

[0284] In the thirty-fourth aspect, the present application provides a communication device, which may be a UPF or a chip or functional module configured in the UPF, etc. The communication device includes a processing unit and a transceiver unit. The transceiver unit is used to receive a data message 2 from a first communication device, and the data message 2 includes window information 2, and the window information 2 is used to indicate the sending window of the data; the transceiver unit is also used to send a data message 3 to a third communication device, and the data message 3 includes window information 3, and the window information 3 is used to indicate the sending window of the data, and the window information 3 is determined based on the window information 2 and the cache resources of the UPF. The size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window indicated by the above-mentioned window information 2. It can be understood that the window information 3 and the window information 2 are information of the same dimension.

[0285] In combination with the thirty-fourth aspect, in a possible implementation, the processing unit is used to determine the window information 3 based on the above-mentioned window information 2 and the cache resources of the UPF.

[0286] In combination with aspect 33 or aspect 34, in a possible implementation, the above-mentioned window information 2 can be carried in the frame header of the data link layer of the above-mentioned data message 2, or the packet header of the network layer, or the message header of the transport layer.

[0287] In combination with aspect thirty-third or aspect thirty-fourth, in one possible implementation, the data (or payload) in the above-mentioned data message 3 may be the same as the data (or payload) in the above-mentioned data message 2.

[0288] In combination with aspect 33 or aspect 34, in a possible implementation, the above-mentioned window information 3 can be carried in the frame header of the data link layer of the above-mentioned data message 3, or the packet header of the network layer, or the message header of the transport layer.

[0289] In aspect 35, the present application provides a congestion control method, the method comprising: a second communication device sends a data message 1 (to a first communication device), the data message 1 including window information 1, the window information 1 being used to request adjustment of a data sending window; the second communication device receives a data message 4 from a third communication device, the data message 4 including window information 3, the window information 3 being used to indicate a data sending window; the second communication device determines the data sending window based on the window information 3 in the data message 4. The implementation method for determining the data sending window by the second communication device is described in the following embodiment and will not be repeated here. It can be understood that the window information 3 and the window information 1 belong to the same dimension of information.

[0290] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0291] Exemplarily, the second communication device is a terminal, and the third communication device is an off-network computing node (such as an edge server / cloud server).

[0292] The second communication device of the present application adjusts the size of its own sending window based on the received indication (i.e., window information 3). Since the window information 3 matches the transmission capability of the first communication device (such as a base station) and the UPF, that is, the size of the sending window actually used by the second communication device matches the transmission capability of the first communication device (such as a base station) and the UPF, it can reduce packet loss in the network (or achieve no packet loss) and data transmission delay, improve the reliability and throughput of data transmission, and thereby achieve low-latency, high-throughput data transmission.

[0293] In a thirty-sixth aspect, the present application provides a communication device, which may be a second communication device or a chip or functional module configured in the second communication device, and the communication device includes a processing unit and a transceiver unit. The transceiver unit is configured to send a data message 1, wherein the data message 1 includes window information 1, and the window information 1 is used to request adjustment of the data sending window; the transceiver unit is also configured to receive a data message 4 from a third communication device, wherein the data message 4 includes window information 3, and the window information 3 is used to indicate the data sending window; the processing unit is configured to determine the data sending window based on the window information 3 in the data message 4.

[0294] In combination with the thirty-fifth aspect or the thirty-sixth aspect, in a possible implementation, the size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window requested to be adjusted by the window information 1.

[0295] In combination with the thirty-fifth aspect or the thirty-sixth aspect, in a possible implementation, the above-mentioned data packet 4 includes RDMA layer 3 or layer 4 feedback information, and the RDMA layer 3 or layer 4 feedback information includes the above-mentioned window information 3.

[0296] In combination with the thirty-fifth aspect or the thirty-sixth aspect, in a possible implementation, the above-mentioned data packet 4 and the above-mentioned data packet 1 belong to the same QoS flow or the same session.

[0297] In combination with aspect 35 or aspect 36, in one possible implementation, the above-mentioned window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device.

[0298] In combination with aspect 35 or aspect 36, in a possible implementation, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0299] In aspect 37, the present application provides a congestion control method, which is applied to a first communication device, such as a base station. The method includes: the first communication device receives a data packet 1 from a second communication device, the data packet 1 including window information 1, the window information 1 being used to request adjustment of the data sending window; the first communication device sends a data packet 2 to a UPF, the data packet 2 including window information 2, the window information 2 being used to indicate the data sending window, the window information 2 being determined based on the window information 1 and air interface resources; the first communication device receives a data packet 4 from a UPF, the data packet 4 including a downlink GTP-u header, the downlink GTP-u header including window information 3; the first communication device sends a data packet 5 to the second communication device, the data packet 5 including the window information 3. The window information 3 is used to indicate the data sending window, and the size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window indicated by the above-mentioned window information 2.

[0300] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0301] Exemplarily, the first communication device is a base station.

[0302] Exemplarily, the second communication device is a terminal, and the third communication device is an off-network computing node (such as an edge server / cloud server).

[0303] After the first communication device of the present application receives a data packet containing window information 1, it can determine window information 2 based on the perceived air interface resources and the window information 1, and then inform the UPF of the window information 2 so that the UPF also participates in the adjustment of the sending window. The first communication device also returns the window information 3 finally determined by the UPF to the second communication device; the size of the sending window used by the second communication device can be better matched with the transmission capacity of the intermediate network element (such as the UPF and the first communication device), thereby reducing packet loss in the network (or achieving no packet loss) and data transmission delay, improving the reliability and throughput of data transmission, and thus achieving low-latency, high-throughput data transmission. In addition, since the intermediate network elements (UPF and base stations) in the mobile network are all involved in congestion control, the transmission capacity of all bottleneck nodes (such as UPF and base stations) is taken into account, thereby improving the service quality of RDMA.

[0304] In conjunction with aspect 37, in one possible implementation, the method further includes: the first communication device determining window information 2 based on the window information 1 and the air interface resources. Alternatively, the first communication device determines window information 2 based on the window information 1, the air interface resources, and the cache resources of the first communication device. The implementation of the first communication device determining window information 2 is described in the following embodiments and is not detailed here. Specific descriptions of the air interface resources and / or the cache resources of the first communication device are described above and are not repeated here.

[0305] Exemplarily, the size of the sending window indicated by the window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0306] In aspect 38, the present application provides a communication device, which may be a first communication device or a chip or functional module configured in the first communication device, and the communication device includes a processing unit and a transceiver unit. The transceiver unit is configured to receive a data message 1 from a second communication device, wherein the data message 1 includes window information 1, and the window information 1 is used to request adjustment of the data sending window; the transceiver unit is further configured to send a data message 2 to a UPF, wherein the data message 2 includes window information 2, and the window information 2 is used to indicate the data sending window, and the window information 2 is determined based on the window information 1 and air interface resources; the transceiver unit is further configured to receive a data message 4 from the UPF, wherein the data message 4 includes a downlink GTP-u header, and the downlink GTP-u header includes window information 3; the transceiver unit is further configured to send a data message 5 to the second communication device, wherein the data message 5 includes the window information 3. The window information 3 is used to indicate the data sending window, and the size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window indicated by the above-mentioned window information 2.

[0307] In conjunction with aspect 38, in one possible implementation, the processing unit is configured to determine window information 2 based on the window information 1 and the air interface resources. Alternatively, the processing unit is configured to determine window information 2 based on the window information 1, the air interface resources, and the cache resources of the first communication device.

[0308] Exemplarily, the size of the sending window indicated by the window information 2 is smaller than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0309] In combination with the thirty-seventh aspect or the thirty-eighth aspect, in a possible implementation manner, the above-mentioned data packet 5 includes a UuL2 header or an L2 control PDU, and the UuL2 header or the L2 control PDU includes the above-mentioned window information 3.

[0310] In combination with aspect 37 or aspect 38, in one possible implementation, the data (or payload) in data packet 4 and the data (or payload) in data packet 2 or data packet 1 belong to the same QoS flow or the same session. Alternatively, the data in data packet 4 is dummy data.

[0311] In conjunction with aspect 37 or aspect 38, in one possible implementation, the window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device. It will be appreciated that the window information 2 and the window information 1 may be information of the same dimension.

[0312] In combination with aspect 37 or aspect 38, in a possible implementation, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0313] In combination with aspect 37 or aspect 38, in a possible implementation, the above-mentioned window information 2 can be carried in the frame header of the data link layer of the above-mentioned data message 2, or the packet header of the network layer, or the message header of the transport layer.

[0314] In the thirty-ninth aspect, the present application provides a congestion control method, which includes: UPF receives a data packet 2 from a first communication device, and the data packet 2 includes window information 2, and the window information 2 is used to indicate the sending window of the data; UPF sends a data packet 4 to the first communication device, and the data packet 4 includes a downlink GTP-u header, and the downlink GTP-u header includes window information 3, and the window information 3 is used to indicate the sending window of the data. The window information 3 can be determined based on the cache resources of the UPF and the above-mentioned window information 2. The size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window indicated by the above-mentioned window information 2. It can be understood that the window information 3 and the window information 2 are information of the same dimension.

[0315] After the UPF of the present application receives a data packet containing window information 2, it determines window information 3 based on its own cache resources and the window information 2, and returns the window information 3 to the first communication device, so that the first communication device notifies the second communication device of the window information 3, thereby making the size of the sending window actually used by the second communication device better match the transmission capacity of the intermediate network element (such as the UPF and the first communication device), thereby reducing packet loss in the network (or achieving no packet loss) and data transmission delay, improving data transmission reliability and throughput, and thus achieving low-latency, high-throughput data transmission. In addition, the UPF of the present application informs the first communication device of "window information 3 (or congestion control information)" through the GTP-u header, which can reduce the detour of window information 3 (or congestion control information) in the air interface, thereby making congestion control (or adjustment of the sending window) more timely and achieving faster adjustment of the data transmission rate.

[0316] In combination with the thirty-ninth aspect, in a possible implementation, the above method also includes: UPF determines window information 3 based on the above window information 2 and its own cache resources.

[0317] In conjunction with the thirty-ninth aspect, in one possible implementation, after the UPF receives the data packet 2 from the first communication device, the method further includes: the UPF sending a data packet 3 to the third communication device, where the data packet 3 includes the above-mentioned window information 2. Exemplarily, the window information 2 may be carried in a frame header of the data link layer, a packet header of the network layer, or a message header of the transport layer of the data packet 3.

[0318] Exemplarily, the data (or payload) in the data message 3 may be the same as the data (or payload) in the above-mentioned data message 2.

[0319] In the fortieth aspect, the present application provides a communication device, which may be a UPF or a chip or functional module configured in the UPF, and the communication device includes a processing unit and a transceiver unit. The transceiver unit is used to receive a data message 2 from a first communication device, and the data message 2 includes window information 2, and the window information 2 is used to indicate the sending window of the data; the transceiver unit is also used to send a data message 4 to the first communication device, and the data message 4 includes a downlink GTP-u header, and the downlink GTP-u header includes window information 3, and the window information 3 is used to indicate the sending window of the data. The window information 3 can be determined based on the cache resources of the UPF and the above-mentioned window information 2. The size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window indicated by the above-mentioned window information 2. It can be understood that the window information 3 and the window information 2 are information of the same dimension.

[0320] In combination with the fortieth aspect, in a possible implementation, the processing unit is used to determine the window information 3 based on the above-mentioned window information 2 and its own cache resources.

[0321] In conjunction with the 40th aspect, in one possible implementation, the transceiver unit is further configured to send a data message 3 to a third communication device, where the data message 3 includes the window information 2. Exemplarily, the window information 2 may be carried in a frame header of a data link layer, a packet header of a network layer, or a message header of a transport layer of the data message 3.

[0322] Exemplarily, the data (or payload) in the data message 3 may be the same as the data (or payload) in the above-mentioned data message 2.

[0323] In combination with the thirty-ninth aspect or the fortieth aspect, in one possible implementation, the data (or payload) in the data packet 4 and the data (or payload) in the data packet 2 belong to the same QoS flow or the same session. Alternatively, the data in the data packet 4 is dummy data.

[0324] In combination with aspect 39 or aspect 40, in a possible implementation, the above-mentioned window information 2 can be carried in the frame header of the data link layer of the above-mentioned data message 2, or the packet header of the network layer, or the message header of the transport layer.

[0325] In a forty-first aspect, the present application provides a congestion control method, comprising: a second communication device sending a data packet 1 (to a first communication device), the data packet 1 including window information 1, the window information 1 being used to request adjustment of a data sending window; the second communication device receiving a data packet 5 from the first communication device, the data packet 5 including window information 3, the window information 3 being used to indicate a data sending window; and the second communication device determining the data sending window based on the window information 3 in the data packet 5. The implementation method for determining the data sending window by the second communication device is described in the following embodiments and is not further described here.

[0326] Exemplarily, the source address of the data message 1 is the address of the second communication device, and the destination address of the data message 1 is the address of the third communication device.

[0327] The second communication device of the present application actively requests to adjust the data sending window according to its own cache situation and internal strategy, and feeds back congestion control information (i.e., window information 3) to the second communication device through the first communication device. This can not only reduce packet loss and data transmission delay in the network and provide data transmission reliability; it can also reduce the detour of window information 3 through the air interface, thereby making congestion control (or adjustment of the sending window) more timely and achieving low latency and high throughput of data transmission.

[0328] In a forty-second aspect, the present application provides a communication device, which may be a second communication device or a chip or functional module configured in the second communication device, and the communication device includes a processing unit and a transceiver unit. The transceiver unit is configured to send a data message 1, wherein the data message 1 includes window information 1, and the window information 1 is used to request adjustment of the data sending window; the transceiver unit is also configured to receive a data message 5 from the first communication device, wherein the data message 5 includes window information 3, and the window information 3 is used to indicate the data sending window; the processing unit is configured to determine the data sending window based on the window information 3 in the data message 5.

[0329] In combination with the forty-first aspect or the forty-second aspect, in a possible implementation, the size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window requested to be adjusted by the window information 1.

[0330] In combination with the forty-first aspect or the forty-second aspect, in a possible implementation manner, the above-mentioned data packet 5 includes a UuL2 header or an L2 control PDU, and the UuL2 header or the L2 control PDU includes the above-mentioned window information 3.

[0331] In conjunction with aspect 41 or aspect 42, in one possible implementation, the window information 1 may include one or more of the following: an increase intent value (II), a buffer queue length within the second communication device, or a link bandwidth capacity of the second communication device. It is understood that the window information 3 and the window information 1 may be information of the same dimension.

[0332] In combination with aspect 41 or aspect 42, in a possible implementation, the above-mentioned window information 1 can be carried in the frame header of the data link layer of the above-mentioned data message 1, or the packet header of the network layer, or the message header of the transport layer.

[0333] In the forty-third aspect, the present application provides a communication device, which may include a processor and an interface circuit, and the processor is connected to the interface circuit. Wherein, the interface circuit is used to exchange (or receive and send or input and output) information or data, and the processor is used to run program instructions so that the communication device performs the method described in the first aspect, or the second aspect, or the third aspect, or the seventh aspect, or the eighth aspect, or the ninth aspect, or the thirteenth aspect, or the fourteenth aspect, or the fifteenth aspect, or the nineteenth aspect, or the twenty-first aspect, or the twenty-third aspect, or the twenty-fifth aspect, or the twenty-seventh aspect, or the twenty-ninth aspect, or the thirty-first aspect, or the thirty-third aspect, or the thirty-fifth aspect, or the twenty-seventh aspect, or the thirty-ninth aspect, or the forty-first aspect, or any possible implementation of any one of the aspects. Wherein, the interface circuit may be a communication interface, or a transceiver. The transceiver may be a radio frequency module in a communication device, or a combination of a radio frequency module and an antenna, or an input and output interface of a chip or circuit.

[0334] In aspect 44, the present application provides a readable storage medium having program instructions stored thereon, which, when executed on a computer, enables the computer to execute the method described in any possible implementation of the first aspect, or the second aspect, or the third aspect, or the seventh aspect, or the eighth aspect, or the ninth aspect, or the thirteenth aspect, or the fourteenth aspect, or the fifteenth aspect, or the nineteenth aspect, or the twenty-first aspect, or the twenty-third aspect, or the twenty-fifth aspect, or the twenty-seventh aspect, or the twenty-ninth aspect, or the thirty-first aspect, or the thirty-third aspect, or the thirty-fifth aspect, or the twenty-seventh aspect, or the thirty-ninth aspect, or the forty-first aspect, or any possible implementation of any one of them.

[0335] In the forty-fifth aspect, the present application provides a program product comprising program instructions, which, when run, enables the method described in any possible implementation of the first aspect, or the second aspect, or the third aspect, or the seventh aspect, or the eighth aspect, or the ninth aspect, or the thirteenth aspect, or the fourteenth aspect, or the fifteenth aspect, or the nineteenth aspect, or the twenty-first aspect, or the twenty-third aspect, or the twenty-fifth aspect, or the twenty-seventh aspect, or the twenty-ninth aspect, or the thirty-first aspect, or the thirty-third aspect, or the thirty-fifth aspect, or the twenty-seventh aspect, or the thirty-ninth aspect, or the forty-first aspect, or any possible implementation of any one of them to be executed.

[0336] In aspect 46, the present application provides an apparatus that can be implemented in the form of a chip or a device, and includes a processor. The processor is configured to read and execute a program stored in a memory to perform the congestion control method provided in one or more of the first to third aspects, or the seventh to ninth aspects, or the thirteenth to fifteenth aspects, or the nineteenth aspect, or the twenty-first aspect, or the twenty-third aspect, or the twenty-fifth aspect, or the twenty-seventh aspect, or the twenty-ninth aspect, or the thirty-first aspect, or the thirty-third aspect, or the thirty-fifth aspect, or the twenty-seventh aspect, or the thirty-ninth aspect, or the forty-first aspect, or any possible implementation of any of these aspects. Optionally, the apparatus further includes a memory, which is connected to the processor via a circuit. Further optionally, the apparatus further includes a communication interface, to which the processor is connected. The communication interface is configured to receive information to be processed, the processor obtains the information from the communication interface, processes the information, and outputs the processing results via the communication interface. The communication interface may be an input / output interface.

[0337] In a possible implementation, the processor and memory may be physically independent units, or the memory may be integrated with the processor.

[0338] In aspect 47, the present application provides a communication system, comprising a first communication device, a second communication device, and a third communication device. Optionally, the communication system further comprises a UPF. The first communication device is used to perform the method described in any possible implementation of the first aspect, the seventh aspect, the thirteenth aspect, the twenty-first aspect, the twenty-seventh aspect, the thirty-first aspect, the thirty-seventh aspect, or any one of the aspects. The second communication device is used to perform the method described in any possible implementation of the second aspect, the eighth aspect, the fifteenth aspect, the twenty-third aspect, the twenty-ninth aspect, the thirty-fifth aspect, the forty-first aspect, or any one of the aspects. The third communication device is used to perform the method described in any possible implementation of the third aspect, the ninth aspect, or any one of the aspects. The UPF is used to perform the method described in any possible implementation of the fourteenth aspect, the nineteenth aspect, the twenty-fifth aspect, the thirty-third aspect, the thirty-ninth aspect, or any one of the aspects.

[0339] The technical effects achieved in the above-mentioned aspects can be referred to each other or to the beneficial effects in the method embodiments shown below, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0340] FIG1 is a schematic diagram of a distributed computing scenario provided by an embodiment of the present application;

[0341] FIG2 is a schematic diagram of a high-precision congestion control method provided by an embodiment of the present application;

[0342] FIG3 is a schematic diagram of a first flow chart of a congestion control method provided in an embodiment of the present application;

[0343] FIG4 is a schematic diagram of a downlink data congestion control method of a UE and a NodeC provided in an embodiment of the present application;

[0344] FIG5 is a schematic diagram of an uplink data congestion control method of a UE and a NodeC provided in an embodiment of the present application;

[0345] FIG6 is a schematic diagram of a downlink data congestion control method of a UE and a server provided in an embodiment of the present application;

[0346] FIG7 is a schematic diagram of an uplink data congestion control method for a UE and a server provided in an embodiment of the present application;

[0347] FIG8 is a schematic diagram of a second flow chart of a congestion control method provided in an embodiment of the present application;

[0348] FIG9 is another schematic diagram of a downlink data congestion control method for a UE and a NodeC provided in an embodiment of the present application;

[0349] FIG10 is another schematic diagram of an uplink data congestion control method of a UE and a NodeC provided in an embodiment of the present application;

[0350] FIG11 is another schematic diagram of an uplink data congestion control method for a UE and a server provided in an embodiment of the present application;

[0351] FIG12 is a schematic diagram of a third flow chart of a congestion control method according to an embodiment of the present application;

[0352] FIG13 is another schematic diagram of a downlink data congestion control method for a UE and a server provided in an embodiment of the present application;

[0353] FIG14 is a fourth flow chart of a congestion control method according to an embodiment of the present application;

[0354] FIG15 is another schematic diagram of a downlink data congestion control method for a UE and a server provided in an embodiment of the present application;

[0355] FIG16 is a schematic diagram of a fifth flow chart of a congestion control method provided in an embodiment of the present application;

[0356] FIG17 is yet another schematic diagram of a downlink data congestion control method for a UE and a server provided in an embodiment of the present application;

[0357] FIG18 is a sixth flow chart of the congestion control method provided in an embodiment of the present application;

[0358] FIG19 is another schematic diagram of an uplink data congestion control method for a UE and a server provided in an embodiment of the present application;

[0359] FIG20 is a seventh flow chart of the congestion control method provided in an embodiment of the present application;

[0360] FIG21 is yet another schematic diagram of an uplink data congestion control method for a UE and a server provided in an embodiment of the present application;

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

[0362] FIG23 is another schematic structural diagram of a communication device provided in an embodiment of the present application;

[0363] FIG24 is another structural diagram of the communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0364] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application.

[0365] In the description of this application, unless otherwise specified, " / " means "or", for example, A / B can mean A or B. "And / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, "at least one" means one or more, and "plurality" means two or more. "The following one (or more)" or similar expressions refer to any combination of these items, including any combination of single or plural items (individuals). For example, at least one of a, b, or c can mean: a, b, c; a and b; a and c; b and c; or a, b, and c. Among them, a, b, and c can be single or multiple.

[0366] In the description of this application, words such as "first" and "second" are used only to distinguish different objects and do not limit the quantity or execution order. Moreover, words such as "first" and "second" do not necessarily mean different. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units that are not listed, or may optionally include other steps or units inherent to the process, method, product, or device.

[0367] In this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described in this application as "exemplary," "for example," or "for example" should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary," "for example," or "for example" is intended to present the relevant concepts in a concrete way.

[0368] It should be understood that in this application, "when", "if" and "if" all mean that the device will perform corresponding processing under certain objective circumstances, and do not limit the time. It does not require that the device must perform a judgment action when it is implemented, nor does it mean that there are other limitations.

[0369] Elements used in the singular herein are intended to mean "one or more" rather than "one and only one" unless specifically stated otherwise.

[0370] It is understood that in each embodiment of the present application, "A corresponds to B" and similar expressions all indicate that there is a corresponding relationship between A and B, and B can be determined based on A. It should also be understood that determining B based on A does not mean determining B based solely on A, and B can also be determined based on A and / or other information.

[0371] In one possible implementation, the technical solution of the present application can be applied to distributed computing scenarios that support various wireless communication networks. Of course, the technical solution of the present application can also be applied to any other data transmission scenarios that support wireless communication networks, and the present application does not limit this. For ease of understanding, the present application below takes the distributed computing scenario that supports wireless communication networks as an example. The wireless communication networks include but are not limited to: long term evolution (LTE) networks, worldwide interoperability for microwave access (WiMAX) communications, fifth generation (5G) mobile communications, such as new radio access technology (NR), next generation wireless local area networks, networks that integrate multiple systems, the Internet of Things, the Internet of Vehicles, open-radio access networks (O-RAN), or future communication networks, such as sixth generation (6G) mobile communications.

[0372] In various embodiments of the present application, the term "wireless communication" may also be referred to as "communication", and the term "communication" may also be described as "data transmission", "information transmission" or "transmission".

[0373] It should be understood that the application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Ordinary technicians in this field can know that as the application scenarios evolve, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0374] For example, refer to Figure 1, which is a schematic diagram of a distributed computing scenario provided by an embodiment of the present application. As shown in Figure 1, the distributed computing scenario can include two categories, for example: a scenario in which a terminal performs distributed computing with an in-network computing node (such as NodeC in Figure 1), and a scenario in which a terminal performs distributed computing with an out-of-network computing node (such as an edge server or cloud server in Figure 1). It can be understood that the scenario in which a terminal performs distributed computing with an out-of-network computing node (such as an edge server or cloud server) can also be referred to as a distributed computing scenario of end-cloud collaboration. Among them, the scenario in which a terminal performs distributed computing with an in-network computing node may include but is not limited to: a terminal, a base station, and an in-network computing node. The scenario in which a terminal performs distributed computing with an out-of-network computing node may include but is not limited to: a terminal, a base station, a user plane function (UPF), and an out-of-network computing node. For example, for a scenario in which a terminal performs distributed computing with an in-network computing node (such as NodeC), the transmission path of data (including memory data or operation instructions on memory data, etc.) may include a terminal, a base station, and an in-network computing node. For scenarios where terminals perform distributed computing with off-network computing nodes, the data transmission path (including memory data or operation instructions for memory data, etc.) may include terminals, base stations, UPFs, edge servers / cloud servers.

[0375] For example, the distributed computing scenario shown in Figure 1 can be a scenario where RDMA technology is used for data transmission during joint AI training or inference between a terminal and an on-network computing node or an off-network computing node. It should be understood that Figure 1 is merely a schematic diagram; in actual applications, this distributed computing scenario may also include other devices / network functions, and this application does not impose any limitations.

[0376] The in-network computing node (such as NodeC) in this application can be a computing node introduced in a wireless network, usually connected to a base station, and can be responsible for the in-network computing of AI tasks. Exemplarily, the in-network computing node in this application can be understood as a computing node within the scope of a wireless network or 3GPP (3rd generation partnership project) standard discussion. The out-of-network computing node (such as an edge server or a cloud server) in this application can be a computing server or computing cluster deployed at the edge or in the cloud, which has strong computing power and can be responsible for the out-of-network computing of AI tasks. The terminal can be connected to the out-of-network computing node through the UPF. Exemplarily, the out-of-network computing node in this application can be understood as a computing node outside the wireless network or 3GPP. For simplicity below, "NodeC" is used to represent the in-network computing node, and "server" is used to represent the out-of-network computing node.

[0377] The term "terminal" in this application may be referred to as user equipment (UE), mobile station (MS), or mobile terminal (MT). It is a device with wireless transceiver capabilities and can be deployed on land, indoors or outdoors, handheld or vehicle-mounted; on water (e.g., ships); or in the air (e.g., on airplanes, balloons, and satellites). Terminals can be used to connect people, objects, and machines. The terminals can be widely used in various scenarios, such as cellular communications, device-to-device (D2D), vehicle-to-everything (V2X), peer-to-peer (P2P), machine-to-machine (M2M), machine type communication (MTC), Internet of Things (IoT), virtual reality (VR), augmented reality (AR), industrial control, autonomous driving, telemedicine, smart grid, smart furniture, smart office, smart wearable, smart transportation, smart city, smart home, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery and mobility, etc. The terminal can be a 3GPP standard user equipment (UE), fixed device, mobile device, handheld device, wearable device, cellular phone, smart phone, Session Initiation Protocol (SIP) phone, laptop, personal computer, smart book, vehicle, satellite, Global Positioning System (GPS) device, target tracking device, drone, helicopter, aircraft, ship, remote control device, smart home device, industrial equipment. The terminal device can also be a communication device in a future wireless communication system.

[0378] In the embodiment of the present application, the device for realizing the function of the terminal may be a terminal; or it may be a device that can support the terminal to realize the function, such as a chip system, or a communication module, or a modem, etc., which may be installed in the terminal. In the embodiment of the present application, the chip system may be composed of chips, or may include chips and other discrete devices. In the technical solution provided in the embodiment of the present application, the device for realizing the function of the terminal is a terminal, and the terminal is a UE as an example to describe the technical solution provided in the embodiment of the present application. The embodiment of the present application does not limit the specific technology and specific device form adopted by the terminal device.

[0379] The base station (BS) in this application can be an entity on the network side for transmitting or receiving signals, which can be a device deployed in a wireless access network that can communicate wirelessly with a terminal. Base stations may have various forms, such as macro base stations, micro base stations, relay stations, and access points. Exemplarily, the base stations involved in the embodiments of the present application can be base stations in 5G, base stations in sixth-generation (6G) mobile communication systems, access network devices or modules of access network devices in open radio access networks (O-RAN) systems, base stations in future mobile communication systems or access nodes in WiFi systems, or evolved base stations (evolved node B, eNB) in LTE, etc. Among them, the base station in 5G can also be called a transmission reception point (TRP) or a 5G base station (next-generation node B, gNB). Base station can also be replaced with the following names, such as: wireless access point, node B (nodeB), transmitting point (TP), master station MeNB, secondary station SeNB, multi-standard radio (MSR) node, home base station, network controller, access node, wireless node, access point (AP), transmission node, transceiver node, baseband unit (BBU), remote radio unit (RRU), active antenna unit (AAU), remote radio head (RRH), centralized unit (CU), distributed unit (DU), positioning node, IAB donor, etc.

[0380] The base station in the embodiments of the present application may be an integrated base station, or may be a base station including a centralized unit (CU) and / or a distributed unit (DU). A base station including a CU and a DU may also be referred to as a base station with separate CU and DU, such as a base station including a gNB-CU and a gNB-DU. The base station in the embodiments of the present application may also be an open radio access network (O-RAN) architecture, etc. The embodiments of the present application do not limit the specific deployment method of the base station. For example, when the base station is an O-RAN architecture, the base station shown in the embodiments of the present application may be an access network device in the O-RAN, such as a CU, a DU, or a combination of one or more of an antenna unit (RU), or a module in an access network device. In the ORAN system, the CU may also be referred to as an open (O)-CU, the CU-CP may also be referred to as an O-CU-CP, the CU-UP may also be referred to as an O-CU-UP, the DU may also be referred to as an O-DU, and the RU may also be referred to as an O-RU.

[0381] The user plane function (UPF) in this application belongs to the network function of the core network and can be responsible for the data connection between the access network and the Internet. For example, the UPF can be responsible for processing user messages, such as forwarding and billing.

[0382] Network-supported distributed AI computing requires real-time model or data interaction, but TCP / IP-based distributed AI computing suffers from poor performance. Some have proposed applying RDMA technology to wireless networks (e.g., mobile networks) to address this performance issue. However, RDMA is extremely sensitive to packet loss, so congestion control can be implemented during data transmission to reduce network packet loss and transmission latency.

[0383] In one possible implementation, high-precision congestion control (HPCC) is a congestion control method applied to data center networks (DCNs) that supports RDMA transmission. HPCC can perform congestion control based on load information provided by the switch, such as adjusting the data transmission window. It is understood that the data sender can adjust its own transmission window to control the data transmission rate to avoid network congestion or receiver processing overload. It is also understood that the data sender typically adjusts the transmission window size of the transport layer (such as the TCP layer).

[0384] Refer to Figure 2, which is a schematic diagram of a high-precision congestion control method provided by an embodiment of the present application. The high-precision congestion control (HPCC) method can be applied to distributed computing in a data center network (DCN). In the high-precision congestion control method, each data packet sent by the sender will be confirmed by the receiver. As shown in Figure 2, during the transmission of a data packet from a sender to a receiver, each switch on the transmission path inserts some metadata into the data packet. These metadata include the current load of the egress port of the data packet, such as: timestamp, cache queue length, transmission bytes, and link bandwidth capacity. When the receiver receives the data packet, it can copy all the metadata inserted by the switches on the transmission path into an acknowledgment (ACK) message and return the ACK message to the sender. After the sender receives the ACK message, it can adjust the size of the transmission window based on the load information carried by the ACK message.

[0385] It's understandable that because the congestion control scheme (HPCC, shown in Figure 2) used in data center networks uses wired connections for data transmission, which offer ultra-low latency and constant total link bandwidth, HPCC can quickly and accurately adjust the send window, thereby enabling low-latency, high-throughput RDMA data transmission in data center networks. However, in mobile network environments where terminals participate in distributed computing, the latency of the data transmission path is at least 1 millisecond (ms), far exceeding the 1 to 10 microseconds (µs) transmission latency of data center networks. Furthermore, wireless channels in mobile networks are unstable. For example, the air interface bandwidth of mobile networks is time-varying, and the bandwidth available for data transmission varies with the terminal's location and / or time of day. Furthermore, the coverage area between the terminal and the UPF is large, resulting in transmission latency of several or even tens of milliseconds. Therefore, if HPCC is applied to mobile networks, it is impossible to quickly and accurately adjust the send window, thus failing to achieve low-latency, high-throughput RDMA data transmission.

[0386] In view of this, embodiments of the present application provide a congestion control method, apparatus, and readable storage medium, which can be applied to RDMA data transmission over mobile networks. They can quickly and accurately adjust the size of the transmission window, reduce packet loss in the network (or achieve zero packet loss) and data transmission latency, and improve data transmission reliability and throughput, thereby achieving low-latency, high-throughput data transmission.

[0387] The terms "transmission delay" and "data transmission delay" in this application can be understood as the time it takes for data / information to travel from the sender to the receiver. This delay is primarily affected by three factors: transmission delay, queuing delay, and processing delay. Transmission delay generally refers to the delay incurred during the transmission of data / information, including the time it takes for the data / information to propagate through the communication medium and the time it takes for the signal to be detected and converted. Queuing delay generally refers to the delay between the sender and receiver, meaning the time a data packet waits for transmission within the network. Processing delay generally refers to the time it takes for data / information to be processed at both the sender and receiver.

[0388] The term "transmission window" in this application can be understood as the amount of data a sender can continuously send. In TCP, the send window refers to the size of a buffer maintained by the sender to store data packets that have been sent but for which no acknowledgement has been received. In other words, the send window can also be understood as the buffer size of the send data queue.

[0389] The technical solution provided in this application will be described in detail below with reference to more drawings.

[0390] The technical solutions provided in this application can be described in detail through multiple embodiments, with specific reference to the description of each embodiment below. It should be understood that the technical solutions described in each embodiment below in this application can be combined in any way to form new embodiments and the same or similar parts of the concepts or solutions involved can be referenced or combined with each other. In this application, unless otherwise specified, the same or similar parts between each embodiment or implementation can be referenced with each other. In each embodiment in this application, and each implementation method / implementation method / implementation method in each embodiment, if there is no special explanation and logical conflict, the terms and / or descriptions between different embodiments and each implementation method / implementation method / implementation method in each embodiment are consistent and can be referenced with each other. The technical features in different embodiments and each implementation method / implementation method / implementation method in each embodiment can be combined to form new embodiments, implementation methods, implementation methods, or implementation methods according to their inherent logical relationships. The embodiments of this application described below do not constitute a limitation on the scope of protection of this application. It is understood that the order of the embodiments below does not represent the degree of importance.

[0391] It should be understood that, in this application, indication includes direct indication (also known as explicit indication) and implicit indication. Direct indication of information A refers to including information A; implicit indication of information A refers to indicating information A through the correspondence between information A and information B and the direct indication of information B. The correspondence between information A and information B can be predefined, pre-stored, pre-burned, or pre-configured.

[0392] It should be understood that, in this application, information D is determined based on information C, which includes information D being determined solely based on information C, as well as information D being determined based on information C and other information. Furthermore, information C being used to determine information D may also include indirect determination, such as information D being determined based on information E, which in turn is determined based on information C.

[0393] In addition, in each embodiment of the present application, "network element A sends information A to network element B" can be understood as the destination end of the information A or the intermediate network element in the transmission path between the destination end and the network element B, which may include directly or indirectly sending information to network element B. "Network element B receives information A from network element A" can be understood as the source end of the information A or the intermediate network element in the transmission path between the source end and the network element A, which may include directly or indirectly receiving information from network element A. The information may be processed as necessary between the source end and the destination end of the information transmission, such as format changes, but the destination end can understand the valid information from the source end. Similar expressions in this application can be understood similarly and will not be elaborated here.

[0394] The method provided in this application can be applied to data transmission scenarios that support wireless communication networks. For example, the method provided in this application can be applied to the distributed computing scenario shown in Figure 1 above. The first communication device in this application can be a base station, the second communication device can be a sender of data, such as the terminal, edge server, cloud server, or NodeC in Figure 1 above; the third communication device can be a receiver of data, such as the NodeC, edge server, cloud server, or terminal in Figure 1 above. For example, when the second communication device (sender of data) is a terminal (such as UE), the third communication device (receiver of data) can be a NodeC, an edge server, or a cloud server. When the second communication device (sender of data) is a NodeC, the third communication device (receiver of data) can be a terminal (such as UE). When the second communication device (sender of data) is an edge server / cloud server, the third communication device (receiver of data) can be a terminal (such as UE).

[0395] It is understandable that in 5G or future mobile networks (such as 6G), base stations and UPFs (or gateway-like devices) are nodes that implement service flow aggregation and are prone to congestion. Therefore, this application focuses on considering the participation of network element nodes (such as base stations or UPFs in the core network) that may become bottlenecks in the link in congestion control, thereby providing low-latency and high-throughput communication services for distributed computing data transmission.

[0396] Refer to Figure 3, which is a first flow chart of the congestion control method provided in an embodiment of the present application. In this method, the first communication device is a base station (such as gNB), the second communication device is a sender (Sender) of data, and the third communication device is a receiver (Receiver) of data. Exemplarily, the second communication device is a terminal (such as UE), and the third communication device is an in-network computing node (such as NodeC); or, the second communication device is an in-network computing node (such as NodeC), and the third communication device is a terminal (such as UE). Another exemplary embodiment, the second communication device is a terminal (such as UE), and the third communication device is an off-network computing node (such as an edge server / cloud server); or, the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal (such as UE).

[0397] As shown in FIG3 , the congestion control method includes but is not limited to the following steps:

[0398] S101: A second communication device (Sender) sends data message 1, which includes window information 1, which is used to request adjustment of the data sending window. The source address (source address) of data message 1 is the address of the second communication device, and the destination address (target address) of data message 1 is the address of a third communication device.

[0399] In one possible implementation, the second communication device (Sender) can carry window information 1 along with the data stream via a datagram header. This window information 1 can be used to request adjustment (e.g., increase or decrease) of the data transmission window. Exemplarily, the second communication device (Sender) can carry window information 1 in datagram 1.

[0400] In this application, unless otherwise specified, various operations on the "send window" can be understood as operations on the size of the transmission window, and will not be further described below. For example, adjusting (e.g., increasing or decreasing) the data send window can be understood as adjusting (e.g., increasing or decreasing) the data send window size. For another example, indicating the data send window can be understood as indicating the data send window size. For another example, determining the data send window can be understood as determining the data send window size.

[0401] In one possible implementation, the window information 1 may be carried in a data link layer frame header, a network layer packet header, or a transport layer message header of the data packet 1. In other words, when encapsulating the data to be transmitted, the second communication device may carry the window information 1 in a data link layer (L2) frame header, a network layer packet header, or a transport layer message header, and then transmit the encapsulated data.

[0402] It is understood that the data message of the present application can have different representations in different protocol layers. For example, at the physical layer, the data message can be a binary bit sequence (bit); at the data link layer, the data message can be a data frame (frame); at the network layer, the data message can be a data packet (packet); at the transport layer, the data message can be a data segment (segment); at the application layer, the data message can be data (data). The present application does not limit the representation of the data message.

[0403] In one possible implementation, the second communication device (Sender) can determine the window information 1 based on the quality of service (QoS) flow to which the data to be sent is located. Exemplarily, if the guaranteed flow bit rate (GFBR) corresponding to the QoS flow to which the data to be sent is located is increased relative to the GFBR at the previous moment, the window information 1 can be used to request an increase in the data sending window. The specific increase value can be determined by the internal policy of the second communication device, and the embodiment of the present application is not limited. Alternatively, the second communication device can determine the window information 1 based on information such as the total amount of data to be sent (these data belong to the same session) and the delay requirement for transmitting these data. Exemplarily, the ratio of the total amount of data to be sent to the delay is the expected sending rate. If the current network transmission rate is less than the expected sending rate, the window information 1 can be used to request an increase in the data sending window. The specific increase value can be determined by the internal policy of the second communication device, and the embodiment of the present application is not limited.

[0404] In one possible implementation, the above-mentioned window information 1 may include one or more of the following: an increase intent value (increase intent, II), a buffer queue length within the second communication device (Sender), or a link bandwidth capacity of the second communication device (Sender). Based on the window information 1, the sending window size (or the expected sending window size) requested by the second communication device (Sender) to be adjusted can be determined. Among them, the increase intent value can indicate the sending window size that the second communication device (Sender) expects to increase. For example, the sending window size at the current moment is 2048 bytes, and the increase intent value is also 2048 bytes, then the sending window size expected by the second communication device (Sender) is 4096 (i.e., 2048+2048) bytes. The buffer queue length within the second communication device (Sender) can be the buffer queue length of all data to be sent that belongs to the same QoS flow as the data packet 1, or it can be the buffer queue length of all data to be sent in the second communication device, and the embodiments of the present application do not limit this. For example, the longer the buffer queue length within the second communication device or the larger the link bandwidth capacity of the second communication device, the larger the desired send window of the second communication device can be; conversely, the shorter the buffer queue length within the second communication device or the smaller the link bandwidth capacity of the second communication device, the smaller the desired send window of the second communication device can be. Exemplarily, the above-mentioned window information 1 can also include one or more of the following: a timestamp, or transmission bytes. For example, the timestamp here can be the sending timestamp of the above-mentioned data message 1, and the transmission bytes can be the number of transmission bytes of the above-mentioned data message 1.

[0405] It is understood that the term "moment" in this application does not refer to a specific point in time. It can also be understood as a time period or a time cycle, etc., and the specific meaning should be understood in the context. For example, "current moment" can be understood as: the current time point, the current time period, the current time cycle, etc.; "previous moment" can be understood as: the previous time point, the previous time period, the previous time cycle, etc.; "next moment" can be understood as: the next time point, the next time period, the next time cycle, etc.

[0406] In one possible implementation, the frequency at which a sender (e.g., a second communication device) sends window information 1 along with a data stream can be determined by the sender (e.g., the second communication device) based on the round-trip time (RTT) of communication between the sender and the receiver. For example, after sending window information 1 along with the data stream, the sender waits for a feedback message from the receiver. Upon receiving the feedback message or after a timer for waiting for the feedback message expires, the sender determines whether to initiate a new window information 1 again based on needs / internal policies to request adjustment of the data sending window.

[0407] It can be understood that the "feedback message" in this application can be understood as a data message carrying feedback information, which will not be repeated below.

[0408] In one possible implementation, in a distributed computing scenario, before two devices (such as a second communication device and a third communication device) interact with each other (i.e., before step S101), they can establish a data channel and negotiate the use of the RDMA mechanism for data transmission. For example, the second communication device is a terminal and the third communication device is a NodeC; alternatively, the second communication device is a NodeC and the third communication device is a terminal. Before the terminal and NodeC interact with each other (i.e., before step S101), the terminal can initiate a computation offload task and, with network assistance, select the computation offload node, NodeC. A data channel is then established between the terminal and NodeC via a base station. The terminal and NodeC can negotiate the computation task and utilize the RDMA mechanism for data transmission. At the application level, the terminal and NodeC can establish a local memory conversion relationship, mapping memory segments to a remote address space. Thereafter, the terminal and NodeC can perform distributed computing, and data can be transmitted between the terminal and NodeC using the RDMA mechanism. For example, step S101 can occur during data transmission between the terminal and NodeC.

[0409] As another example, the second communication device is a terminal, and the third communication device is an edge server / cloud server (which may be referred to as a server); or, the second communication device is an edge server / cloud server, and the third communication device is a terminal. Then, before the terminal and the edge server / cloud server interact with data (i.e., before step S101), the terminal can initiate a computation offloading task and, with the assistance of the network, select a computation offloading node, such as an edge server / cloud server or other computational server. Then, a data channel is established between the terminal and the edge server / cloud server via the base station and the UPF. The terminal and the edge server / cloud server can negotiate the computation task and use the RDMA mechanism to transmit data. At the application level, the terminal and the edge server / cloud server can establish a local memory conversion relationship, mapping memory segments to a remote address space. Thereafter, the terminal and the edge server / cloud server can perform distributed computing, and the RDMA mechanism can be used to transmit data between the terminal and the edge server / cloud server. For example, the above step S101 can occur during data transmission between the terminal and the edge server / cloud server.

[0410] S102, the first communication device (such as a base station) receives the data message 1, and determines the window information 2 based on the window information 1 and the air interface resources in the data message 1, wherein the window information 2 is used to indicate the sending window of the data, and the size of the sending window indicated by the window information 2 is less than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0411] It can be understood that if the source address or destination address of the data message 1 is an in-network computing node (NodeC), the transmission path of the data message 1 passes through the first communication device (such as a base station). If the source address or destination address of the data message 1 is an out-of-network computing node (such as an edge server / cloud server), the transmission path of the data message 1 passes through the first communication device (such as a base station) and the UPF. Therefore, the first communication device can receive the data message 1.

[0412] In one possible implementation, after receiving the data packet 1, a first communication device (e.g., a base station) may detect whether the data packet 1 contains the window information 1. Exemplarily, the first communication device (e.g., a base station) may parse the header information of the data packet 1, or perform deep packet inspection (DPI) on the data packet 1 to determine whether the data packet 1 contains the window information 1. When the first communication device (e.g., a base station) detects that the data packet 1 contains the window information 1, it may determine window information 2 based on its perceived air interface resources and the window information 1. The window information 2 may be used to indicate a data sending window. Exemplarily, the sending window size indicated by the window information 2 is less than or equal to the sending window size requested to be adjusted in the window information 1. In other words, the sending window size determined / indicated by the first communication device (base station) is less than or equal to the sending window size desired by the second communication device (sender).

[0413] It is understandable that window information 1 and window information 2 can be information of the same dimension. For example: window information 1 is an increase in intention value, and window information 2 is also a value; or, window information 1 is the buffer queue length in the second communication device (Sender), and window information 2 is also a buffer queue length; or, window information 1 is the link bandwidth capacity of the second communication device (Sender), and window information 2 is also a link bandwidth capacity. It is also understandable that the specific value of window information 2 can be determined by the internal policy of the first communication device, and the embodiments of the present application do not limit it.

[0414] In one possible implementation, the air interface resources may include one or more of the following: the channel state / channel quality of the air interface (for example, the gain of the wireless channel, or the path loss, etc.), or the air interface bandwidth situation (for example, the allocation of the system bandwidth, or the remaining bandwidth resources in the first communication device, etc.). For example, if the air interface resources perceived by the first communication device can meet the size (size) of the sending window requested to be adjusted by the above-mentioned window information 1, for example, the channel quality currently perceived by the first communication device is good and there are more bandwidth resources remaining on the air interface, which can meet the sending window adjustment (such as increase) requirements of the second communication device (Sender). Then, the size of the sending window indicated by the above-mentioned window information 2 can be equal to the size of the sending window requested to be adjusted by the above-mentioned window information 1. On the contrary, if the air interface resources perceived by the first communication device cannot meet the size (size) of the sending window requested to be adjusted by the above window information 1, for example: the channel quality perceived by the first communication device is poor or the remaining bandwidth resources on the air interface are small, which cannot meet the sending window adjustment (such as increase) requirements of the second communication device (Sender); then the size of the sending window indicated by the above window information 2 is smaller than the size of the sending window requested to be adjusted by the above window information 1.

[0415] In one possible implementation, the first communication device (e.g., a base station) may further determine window information 2 based on the air interface resources, the window information 1, and the buffer resources of the first communication device. For example, the first communication device may determine a send window size for the QoS flow or session to which the data packet 1 belongs based on the air interface resources and the buffer resources of the first communication device. If the send window size determined by the first communication device is greater than or equal to the send window size requested to be adjusted according to the window information 1, the first communication device may generate window information 2 based on the send window size requested to be adjusted according to the window information 1, with the send window size indicated by the window information 2 being equal to the send window size requested to be adjusted according to the window information 1. If the send window size determined by the first communication device is less than the send window size requested to be adjusted according to the window information 1, the first communication device may generate window information 2 based on the determined send window size, with the send window size indicated by the window information 2 being the send window size determined by the first communication device, provided that the send window size indicated by the window information 2 is less than the send window size requested to be adjusted according to the window information 1. Exemplarily, the cache resources of the first communication device include, but are not limited to, the lengths of the various buffer queues of the shared air interface resources (such as time-frequency resources) within the first communication device. For example, if the air interface resources perceived by the first communication device and / or its own cache resources can meet the size (size) of the sending window requested to be adjusted by the above-mentioned window information 1, for example: the current channel quality perceived by the first communication device is good and there are more bandwidth resources remaining on the air interface, and / or the lengths of the various buffer queues of the shared air interface resources (such as time-frequency resources) within the first communication device are short, it means that the transmission capacity of the first communication device can meet the needs of the second communication device. Then the size of the sending window indicated by the above-mentioned window information 2 can be equal to the size of the sending window requested to be adjusted by the above-mentioned window information 1. Conversely, if the air interface resources perceived by the first communication device and / or its own buffer resources cannot meet the send window size (size) requested for adjustment in the above-mentioned window information 1, for example: the channel quality perceived by the first communication device is poor, the remaining bandwidth resources on the air interface are small, or the lengths of the various buffer queues of the shared air interface resources (such as time-frequency resources) within the first communication device are long, it indicates that the transmission capacity of the first communication device cannot meet the needs of the second communication device (Sender). In this case, the send window size indicated by the above-mentioned window information 2 is smaller than the send window size requested for adjustment in the above-mentioned window information 1.

[0416] S103: The first communication device (e.g., a base station) sends data message 2 to the third communication device (Receiver), where the data message 2 includes window information 2. Window information 2 may be used to indicate a data sending window, and the size of the sending window indicated by window information 2 is less than or equal to the size of the sending window requested to be adjusted by window information 1.

[0417] Correspondingly, the third communication device (Receiver) receives the data message 2.

[0418] In one possible implementation, after determining the window information 2, the first communication device (such as a base station) may send a data message 2 to a third communication device (Receiver). Accordingly, the third communication device (Receiver) receives the data message 2. The data in the data message 2 (also referred to as a payload, which will not be described in detail below) may be the same as the data (or payload) in the data message 1. Exemplarily, the data contained in the data message may be RDMA data. The header of the data message 2 may include the window information 2. For example, the window information 2 may be carried in the frame header of the data link layer, the packet header of the network layer, or the message header of the transport layer of the data message 2. It is understood that when the size of the sending window indicated by the window information 2 determined by the first communication device (such as a base station) is equal to the size of the sending window requested to be adjusted by the window information 1, the first communication device may directly forward the data message 1 to the third communication device (Receiver) without processing the data message 1. In other words, at this time, data message 2 may be the same as the above-mentioned data message 1, and the value of window information 2 may be the same as the value of window information 1.

[0419] It can also be understood that when the size of the sending window indicated by the window information 2 determined by the first communication device (e.g., a base station) is smaller than the size of the sending window requested to be adjusted by the window information 1, the data message 2 can be obtained by replacing / updating the window information 1 in the data message 1 with the window information 2. In other words, when the size of the sending window indicated by the window information 2 is smaller than the size of the sending window requested to be adjusted by the window information 1, the first communication device can rewrite / replace / update the window information 1 in the data message 1 with the window information 2 to obtain the data message 2.

[0420] S104: The third communication device (Receiver) sends a data message 3 to the second communication device (Sender), where the data message 3 includes the window information 2. Correspondingly, the second communication device (Sender) receives the data message 3.

[0421] In one possible implementation, after receiving the data packet 2, the third communication device (Receiver) may send a data packet 3 to the second communication device (Sender). The data packet 3 may include the window information 2. Exemplarily, the data packet 3 may include RDMA layer 3 or layer 4 feedback information, which may carry the window information 2. It is understood that the data packet 3 may be forwarded by the first communication device (e.g., a base station) and, optionally, by the UPF, before finally reaching the second communication device (Sender).

[0422] In a possible implementation, the data packet 2 and the data packet 3 may belong to the same QoS flow or the same session. The data in the data packet 3 may be different from the data in the data packet 2.

[0423] In the embodiment of the present application, the receiving end (third communication device) feeds back window information 2 (or congestion control information) to the sending end (second communication device), which can maximize the use of RDMA's congestion control mechanism and adapt it to the mobile network, making it easy to implement and highly compatible.

[0424] S105 , the second communication device (Sender) determines a data sending window based on the window information 2 in the data message 3 .

[0425] In one possible implementation, after receiving the data packet 3, the second communication device (Sender) may determine the size of the data send window based on the window information 2 carried in the data packet 3. For example, when the send window size indicated by window information 2 is equal to the send window size requested to be adjusted according to window information 1, the second communication device (Sender) may adjust (e.g., increase) the send window at the next moment to its desired send window size (i.e., the send window size requested to be adjusted according to window information 1, or the send window size indicated by window information 2). When the send window size indicated by window information 2 is smaller than the send window size requested to be adjusted according to window information 1, the second communication device (Sender) may adjust (either increase or decrease) the send window at the next moment to the send window size indicated by window information 2. It will be understood that if the send window size indicated by window information 2 is equal to the current send window size of the second communication device, the second communication device may confirm to use the current send window to send the data at the next moment, or may not adjust the send window size. In other words, after the sender (the second communication device) receives the feedback message (i.e., data message 3) from the receiver (the third communication device), it does not necessarily change or adjust the data sending window. In other words, the sender's request to adjust the data sending window does not necessarily result in a change in the sending window.

[0426] It can also be understood that if the sending window size indicated by the window information 2 is smaller than the current sending window size of the second communication device, the second communication device (Sender) may reduce / reduce the sending window at the next moment to the sending window size indicated by the window information 2. If the sending window size indicated by the window information 2 is larger than the current sending window size of the second communication device, the second communication device (Sender) may increase the sending window at the next moment to the sending window size indicated by the window information 2.

[0427] In a possible implementation, after step S105, the second communication device (Sender) may send data according to the determined size of the sending window.

[0428] The sending end (i.e., the second communication device) of the embodiment of the present application sends window information 1 along with the data stream to request adjustment of the data sending window; after the first communication device (such as a base station) receives the data packet containing window information 1, it determines whether its own transmission capacity can meet the needs of the sending end (i.e., the size of the sending window requested to be adjusted by window information 1) by sensing the usage and / or remaining status of the air interface resources, and / or the current cache resources. This can make the size of the sending window more compatible with the transmission capacity of the first communication device (such as a base station), reduce packet loss in the network (or achieve no packet loss) and data transmission delay, improve data transmission reliability and throughput, and thus achieve low-latency, high-throughput data transmission.

[0429] To better understand the method flow of the embodiment shown in FIG3 , the data transmission process in a distributed computing scenario is used as an example for illustration.

[0430] For example, the second communication device is a NodeC, the third communication device is a UE, and the first communication device is a gNB. Referring to Figure 4, Figure 4 is a schematic diagram of a method for downlink data congestion control for a UE and a NodeC according to an embodiment of the present application. The UE and NodeC utilize the RDMA mechanism to transmit data, with the NodeC acting as the data sender and the UE acting as the data receiver. As shown in Figure 4, the NodeC sends a data packet 1 containing window information 1 (e.g., an increase intention value a, i.e., II value a in Figure 4) to request adjustment (e.g., increase) of the data transmission window. The data transmission path from the NodeC to the UE is from the NodeC through the gNB and finally to the UE. When the gNB detects that the data packet 1 sent from the NodeC to the UE contains window information 1 (e.g., II value a), the gNB determines window information 2 (e.g., II value b, where II value b is less than or equal to II value a) based on the window information 1 and one or more of the following: the downlink air interface status of the destination UE (e.g., downlink channel quality), the remaining downlink air interface bandwidth resources, or the lengths of the downlink buffer queues for all shared downlink air interface resources (e.g., time-frequency resources) within the gNB. The specific determination method is described above and is not repeated here. Window information 2 can be used to indicate the data send window. The gNB generates data message 2 based on data message 1 and window information 2 (e.g., II value b) and sends this data message 2 to the UE. Data message 2 includes window information 2 (e.g., II value b, where II value b is less than or equal to II value a). The generation method of data message 2 is described above and is not repeated here. After receiving data message 2, the UE carries window information 2 (e.g., II value b) in RDMA layer 3 or layer 4 feedback information and sends it to NodeC via a feedback message (e.g., data message 3). NodeC adjusts the send window based on the UE's feedback, such as window information 2 (e.g., II value b). It is understood that if II value b is 0 (or the send window size indicated by window information 2 is equal to the current send window size of NodeC), the send window size is not adjusted.

[0431] In one possible implementation, the gNB may decide to reduce the sending window when determining window information 2 (such as II value b), that is, II value b is a negative value; in other words, the size of the sending window indicated by window information 2 determined by the gNB is smaller than the size of the current sending window of NodeC. In this case, the method of the embodiment of the present application can still be used (i.e., the UE sends window information 2 (such as II value b) to NodeC via L3 or L4 feedback information of RDMA) to instruct the sender (such as NodeC) to reduce the sending window. Of course, other methods can also be used, such as the explicit congestion notification (ECN) mechanism, to instruct the sender (such as NodeC) to reduce the sending window. The embodiment of the present application does not limit the specific method used to implement the sending window reduction control.

[0432] In the embodiment of the present application, during downlink data transmission between the UE and the NodeC, congestion control for RDMA data transmission is performed through the bottleneck node gNB. This allows for better perception of restricted and fluctuating air interface conditions, allowing the send window size to be better matched to the transmission capabilities of the gNB, the communication bottleneck node. This allows for quick and accurate adjustment of the send window size, enabling low-latency, high-throughput RDMA data transmission for distributed computing. Furthermore, the embodiment of the present application maximizes the adaptation of the RDMA protocol and congestion control mechanism to mobile communication networks, or in other words, maximizes the use of the RDMA congestion control mechanism and adapts it to mobile communication networks, making implementation easy.

[0433] For example, the second communication device is a UE, the third communication device is a NodeC, and the first communication device is a gNB. Referring to Figure 5, Figure 5 is a schematic diagram of a method for uplink data congestion control for a UE and a NodeC according to an embodiment of the present application. The UE and the NodeC utilize the RDMA mechanism to transmit data, with the UE acting as the data sender and the NodeC acting as the data receiver. As shown in Figure 5, the UE transmits a data packet 1 containing window information 1 (e.g., an increase intention value a, i.e., II value a in Figure 5) to request adjustment (e.g., increase) of the data transmission window. The data transmission path from the UE to the NodeC is from the UE via the gNB and then to the NodeC. When the gNB detects that the data packet 1 sent by the UE to the NodeC contains window information 1 (e.g., II value a), the gNB determines window information 2 (e.g., II value b, where II value b is less than or equal to II value a) based on the window information 1 and one or more of the following: the source UE's uplink air interface status (e.g., uplink channel quality), the remaining uplink air interface bandwidth resources, or the lengths of each uplink buffer queue for all shared uplink air interface resources (e.g., time-frequency resources) within the gNB. The specific determination method is described above and is not repeated here. Window information 2 can be used to indicate the data send window. The gNB generates data message 2 based on data message 1 and window information 2 (e.g., II value b) and sends this data message 2 to NodeC. Data message 2 includes window information 2 (e.g., II value b, where II value b is less than or equal to II value a). The generation method of data message 2 is described above and is not repeated here. After receiving data message 2, NodeC carries window information 2 (e.g., II value b) in RDMA layer 3 or layer 4 feedback information and sends it to the UE via a feedback message (e.g., data message 3). The UE adjusts its send window based on the feedback from NodeC, such as window information 2 (e.g., II value b). It is understood that if II value b is 0 (or the send window size indicated by window information 2 is equal to the UE's current send window size), the send window size is not adjusted.

[0434] In one possible implementation, when the gNB decides to reduce the send window, the method of the embodiment of the present application can be used (i.e., the NodeC sends window information 2 (e.g., II value b) to the UE via L3 or L4 feedback information of RDMA) to instruct the sender (e.g., UE) to reduce the send window. Of course, other methods, such as an explicit congestion notification (ECN) mechanism, can also be used to instruct the sender (e.g., UE) to reduce the send window. This will not be discussed in detail below. The embodiment of the present application does not limit the specific method used to implement the send window reduction control.

[0435] In this embodiment of the present application, during uplink data transmission between a UE and a NodeC, the gNB, acting as a bottleneck node, participates in congestion control. This allows for better awareness of restricted and fluctuating air interface conditions, enabling the send window size to be more accurately matched to the transmission capabilities of the bottleneck gNB. This allows for quick and accurate adjustment of the send window size, enabling low-latency, high-throughput RDMA data transmission for distributed computing. Furthermore, this embodiment of the present application leverages RDMA's congestion control mechanism to the greatest extent possible and adapts it to mobile communication networks, facilitating implementation.

[0436] For example, the second communication device is a server (here, an edge server / cloud server, etc.), the third communication device is a UE, and the first communication device is a gNB. Referring to Figure 6 , Figure 6 is a schematic diagram of a downlink data congestion control method for a UE and a server, provided in an embodiment of the present application. The UE and server utilize the RDMA mechanism to transmit data, with the server acting as the sender and the UE acting as the receiver. As shown in Figure 6 , the data transmission path from the server to the UE is from the server to the UPF, then to the gNB, and finally to the UE. However, because the UPF in Figure 6 transparently forwards data and does not participate in send window adjustment (or congestion control), the downlink data congestion control method shown in Figure 6 is equivalent to the downlink data congestion control method shown in Figure 4 , and a detailed description thereof will not be given here.

[0437] In this embodiment of the present application, during downlink data transmission between a UE and a server, the gNB, acting as a bottleneck node, participates in congestion control. This allows for better awareness of restricted and fluctuating air interface conditions, enabling the send window size to be more accurately matched to the transmission capabilities of the bottleneck gNB. This allows for quick and accurate adjustment of the send window size, enabling low-latency, high-throughput RDMA data transmission for distributed computing. Furthermore, this embodiment of the present application maximizes the adaption of the RDMA protocol and congestion control mechanism to mobile communication networks, facilitating implementation.

[0438] For example, the second communication device is a UE, the third communication device is a server (here, an edge server / cloud server, etc.), and the first communication device is a gNB. Referring to Figure 7 , Figure 7 is a schematic diagram of a method for uplink data congestion control for a UE and a server, provided in an embodiment of the present application. The UE and server utilize the RDMA mechanism to transmit data, with the UE acting as the sender and the server acting as the receiver. As shown in Figure 7 , the data transmission path from the UE to the server is from the UE to the gNB, then to the UPF, and finally to the server. However, because the UPF in Figure 7 transparently forwards data and does not participate in send window adjustment (or congestion control), the uplink data congestion control method shown in Figure 7 is equivalent to the uplink data congestion control method shown in Figure 5 , and a detailed description thereof will not be given here.

[0439] In this embodiment of the present application, during uplink data transmission between a UE and a server, the gNB, acting as a bottleneck node, participates in congestion control. This allows for better awareness of restricted and fluctuating air interface conditions, aligning the send window size with the capabilities of the bottleneck gNB. This allows for rapid and accurate adjustment of the send window size, enabling low-latency, high-throughput RDMA data transmission for distributed computing. Furthermore, this embodiment of the present application largely leverages RDMA's congestion control mechanisms and adapts them to mobile communication networks, simplifying implementation.

[0440] See Figure 8, which is a second flow chart of the congestion control method provided in an embodiment of the present application. In this method, the first communication device is a base station (such as gNB), the second communication device is a sender (Sender) of data, and the third communication device is a receiver (Receiver) of data. Exemplarily, the second communication device is a terminal (such as UE), and the third communication device is an in-network computing node (such as NodeC); or, the second communication device is an in-network computing node (such as NodeC), and the third communication device is a terminal (such as UE). Another exemplary embodiment, the second communication device is a terminal (such as UE), and the third communication device is an off-network computing node (such as an edge server / cloud server); or, the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal (such as UE).

[0441] As shown in FIG8 , the congestion control method includes but is not limited to the following steps:

[0442] In step S201, a second communication device (Sender) sends data message 1, which includes window information 1 for requesting adjustment of the data sending window. The source address (source address) of data message 1 is the address of the second communication device, and the destination address (target address) of data message 1 is the address of a third communication device.

[0443] S202, the first communication device (such as a base station) receives the data message 1, and determines the window information 2 based on the window information 1 and the air interface resources in the data message 1, where the window information 2 is used to indicate the sending window of the data, and the size of the sending window indicated by the window information 2 is less than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0444] In one possible implementation, the implementation of step S201 and step S202 in the embodiment of the present application can refer to the implementation of step S101 and step S102 in the embodiment shown in Figure 3 above, and will not be repeated here.

[0445] S203: The first communication device (e.g., a base station) sends data message 2 to the third communication device (Receiver), where the data message 2 includes the window information 2. The window information 2 may be used to indicate a data sending window, and the size of the sending window indicated by the window information 2 is less than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0446] Accordingly, after receiving the data packet 2, the third communication device (Receiver) may send a feedback message to the second communication device (Sender). The data carried in the feedback message is different from the data carried in the data packet 2, but the feedback message and the data packet 2 may belong to the same QoS flow or the same session.

[0447] In one possible implementation, after the first communication device (such as a base station) determines the above-mentioned window information 2, it can send a data message 2 to the third communication device (Receiver). The data (or load payload) in the data message 2 can be the same as the data (or load payload) in the above-mentioned data message 1. Exemplarily, the data contained in the data message in the embodiment of the present application can be RDMA data. The window information 2 can be contained in the header of the data message 2. For example: the window information 2 can be carried in the frame header of the data link layer of the data message 2, or the packet header of the network layer, or the message header of the transport layer.

[0448] In the embodiment of the present application, the window information 2 is carried in the data message 2 so that the receiving end can know the sending window size of the sending end at the next moment, thereby preparing to receive data.

[0449] It is understood that when the sending window size indicated by window information 2 determined by the first communication device (e.g., a base station) is equal to the sending window size requested to be adjusted by window information 1, the first communication device may directly forward data message 1 to the third communication device (Receiver) without processing data message 1. In other words, data message 2 may be the same as data message 1, and the value of window information 2 may be the same as the value of window information 1. It is also understood that when the sending window size indicated by window information 2 determined by the first communication device (e.g., a base station) is smaller than the sending window size requested to be adjusted by window information 1, data message 2 may be obtained by replacing / updating window information 1 in data message 1 with window information 2. In other words, when the sending window size indicated by window information 2 is smaller than the sending window size requested to be adjusted by window information 1, the first communication device may rewrite / replace / update window information 1 in data message 1 with window information 2 to obtain data message 2.

[0450] In another possible implementation, after the first communication device (such as a base station) receives the above-mentioned data message 1, it can, on the one hand, execute step S202, and on the other hand, forward the data message 1 to the third communication device (Receiver); this can reduce the delay in data transmission. Alternatively, after the first communication device (such as a base station) receives the above-mentioned data message 1, it can, on the one hand, execute step S202, and on the other hand, remove the window information 1 in the data message 1 to obtain a new data message, and send this new data message to the third communication device (Receiver). In other words, the data message sent by the first communication device (such as a base station) to the third communication device (Receiver) may not carry any window information (including window information 1 and window information 2), but the data (or load payload) in the data message is the same as the data (or load payload) in the data message 1.

[0451] S204: The first communication device (e.g., a base station) sends a data packet 3 to the second communication device (Sender), where the data packet 3 includes the window information 2. The window information 2 may be used to indicate a data sending window, and the size of the sending window indicated by the window information 2 is less than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0452] In a possible implementation, the embodiment of the present application does not limit the execution order of step S203 and step S204. For example, step S203 can be executed before step S204, after step S204, or simultaneously with step S204.

[0453] In one possible implementation, after determining the window information 2, the first communication device (e.g., a base station) may send a data message 3 to the second communication device (Sender), where the data message 3 may include the window information 2. The following example illustrates how the window information 2 is carried in the data message 3.

[0454] Exemplarily, the data packet 3 may include layer 3 or layer 4 feedback information of RDMA, the layer 3 or layer 4 feedback information of RDMA may carry the window information 2, and the data packet 3 and the above-mentioned data packet 1 belong to the same QoS flow or the same session. For example, in a downlink data transmission scenario, if the sender (the second communication device) is NodeC and the receiver (the third communication device) is UE, after the first communication device (such as the base station) determines the above-mentioned window information 2, it can search for a feedback message belonging to the same QoS flow / the same session as the data packet 1 in the uplink direction, and can carry the window information 2 in the RDMA layer 3 or layer 4 feedback information of the first feedback message (i.e., data packet 3) that meets the conditions (i.e., belongs to the same QoS flow / the same session as the data packet 1), and send the feedback message (i.e., data packet 3) to the second communication device (Sender).

[0455] Exemplarily, the data packet 3 may include RDMA layer 3 or layer 4 feedback information, and the RDMA layer 3 or layer 4 feedback information may carry the window information 2. For example, in a downlink data transmission scenario, if the sender (the second communication device) is a NodeC and the receiver (the third communication device) is a UE, after the first communication device (such as a base station) determines the above-mentioned window information 2, it may generate a new uplink feedback message (i.e., data packet 3), which includes RDMA layer 3 or layer 4 feedback information, including the window information 2; and send the feedback message (i.e., data packet 3) to the second communication device (Sender). The feedback message (i.e., data packet 3) may not include data.

[0456] Exemplarily, data packet 3 may include a user plane General Packet Radio Service (GPRS) Tunneling Protocol (GTP-u) header, which may carry window information 2. For example, in a downlink data transmission scenario, where the sender (second communication device) is a NodeC and the receiver (third communication device) is a UE, the first communication device (e.g., a base station) determines the window information 2 and may search in the uplink direction for uplink RDMA data belonging to the same QoS flow / session as data packet 1. The uplink RDMA data is then encapsulated into a GTP-u tunnel message (which can be understood as a data message with a GTP-u header added, so for ease of description, the GTP-u tunnel message may also be referred to as data message 3). The GTP-u header of the GTP-u tunnel message (i.e., data message 3) carries the window information 2, and the GTP-u tunnel message is sent to the second communication device (sender). Alternatively, after the first communication device (such as a base station) determines the above-mentioned window information 2, it generates dummy data, and then encapsulates the dummy data into a GTP-u tunnel message (i.e., data message 3), carries the window information 2 in the GTP-u header of the GTP-u tunnel message (i.e., data message 3), and sends the GTP-u tunnel message to the second communication device (Sender).

[0457] It is understood that, for the method of carrying window information 2 via the GTP-u header, the second communication device (Sender) needs to have the ability to encapsulate and decapsulate the GTP-u tunnel, or have an application programming interface (API) capability to obtain window information via the operating system. For example, the RDMA network card in the second communication device (Sender) may have the ability to encapsulate and decapsulate the GTP-u tunnel, or have an API capability to obtain window information via the operating system.

[0458] Exemplarily, the data message 3 may include a Uu Layer 2 header or a Layer 2 control protocol data unit (PDU), and the UuL2 header or L2 control PDU may carry the window information 2. For example, in an uplink data transmission scenario, if the sender (second communication device) is a UE and the receiver (third communication device) is a NodeC or a server, after determining the window information 2, the first communication device (such as a base station) may generate a new feedback message (i.e., data message 3). The feedback message (i.e., data message 3) includes a UuL2 header or L2 control PDU, which carries the window information 2, and send this feedback message to the second communication device (Sender). The feedback message (i.e., data message 3) may not include data. In one possible implementation, the modem of the second communication device (Sender) may decode the feedback message (i.e., data message 3) through an AT command (AT cmd), obtain the window information 2 therein, and output the window information 2 to the RDMA network card.

[0459] In an embodiment of the present application, the first communication device (such as a base station) modifies the feedback message in the cache, or generates a new feedback message, or carries the window information 2 through the GTP-u header / Uu L2 header / L2 control PDU; the window information 2 (or congestion control information) can be reduced from passing through the air interface, thereby making congestion control (or adjustment of the send window) more timely, and achieving low latency and high throughput of RDMA data transmission.

[0460] S205 , the second communication device (Sender) determines a data sending window based on the window information 2 in the data message 3 .

[0461] In a possible implementation manner, the implementation manner of step S205 in the embodiment of the present application can refer to the implementation manner of step S105 in the embodiment shown in Figure 3 above, and will not be repeated here.

[0462] The sending end (i.e., the second communication device) of the embodiment of the present application sends window information 1 along with the data stream to request adjustment of the data sending window; after the first communication device (such as a base station) receives the data packet containing window information 1, it determines whether its own transmission capacity can meet the needs of the sending end (i.e., the size of the sending window requested to be adjusted by window information 1) by sensing the usage and / or remaining status of the air interface resources, and / or the current cache resources. This can make the size of the sending window more compatible with the transmission capacity of the first communication device (such as a base station), reduce packet loss in the network (or achieve no packet loss) and data transmission delay, improve data transmission reliability and throughput, and thus achieve low-latency, high-throughput data transmission.

[0463] To better understand the method flow of the embodiment shown in FIG8 , the data transmission process in a distributed computing scenario is used as an example for illustration.

[0464] For example, the second communication device is a NodeC, the third communication device is a UE, and the first communication device is a gNB. Referring to Figure 9, Figure 9 is another schematic diagram of a method for downlink data congestion control for a UE and a NodeC, provided in an embodiment of the present application. The UE and NodeC utilize the RDMA mechanism to transmit data, with the NodeC acting as the data sender and the UE acting as the data receiver. As shown in Figure 9, the NodeC sends a data packet 1 containing window information 1 (e.g., an increase intention value a, i.e., II value a in Figure 9), requesting adjustment (e.g., increase) of the data transmission window. The data transmission path from the NodeC to the UE is from the NodeC via the GNB and finally to the UE. When the gNB detects that the data packet 1 sent by the NodeC to the UE contains window information 1 (e.g., II value a), the gNB determines window information 2 (e.g., II value b, where II value b is less than or equal to II value a) based on the window information 1 and one or more of the following: the downlink air interface status of the destination UE (e.g., downlink channel quality), the remaining downlink air interface bandwidth resources, or the lengths of the downlink buffer queues for all shared downlink air interface resources (e.g., time-frequency resources) within the gNB. The specific determination method is described above and is not repeated here. Window information 2 can be used to indicate the data sending window. The gNB generates data message 2 based on data message 1 and / or window information 2 (e.g., II value b) and sends data message 2 to the UE. The data in data message 2 is the same as the data in data message 1. The generation method of data message 2 is described above and is not repeated here. The gNB sends data message 3 to the NodeC, carrying window information 2. The method for carrying window information 2 in data message 3 is described above and is not repeated here. For example, the gNB may modify / generate an uplink feedback message to carry window information 2, or carry window information 2 in an uplink GTP-u header. The NodeC adjusts the sending window based on the gNB feedback, such as window information 2 (e.g., II value b). It is understood that if II value b is 0 (or the size of the sending window indicated by window information 2 is equal to the current size of the NodeC's sending window), the sending window size is not adjusted.

[0465] For example, the second communication device is a UE, the third communication device is a NodeC, and the first communication device is a gNB. Referring to Figure 10, Figure 10 is another schematic diagram of the uplink data congestion control method for UE and NodeC provided in an embodiment of the present application. UE and NodeC use the RDMA mechanism to transmit data, with the UE acting as the sender of the data and the NodeC acting as the receiver. As shown in Figure 10, the UE sends a data message 1 containing window information 1 (for example, an increase in the intention value a, i.e., the II value a in Figure 10), which is used to request adjustment (for example, increase) of the data sending window. The data transmission path from the UE to the NodeC is from the UE via the GNB and finally reaches the NodeC. When the gNB detects that data message 1 sent by the UE to the NodeC contains window information 1 (e.g., II value a), the gNB determines window information 2 (e.g., II value b, where II value b is less than or equal to II value a) based on window information 1 and one or more of the following: the source UE's uplink air interface status (e.g., uplink channel quality), remaining uplink air interface bandwidth resources, or the lengths of uplink buffer queues for all shared uplink air interface resources (e.g., time-frequency resources) within the gNB. The specific determination method is described above and is not repeated here. Window information 2 can be used to indicate a data transmission window. The gNB generates data message 2 based on data message 1 and / or window information 2 (e.g., II value b) and sends data message 2 to the NodeC. The data in data message 2 is the same as the data in data message 1. The generation method of data message 2 is described above and is not repeated here. The gNB sends data message 3 to the UE, carrying window information 2. The method for carrying window information 2 in data message 3 is described above and is not repeated here. For example, the gNB carries window information 2 via the Uu L2 header or L2 control PDU. The UE adjusts its send window based on the gNB's feedback, such as window information 2 (e.g., II value b). For example, the UE's modem decodes data packet 3 using an AT command (AT cmd), obtains window information 2 (e.g., II value b), and outputs this window information 2 (e.g., II value b) to the RDMA network card. The RDMA network card adjusts its send window based on this window information 2 (e.g., II value b). It should be understood that if II value b is 0 (or the send window size indicated by window information 2 is equal to the UE's current send window size), the send window size is not adjusted.

[0466] For example, the second communication device is a UE, the third communication device is a server (here, an edge server / cloud server, etc.), and the first communication device is a gNB. Referring to Figure 11, Figure 11 is another schematic diagram of an uplink data congestion control method for a UE and a server provided in an embodiment of the present application. The UE and the server use the RDMA mechanism to transmit data, with the UE acting as the sender and the server acting as the receiver. As shown in Figure 11, the data transmission path from the UE to the server is from the UE to the gNB, then to the UPF, and finally to the server. However, because the UPF in Figure 11 transparently forwards data and does not participate in send window adjustment (or congestion control), the uplink data congestion control method shown in Figure 11 is equivalent to the uplink data congestion control method shown in Figure 10, and a detailed description thereof will not be given here.

[0467] In the embodiments of the present application, the gNB perceives the air interface status and participates in congestion control, so that the sending window of RDMA data is more closely matched with the transmission capacity of the network, thereby achieving low latency and high throughput transmission of distributed computing in mobile networks.

[0468] See Figure 12, which is a schematic diagram of a third flow chart of the congestion control method provided in an embodiment of the present application. In this method, the first communication device is a base station (such as a gNB), the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal (such as a UE). The second communication device acts as a sender of data, and the third communication device acts as a receiver of data.

[0469] As shown in FIG12 , the congestion control method includes but is not limited to the following steps:

[0470] In step S301, a second communication device (Sender) sends data message 1, which includes window information 1 for requesting adjustment of the data sending window. The source address (source address) of data message 1 is the address of the second communication device, and the destination address (target address) of data message 1 is the address of a third communication device.

[0471] In a possible implementation, the implementation of step S301 in the embodiment of the present application can refer to the implementation of step S101 in the embodiment shown in Figure 3 above, and will not be repeated here.

[0472] S302, the UPF receives the data packet 1 and generates a data packet 2 based on the data packet 1, where the data packet 2 includes a downlink GTP-u header, and the downlink GTP-u header includes the window information 1.

[0473] S303: The UPF sends the data message 2 to the first communication device (eg, a base station).

[0474] It can be understood that since the transmission path of the data message 1 passes through the UPF and the first communication device (such as a base station), the UPF can receive the data message 1.

[0475] In one possible implementation, after receiving the above-mentioned data message 1, the UPF can detect whether the data message 1 contains the above-mentioned window information 1. Exemplarily, the UPF can parse the header information of the data message 1, or the UPF can perform deep packet inspection (DPI) on the data message 1 to determine whether the data message 1 contains the above-mentioned window information 1. When the UPF detects that the data message 1 contains the above-mentioned window information 1, the UPF can obtain the window information 1 and add a downlink GTP-u header to the data message 1 to obtain a data message 2, the downlink GTP-u header carries the window information 1, and sends the data message 2 to the first communication device (such as a base station).

[0476] It can be understood that after the UPF of the embodiment of the present application reads the above-mentioned window information 1 from the above-mentioned data message 1, it carries the window information 1 in the downlink GTP-u header and sends it to the first communication device (such as a base station). The first communication device (such as a base station) does not need to perform DPI on the received data message, which can reduce the complexity of the first communication device (such as a base station) and reduce changes to existing base station equipment.

[0477] S304, the first communication device (such as a base station) determines window information 2 based on the window information 1 in the data message 2 and the air interface resources, and the window information 2 is used to indicate the sending window of the data, and the size (size) of the sending window indicated by the window information 2 is less than or equal to the size (size) of the sending window requested to be adjusted by the above-mentioned window information 1.

[0478] In one possible implementation, after receiving the data packet 2, the first communication device (e.g., a base station) may parse the downlink GTP-u header of the data packet 2 to obtain the window information 1. The first communication device (e.g., a base station) may determine the window information 2 based on the perceived air interface resources and the window information 1. For a description of the window information 2 and the implementation of the first communication device (e.g., a base station) determining the window information 2, please refer to the description of step S102 in the embodiment shown in FIG. 3 , which will not be repeated here.

[0479] S305: The first communication device (e.g., a base station) sends data packet 3 to the third communication device (Receiver). Data packet 3 includes window information 2. Accordingly, after receiving data packet 3, the third communication device (Receiver) may send a feedback message to the second communication device (Sender). The data carried in the feedback message is different from the data carried in data packet 3, but the feedback message and data packet 3 may belong to the same QoS flow or the same session.

[0480] In one possible implementation, the implementation of step S305 in the embodiment of the present application can refer to the implementation of step S203 in the embodiment shown in Figure 8 above, and will not be repeated here.

[0481] S306 , the first communication device (eg, a base station) sends a data packet 4 to the UPF, where the data packet 4 includes an uplink GTP-u header, and the uplink GTP-u header includes the window information 2. Accordingly, the UPF receives the data packet 4 .

[0482] In a possible implementation, the embodiment of the present application does not limit the execution order of step S305 and step S306. For example, step S305 can be executed before step S306, after step S306, or simultaneously with step S306.

[0483] In a possible implementation, the data message 4 may be a GTP-u tunnel message. In the embodiment of the present application, the GTP-u tunnel message may be understood as a data message with a GTP-u header added.

[0484] In one possible implementation, after the first communication device (such as a base station) determines the above-mentioned window information 2, it can search the local cache for uplink RDMA data sent to the UPF and belonging to the same QoS flow as the above-mentioned data packet 2, encapsulate the uplink RDMA data into a GTP-u tunnel message (i.e., data message 4), and carry the window information 2 in the uplink GTP-u header of the GTP-u tunnel message (i.e., data message 4); and send the GTP-u tunnel message (i.e., data message 4) to the UPF.

[0485] In another possible implementation, after the first communication device (such as a base station) determines the above-mentioned window information 2, it can generate dummy data, and then encapsulate the dummy data into a GTP-u tunnel message (i.e., data message 4), carry the window information 2 in the uplink GTP-u header of the GTP-u tunnel message (i.e., data message 4), and send the GTP-u tunnel message (i.e., data message 4) to the UPF.

[0486] S307 , the UPF sends a data packet 5 to the second communication device (Sender), where the data packet 5 includes the window information 2 . Correspondingly, the second communication device (Sender) receives the data packet 5 .

[0487] In one possible implementation, after receiving the data packet 4, the UPF may parse the uplink GTP-u header of the data packet 4 to obtain the window information 2. The UPF may generate a data packet 5 based on the window information 2 and send the data packet 5 to the second communication device (Sender). The data packet 5 includes the window information 2.

[0488] Exemplarily, after obtaining the above-mentioned window information 2, the UPF can search for a feedback message that belongs to the same QoS flow / the same session as the above-mentioned data message 1 in the uplink direction, and can carry the window information 2 in the RDMA layer 3 or layer 4 feedback information of the first feedback message (i.e., data message 5) that meets the conditions (i.e., belongs to the same QoS flow / the same session as the data message 1), and send the feedback message (i.e., data message 5) to the second communication device (Sender).

[0489] For example, after obtaining the window information 2, the UPF may generate a new uplink feedback message (i.e., data message 5), which includes RDMA layer 3 or layer 4 feedback information and carries the window information 2. The UPF then sends the feedback message (i.e., data message 5) to the second communication device (Sender). The feedback message (i.e., data message 5) may not include data.

[0490] In one possible implementation, after the UPF obtains the above-mentioned window information 2, it can send the window information 2 to the second communication device (Sender) through the API. Of course, the UPF can also send the data message 5 to the second communication device (Sender) through the API after obtaining the above-mentioned window information 2 and generating the data message 5. This is not limited in the embodiment of the present application. It can be understood that for the method of sending the above-mentioned window information 2 through the API, the second communication device (Sender) needs to have the API encapsulation and decapsulation capabilities, or have the API capability of obtaining window information through the operating system. Exemplarily, the RDMA network card in the second communication device (Sender) may have the API encapsulation and decapsulation capabilities, or have the API capability of obtaining window information through the operating system.

[0491] In an embodiment of the present application, the first communication device (such as a base station) informs the UPF of the "window information 2 (or congestion control information)" through the GTP-u header. The UPF modifies the feedback message in the cache or generates a new feedback message to carry the window information 2, or feeds back the window information 2 through the API. This can reduce the window information 2 (or congestion control information) from bypassing the air interface, thereby making congestion control (or adjustment of the sending window) more timely, and achieving low latency and high throughput of RDMA data transmission.

[0492] S308 , the second communication device (Sender) determines a data sending window based on the window information 2 in the data message 5 .

[0493] In a possible implementation, the implementation of step S308 in the embodiment of the present application can refer to the implementation of step S105 in the embodiment shown in FIG3 above, and will not be repeated here.

[0494] The sending end (i.e., the second communication device) of the embodiment of the present application sends window information 1 along with the data stream to request adjustment of the data sending window; after the UPF receives the data packet 1 containing the window information 1, it adds a downlink GTP-u header to the data packet 1 to carry the window information 1, and sends the data packet (i.e., data packet 2) with the downlink GTP-u header added to the first communication device (such as a base station); in this way, after the first communication device (such as a base station) receives the data packet 2, there is no need to perform DPI on the received packet, which can reduce the complexity of the first communication device (such as a base station) and reduce changes to the existing base station equipment. In addition, the embodiment of the present application determines whether its own transmission capacity can meet the needs of the sender (i.e., the size of the sending window requested to be adjusted by window information 1) by sensing the usage and / or remaining status of the air interface resources and / or the current cache resources through the bottleneck node (i.e., the first communication device). This can make the size of the sending window more compatible with the transmission capacity of the bottleneck node (the first communication device, such as a base station), and can reduce packet loss in the network (or achieve no packet loss) and data transmission delay, improve the reliability and throughput of data transmission, and thus achieve low-latency, high-throughput data transmission.

[0495] To better understand the method flow of the embodiment shown in FIG. 12 , the following is an illustration using the downlink data transmission process in a distributed computing scenario.

[0496] For example, the second communication device is a server (here, an edge server / cloud server, etc.), the third communication device is a UE, and the first communication device is a gNB. Referring to Figure 13, Figure 13 is another schematic diagram of a downlink data congestion control method for a UE and a server provided in an embodiment of the present application. The UE and server utilize the RDMA mechanism to transmit data, with the server acting as the data sender and the UE acting as the data receiver. As shown in Figure 13, the server sends data packet 1 containing window information 1 (e.g., an increase intent value a, i.e., II value a in Figure 13) to request adjustment (e.g., increase) of the data send window. The data transmission path from the server to the UE is from the server, through the UPF, to the gNB, and finally to the UE. When the UPF detects that data packet 1 sent from the server to the UE contains window information 1 (e.g., II value a), the UPF reads the window information 1 from data packet 1 and may add a downlink GTP-u header to data packet 1 to obtain data packet 2. The downlink GTP-u header carries the window information 1, and data packet 2 may then be sent to the gNB. The gNB determines window information 2 (e.g., II value b, where II value b is less than or equal to II value a) based on window information 1 in the downlink GTP-u header and one or more of the following: the downlink air interface status of the destination UE (e.g., downlink channel quality), remaining downlink air interface bandwidth resources, or the lengths of downlink buffer queues for all shared downlink air interface resources (e.g., time-frequency resources) within the gNB. The specific determination method is described above and is not repeated here. Window information 2 can be used to indicate a data transmission window. The gNB generates data message 3 based on data message 2 and sends this data message 3 to the UE. The data in data message 3 is the same as the data in data message 1 and data message 2. The generation method of data message 3 is described above and is not repeated here. The gNB sends data packet 4 to the UPF. This data packet 4 includes an uplink GTP-u header containing window information 2 (e.g., II value b, where II value b is less than or equal to II value a). The generation of data packet 4 is described above and is not repeated here. After receiving data packet 4, the UPF modifies or generates an uplink feedback message (e.g., data packet 5) to carry window information 2 (e.g., II value b) within the RDMA layer 3 or layer 4 feedback information and sends it to the server. Alternatively, the UPF sends this window information 2 (e.g., II value b) to the server via an API. The server adjusts the send window based on the UPF's feedback, such as window information 2 (e.g., II value b). It is understood that if II value b is 0 (or the send window size indicated by window information 2 is equal to the server's current send window size), the send window size is not adjusted.

[0497] In this embodiment of the present application, the gNB perceives the air interface status and participates in congestion control, ensuring that the RDMA data send window is more closely aligned with the network's transmission capabilities, thereby achieving low-latency and high-throughput transmission for distributed computing in mobile networks. Furthermore, the UPF in this embodiment of the present application extracts window information 1 from data packet 1 and communicates this window information 1 to the gNB via the GTP-u header. This eliminates the need for the gNB to perform DPI on received packets, reducing gNB complexity and minimizing modifications to existing base station equipment.

[0498] See Figure 14, which is a fourth flow chart of the congestion control method provided in an embodiment of the present application. In this method, the first communication device is a base station (such as a gNB), the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal (such as a UE). The second communication device acts as a sender of data, and the third communication device acts as a receiver of data.

[0499] As shown in FIG14 , the congestion control method includes but is not limited to the following steps:

[0500] In step S401, a second communication device (Sender) sends data message 1, which includes window information 1, which is used to request adjustment of the data sending window. The source address (source address) of data message 1 is the address of the second communication device, and the destination address (target address) of data message 1 is the address of a third communication device.

[0501] In a possible implementation, the implementation of step S401 in the embodiment of the present application can refer to the implementation of step S101 in the embodiment shown in FIG3 above, and will not be repeated here.

[0502] S402, UPF receives the data packet 1, and determines the window information 2 based on the window information 1 in the data packet 1 and its own cache resources. The window information 2 is used to indicate the sending window of the data, and the size of the sending window indicated by the window information 2 is less than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0503] It can be understood that since the transmission path of the data message 1 passes through the UPF and the first communication device (such as a base station), the UPF can receive the data message 1.

[0504] In one possible implementation, after receiving the above-mentioned data packet 1, the UPF can detect whether the data packet 1 contains the above-mentioned window information 1. Exemplarily, the UPF can parse the header information of the data packet 1, or the UPF can perform deep packet inspection (DPI) on the data packet 1 to determine whether the data packet 1 contains the window information 1. When the UPF detects that the data packet 1 contains the above-mentioned window information 1, the UPF can determine the window information 2 based on its own cache resources and the window information 1. The window information 2 can be used to indicate the sending window of the data. Exemplarily, the size of the sending window indicated by the above-mentioned window information 2 is less than or equal to the size of the sending window requested to be adjusted by the above-mentioned window information 1. In other words, the sending window size determined / indicated by the UPF is less than or equal to the sending window size expected by the second communication device (Sender). For example, the UPF can determine a sending window size for the QoS flow or session to which the above-mentioned data packet 1 belongs based on its own cache resources. If the sending window size determined by the UPF is greater than or equal to the sending window size requested to be adjusted by the above-mentioned window information 1, the UPF may generate window information 2 based on the sending window size requested to be adjusted by the window information 1, and the size of the sending window indicated by the window information 2 is equal to the size of the sending window requested to be adjusted by the window information 1. If the sending window size determined by the UPF is smaller than the sending window size requested to be adjusted by the above-mentioned window information 1, the UPF may generate window information 2 based on the determined sending window size, and the size of the sending window indicated by the window information 2 is the sending window size determined by the UPF. Of course, the size of the sending window indicated by the window information 2 is smaller than the size of the sending window requested to be adjusted by the window information 1.

[0505] It is understood that window information 1 and window information 2 can be information of the same dimension. For example, window information 1 is an increase in intent value, and window information 2 is also a value; or, window information 1 is the buffer queue length within the second communication device (Sender), and window information 2 is also a buffer queue length; or, window information 1 is the link bandwidth capacity of the second communication device (Sender), and window information 2 is also a link bandwidth capacity. It is also understood that the specific value of window information 2 can be determined by the internal policy of the UPF, and the embodiments of this application do not impose any restrictions.

[0506] In one possible implementation, the UPF's cache resources include, but are not limited to, cache queue information (e.g., cache queue length) within the UPF that has the same destination address and next-hop address as the data packet 1. For example, if the UPF's currently remaining cache resources can support the send window size requested for adjustment as specified in window information 1, e.g., if the lengths of the cache queues within the UPF that have the same destination address and next-hop address as the data packet 1 are both relatively short (e.g., less than a certain threshold), the send window size requested for adjustment as specified in window information 1 can be supported. Then, the send window size indicated by window information 2 can be equal to the send window size requested for adjustment as specified in window information 1. Conversely, if the UPF's currently remaining cache resources cannot support the send window size requested for adjustment as specified in window information 1, e.g., if the lengths of the cache queues within the UPF that have the same destination address and next-hop address as the data packet 1 are relatively long (e.g., greater than a certain threshold), the send window size requested for adjustment as specified in window information 1 cannot be supported. Then, the send window size indicated by window information 2 is smaller than the send window size requested for adjustment as specified in window information 1.

[0507] In one possible implementation, the UPF may also determine window information 2 based on its own cache resources, the bandwidth / transmission rate of wired transmission at the current moment, and the window information 1. For example, if the UPF's currently remaining cache resources, and / or the bandwidth / transmission rate of wired transmission at the current moment, can support the size of the sending window requested to be adjusted by the above-mentioned window information 1, for example: the length of the cache queue in the current UPF that has the same destination address and next-hop address as the above-mentioned data packet 1 is relatively short (such as less than a certain threshold), and the bandwidth / transmission rate of wired transmission at the current moment is relatively large, which can support the size of the sending window requested to be adjusted by the above-mentioned window information 1. Then, the size of the sending window indicated by the above-mentioned window information 2 may be equal to the size of the sending window requested to be adjusted by the above-mentioned window information 1. On the other hand, if the remaining cache resources of the UPF and / or the bandwidth / transmission rate of the wired transmission at the current moment can support the size of the sending window requested to be adjusted by the above-mentioned window information 1, for example, the length of the cache queue in the current UPF with the same destination address and next-hop address as the above-mentioned data packet 1 is long (e.g., greater than a certain threshold), and the bandwidth / transmission rate of the wired transmission at the current moment is low, and cannot support the size of the sending window requested to be adjusted by the above-mentioned window information 1, then the size of the sending window indicated by the above-mentioned window information 2 is smaller than the size of the sending window requested to be adjusted by the above-mentioned window information 1.

[0508] S403: The UPF sends data message 2 to the first communication device (eg, base station), where the data message 2 includes the window information 2. Accordingly, the first communication device (eg, base station) receives the data message 2. Accordingly, the first communication device (eg, base station) receives the data message 2.

[0509] In one possible implementation, after the UPF determines the above-mentioned window information 2, it can send data message 2 to the first communication device (such as a base station). The data (or load payload) in the data message 2 can be the same as the data (or load payload) in the above-mentioned data message 1. Exemplarily, the data contained in the data message in the embodiment of the present application can be RDMA data. The header of the data message 2 can contain the window information 2. For example: the window information 2 can be carried in the frame header of the data link layer of the data message 2, or the packet header of the network layer, or the message header of the transport layer. It can be understood that when the size of the sending window indicated by the window information 2 determined by the UPF is equal to the size of the sending window requested to be adjusted by the above-mentioned window information 1, the UPF can directly forward the above-mentioned data message 1 to the first communication device (such as a base station) without processing the data message 1. In other words, at this time, the data message 2 can be the same as the above-mentioned data message 1, and the value of the window information 2 can be the same as the value of the window information 1.

[0510] It can also be understood that when the size of the sending window indicated by the window information 2 determined by the UPF is smaller than the size of the sending window requested to be adjusted by the window information 1, the data message 2 can be obtained by replacing / updating the window information 1 in the data message 1 with the window information 2. In other words, when the size of the sending window indicated by the window information 2 is smaller than the size of the sending window requested to be adjusted by the window information 1, the UPF can rewrite / replace / update the window information 1 in the data message 1 with the window information 2 to obtain data message 2.

[0511] S404, the first communication device (such as a base station) determines the window information 3 based on the window information 2 in the data message 2 and the air interface resources, and the window information 3 is used to indicate the sending window of the data, and the size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window indicated by the above-mentioned window information 2.

[0512] In one possible implementation, after receiving the above-mentioned data message 2, the first communication device (such as a base station) can parse the header information of the data message 2, or the first communication device (such as a base station) can perform deep packet inspection (DPI) on the data message 2 to determine whether the data message 2 contains the above-mentioned window information 2. When the first communication device (such as a base station) detects that the data message 2 contains the above-mentioned window information 2, the first communication device (such as a base station) can determine the window information 3 based on the air interface resources it perceives and the window information 2. Exemplarily, the implementation method of the first communication device (such as a base station) determining the window information 3 can refer to the relevant description of step S102 in the embodiment shown in Figure 3 above, and will not be repeated here.

[0513] Window information 3 can be used to indicate a data transmission window. Exemplarily, the size of the transmission window indicated by window information 3 is less than or equal to the size of the transmission window indicated by window information 2. In other words, the transmission window size determined / indicated by the first communication device (base station) is less than or equal to the transmission window size determined / indicated by the UPF. It is understood that window information 3 and window information 2 can be information of the same dimension.

[0514] S405 , the first communication device (such as a base station) sends a data message 3 to a third communication device (Receiver), where the data message 3 includes the window information 3 .

[0515] In a possible implementation, the implementation of step S405 in the embodiment of the present application can refer to the implementation of step S203 in the embodiment shown in Figure 8 above, and will not be repeated here.

[0516] S406, the first communication device (such as a base station) sends a data packet 4 to the UPF, where the data packet 4 includes an uplink GTP-u header, and the uplink GTP-u header includes the window information 3.

[0517] In one possible implementation, the implementation of step S406 in the embodiment of the present application can refer to the implementation of step S306 in the embodiment shown in Figure 12 above, and will not be repeated here.

[0518] S407 , the UPF sends a data message 5 to the second communication device (Sender), where the data message 5 includes the window information 3 . Correspondingly, the second communication device (Sender) receives the data message 5 .

[0519] In one possible implementation, the implementation of step S407 in the embodiment of the present application can refer to the implementation of step S307 in the embodiment shown in Figure 12 above, and will not be repeated here.

[0520] In the embodiment of the present application, the gNB informs the UPF of "window information 3 (or congestion control information)" via the GTP-u header. The UPF modifies the feedback message in the buffer or generates a new feedback message to carry window information 3, or feeds back window information 3 via an API. This can reduce the detour of window information 3 (or congestion control information) in the air interface, thereby making congestion control (or adjustment of the send window) more timely and enabling faster adjustment of the data transmission rate. In addition, because intermediate network elements (UPF and base stations) in the mobile network participate in congestion control, the transmission capabilities of all bottleneck nodes (such as UPF and base stations) are taken into account, thereby improving the service quality of RDMA.

[0521] S408 , the second communication device (Sender) determines a data sending window based on the window information 3 in the data message 5 .

[0522] In a possible implementation, the implementation of step S408 in the embodiment of the present application can refer to the implementation of step S105 in the embodiment shown in Figure 3 above, and will not be repeated here.

[0523] The transmitting end (i.e., the second communication device) of the embodiment of the present application sends window information 1 along with the data stream to request adjustment of the data sending window; after the UPF receives the data packet containing window information 1, it can determine window information 2 based on its own cache resources and the window information 1, and then inform the first communication device (such as a base station) of the window information 2. The first communication device (such as a base station) determines window information 3 based on the perceived air interface resources and window information 2, and / or the current cache resources, so that the size of the sending window can be better matched with the transmission capacity of the intermediate network element (such as the UPF and the first communication device), thereby reducing packet loss in the network (or achieving no packet loss) and data transmission delay, improving data transmission reliability and throughput, and thus achieving low-latency, high-throughput data transmission. In addition, since the intermediate network elements (UPF and base station) in the mobile network all participate in congestion control, the transmission capacity of all bottleneck nodes (such as UPF and base station) is taken into account, thereby improving the service quality of RDMA.

[0524] It is understood that the embodiment of the present application takes two intermediate network elements (UPF and base station) participating in congestion control in sequence (or adjusting the size of the sending window in sequence) as an example. In actual applications, there is no limit on the number of intermediate network elements participating in congestion control. The method of the embodiment of the present application can be used to adjust the size of the sending window in sequence. This will not be described in detail below. It is also understood that from the sender of the data to the receiver of the data, the nodes participating in congestion control along the way are not limited to the base station and UPF. This application supports more nodes participating in congestion control in sequence. This will not be described in detail below.

[0525] To better understand the method flow of the embodiment shown in FIG. 14 , the following is an illustration using the downlink data transmission process in a distributed computing scenario.

[0526] For example, the second communication device is a server (here, an edge server / cloud server, etc.), the third communication device is a UE, and the first communication device is a gNB. Referring to Figure 15, Figure 15 is another schematic diagram of a downlink data congestion control method for a UE and a server, provided in an embodiment of the present application. The UE and server utilize the RDMA mechanism to transmit data, with the server acting as the data sender and the UE acting as the data receiver. As shown in Figure 15, the server sends data packet 1 containing window information 1 (e.g., an increase intention value a, i.e., II value a in Figure 15), requesting adjustment (e.g., increase) of the data send window. The data transmission path from the server to the UE is from the server, via the UPF, to the gNB, and finally to the UE. When the UPF detects that data packet 1 sent from the server to the UE contains window information 1 (e.g., II value a), the UPF determines window information 2 (e.g., II value b, where II value b is less than or equal to II value a) based on its own cache resources and this window information 1. The specific determination method is described above and is not repeated here. This window information 2 can be used to indicate the data send window. The UPF then replaces / updates window information 1 in data message 1 with window information 2, obtains data message 2, and sends it to the gNB. The gNB determines window information 3 (e.g., value II c, which is less than or equal to value II b) based on window information 2 (e.g., value II b, which is less than or equal to value II a) and one or more of the following: the destination UE's downlink air interface status (e.g., downlink channel quality), remaining downlink air interface bandwidth, or the length of each downlink buffer queue for all shared downlink air interface resources (e.g., time-frequency resources) within the gNB. The specific determination method is described above and is not repeated here. The gNB generates data message 3 based on data message 2 and sends it to the UE. The data in data message 3 is the same as the data in data message 1 and data message 2. The generation method of data message 3 is described above and is not repeated here. The gNB sends data packet 4 to the UPF. This data packet 4 includes an uplink GTP-u header containing window information 3 (e.g., II value c, where II value c is less than or equal to II value b). The generation of data packet 4 is described above and is not repeated here. After receiving data packet 4, the UPF modifies or generates an uplink feedback message (e.g., data packet 5) to carry window information 3 (e.g., II value c, where II value c is less than or equal to II value b) within the RDMA layer 3 or layer 4 feedback message and sends it to the server. Alternatively, the UPF sends window information 3 (e.g., II value c, where II value c is less than or equal to II value b) to the server via an API. The server adjusts the send window based on the UPF feedback, such as window information 3 (e.g., II value c). It is understood that if II value c is 0 (or the send window size indicated by window information 3 is equal to the server's current send window size), the send window size is not adjusted.

[0527] In the embodiment of the present application, the UPF perceives its own cache resources and participates in congestion control, and the gNB perceives the air interface status and participates in congestion control, so that the sending window of RDMA data is matched with the transmission capabilities of all bottleneck nodes (such as UPF and base stations), thereby achieving low latency and high throughput transmission of distributed computing in mobile networks.

[0528] See Figure 16, which is a fifth flow chart of the congestion control method provided in an embodiment of the present application. In this method, the first communication device is a base station (such as a gNB), the second communication device is an off-network computing node (such as an edge server / cloud server), and the third communication device is a terminal (such as a UE). The second communication device acts as a sender of data, and the third communication device acts as a receiver of data.

[0529] As shown in FIG16 , the congestion control method includes but is not limited to the following steps:

[0530] S501: A second communication device (Sender) sends data message 1, which includes window information 1, which is used to request adjustment of the data sending window. The source address (source address) of data message 1 is the address of the second communication device, and the destination address (target address) of data message 1 is the address of a third communication device.

[0531] In a possible implementation, the implementation of step S501 in the embodiment of the present application can refer to the implementation of step S101 in the embodiment shown in FIG3 above, and will not be repeated here.

[0532] S502, UPF receives the data packet 1, and determines the window information 2 based on the window information 1 in the data packet 1 and its own cache resources. The window information 2 is used to indicate the sending window of the data, and the size of the sending window indicated by the window information 2 is less than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0533] S503: The UPF sends a data message 2 to the first communication device (eg, a base station), where the data message 2 includes the window information 2. Correspondingly, the first communication device (eg, a base station) receives the data message 2.

[0534] S504, the first communication device (such as a base station) determines window information 3 based on the window information 2 in the data message 2 and the air interface resources, and the window information 3 is used to indicate the sending window of the data, and the size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window indicated by the above-mentioned window information 2.

[0535] In one possible implementation method, the implementation method of steps S502 to S504 in the embodiment of the present application can refer to the implementation method of steps S402 to S404 in the embodiment shown in Figure 14 above, and will not be repeated here.

[0536] S505: The first communication device (eg, base station) sends a data message 3 to the third communication device (Receiver), where the data message 3 includes the window information 3. Correspondingly, the third communication device (Receiver) receives the data message 3.

[0537] In one possible implementation, after the first communication device (such as a base station) determines the above-mentioned window information 3, it can send a data message 3 to the third communication device (Receiver). Accordingly, the third communication device (Receiver) receives the data message 3. The data (or load payload) in the data message 3 can be the same as the data (or load payload) in the above-mentioned data message 2. Exemplarily, the data contained in the data message in the embodiment of the present application can be RDMA data. The header of the data message 3 can contain the window information 3. For example: the window information 3 can be carried in the frame header of the data link layer of the data message 3, or the packet header of the network layer, or the message header of the transport layer. It can be understood that when the size of the sending window indicated by the window information 3 determined by the first communication device (such as a base station) is equal to the size of the sending window indicated by the above-mentioned window information 2, the first communication device can forward the above-mentioned data message 2 to the third communication device (Receiver) without processing the data message 2. In other words, at this time, data message 3 may be the same as the above-mentioned data message 2, and the value of window information 3 may be the same as the value of window information 2.

[0538] It can also be understood that when the size of the sending window indicated by the window information 3 determined by the first communication device (such as a base station) is smaller than the size of the sending window indicated by the window information 2, the data message 3 can be obtained by replacing / updating the window information 2 in the data message 2 with the window information 3. In other words, when the size of the sending window indicated by the window information 3 is smaller than the size of the sending window indicated by the window information 2, the first communication device can rewrite / replace / update the window information 2 in the data message 2 with the window information 3 to obtain the data message 3.

[0539] S506: The third communication device (Receiver) sends a data message 4 to the second communication device (Sender), where the data message 4 includes the window information 3. Correspondingly, the second communication device (Sender) receives the data message 4.

[0540] S507 , the second communication device (Sender) determines a data sending window based on the window information 3 in the data message 4 .

[0541] In one possible implementation, the implementation of step S506 and step S507 in the embodiment of the present application can refer to the implementation of step S104 and step S105 in the embodiment shown in Figure 3 above, and will not be repeated here.

[0542] The transmitting end (i.e., the second communication device) of the embodiment of the present application sends window information 1 along with the data stream to request adjustment of the data sending window; after the UPF receives the data packet containing window information 1, it can determine window information 2 based on its own cache resources and the window information 1, and then inform the first communication device (such as a base station) of the window information 2. The first communication device (such as a base station) determines window information 3 based on the perceived air interface resources and window information 2, and / or the current cache resources, so that the size of the sending window can be better matched with the transmission capacity of the intermediate network element (such as the UPF and the first communication device), thereby reducing packet loss in the network (or achieving no packet loss) and data transmission delay, improving data transmission reliability and throughput, and thus achieving low-latency, high-throughput data transmission. In addition, since the intermediate network elements (UPF and base station) in the mobile network all participate in congestion control, the transmission capacity of all bottleneck nodes (such as UPF and base station) is taken into account, thereby improving the service quality of RDMA.

[0543] To better understand the method flow of the embodiment shown in FIG. 16 , the following is an illustration using the downlink data transmission process in a distributed computing scenario as an example.

[0544] For example, the second communication device is a server (here, an edge server / cloud server, etc.), the third communication device is a UE, and the first communication device is a gNB. Referring to Figure 17, Figure 17 is yet another schematic diagram of a method for downlink data congestion control for a UE and a server, provided in an embodiment of the present application. The UE and server utilize the RDMA mechanism to transmit data, with the server acting as the data sender and the UE acting as the data receiver. As shown in Figure 17, the server sends data packet 1 containing window information 1 (e.g., an increase intention value a, i.e., II value a in Figure 17), requesting adjustment (e.g., increase) of the data send window. The data transmission path from the server to the UE is from the server, via the UPF, to the gNB, and finally to the UE. When the UPF detects that data packet 1 sent from the server to the UE contains window information 1 (e.g., II value a), the UPF determines window information 2 (e.g., II value b, where II value b is less than or equal to II value a) based on its own cache resources and this window information 1. The specific determination method is described above and is not repeated here. This window information 2 can be used to indicate the data send window. The UPF then replaces / updates window information 1 in data message 1 with window information 2, obtains data message 2, and sends data message 2 to the gNB. The gNB determines window information 3 (e.g., value II c, where value II c is less than or equal to value II b) based on window information 2 (e.g., value II b, where value II b is less than or equal to value II a) and one or more of the following: the downlink air interface status of the destination UE (e.g., downlink channel quality), remaining downlink air interface bandwidth resources, or the lengths of downlink buffer queues for all shared downlink air interface resources (e.g., time-frequency resources) within the gNB. The specific determination method is described above and is not repeated here. The gNB generates data message 3 based on data message 2 and window information 3 (e.g., value II c), and sends data message 3 to the UE. Data message 3 includes window information 3 (e.g., value II c, where value II c is less than or equal to value II b). The generation method of data message 3 is described above and is not repeated here. After receiving data packet 3, the UE carries window information 3 (e.g., II value c) in RDMA layer 3 or layer 4 feedback information and sends it to the server via a feedback message (e.g., data packet 4). The server adjusts the send window based on the UE's feedback, such as window information 3 (e.g., II value c). It is understood that if II value c is 0 (or the send window size indicated by window information 3 is equal to the server's current send window size), the send window size is not adjusted.

[0545] In the embodiment of the present application, the UPF perceives its own cache resources and participates in congestion control, and the gNB perceives the air interface status and participates in congestion control, so that the sending window of RDMA data is more closely matched with the transmission capabilities of all bottleneck nodes (such as UPF and base stations), thereby achieving low latency and high throughput transmission of distributed computing in mobile networks.

[0546] Referring to Figure 18, Figure 18 is a sixth flow diagram of the congestion control method provided in an embodiment of the present application. In this method, the first communication device is a base station (such as a gNB), the second communication device is a terminal (such as a UE), and the third communication device is an off-network computing node (such as an edge server / cloud server). The second communication device acts as a sender of data, and the third communication device acts as a receiver of data.

[0547] As shown in FIG18 , the congestion control method includes but is not limited to the following steps:

[0548] S601: A second communication device (Sender) sends data message 1, which includes window information 1, which is used to request adjustment of the data sending window. The source address (source address) of data message 1 is the address of the second communication device, and the destination address (target address) of data message 1 is the address of a third communication device.

[0549] S602, the first communication device (such as a base station) receives the data message 1, and determines the window information 2 based on the window information 1 and the air interface resources in the data message 1, where the window information 2 is used to indicate the sending window of the data, and the size of the sending window indicated by the window information 2 is less than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0550] In one possible implementation, the implementation of step S601 and step S602 in the embodiment of the present application can refer to the implementation of step S101 and step S102 in the embodiment shown in Figure 3 above, and will not be repeated here.

[0551] S603: The first communication device (e.g., a base station) sends data packet 2 to the UPF. Data packet 2 includes window information 2. Accordingly, the UPF receives data packet 2. The size of the sending window indicated by window information 2 is less than or equal to the size of the sending window requested to be adjusted according to window information 1.

[0552] In one possible implementation, the implementation of step S603 in the embodiment of the present application can refer to the implementation of step S403 in the embodiment shown in Figure 14 above, and will not be repeated here.

[0553] S604, UPF determines window information 3 based on window information 2 in the data packet 2 and its own cache resources. The window information 3 is used to indicate the sending window of the data, and the size (size) of the sending window indicated by the window information 3 is less than or equal to the size (size) of the sending window indicated by the above-mentioned window information 2.

[0554] In one possible implementation, after receiving the above-mentioned data packet 2, the UPF can detect whether the data packet 2 contains the above-mentioned window information 2. Exemplarily, the UPF can parse the header information of the data packet 2, or the UPF can perform deep packet inspection (DPI) on the data packet 2 to determine whether the data packet 2 contains the above-mentioned window information 2. When the UPF detects that the data packet 2 contains the above-mentioned window information 2, the UPF can determine the window information 3 based on its own cache resources and the window information 2. Among them, regarding the implementation method of the UPF determining the window information 3, please refer to the relevant description of step S402 in the embodiment shown in Figure 14 above, which will not be repeated here. Regarding the explanation of window information 3, please refer to the relevant description of step S404 in the embodiment shown in Figure 14 above, which will not be repeated here.

[0555] S605: The UPF sends a data packet 3 to the third communication device (Receiver), where the data packet 3 includes the window information 3. Correspondingly, the third communication device (Receiver) receives the data packet 3.

[0556] In one possible implementation, the implementation of step S605 in the embodiment of the present application can refer to the implementation of step S505 in the embodiment shown in Figure 16 above, and will not be repeated here.

[0557] S606: The third communication device (Receiver) sends a data message 4 to the second communication device (Sender), where the data message 4 includes the window information 3. Correspondingly, the second communication device (Sender) receives the data message 4.

[0558] S607 , the second communication device (Sender) determines a data sending window based on the window information 3 in the data message 4 .

[0559] In one possible implementation, the implementation of step S606 and step S607 in the embodiment of the present application can refer to the implementation of step S104 and step S105 in the embodiment shown in Figure 3 above, and will not be repeated here.

[0560] The transmitting end (i.e., the second communication device) of the embodiment of the present application sends window information 1 along with the data stream to request adjustment of the data sending window; after the first communication device (such as a base station) receives the data packet containing window information 1, it can determine window information 2 based on the perceived air interface resources and window information 1, and / or the current cache resources, and then inform the UPF of window information 2; the UPF can determine window information 3 based on its own cache resources and the window information 2, so that the size of the sending window can be better matched with the transmission capacity of the intermediate network elements (such as the UPF and the first communication device), thereby reducing packet loss in the network (or achieving no packet loss) and data transmission delay, improving the reliability and throughput of data transmission, and thus achieving low-latency, high-throughput data transmission. In addition, since the intermediate network elements (UPF and base station) in the mobile network all participate in congestion control, the transmission capacity of all bottleneck nodes (such as UPF and base station) is taken into account, thereby improving the service quality of RDMA.

[0561] To better understand the method flow of the embodiment shown in FIG. 18 , the following is an illustration using the uplink data transmission process in a distributed computing scenario as an example.

[0562] For example, the second communication device is a UE, the third communication device is a server (here, an edge server / cloud server, etc.), and the first communication device is a gNB. Referring to FIG. 19 , FIG. 19 is another schematic diagram of an uplink data congestion control method for a UE and a server provided in an embodiment of the present application. The UE and the server (server) use the RDMA mechanism to transmit data, with the UE acting as the sender of the data and the server acting as the receiver. As shown in FIG. 19 , the UE sends a data message 1 containing window information 1 (e.g., an increase in intent value a, i.e., II value a in FIG. 19 ), requesting adjustment (e.g., increase) of the data transmission window. The data transmission path from the UE to the server is from the UE via the gNB to the UPF and finally to the server. When the gNB detects that a data packet 1 sent by the UE to the server contains window information 1 (e.g., II value a), the gNB determines window information 2 (e.g., II value b, where II value b is less than or equal to II value c) based on this window information 1 (e.g., II value a) and one or more of the following: the source UE's uplink air interface status (e.g., uplink channel quality), the remaining uplink air interface bandwidth resources, or the lengths of the uplink buffer queues for all shared uplink air interface resources (e.g., time-frequency resources) within the gNB. The specific determination method is described above and is not repeated here. This window information 2 can be used to indicate the data transmission window. The gNB then replaces / updates window information 1 in data packet 1 with this window information 2, obtains data packet 2, and sends this data packet 2 to the UPF. The UPF determines window information 3 (e.g., II value c, where II value c is less than or equal to II value b) based on its own buffer resources and this window information 2. The specific determination method is described above and is not repeated here. UPF generates data message 3 based on data message 2 and window information 3 (such as II value c), and sends data message 3 to the server. Data message 3 contains window information 3 (such as II value c, II value c is less than or equal to II value b). For the generation method of data message 3, please refer to the previous description and will not be repeated here. After receiving data message 3, the server carries the window information 3 (such as II value c) in the layer 3 or layer 4 feedback information of RDMA and sends it to the UE through a feedback message (such as data message 4). The UE adjusts the sending window based on the feedback from the server, such as window information 3 (such as II value c). It can be understood that if the II value c is 0 (or the size of the sending window indicated by the window information 3 is equal to the size of the UE's current sending window), the size of the sending window will not be adjusted.

[0563] In this embodiment of the present application, during uplink data transmission between a UE and a server, intermediate network elements, the gNB and UPF, participate in congestion control. This allows for better awareness of restricted and fluctuating air interface conditions, aligning the send window size with the transmission capabilities of all nodes along the path (gNB and UPF). This allows for rapid and accurate adjustment of the send window size, enabling low-latency, high-throughput RDMA data transmission for distributed computing. Furthermore, this embodiment of the present application leverages RDMA's congestion control mechanism to the greatest extent possible and adapts it to mobile communication networks, making it easy to implement.

[0564] Referring to Figure 20, Figure 20 is a seventh flow diagram of the congestion control method provided in an embodiment of the present application. In this method, the first communication device is a base station (such as a gNB), the second communication device is a terminal (such as a UE), and the third communication device is an off-network computing node (such as an edge server / cloud server). The second communication device acts as a sender of data, and the third communication device acts as a receiver of data.

[0565] As shown in FIG20 , the congestion control method includes but is not limited to the following steps:

[0566] S701: A second communication device (Sender) sends data message 1, which includes window information 1, which is used to request adjustment of the data sending window. The source address (source address) of data message 1 is the address of the second communication device, and the destination address (target address) of data message 1 is the address of a third communication device.

[0567] S702, the first communication device (such as a base station) receives the data message 1, and determines the window information 2 based on the window information 1 and the air interface resources in the data message 1, where the window information 2 is used to indicate the sending window of the data, and the size of the sending window indicated by the window information 2 is less than or equal to the size of the sending window requested to be adjusted by the window information 1.

[0568] In one possible implementation, the implementation of steps S701 to S702 in the embodiment of the present application can refer to the implementation of steps S101 to S102 in the embodiment shown in Figure 3 above, and will not be repeated here.

[0569] S703: The first communication device (e.g., a base station) sends data packet 2 to the UPF. Data packet 2 includes window information 2. Accordingly, the UPF receiv...

Claims

1. A congestion control method, characterized in that, Including: The first communication device receives a first data packet, where the first data packet contains first window information for requesting an adjustment to the transmission window of data. The first communication device sends a second data packet, where the second data packet contains second window information determined based on radio interface resources and the first window information, and the second window information is used to indicate the transmission window of the data.

2. The method according to claim 1, wherein The size of the transmission window indicated by the second window information is less than or equal to the size of the transmission window whose adjustment is requested by the first window information.

3. The method according to claim 1 or 2, characterized in that, The second window information is determined based on radio interface resources and the first window information, including: The second window information is determined based on radio interface resources, the first window information, and the buffer resources of the first communication device.

4. The method according to any one of claims 1 to 3, characterized in that The first communication device sending the second data packet includes: The first communication device sends the second data packet to the second communication device, and the source address of the first data packet is the address of the second communication device.

5. The method according to claim 4, characterized in that The second data packet includes a layer 2 packet header or a layer 2 control protocol data unit, and the layer 2 packet header or the layer 2 control protocol data unit includes the second window information.

6. The method according to claim 4, wherein The second data packet includes a user plane General Packet Radio Service (GPRS) Tunnel Protocol (GTP-u) header, and the GTP-u header includes the second window information. The second data packet and the first data packet belong to the same Quality of Service (QoS) flow or the same session; or, the data in the second data packet is dummy data.

7. The method according to any one of claims 1 to 3, characterized in that, The first communication device receiving the first data packet includes: The first communication device receives the first data packet from a User Plane Function (UPF).

8. The method according to claim 7, wherein The first communication device sending the second data packet includes: The first communication device sends the second data packet to the UPF.

9. The method according to claim 8, characterized in that The second data packet includes a second GTP-u header, and the second GTP-u header includes the second window information.

10. The method according to any one of claims 1 to 3, characterized in that The first communication device sending the second data packet includes: The first communication device sends the second data packet to the User Plane Function (UPF).

11. The method according to claim 10, wherein After the first communication device sends the second data packet to the User Plane Function (UPF), the method further includes: The first communication device receives a fourth data packet from the UPF, where the fourth data packet includes third window information for indicating the transmission window of the data, and the size of the transmission window indicated by the third window information is less than or equal to the size of the transmission window indicated by the second window information.

12. A congestion control method, characterized in that, Including: The second communication device sends a first data packet, where the first data packet contains first window information for requesting an adjustment to the transmission window of data. The second communication device receives a second data packet, where the second data packet contains second window information for indicating the transmission window of the data. The second communication device determines the transmission window of the data based on the second window information.

13. The method according to claim 12, wherein The size of the transmission window indicated by the second window information is less than or equal to the size of the transmission window whose adjustment is requested by the first window information.

14. The method according to claim 12 or 13, characterized in that, The second communication device receives a second data packet, including: The second communication device receives a second data packet from a third communication device, and the address of the third communication device is the destination address of the first data packet.

15. The method according to claim 12 or 13, characterized in that, The second communication device receives a second data packet, including: The second communication device receives a second data packet from a base station.

16. The method according to claim 15, wherein The second data packet includes a layer 2 header or a layer 2 control protocol data unit, and the layer 2 header or the layer 2 control protocol data unit includes second window information.

17. The method according to claim 15, wherein The second data packet includes a user plane General Packet Radio Service (GPRS) Tunnel Protocol (GTP-u) header, and the GTP-u header includes second window information; The second data packet and the first data packet belong to the same QoS flow or the same session; or, the data in the second data packet is dummy data.

18. The method according to claim 12 or 13, characterized in that, The second communication device receives a second data packet, including: The second communication device receives a second data packet from a User Plane Function (UPF).

19. A congestion control method, characterized in that, Including: The UPF receives a first data packet, and the first data packet contains first window information, where the first window information is used to request adjustment of the data transmission window, or the first window information is used to indicate the data transmission window; The UPF sends a second data packet, and the second data packet contains second window information, where the second window information is used to indicate the data transmission window, and the size of the transmission window indicated by the second window information is less than or equal to the size of the transmission window indicated by the first window information, or the size of the transmission window indicated by the second window information is less than or equal to the size of the transmission window whose adjustment is requested by the first window information.

20. The method according to claim 19, characterized in that, The UPF sends a second data packet, including: The UPF sends a second data packet to a base station, and the second window information in the second data packet is determined based on the first window information and the buffer resources of the UPF.

21. The method according to claim 19, wherein The UPF sends a second data packet, including: The UPF sends a second data packet to the second communication device.

22. The method according to claim 21, wherein Before the UPF sends a second data packet to the second communication device, the method further includes: The UPF receives a third data packet from a base station, and the third data packet includes the second window information.

23. The method according to claim 22, wherein The third data packet includes a first user plane General Packet Radio Service (GPRS) Tunnel Protocol (GTP-u) header, and the first GTP-u header includes the second window information.

24. The method according to claim 22 or 23, characterized in that, Before the UPF receives a third data packet from a base station, the method further includes: The UPF sends a fourth data packet to a base station, and the fourth data packet includes third window information, where the third window information is used to indicate the data transmission window, and the third window information is determined based on the first window information and the buffer resources of the UPF.

25. The method according to claim 24, wherein The size of the transmission window indicated by the third window information is less than or equal to the size of the transmission window whose adjustment is requested by the first window information.

26. The method according to claim 19, characterized in that, The first window information is used to indicate the transmission window of data. The user plane function UPF receives a first data packet, including: The UPF receives a first data packet from the base station.

27. The method according to claim 26, wherein The UPF sends a second data packet, including: The UPF sends a second data packet to the base station. The second window information in the second data packet is determined based on the first window information and the buffer resources of the UPF.

28. A communication device, characterized in that, Comprising units or modules for performing the method according to any one of claims 1 to 27.

29. A communication device, characterized in that, Comprising a processor and an interface circuit. The interface circuit is used to receive signals from other communication devices and transmit them to the processor or send data from the processor to other communication devices. The processor is used to implement the method according to any one of claims 1 to 27 through logic circuits or by executing code instructions.

30. A readable storage medium, characterized in that, For storing a program, the program is executed by one or more processors, so that a device including the one or more processors executes the method according to any one of claims 1 to 27.

Images