Communication method, and apparatus

Abstract

The present application relates to the technical field of wireless communications. Provided are a communication method, and an apparatus. The method comprises: a first access network apparatus receives first information, the first information being used for indicating T-PDU context information of a first terminal apparatus; the first access network apparatus establishes a communication connection with the first terminal apparatus; and the first access network apparatus performs user plane data transmission with a core network apparatus according to the T-PDU context information. On the basis of the foregoing solution, when the first terminal apparatus and the first access network apparatus have established a communication connection, the first access network apparatus may continue transmission of T-PDUs of the first terminal apparatus according to the transmission status of the T-PDUs of the first terminal apparatus, thereby improving the continuity of user plane data transmission and further improving the efficiency of user plane data transmission.

Description

A communication method and apparatus

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411750694.0, filed on November 29, 2024, entitled "A Communication Method and Apparatus", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of communication technology, and in particular to a communication method and apparatus. Background Technology

[0004] New radio (NR) communication systems include the 5G core network (5GC) and the next-generation (NG) radio access network (RAN). The NG interface is the logical interface between the NG-RAN and the 5GC. The NG interface is divided into the NG-control plane (NG-C) interface and the NG-user plane (NG-U) interface. The NG-C interface provides reliable signaling transmission services, while the NG-U interface provides non-guaranteed data transmission services.

[0005] Currently, the NG-U interface protocol stack uses the User Datagram Protocol (UDP) and the General Packet Radio Service (GPRS) Tunneling Protocol-User Plane (GTP-U) as its transport layer protocols. UDP lacks congestion control and retransmission mechanisms, and user plane messages transmitted using GTP-U also lack these mechanisms, leading to packet loss and significant latency. Therefore, a transport layer protocol supporting congestion control and retransmission mechanisms can be introduced into the NG-U interface protocol stack to address this issue.

[0006] However, no further implementation methods have been provided at present. Summary of the Invention

[0007] This application provides a communication method and apparatus to improve the continuity and efficiency of user plane data transmission.

[0008] In a first aspect, a first communication method is provided, which can be applied to a first access network device. The first access network device may be, for example, an access network equipment, or a component of an access network equipment, such as a communication module, processor, circuit, or chip system (or chip) or other functional module applicable to the access network equipment. This chip system or functional module can implement the functions of the access network equipment, and may be, for example, disposed within the access network equipment, or may be a logic module or software capable of implementing all or part of the functions of the access network equipment. The access network equipment may be a non-ORAN architecture or an ORAN architecture; or, the access network equipment may be a CU, DU, or RU under an ORAN architecture. The access network equipment may be, for example, located on the ground, or the access network equipment may be, for example, a satellite or an airborne vehicle, or located on a satellite or an airborne vehicle, or on a non-ground device. The method includes: the first access network device receiving first information, the first information indicating T-PDU context information of a first terminal device; the first access network device establishing a communication connection with the first terminal device; and the first access network device performing user plane data transmission with a core network device according to the T-PDU context information.

[0009] In this method, the first access network device can obtain the transmission status of the first terminal device's T-PDU based on the T-PDU context information. After the first terminal device establishes a communication connection with the first access network device, the first access network device can continue to transmit user plane data based on the transmission status of the first terminal device's T-PDU. For example, when the first terminal device switches from a communication connection with the second access network device to a communication connection with the first access network device, the first access network device can continue to transmit user plane data based on the transmission status before the switch, improving the continuity and efficiency of user plane data transmission. For example, when the NG-U interface protocol stack introduces a protocol that supports retransmission mechanisms, this method allows the first access network device to retransmit lost user data packets based on the user plane data transmission status before the switch after a handover, reducing the probability of packet loss and improving communication performance.

[0010] In one possible implementation, the T-PDU context information may include one or more of the following: T-PDU status information of the first terminal device; or, the transport layer protocol used by the second access network device and the core network device to transmit user plane data. Based on this implementation, the first access network device can obtain the T-PDU transmission status and transport layer protocol of the first terminal device, so as to use the transport layer protocol to continue to perform user plane data transmission according to the T-PDU transmission status, thereby improving the continuity of user plane data transmission.

[0011] In one possible implementation, the T-PDU status information includes one or more of the following: the sequence number of the lost downlink T-PDU and / or uplink T-PDU; the sequence number of the first lost downlink T-PDU and / or uplink T-PDU; the reception status information of at least one downlink T-PDU and / or at least one uplink T-PDU; the sequence number of the downlink T-PDU and / or uplink T-PDU that needs to be retransmitted; the sequence number of the next downlink T-PDU that the core network device needs to transmit; the sequence number of the next uplink T-PDU that the second access network device needs to transmit; the sequence number of the last uplink T-PDU sent by the second access network device; or, the sequence number of the last downlink T-PDU sent by the core network device. Based on this implementation, the first access network device can determine the uplink T-PDU that needs to be retransmitted, and then retransmit the uplink T-PDU to reduce the probability of packet loss. Alternatively, the first access network device can determine the next uplink T-PDU that needs to be transmitted, and then continue transmitting subsequent uplink T-PDUs from that uplink T-PDU to improve the continuity of user plane data transmission.

[0012] In one possible implementation, the first access network device performs user plane data transmission with the core network device based on T-PDU context information, including several implementation methods. One implementation method involves the first access network device sending a first uplink T-PDU, which is a lost uplink T-PDU. That is, the first access network device retransmits the lost uplink T-PDU. Based on this implementation method, the first access network device can retransmit the uplink T-PDU, reducing the probability of packet loss. Another implementation method involves the first access network device sending a second uplink T-PDU, the sequence number of which is greater than or equal to the sequence number of the next uplink T-PDU that the second access network device needs to transmit. That is, the first access network device can continue transmitting subsequent uplink T-PDUs starting from the next uplink T-PDU that needs to be transmitted, thereby improving the continuity of user plane data transmission. Alternatively, a combination of the above implementation methods may also be used.

[0013] In one possible implementation, the T-PDU status information can be the T-PDU status information for each PDU session. Based on this implementation, T-PDU status information can be retained separately for each PDU session, which helps the first access network device inherit the transmission status of each PDU session of the first terminal device. Alternatively, the T-PDU status information can be the T-PDU status information for each QoS flow of each PDU session. Based on this implementation, T-PDU status information can be retained separately for each QoS flow of each PDU session, which helps the first access network device inherit the transmission status of each QoS flow of each PDU session of the first terminal device. Furthermore, this method provides multiple information granularities, which helps to select according to the needs of the actual scenario to meet the requirements of various scenarios.

[0014] In one possible implementation, the method further includes: a first access network device receiving second information and determining the T-PDU context information of a first terminal device based on the second information. The second information includes one or more of the following: an identifier of the second access network device; an identifier assigned by the second access network device to the first terminal device related to a first interface, where the first interface is the interface between the second access network device and the core network device; or an identifier assigned by the core network device to the first terminal device related to the first interface. Based on this implementation, the first access network device can accurately determine the first terminal device based on the second information, thereby accurately performing user plane data transmission according to the T-PDU context information of the first terminal device.

[0015] In one possible implementation, the transport layer protocol used for user plane data transmission may include a first transport layer protocol that supports congestion control. The T-PDU context information also includes congestion control status information related to the first terminal device, which is used to control user plane data transmission with the core network device. The method further includes: the first access network device performing congestion control based on the congestion control status information. Based on this implementation, the first access network device can continue to use the congestion control status of the second access network device, improving the continuity of congestion control functions before and after handover, avoiding the problem of low data transmission efficiency caused by starting congestion control from the initial state, and improving data transmission efficiency.

[0016] In one possible implementation, the first transport layer protocol is TCP, and the congestion control status information indicates one or more of the following: the current TCP congestion control stage; the retransmission mechanism used; the number of sending windows; the number of congestion windows; or, the number of receiving windows. Based on this implementation, the first access network device can continue to use various parameters related to the TCP congestion control algorithm, improve the continuity of the TCP congestion control function, avoid the problem of low data transmission efficiency caused by starting TCP congestion control from the initial state, and improve data transmission efficiency.

[0017] In one possible implementation, the first transport layer protocol is the QUIC protocol, and the congestion control status information indicates one or more of the following: the congestion control algorithm used; the flow control level; the number of available windows at the flow control level; the maximum number of windows at the flow control level; or, the maximum offset of the received data at the flow control level. Based on this implementation, the first access network device can continue to use various parameters related to the QUIC protocol to improve the continuity of the QUIC congestion control function and improve the efficiency of data transmission.

[0018] In one possible implementation, the T-PDU status information is any of the following: T-PDU status information for each connection; T-PDU status information for each session stream of each connection; T-PDU status information for each path of each connection; or, T-PDU status information for each session stream of each path of each connection. This implementation provides multiple granularities of T-PDU status information, which helps to select according to the needs of the actual scenario to meet the requirements of various scenarios.

[0019] In one possible implementation, the method further includes: a first access network device receiving third information and determining the T-PDU context information of a first terminal device based on the third information. The third information includes one or more of the following: a connection identifier corresponding to the first terminal device; a session flow identifier corresponding to the first terminal device; or a path identifier corresponding to the first terminal device. Based on this implementation, the first access network device can also accurately determine the first terminal device based on the third information, thereby enabling accurate execution of user plane data transmission according to the T-PDU context information of the first terminal device.

[0020] Secondly, a first communication method is provided, which can be applied to a core network device. This core network device can be, for example, a core network equipment or a component of a core network equipment, such as a communication module, processor, circuit, or chip system (or chip) or other functional module applicable to the core network equipment. This chip system or functional module can implement the functions of the core network equipment, and can be, for example, disposed within the core network equipment, or can be a logic module or software capable of implementing all or part of the functions of the core network equipment. The method includes: the core network device receiving fourth information, the fourth information indicating the retention of T-PDU context information of the first terminal device; and the core network device performing user plane data transmission with the first access network device based on the T-PDU context information.

[0021] In one possible implementation, the T-PDU context information includes one or more of the following: T-PDU status information of the first terminal device; or, the transport layer protocol used by the second access network device and the core network device to transmit user plane data.

[0022] In one possible implementation, the T-PDU status information includes one or more of the following: the sequence number of the lost downlink T-PDU and / or uplink T-PDU; the sequence number of the first lost downlink T-PDU and / or uplink T-PDU; the reception status information of at least one downlink T-PDU and / or at least one uplink T-PDU; the sequence number of the downlink T-PDU and / or uplink T-PDU that needs to be retransmitted; the sequence number of the next downlink T-PDU that the core network device needs to transmit; the sequence number of the next uplink T-PDU that the second access network device needs to transmit; the sequence number of the last uplink T-PDU transmitted by the second access network device; or, the sequence number of the last downlink T-PDU transmitted by the core network device.

[0023] In one possible implementation, user plane data transmission is performed with the first access network device based on T-PDU context information, including: the core network device sending a first downlink T-PDU, the first downlink T-PDU being a lost downlink T-PDU; and / or, the core network device sending a second downlink T-PDU, the sequence number of the second downlink T-PDU being greater than or equal to the sequence number of the next downlink T-PDU that the core network device needs to transmit.

[0024] In one possible implementation, the T-PDU status information is either: the T-PDU status information for each PDU session; or, the T-PDU status information for each QoS flow of each PDU session.

[0025] In one possible implementation, the method further includes: determining T-PDU context information of the first terminal device based on second information. The second information includes one or more of the following: an identifier of the second access network device; an identifier assigned by the second access network device to the first terminal device related to a first interface, wherein the first interface is an interface between the second access network device and the core network device; or, an identifier assigned by the core network device to the first terminal device related to the first interface.

[0026] In one possible implementation, the transport layer protocol used for user plane data transmission may include a first transport layer protocol that supports congestion control. The T-PDU context information also includes congestion control status information related to the first terminal device, which is used to control user plane data transmission with the second access network device. The method further includes: the core network device performing congestion control based on the congestion control status information.

[0027] In one possible implementation, the first transport layer protocol is the TCP protocol, and the congestion control status information indicates one or more of the following: TCP congestion control phase; the retransmission mechanism used; the number of sending windows; the number of congestion windows; or, the number of receiving windows.

[0028] In one possible implementation, the first transport layer protocol is the QUIC protocol, and the congestion control status information indicates one or more of the following: the congestion control algorithm used; the flow control level; the number of available windows at the flow control level; the maximum number of windows at the flow control level; or, the maximum offset of the data received at the flow control level.

[0029] In one possible implementation, the T-PDU status information may also be any of the following: T-PDU status information for each connection; T-PDU status information for each session stream of each connection; T-PDU status information for each path of each connection; or T-PDU status information for each session stream of each path of each connection.

[0030] In one possible implementation, the method further includes: the core network device determining the T-PDU context information of the first terminal device based on third information. The third information includes one or more of the following: a connection identifier corresponding to the first terminal device; a flow identifier corresponding to the first terminal device; or a path identifier corresponding to the first terminal device.

[0031] For the technical effects of the second aspect or its various alternative implementations, please refer to the description of the technical effects of the first aspect or its corresponding implementations.

[0032] Thirdly, a first communication method is provided, which can be applied to a second access network device. The second access network device can be, for example, an access network equipment, or a component of an access network equipment, such as a communication module, processor, circuit, or chip system (or chip) or other functional module applicable to the access network equipment. This chip system or functional module can implement the functions of the access network equipment, and can be, for example, disposed within the access network equipment, or can be a logic module or software capable of implementing all or part of the functions of the access network equipment. The access network equipment can be a non-ORAN architecture or an ORAN architecture; or, the access network equipment can be a CU, DU, or RU under an ORAN architecture. The access network equipment is, for example, located on the ground, or the access network equipment is, for example, a non-ground device such as a satellite or an aircraft, or located on a non-ground device such as a satellite or an aircraft. The method includes: the second access network device sending first information to a first access network device, the first information indicating the T-PDU context information of a first terminal device. Wherein, the first terminal device switches from a communication connection with the second access network device to a communication connection with the first access network device.

[0033] In one possible implementation, the method further includes: the second access network device sending fourth information to the core network device, the fourth information being used to indicate that the T-PDU context information of the first terminal device be retained.

[0034] In one possible implementation, the T-PDU context information includes one or more of the following: T-PDU status information of the first terminal device; or, the transport layer protocol used by the second access network device and the core network device to transmit user plane data.

[0035] In one possible implementation, the T-PDU status information includes one or more of the following: the sequence number of the lost downlink T-PDU and / or uplink T-PDU; the sequence number of the first lost downlink T-PDU and / or uplink T-PDU; the reception status information of at least one downlink T-PDU and / or at least one uplink T-PDU; the sequence number of the downlink T-PDU and / or uplink T-PDU that needs to be retransmitted; the sequence number of the next downlink T-PDU that the core network device needs to transmit; the sequence number of the next uplink T-PDU that the second access network device needs to transmit; the sequence number of the last uplink T-PDU transmitted by the second access network device; or, the sequence number of the last downlink T-PDU transmitted by the core network device.

[0036] In one possible implementation, the T-PDU status information is either: the T-PDU status information for each PDU session; or, the T-PDU status information for each QoS flow of each PDU session.

[0037] In one possible implementation, the transport layer protocol used for user plane data transmission includes a first transport layer protocol, which is a protocol that supports congestion control functions. The T-PDU context information also includes congestion control status information related to the first terminal device, which is used to control user plane data transmission with the core network device.

[0038] In one possible implementation, the first transport layer protocol is the TCP protocol, and the congestion control status information indicates one or more of the following: the TCP congestion control phase being in; the retransmission mechanism being used; the number of sending windows; the number of congestion windows; or, the number of receiving windows.

[0039] In one possible implementation, the first transport layer protocol is the QUIC protocol, and the congestion control status information indicates one or more of the following: the congestion control algorithm used; the flow control level; the number of available windows at the flow control level; the maximum number of windows at the flow control level; or, the maximum offset of the data received at the flow control level.

[0040] In one possible implementation, the T-PDU status information may also be any of the following: T-PDU status information for each connection; T-PDU status information for each session stream of each connection; T-PDU status information for each path of each connection; or T-PDU status information for each session stream of each path of each connection.

[0041] For information on the technical effects of the third aspect or its various alternative implementations, please refer to the description of the technical effects of the first aspect or its corresponding implementations.

[0042] Fourthly, a communication device is provided. The communication device can be the first access network device described in the first aspect above. The communication device possesses the functions of the first access network device. For example, the communication device has the functions described in the first aspect above. For instance, the communication device includes modules, units, or means corresponding to performing the operations involved in the first aspect above. These modules, units, or means can be implemented through software, hardware, or a combination of software and hardware. The communication device is, for example, an access network device, or a component of an access network device, such as a communication module, circuit or chip (or chip system), or other functional module applicable to the access network device. This chip system or functional module can realize the functions of the access network device, and is, for example, disposed within the access network device. In one optional implementation, the communication device includes a baseband device and a radio frequency device. In another optional implementation, the communication device includes a processing unit (sometimes also called a processing module) and a transceiver unit (sometimes also called a transceiver module). A transceiver unit can perform both sending and receiving functions. When the transceiver unit performs the sending function, it can be called a sending unit (sometimes also called a sending module), and when it performs the receiving function, it can be called a receiving unit (sometimes also called a receiving module). The sending unit and the receiving unit can be the same functional module, which is called the transceiver unit and can perform both sending and receiving functions; or, the sending unit and the receiving unit can be different functional modules, and the transceiver unit is a collective term for these functional modules.

[0043] In one optional implementation, the transceiver unit (or the receiving unit) is configured to receive first information, which indicates the user plane protocol data unit (T-PDU) context information of the first terminal device. The processing unit is configured to establish a communication connection with the first terminal device and perform user plane data transmission with the core network device based on the T-PDU context information.

[0044] In an alternative embodiment, the communication device further includes a storage unit (sometimes also called a storage module), and the processing unit is configured to couple with the storage unit and execute programs or instructions in the storage unit to enable the communication device to perform the functions of the first access network device described in the first aspect above.

[0045] Fifthly, a communication device is provided. The communication device can be the core network device described in the second aspect above. The communication device possesses the functions of the core network device described above. For example, the communication device has the functions described in the second aspect above; for example, the communication device includes modules, units, or means corresponding to performing the operations involved in the second aspect above. These modules, units, or means can be implemented through software, hardware, or a combination of software and hardware. The communication device is, for example, a core network device, or a component of a core network device, such as a communication module, processor, chip system (or chip or circuit), or other functional module applicable to the core network device. This chip system or functional module can realize the functions of the core network device, and is, for example, disposed within the core network device. In one optional implementation, the communication device includes a baseband device and a radio frequency device. In another optional implementation, the communication device includes a processing unit (sometimes also called a processing module) and a transceiver unit (sometimes also called a transceiver module). For details on the implementation of the transceiver unit, please refer to the description in the fifth aspect.

[0046] In one optional implementation, the transceiver unit (or the receiving unit) is configured to receive fourth information, which indicates that the T-PDU context information of the first terminal device should be retained. The processing unit is configured to perform user plane data transmission with the first access network device based on the T-PDU context information.

[0047] In an alternative implementation, the communication device further includes a storage unit (sometimes also called a storage module), and the processing unit is configured to couple with the storage unit and execute programs or instructions in the storage unit to enable the communication device to perform the functions of the core network device described in the second aspect above.

[0048] Sixthly, a communication device is provided. The communication device can be the second access network device described in the first aspect above. The communication device possesses the functions of the second access network device described above. For example, the communication device has the functions described in the first aspect above. For example, the communication device includes modules, units, or means corresponding to performing the operations involved in the first aspect above. These modules, units, or means can be implemented through software, hardware, or a combination of software and hardware. The communication device is, for example, an access network device, or a component of an access network device, such as a communication module, circuit or chip (or chip system), or other functional module applicable to the access network device. This chip system or functional module can realize the functions of the access network device, and is, for example, disposed within the access network device. In one optional implementation, the communication device includes a baseband device and a radio frequency device. In another optional implementation, the communication device includes a processing unit (sometimes also called a processing module) and a transceiver unit (sometimes also called a transceiver module). For details on the implementation of the transceiver unit, please refer to the description in the fifth aspect.

[0049] In one optional implementation, the transceiver unit (or the sending unit) is configured to send first information to the first access network device, the first information being used to indicate the T-PDU context information of the first terminal device. The first terminal device switches from a communication connection with the second access network device to a communication connection with the first access network device.

[0050] In an alternative embodiment, the communication device further includes a storage unit (sometimes also called a storage module), and the processing unit is configured to couple with the storage unit and execute programs or instructions in the storage unit to enable the communication device to perform the functions of the second access network device described in the first aspect above.

[0051] A seventh aspect provides an apparatus comprising a memory and one or more processors. The memory is used to store part or all of a computer program or instructions necessary for implementing the functions described in the first aspect. The one or more processors are executable to carry out the computer program or instructions, such that, when executed, the apparatus implements the methods in any possible design or implementation of the first aspect.

[0052] In one possible design, the device may further include interface circuitry, through which the processor communicates with other devices or components.

[0053] In one possible design, the device may also include the memory.

[0054] The aforementioned device may be an access network device, or a communication module in an access network device, or a chip in an access network device that is responsible for communication functions, such as a modem chip (also known as a baseband chip) or a SoC or SIP chip containing a modem module.

[0055] Eighthly, an apparatus is provided, the apparatus comprising a memory and one or more processors. The memory is used to store part or all of a computer program or instructions necessary for implementing the functions described in the second aspect above. The one or more processors are executable to carry out the computer program or instructions, such that, when executed, the apparatus implements the methods in any possible design or implementation of the second aspect above.

[0056] In one possible design, the device may further include interface circuitry, through which the processor communicates with other devices or components.

[0057] In one possible design, the device may also include the memory.

[0058] The aforementioned device may be a core network device, or a communication module in a core network device, or a chip in a core network device that is responsible for communication functions, such as a modem chip (also known as a baseband chip) or a SoC or SIP chip containing a modem module.

[0059] A ninth aspect provides an apparatus comprising a memory and one or more processors. The memory is used to store part or all of a computer program or instructions necessary for implementing the functions described in the third aspect above. The one or more processors are executable to carry out the computer program or instructions, such that, when executed, the apparatus implements the methods in any possible design or implementation of the third aspect above.

[0060] In one possible design, the device may further include interface circuitry, through which the processor communicates with other devices or components.

[0061] In one possible design, the device may also include the memory.

[0062] The aforementioned device may be an access network device, or a communication module in an access network device, or a chip in an access network device that is responsible for communication functions, such as a modem chip (also known as a baseband chip) or a SoC or SIP chip containing a modem module.

[0063] A tenth aspect provides a communication system including a first access network device, a second access network device, and a core network device. The first access network device is configured to execute the method described in the first aspect, the core network device is configured to execute the method described in the second aspect, and the second access network device is configured to execute the method described in the third aspect. For example, the first access network device can be implemented using the device described in the fourth or seventh aspect, the core network device can be implemented using the device described in the fifth or eighth aspect, and the second access network device can be implemented using the device described in the sixth or ninth aspect.

[0064] Optionally, the communication system further includes a terminal device, wherein the terminal device may be, for example, the first terminal device described in the first to third aspects above.

[0065] Eleventhly, a computer-readable storage medium is provided for storing a computer program or instructions that, when executed, cause the method performed by the first access network device, the second access network device, or the core network device in the above aspects to be implemented.

[0066] In a twelfth aspect, a computer program product containing instructions is provided, which, when the computer program or instructions are run on a computer, causes the methods described in the above aspects to be implemented.

[0067] In a thirteenth aspect, a chip system is provided, including a processor and an interface, the processor being configured to call and execute instructions from the interface to enable the chip system to implement the methods described above. Attached Figure Description

[0068] Figures 1A to 1D and 2A are schematic diagrams of several application scenarios of the embodiments of this application;

[0069] Figure 2B is a schematic diagram of an NG interface protocol stack;

[0070] Figures 3 and 4 are flowcharts of a communication method provided in an embodiment of this application;

[0071] Figures 5A and 5B are schematic diagrams related to the TCP protocol;

[0072] Figure 6A is a schematic diagram of an NG-U interface protocol stack provided in an embodiment of this application;

[0073] Figure 6B is a schematic flowchart of another communication method provided in an embodiment of this application;

[0074] Figure 7 is a schematic diagram of the QUIC protocol provided in the embodiments of this application;

[0075] Figure 8A is another schematic diagram of the NG-U interface protocol stack provided in an embodiment of this application;

[0076] Figure 8B is a schematic flowchart of another communication method provided in an embodiment of this application;

[0077] Figure 9 is a schematic diagram of the structure of a device provided in an embodiment of this application;

[0078] Figure 10 is a schematic diagram of another device provided in an embodiment of this application. Detailed Implementation

[0079] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0080] In this application embodiment, the number of nouns, unless otherwise specified, refers to "singular nouns or plural nouns," that is, "one or more." "At least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, or B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the related objects before and after are in an "or" relationship. For example, A / B means: A or B. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c means: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0081] The ordinal numbers such as "first" and "second" mentioned in the embodiments of this application are used to distinguish multiple objects and are not used to limit the size, content, order, timing, priority, or importance of the multiple objects. Furthermore, the numbering of steps in the various embodiments described in this application is only to distinguish different steps and is not used to limit the order of steps. In the embodiments of this application, words such as "exemplarily" and "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as an "example" in this application should not be construed as being better or more advantageous than other embodiments or design schemes. Specifically, the use of the term "example" is intended to present concepts in a concrete manner. In the embodiments of this application, "of," "corresponding (relevant)," and "corresponding" can sometimes be used interchangeably; it should be noted that their intended meanings are consistent when their distinctions are not emphasized.

[0082] The technical solutions of this application can be applied to various wireless communication systems, such as fourth-generation (4G) communication systems, LTE communication systems, and fifth-generation (5G) communication systems, such as 5G new radio (NR) communication systems, or various communication systems evolved after 5G, such as future communication systems. The technical solutions of this application can also be applied to universal mobile telecommunications systems (UMTS), wireless local area networks (WLANs), short-range wireless communication systems (such as sidelink, wireless fidelity (Wi-Fi), Bluetooth, etc.), wired networks, vehicle-to-everything (V2X) communication systems, device-to-device (D2D) communication systems, or long-range radio (LoRa) systems. The technical solutions of this application can also be applied to sidelink (SL) communication. The technical solutions of this application embodiment can be applied to terrestrial networks (TN); alternatively, the methods provided in this application embodiment can also be applied to non-terrestrial networks (NTN), such as satellite communication systems, for example, transparent satellite architecture, backhaul satellite architecture, or regenerative satellite architecture, etc., without limitation. NTN can be a communication system integrated with other communication systems such as 4G, 5G mobile communication systems, or future communication systems, such as NR NTN, IoT NTN, etc. This application embodiment uses the communication system shown in Figure 1A as an example for description. When applying the technical solutions of this application embodiment to other communication systems, the devices, components, modules, etc. in the embodiment can be replaced with corresponding devices, components, modules in other communication systems, without limitation.

[0083] Figure 1A is a schematic diagram of the architecture of the communication system applied in an embodiment of this application. As shown in Figure 1A, the communication system includes a radio access network (RAN) 100 and a core network 200. Optionally, the communication system may also include an Internet 300. The RAN 100 includes at least one RAN device (110a-110b in Figure 1A, collectively referred to as 110), and may also include at least one terminal device (120a-120j in Figure 1A, collectively referred to as 120). The RAN 100 may also include other RAN devices, such as wireless relay devices and / or wireless backhaul devices (not shown in Figure 1A). The terminal device 120 is wirelessly connected to the RAN device 110. The RAN device 110 is wirelessly or wiredly connected to the core network 200. The core network device in the core network 200 and the RAN device 110 in the RAN 100 may be different physical devices, or they may be the same physical device integrating core network logical functions and radio access network logical functions.

[0084] RAN 100 can be a cellular system related to the 3rd Generation Partnership Project (3GPP), such as 4G, 5G mobile communication systems, NTN (non-terrestrial network) systems, or future-oriented evolution systems. RAN 100 can also be an open RAN (O-RAN or ORAN), a cloud radio access network (CRAN), or a wireless fidelity (WiFi) system, or a communication system that integrates two or more of the above systems.

[0085] Terminal device 120 is a device with wireless transceiver function, which may be a fixed device, a mobile device, a handheld device (e.g., a mobile phone), a wearable device, an in-vehicle device, or a wireless device (e.g., a communication module, a modem, or a chip system, etc.) built into the above devices. Terminal device 120 is used to connect people, things, machines, etc. Terminal device 120 can be widely used in various scenarios, including but not limited to the following: satellite communication scenarios, sensing scenarios, cellular communication, non-terrestrial network (NTN), device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, machine-to-machine / machine-type communications (M2M / MTC), Internet of Things (IoT), virtual reality (VR), augmented reality (AR), industrial control, self-driving, remote medical, smart grid, smart furniture, smart office, smart wearables, smart transportation, smart city, drones, robots, and indoor commercial scenarios (such as mobile phone screen projection, file sharing, and mobile phone to VR glasses video transmission). The terminal device 120 can be a mobile phone, tablet computer, computer with wireless transceiver function, wearable device, vehicle, drone, helicopter, airplane, ship, robot, robotic arm, smart home device, etc. The embodiments of this application do not limit the device form of the terminal device.When terminal device 120 is applied to V2X, it can also be called a V2X device, such as a smart car, digital car, unmanned car, driverless car, pilotless car, or automobile, self-driving car, or autonomous car, pure electric vehicle (EV), hybrid electric vehicle (HEV), range-extended electric vehicle (REEV), plug-in hybrid electric vehicle (PHEV), new energy vehicle, or roadside unit (RSU). Terminal device 120 can also be a device in D2D communication, such as an electricity meter or water meter. Terminal device 120 can also be a device in an Internet of Things (IoT) system. IoT is an important component of future information technology development, and its main technical characteristic is connecting objects to networks through communication technology, thereby realizing an intelligent network of human-machine interconnection and object-to-object interconnection.

[0086] The various terminal devices described above, if located in a vehicle (e.g., placed inside or installed inside a vehicle), can all be considered in-vehicle terminal devices, also known as on-board units (OBUs). The terminal device of this application can also be an in-vehicle module, in-vehicle component, in-vehicle chip, or in-vehicle unit built into a vehicle as one or more components or units. The vehicle can implement the methods of this application through the built-in in-vehicle module, in-vehicle component, in-vehicle chip, or in-vehicle unit.

[0087] Terminal equipment 120 may sometimes be referred to as a terminal, access station, UE station, remote station, wireless communication equipment, user equipment (UE), mobile station, mobile terminal, terminal device, or user device, etc.

[0088] In this application embodiment, the communication device used to implement the terminal device can be a terminal device, which can be a terminal device or a device capable of supporting the terminal device to implement the function, such as a communication module or chip system. This device can be installed in the terminal device. In the technical solutions provided in this application embodiment, the terminal device is used as an example to describe the technical solutions provided in this application embodiment.

[0089] RAN device 110 may sometimes be referred to as access network device, RAN entity, access node, RAN equipment, or access network element. RAN device 110 has wireless transceiver capabilities and can be used to communicate with terminal device 120, helping terminal device 120 achieve wireless access. For example, terminal device 120 resides in a cell provided by RAN device 110. Multiple RAN devices 110 in the communication system can be nodes of the same type or different types; in other words, multiple RAN devices 110 can support networks using the same access technology or networks using different access technologies. RAN device 110 may contain one or more co-located or non-co-located transmit / receive points. In some scenarios, the roles of RAN device 110 and terminal device 120 are relative. For example, in Figure 1A, network element 120i can be a helicopter or drone, which can be configured as a mobile base station. For terminal devices 120j accessing RAN 100 through network element 120i, network element 120i is a base station; but for base station 110a, network element 120i is a terminal device. RAN device 110 and terminal device 120 are sometimes referred to as communication devices. For example, network elements 110a-110b in Figure 1A can be understood as communication devices with base station functions, and network elements 120a-120j can be understood as communication devices with terminal device functions. RAN device 110 can be located on the ground or in the air, for example, it can be located on a satellite, a drone, or an aircraft, or the network device can be a satellite, a drone, or an aircraft.

[0090] In one possible scenario, RAN device 110 can be a base station (base transceiver station, BTS, Node B, evolved Node B (eNodeB) / eNB, or next-generation Node B (gNodeB) / gNB), access point (AP), transmission reception point (TRP), base station in future mobile communication systems, base station evolved under the 3rd generation partnership project (3GPP), access node in a WiFi system, wireless relay node, wireless backhaul node, etc. RAN device 110 can be a macro base station (as shown in Figure 1A, 110a), a micro base station or indoor station (as shown in Figure 1A, 110b), a pico base station, a small cell, a relay station, a relay node, or a donor node. Optionally, RAN device 110 can also be a server, wearable device, vehicle, or in-vehicle equipment, etc. For example, in vehicle-to-everything (V2X) technology, the access network equipment can be a roadside unit (RSU). RAN equipment 110 can also be a server, etc. In satellite communication systems, RAN equipment 110 can be a satellite, a base station mounted on a satellite, or a gateway station (also called a ground station, earth station, signaling station, gateway, or gateway station). In some scenarios, RAN node 110 can also be a satellite communication terminal, such as a portable station, a fixed station, a vehicle-mounted or airborne satellite communication terminal. It should be understood that in these scenarios, the satellite communication terminal communicates with the satellite and can act as a micro base station or satellite data station to further provide data interfaces to user equipment accessing the satellite communication terminal. The following explanation of RAN equipment 110 uses a base station as an example. The base station can communicate with the terminal equipment or through a relay station. The terminal equipment can communicate with multiple base stations in different access technologies.

[0091] In another possible scenario, multiple RAN devices 110 collaborate to assist terminal device 120 in achieving wireless access, with each RAN device 110 implementing a portion of the base station's functions. For example, RAN device 110 could be a radio controller in a CRAN scenario. Alternatively, in a CU-DU architecture or an open RAN (ORAN) system, RAN device 110 could include one or more logical network elements such as a central unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU). CUs and DUs can be configured separately or included in the same network element, such as a baseband unit (BBU). RUs can be included in radio equipment or radio units, such as remote radio units (RRUs), active antenna units (AAUs), or remote radio heads (RRHs).

[0092] The CU and DU can be configured according to the protocol layer functions of the wireless network they implement. For example, the CU and DU nodes can separate the protocol layers of the gNB, with some protocol layer functions centrally controlled by the CU, and the remaining part or all of the protocol layer functions distributed in the DU, which is centrally controlled by the CU. In one implementation, as shown in Figure 1B, the CU is configured to implement the functions of the Packet Data Convergence Protocol (PDCP) layer and above (e.g., the Radio Resource Control (RRC) layer and / or the Service Data Adaptation Protocol (SDAP) layer); the DU is configured to implement the functions of protocol layers below the PDCP layer (e.g., one or more of the Radio Link Control (RLC) layer, Media Access Control (MAC) layer, or Physical (PHY) layer). Alternatively, the CU-CP is configured to implement the functions of the RRC layer and the PDCP control plane (PDCP-C), and the CU-UP is configured to implement the functions of the SDAP layer and the PDCP user plane (PDCP-U). For example, CU is configured to implement the functions of protocol layers above PDCP (such as RRC layer and / or SDAP layer), and DU is configured to implement the functions of protocol layers at and below PDCP (such as RLC layer, MAC layer, or PHY layer, or one or more of them).

[0093] The above CU and DU configurations are merely examples; the functions of the CU and DU can be configured as needed. For instance, the CU or DU can be configured to have more protocol layer functions, or only some protocol layer processing functions. For example, some RLC layer functions and protocol layer functions above the RLC layer can be placed in the CU, while the remaining RLC layer functions and protocol layer functions below the RLC layer can be placed in the DU. Furthermore, the functions of the CU or DU can be divided according to service type or other system requirements, such as by latency. Functions that require low latency can be placed in the DU, while functions that do not require low latency can be placed in the CU.

[0094] DU and RU can cooperate to implement the functions of the PHY layer. A DU can be connected to one or more RUs. The functions of DU and RU can be configured in various ways depending on the design. For example, a DU can be configured to implement baseband functions, and an RU can be configured to implement mid-RF functions. Another example is that a DU can be configured to implement higher-level functions in the PHY layer, and an RU can be configured to implement lower-level functions in the PHY layer, or to implement both lower-level and RF functions. Higher-level functions in the physical layer can include a portion of the physical layer's functions that are closer to the MAC layer, while lower-level functions in the physical layer can include another portion of the physical layer's functions that are closer to the mid-RF side.

[0095] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called an open CU (O-CU), DU can also be called an open DU (O-DU), CU-CP can also be called an open CU-CP (O-CU-CP), CU-UP can also be called an open CU-UP (O-CU-CP), and RU can also be called an open RU (O-RU). For ease of description, this application uses CU, CU-CP, CU-UP, DU, and RU as examples in its embodiments. Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application embodiment can be implemented through software modules, hardware modules, or a combination of software and hardware modules. The O-RAN system aims to realize an intelligent and open access network. The main feature of the O-RAN architecture is the separation of software and hardware, realizing the virtualization of network functions and the standardization of hardware. In addition, O-RAN also introduces artificial intelligence (AI).

[0096] Referring to Figure 1C, which is a schematic diagram of an O-RAN architecture provided in an embodiment of this application, the correspondence between ORAN nodes and their implementable protocol layer functions can be found in the following description.

[0097] The O-CU, also known as the O-RAN central unit or O-RAN control unit, can be configured to implement the functions of the PDCP layer and higher protocol layers (such as the RRC layer and / or SDAP layer). The O-CU-CP, also known as the O-RAN central unit control plane or O-RAN control unit control plane, is similar to the CU-CP in the NR system, implementing the RRC layer functions and the PDCP layer control plane functions. The O-CU-UP, also known as the O-RAN central unit user plane or O-RAN control unit user plane, is similar to the CU-UP in the NR system, implementing the SDAP layer functions and the PDCP layer user plane functions.

[0098] O-DU, also known as ORAN distributed unit, is based on the division of underlying functions and can be configured to implement one or more functions of protocol layers below the PDCP layer (such as the RLC layer, MAC layer, or higher layers of the PHY layer (closer to the MAC layer)). The higher-level functions of the PHY layer include one or more of the following: forward error correction (FEC) encoding / decoding, scrambling / descrambling, or modulation / demodulation.

[0099] O-RU, also known as ORAN radio unit, is based on low-layer function partitioning and is used to implement low-layer (near radio frequency) functions of the PHY as well as radio frequency functions. The low-layer physical layer functions include one or more of the following: Fast Fourier Transform (FFT) / Inverse Fast Fourier Transform (iFFT), digital beamforming, or extraction and filtering of the physical random access channel (PRACH). O-RU is similar to TRP or RRH in 3GPP, but it includes low-layer PHY functions such as FFT / iFFT or PRACH extraction.

[0100] A non-real-time RAN intelligent controller (non-real-time RIC), sometimes also called a non-RT RIC or NRT RIC, is used to implement non-real-time intelligent management of RAN functions. It can implement AI / ML workflows including model training and model updates, and guide applications / functions within the nRT RIC based on policies.

[0101] The near-real-time RAN intelligent controller (near-real-time RIC), sometimes also called near-RT RIC or nRT RIC, is used to achieve near-real-time intelligent management of the RAN. Through data collection and related operations on the E2 interface, it enables near-real-time control and optimization of O-RAN modules and resources.

[0102] The interfaces in the ORAN architecture shown in Figure 1C can be referenced as follows:

[0103] NG interface: The interface between NR RAN equipment (such as base stations, CUs, CU-CPs, or CU-UPs) and the NR core network; among them, NG-u is the user plane NG interface, and NG-c is the control plane NG interface.

[0104] Xn interface: The interface between NR RAN devices (such as base stations, CUs, CU-CPs, or CU-UPs); where Xn-u is the user plane Xn interface and Xn-c is the control plane Xn interface.

[0105] X2 Interface: The interface between LTE RAN devices; X2-u is the user plane X2 interface, and X2-c is the control plane X2 interface. In NR, the X2 interface is mainly used in E-UTRA-NR dual connectivity (EN-DC) scenarios, where the master station is an LTE RAN device that connects to the LTE core network through the X2 interface.

[0106] E1 interface: The interface between CU-CP and CU-UP.

[0107] F1-C interface: The interface between CU-CP and DU.

[0108] F1-U interface: The interface between CU-UP and DU.

[0109] In this application embodiment, the communication device used to implement the functions of the RAN device can be called an access network device. This access network device can be a network element, an access network device, or a device capable of supporting the access network device or network element to implement the function, such as a chip system. This device can be installed in the access network device. In the technical solutions provided in this application embodiment, the use of an access network device as an example to describe the technical solutions provided in this application embodiment.

[0110] The core network 200 is responsible for maintaining the subscription data of the mobile network, managing the network elements of the mobile network, and providing terminal equipment with functions such as user access control, session management, mobility management, data processing, policy management, user security authentication and billing.

[0111] The core network 200 consists of multiple functional units, which can be divided into control plane network elements (or control plane functional units) and user plane network elements (or user plane processing units). User plane network elements are responsible for transmitting service data; for example, user plane network elements may include, but are not limited to, user plane function (UPF) network elements. Control plane network elements are responsible for managing the mobile network; for example, control plane network elements may include, but are not limited to, access and mobility management function (AMF) network elements, session management function (SMF) network elements, authentication server function (AUSF) network elements, network exposure function (NEF) network elements, network function repository function (NRF) network elements, policy control function (PCF) network elements, unified data management (UDM) network elements, and application function (AF) network elements. The names of the devices implementing core network functions may differ in systems using different access technologies; this application embodiment does not limit this.

[0112] In this application embodiment, the communication device used to implement the functions of the core network equipment can be referred to as a core network device. This core network device can be a network element, a core network device, or a device capable of supporting the core network device or network element to implement the function, such as a chip system. This device can be installed in the core network equipment. In the technical solutions provided in this application embodiment, the core network device is used as an example to describe the technical solutions provided in this application embodiment.

[0113] The technical solutions of this application embodiment can also be applied to non-terrestrial networks (NTNs). NTNs include nodes such as satellite networks, high-altitude platforms, and unmanned aerial vehicles (UAVs). They possess significant advantages such as global coverage, long-distance transmission, flexible networking, convenient deployment, and no geographical limitations, and have been widely used in various fields such as maritime communication, positioning and navigation, disaster relief, scientific experiments, video broadcasting, and Earth observation. Terrestrial communication systems and satellite networks, among other NTN communication systems, are integrated, complementing each other's strengths to jointly form a globally seamless, integrated sea, land, air, space, and ground communication network, meeting the ubiquitous and diverse service needs of users. In this application embodiment, NTN communication is exemplified by satellite communication, or more specifically, NTN is exemplified by a satellite communication system. Figure 1D is a schematic diagram of a possible satellite communication system architecture applicable to this application embodiment.

[0114] As shown in Figure 1D, this satellite communication system architecture may include at least one terminal device (e.g., terminal device 1, terminal device 2, etc.), at least one satellite (e.g., satellite 1, satellite 2, etc.) (or a base station deployed on the satellite, such as a 5G base station), a ground station, a core network (CN) (e.g., a 5G core network), and a data network (DN). The terminal device and the satellite (or the base station deployed on the satellite) can communicate via an air interface (which can be of various types, such as 5G New Radio). For example, taking terminal device 1 as an example, terminal device 1 can access satellite 1 via a 5G New Radio interface. There are wireless links (e.g., Xn interfaces) between satellites (or base stations deployed on the satellite), which can be used for signaling interaction and user data transmission between base stations. For example, satellites (or base stations deployed on the satellite) can communicate via the Xn interface. The satellite and the ground station can communicate via the NG interface. The ground station can connect to the core network via the NG interface, which can be wired or wireless. The core network and the data network can communicate via the N6 interface. Satellites can typically form multiple beams, each beam similar to a cell / sector in a terrestrial mobile communication system (such as LTE / NR).

[0115] A data network is a network that provides business services (such as data and / or voice services) to users. Generally, the client is located on the terminal device, and the server is located on the data network. A data network can be a private network, such as a local area network (LAN), an external network not controlled by the operator, such as the Internet, or a dedicated network jointly deployed by operators, such as a network that provides IP multimedia core network subsystem (IMS) services.

[0116] Optionally, the ground station can also be called a gateway station (GW). The link between the satellite and the terminal equipment is called the user link, and the link between the satellite and the ground station is called the feeder link. Satellites can communicate with each other via inter-satellite links. Satellite operating modes include transparent and regenerative.

[0117] When the satellite operates in transparent transmission mode, it has signal relay capabilities, and the ground station possesses all or some of the functions of a base station; the ground station can be considered a base station. It is understood that a ground station can be a single device (e.g., a macro base station or a micro base station), or it can consist of multiple RAN devices (e.g., CU and DU) implementing the corresponding functions; refer to the aforementioned description of the terrestrial network for details. Alternatively,

[0118] When a satellite operates in regenerative mode, it has the ability to process digital signals and possesses all or some of the functions of a base station; thus, the satellite can be considered a base station. Further, regenerative mode can be subdivided into two scenarios: all base station functions are deployed on the satellite (referred to as full base station functions (e.g., CU and DU) on satellite); or, some base station functions are deployed on the satellite (referred to as partial base station functions (e.g., DU) on satellite), with the remaining functions (e.g., CU) implemented at a ground station.

[0119] In this embodiment of the application, the RAN equipment in the terrestrial communication system and the satellite in the NTN communication system can be regarded as RAN equipment.

[0120] It should be noted that the communication system and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0121] The technical solution provided in this application embodiment will be described below using a 5G NR communication system as an example. Figure 2A is a schematic diagram of the system architecture of a 5G NR communication system. The overall architecture of the 5G NR communication system consists of two parts: 5GC and NG-RAN.

[0122] NG-RAN devices can be gNBs or ng-eNBs. NG-RAN devices are connected to each other through the Xn interface, which is the logical interface between gNBs, between ng-eNBs, and between gNBs and ng-eNBs. NG-RAN devices are connected to 5GC through the NG interface.

[0123] The NG interface is the logical interface between NG-RAN and 5GC. The NG interface is divided into the NG-C interface and the NG-U interface. For example, NG-RAN equipment connects to AMF through the NG-C interface, which provides reliable signaling transmission services. NG-RAN equipment connects to UPF through the NG-U interface, which provides non-guaranteed data transmission services.

[0124] The NG interface protocol stack can also be divided into the NG-C interface protocol stack and the NG-U interface protocol stack. See Figure 2B for a schematic diagram of an NG interface protocol stack. Both the NG-C and NG-U interface protocol stacks are based on the Internet Protocol (IP) architecture. At the transport layer, the Stream Control Transmission Protocol (SCTP) can be used for the NG-C interface. SCTP can be seen as an improvement on the Transmission Control Plane (TCP) protocol, inheriting TCP's congestion control. For the NG-U interface, UDP and GTP-U protocols can be used.

[0125] Compared to TCP and SCTP protocols, UDP has lower reliability and security, but lower complexity. GTP-U protocol can encapsulate all user plane data and tunnel it for transmission. Data between tunnel endpoints is routed using IP addresses and UDP port numbers. Specifically, each Protocol Data Unit (PDU) session establishes its own GTP-U tunnel. A PDU session supports one or more Quality of Service (QoS) flows. A QoS flow is a set of service data streams or packets with the same QoS requirements. The user data of these QoS flows is encapsulated using the GTP-U protocol and transmitted within the GTP-U tunnel corresponding to the PDU session.

[0126] As shown in Figure 2B, GTP-U messages can be divided into two types. One type is the GTP-U user plane message, or G-PDU. A G-PDU consists of a user plane PDU (T-PDU, or user data packet) and a GTP-U header (as shown in Figure 2B, the GTPv1-U header). GTP-U user plane messages can be used to transmit user data packets between two GTP-U entities. The other type is the GTP-U signaling message, such as control-related signaling. GTP-U signaling messages are GTP-U messages but not G-PDUs, and can include path management messages and tunnel management messages. Therefore, GTP-U tunnels can be used for both data and signaling transmission.

[0127] The UDP protocol lacks flow control, congestion control, and retransmission mechanisms. The GTP-U protocol only has a simple timeout retransmission mechanism for GTP-U signaling messages, and similarly lacks congestion control and retransmission mechanisms for GTP-U user plane messages. This leads to a high probability of user data packet loss and significant latency. For example, in NTN scenarios, base stations can be satellites, typically transmitting data wirelessly to core network equipment. This compromises data transmission reliability, increasing the probability of user data packet loss and resulting in higher latency. One solution is to introduce a transport layer protocol supporting these mechanisms into the NG-U interface protocol stack to enable flow control, congestion control, and retransmission mechanisms.

[0128] However, no further solutions have yet been provided regarding how to implement the introduction of new transport layer protocols into the NG-U interface protocol stack.

[0129] For example, after introducing a new transport layer protocol into the NG-U interface protocol stack, or even without introducing a new transport layer protocol, when a terminal device performs a cell handover procedure, switching the connected base station from the source gNB to the target gNB, the data transmission between the target gNB and the core network needs to restart the NG-U interface. Since the current NG-U interface data transmission lacks a retransmission mechanism, neither the base station nor the core network equipment retains the terminal device's T-PDU transmission information. Therefore, the target gNB and core network equipment cannot continue transmitting the T-PDU from before the handover, resulting in potentially discontinuous T-PDU transmission for the terminal device, with possible omissions or duplicate transmissions, leading to reduced user data packet transmission efficiency. Especially in NTN scenarios, high mobility causes frequent handovers of the base stations connected to the terminal device. Frequent handovers result in frequent restarts of NG-U interface data transmission (i.e., restarting T-PDU transmission), exacerbating the reduced efficiency of NG-U interface data transmission.

[0130] Based on this, embodiments of this application provide a communication method. In this method, a first access network device can receive first information, which is used to indicate the T-PDU context information of a first terminal device. Then, after the first terminal device establishes a communication connection with the first access network device, the first access network device can perform user plane data transmission with the core network device according to the T-PDU context information. For example, after the first terminal device switches from a second access network device to the first access network device, the first access network device (such as a target base station) can inherit the T-PDU transmission status of the second access network device (such as a source base station) without restarting the NG-U interface data transmission, thus ensuring the continuity of NG-U interface data transmission and improving the efficiency of NG-U interface data transmission.

[0131] For example, congestion control adjusts its strategy based on real-time congestion status. However, with the introduction of a new transport layer protocol in the NG-U interface protocol stack, when the base station connected to the terminal device switches from the source base station to the target base station, the congestion control between the target base station and the core network equipment typically needs to be restarted—meaning congestion control needs to start from scratch. This can lead to a sharp drop in data transmission efficiency. Especially in NTN scenarios, frequent switching of the base station connected to the terminal device will result in frequent restarts of congestion control, reducing the efficiency of NG-U interface data transmission and potentially causing network congestion. It should be understood that congestion control and flow control are similar, or in some scenarios, they can be considered equivalent. Therefore, flow control also suffers from the aforementioned problems.

[0132] Based on this, in the communication method provided in this application embodiment, the T-PDU context information may further include congestion control status information corresponding to the first terminal device. After the first terminal device establishes a communication connection with the first access network device, the first access network device can continue to perform congestion control according to the congestion control status information without starting from scratch, thus avoiding a sudden drop in data transmission efficiency and reducing the probability of network lag. Similarly, this method can also solve the problems related to flow control.

[0133] The methods provided in the embodiments of this application are described below with reference to the accompanying drawings. In the flowcharts corresponding to the various embodiments of this application, unless otherwise specified, all steps indicated by dashed lines are optional. The various embodiments herein can be executed by RAN devices and core network devices. The various embodiments herein can be applied to the network architecture shown in any of Figures 1A to 1D. For example, the RAN device in the following embodiments can be any of the RAN devices shown in Figures 1A to 1D, the core network device in the following embodiments can be any of the core network devices shown in Figures 1A to 1D, and the UE in the following embodiments can be any of the UEs shown in Figures 1A to 1D.

[0134] Figure 3 is a flowchart illustrating a communication method provided in an embodiment of this application. As shown in Figure 3, the method may include the following steps:

[0135] Step 301: The second RAN device or the first RAN device sends the fourth information. Correspondingly, the core network device receives the fourth information.

[0136] The fourth information is used to indicate (or request) the retention of the T-PDU context information of the first UE. Here, "retain" can be replaced with "save," "store," "do not clear," etc. The first UE is a UE that is about to establish a connection with the first RAN device or has already established one. For example, the first UE is a UE performing a handover, switching from the second RAN device to the first RAN device. The T-PDU context information may include context information related to the transmission of user plane data between the second RAN device and the core network device; the T-PDU context information may also be called user data packet context information or user plane data context information, etc. Alternatively, the fourth information indicates the retention of the first UE's context information, which may include information related to the first UE's T-PDU transmission.

[0137] In some embodiments, the fourth information may be sent by the second RAN device to the core network device. For example, when the second RAN device determines that the first UE is about to switch to another RAN device (such as the first RAN device) to maintain the connection, the second RAN device sends the fourth information to the core network device. For example, the second RAN device sends the fourth information to the core network device before or after sending the handover command to the first UE, in order to notify the core network device to save the first UE's T-PDU context information.

[0138] In some embodiments, the fourth information may be sent by the first RAN device to the core network device. For example, after the first UE switches to the first RAN device, the first RAN device may send the fourth information to the first RAN device. For example, the fourth information may be sent through a path switch request message.

[0139] Optionally, the fourth information can explicitly indicate the retention of the first UE's T-PDU context information. For example, the fourth information can be specifically used to indicate the retention of the first UE's T-PDU context information, and based on the received fourth information, the core network device can determine whether the first UE's T-PDU context information needs to be retained. Optionally, the fourth information can also implicitly indicate the retention of the first UE's T-PDU context information. For example, the fourth information can be information related to the handover of the first UE, indicating that the first UE has undergone a handover. For example, the aforementioned path switch request message implicitly indicates that the first UE has switched to the target RAN device (i.e., the first RAN device), and can be used to implicitly indicate the retention of the first UE's T-PDU context information.

[0140] It should be understood that, in practice, core network equipment can also be configured to retain the UE's T-PDU context information by default. Therefore, even if the second RAN equipment or the first RAN equipment does not send the fourth information, the core network equipment can still retain the first UE's T-PDU context information. Thus, step 301 is optional and can be omitted.

[0141] In this embodiment, the second RAN device and / or core network device can determine (or identify) the first UE based on second information. The second information may include one or more of the following: the node identity (node ​​ID) of the second RAN device, an identifier related to the first interface assigned to the first UE by the second RAN device, or an identifier related to the first interface assigned to the first UE by the core network device. The first interface is the interface between the second access network device and the core network device. User plane data is transmitted between the second RAN device and the core network device through the user plane interface of the first interface. For example, the first interface is an NG interface, the identifier related to the first interface assigned to the first UE by the second RAN device may be a RAN UE NGAP ID, and the identifier related to the first interface assigned to the first UE by the core network device may be an AMF UE NGAP ID, where the AMF UE NGAP ID is the NG interface identifier assigned to the first UE by the AMF of the core network.

[0142] In some embodiments, the second RAN device may also send (or indicate) a fifth message to the core network device, the fifth message indicating (or including) the T-PDU context information of the first UE retained by the second RAN device. Optionally, the fifth message may be sent to the core network device together with the fourth message. Alternatively, the fourth message may include the fifth message. Or, the fourth message may be the same as the fifth message; upon receiving the T-PDU context information of the first UE retained by the second RAN device, the core network device can determine that it also needs to retain the T-PDU context information of the first UE. Optionally, the fourth message and the fifth message may also be sent to the core network device separately.

[0143] In one possible implementation, the T-PDU status information stored by the second RAN device may include (indicate or characterize) one or more of the following:

[0144] a1, the sequence number (SN) of the lost downlink T-PDU. A downlink T-PDU refers to a T-PDU sent by the core network device to the RAN device. Lost downlink T-PDUs may include those that the second RAN device failed to receive or that were received but not yet read. In one example, lost downlink T-PDUs may include some or all of the lost downlink T-PDUs. For example, lost downlink T-PDUs may include those lost within a recent period. Indicating the SN of the lost downlink T-PDUs helps determine which downlink T-PDUs of the first UE were lost after the first UE handover, allowing for the retransmission of the lost downlink T-PDUs corresponding to the first UE.

[0145] a2, the SN of the first lost downlink T-PDU. For example, if the SNs of the downlink T-PDUs lost by the first UE are 3, 4, 6, or 8, then the SN of the first lost downlink T-PDU is 3. Indicating the SN of the first lost downlink T-PDU helps determine from which downlink T-PDU the first UE experienced packet loss after the handover, allowing for retransmission of the first UE's downlink T-PDUs starting from that specific downlink T-PDU. Furthermore, indicating the SN of the first lost downlink T-PDU reduces the number of downlink T-PDU SNs that need to be indicated, thus lowering communication overhead.

[0146] a3, Receive status information of at least one downlink T-PDU. Optionally, the at least one downlink T-PDU may include at least one recently received downlink T-PDU. One implementation is that the receive status information of at least one downlink T-PDU can be indicated by a first bitmap. The first bitmap can also be called a downlink T-PDU receive status bitmap. For example, the first bitmap includes N bits, one bit corresponding to one downlink T-PDU, and one bit used to indicate the receive status of the downlink T-PDU corresponding to that bit. For example, when a bit is 0 (or 1), it indicates that the corresponding downlink T-PDU has not been lost, or when a bit is 1 (or 0), it indicates that the corresponding downlink T-PDU has been lost. "Not lost" can also be interpreted as successful reception, successful reading, or no need for retransmission; "lost" can also be interpreted as unsuccessful reception, unsuccessful reading, or need for retransmission. Indicating the receive status information of the downlink T-PDU through a bitmap can reduce the amount of data required for the receive status information and reduce communication overhead. Another implementation is that the receive status information of at least one downlink T-PDU can also be indicated by a status field. For example, the status field of each downlink T-PDU can include "SN + status value". The reception status of each downlink T-PDU can be accurately indicated by the status field.

[0147] By indicating the reception status information of at least one downlink T-PDU, it is possible to determine the reception status of each downlink T-PDU of the first UE after the first UE handover is completed, so as to determine which downlink T-PDUs of the first UE are lost or need to be retransmitted, so as to retransmit the lost downlink T-PDUs corresponding to the first UE.

[0148] a4, the SN of the downlink T-PDU that needs to be retransmitted. The downlink T-PDU that needs to be retransmitted can include lost downlink T-PDUs. Downlink T-PDUs are typically sent to the RAN equipment by the UPF included in the core network; therefore, the downlink T-PDU that needs to be retransmitted can also be understood as the downlink T-PDU that the UPF needs to retransmit. By including the SN of the downlink T-PDU that needs to be retransmitted in the T-PDU status information, the SN of the downlink T-PDU that does not need to be retransmitted does not need to be indicated, reducing the number of SNs of T-PDUs that need to be indicated and lowering communication overhead. Indicating the SN of the downlink T-PDU that needs to be retransmitted helps to promptly retransmit the downlink T-PDU that needs to be retransmitted after the first UE handover.

[0149] Based on b1 to b4 above, the first RAN device can determine which downlink T-PDUs of the first UE need to be retransmitted and can request the core network device to retransmit these downlink T-PDUs. Alternatively, the core network device can also determine which downlink T-PDUs of the first UE need to be retransmitted and then retransmit these downlink T-PDUs in a timely manner.

[0150] a5, the SN of the next uplink T-PDU that the second RAN device needs to transmit. An uplink T-PDU refers to a T-PDU sent by the RAN device to the core network device. In this embodiment, by indicating the SN of the next uplink T-PDU that the second RAN device needs to transmit, the core network device can determine the location where it will subsequently receive uplink T-PDUs transmitted by the first RAN device (i.e., the SN of the next uplink T-PDU), thus receiving the uplink T-PDU more accurately. Alternatively, for the first RAN device, knowing the location where it will continue transmitting uplink T-PDUs allows it to continue transmitting the uplink T-PDUs of the first UE after the first UE completes its handover, ensuring the continuity of user plane data transmission for the first UE.

[0151] a6, the serial number (SN) of the last uplink T-PDU transmitted by the second RAN device. In this embodiment, by indicating the SN of the last uplink T-PDU transmitted by the second RAN device, the core network device can determine the location where it will subsequently receive the uplink T-PDU transmitted by the first RAN device (i.e., the next SN after the SN of the last transmitted uplink T-PDU), thus enabling more accurate reception of the uplink T-PDU. Alternatively, for the first RAN device, knowing the location where it will continue transmitting the uplink T-PDU allows it to take over from the second RAN device after the first UE completes its handover, ensuring the continuity of user plane data transmission for the first UE.

[0152] It should be understood that the above uses the SN of a T-PDU as an example to identify a T-PDU. However, in specific implementation, other information may be used as the identifier of a T-PDU, and the SN mentioned above can be replaced with other information.

[0153] In some embodiments, the core network device may also send (or indicate) a sixth message, which can be received by either the second RAN device or the first RAN device. The sixth message may indicate (or include) the T-PDU context information of the first UE retained by the core network device. For example, after receiving the fourth or fifth message, the core network device may send the sixth message to the second RAN device. This allows the second RAN device to obtain the T-PDU context information of the first UE retained by the core network device, gaining a more comprehensive understanding of the T-PDU context information related to the first UE before the handover. Alternatively, the second RAN device may indicate the first RAN device to the core network device, allowing the core network device to send the sixth message to the first RAN device. This eliminates the need for the second RAN device to forward the T-PDU context information of the first UE retained by the core network device to the first RAN device, reducing communication overhead. Optionally, the second RAN device may indicate the first RAN device to the core network device when sending the fourth or fifth message.

[0154] In one possible implementation, the T-PDU status information stored by the core network equipment may include (indicate or characterize) one or more of the following:

[0155] b1, the serial number (SN) of the lost uplink T-PDU. Lost downlink T-PDUs can include uplink T-PDUs that the core network equipment failed to receive or that were received but not yet read. In one example, lost uplink T-PDUs can include some or all of the lost uplink T-PDUs. For example, lost uplink T-PDUs can include uplink T-PDUs lost within a recent period. Indicating the SN of the lost uplink T-PDUs helps determine which uplink T-PDUs of the first UE were lost after the first UE handover, allowing for the retransmission of the lost uplink T-PDUs corresponding to the first UE.

[0156] b2, the SN of the first lost uplink T-PDU. Indicating the SN of the first lost uplink T-PDU helps determine from which uplink T-PDU the packet loss occurred after the first UE handover, allowing for retransmission of the first UE's uplink T-PDU from that specific uplink T-PDU. Furthermore, indicating the SN of the first lost uplink T-PDU reduces the number of uplink T-PDU SNs that need to be indicated, thus lowering communication overhead.

[0157] b3, Receive status information of at least one uplink T-PDU. Optionally, the at least one uplink T-PDU may include at least one most recently received uplink T-PDU. One implementation is that the receive status information of at least one uplink T-PDU can be indicated by a second bitmap. The second bitmap can also be called an uplink T-PDU receive status bitmap. For example, the second bitmap includes M bits, one bit corresponding to one uplink T-PDU, and one bit used to indicate the receive status of the uplink T-PDU corresponding to that bit. For example, when a bit is 0 (or 1), it indicates that the corresponding uplink T-PDU has not been lost; or, when a bit is 1 (or 0), it indicates that the corresponding uplink T-PDU has been lost. "Not lost" can also be interpreted as successful reception, successful reading, or no need for retransmission; "lost" can also be interpreted as unsuccessful reception, unsuccessful reading, or need for retransmission. Indicating the receive status information of uplink T-PDUs through a bitmap can reduce the amount of data required for receive status information and reduce communication overhead. Another implementation involves indicating the reception status information of at least one uplink T-PDU via a status field. For example, the status field of each uplink T-PDU could include "SN + status value". This status field approach allows for accurate indication of the reception status of each uplink T-PDU.

[0158] By indicating the reception status information of at least one uplink T-PDU, it is possible to determine the reception status of each uplink T-PDU of the first UE after the first UE handover is completed, so as to determine which uplink T-PDUs of the first UE are lost or need to be retransmitted, so as to retransmit the lost uplink T-PDUs corresponding to the first UE.

[0159] b4, the SN of the uplink T-PDU that needs to be retransmitted. The uplink T-PDU that needs to be retransmitted can include lost uplink T-PDUs. The uplink T-PDU that needs to be retransmitted refers to the uplink T-PDU that the second RAN device needs to retransmit. By including the SN of the uplink T-PDU that needs to be retransmitted in the T-PDU status information, the SN of the uplink T-PDU that does not need to be retransmitted does not need to be indicated, reducing the number of SNs of T-PDUs that need to be indicated and lowering communication overhead. Indicating the SN of the uplink T-PDU that needs to be retransmitted helps to promptly retransmit the uplink T-PDU that needs to be retransmitted after the first UE handover is completed.

[0160] Based on c1 to c4 above, the first RAN device can determine which uplink T-PDUs of the first UE need to be retransmitted, and then retransmit these uplink T-PDUs in a timely manner. Alternatively, the core network device can also determine which uplink T-PDUs of the first UE need to be retransmitted, and can request the first RAN device to retransmit these uplink T-PDUs.

[0161] b5, the SN of the next downlink T-PDU that the core network device needs to transmit. In this embodiment of the application, by indicating the SN of the next downlink T-PDU that the core network device needs to transmit, the first RAN device can determine the downlink T-PDU that it will receive subsequently, so as to receive the downlink T-PDU more accurately.

[0162] b6, the serial number (SN) of the last downlink T-PDU transmitted by the core network equipment. Indicating the SN of the last downlink T-PDU transmitted by the core network equipment helps the first RAN equipment determine the subsequent downlink T-PDUs to be received, thus enabling more accurate reception of downlink T-PDUs.

[0163] Step 302: The second RAN device sends the first information. Correspondingly, the first RAN device receives the first information.

[0164] The first information can be used to indicate (or include) the T-PDU context information of the first UE. The first UE is a UE that is about to establish or has already established a communication connection with the first RAN device. For example, the first UE is a UE that switches from a communication connection with the second RAN device to a communication connection with the first RAN device. For example, the second RAN device is the source base station of the first UE, and the first RAN device is the target base station of the first UE. The T-PDU context information can include context information related to the transmission of user plane data between the second RAN device and the core network device. Based on this T-PDU context information, after the first UE switches to a connection with the first RAN device, the first RAN device can continue to transmit the user plane data of the first UE between the second RAN device and the core network device, ensuring the continuity of user plane data transmission of the first UE and improving the efficiency of user plane data transmission.

[0165] In some embodiments, the second RAN device may send first information to the first RAN device when it determines that the first UE will switch to a communication connection with the first RAN device. One implementation is that the first information may be carried in a message involved in the handover process. For example, the first information may be carried in a handover request or a handover command. Another implementation is that the first information may also be carried in other messages, which can be existing messages or newly constructed messages, without limitation.

[0166] T-PDU context information may include T-PDU context information stored (or generated) by the second RAN device, and / or T-PDU context information stored (or generated) by the core network device. The T-PDU context information stored by the second RAN device may include context information related to the second RAN device sending user plane data to the core network device. The T-PDU context information stored by the core network device may include context information related to the core network device sending user plane data to the second RAN device.

[0167] As an example, T-PDU context information may include one or more of the following:

[0168] c1, T-PDU status information of the first UE. The T-PDU status information can indicate (or characterize) the T-PDU transmission status of the first UE. For example, the T-PDU status information can indicate one or more of the following in the first UE's T-PDU: lost T-PDUs, transmitted T-PDUs (such as the most recent or several transmitted T-PDUs), or T-PDUs that need to be transmitted (such as one or more T-PDUs about to be transmitted). Here, "transmission" can be understood as sending and / or receiving. Optionally, the T-PDU transmission status can include uplink transmission status and / or downlink transmission status. Alternatively, the T-PDU status information can include T-PDU status information stored (or generated) by the second RAN device, and / or T-PDU status information stored (or generated) by the core network device. As one implementation of c1, the T-PDU status information can be retained by the second RAN device, that is, it can include one or more of the above a1 to a6. As another implementation of c1, the T-PDU status information can be retained by the second RAN equipment and the core network equipment, that is, it can include one or more of a1 to a6 or b1 to b6 mentioned above.

[0169] In some embodiments, one or more PDU sessions can be established for the first UE. Optionally, the T-PDU status information can be the T-PDU status information per PDU session, or the granularity of the T-PDU status information can be at the PDU session level. For example, when the first UE has multiple PDU sessions, the T-PDU context information can include the T-PDU status information of each of the multiple PDU sessions. Each PDU session of the first UE can be used to transmit different types of data flows or services, that is, each PDU session can include one or more QoS flows. Optionally, the T-PDU status information can also be the T-PDU status information per QoS flow of each PDU session, or the granularity of the T-PDU status information can be at the QoS flow level. For example, when a certain PDU session of the first UE includes multiple QoS flows, the T-PDU context information can include the T-PDU status information corresponding to each of the multiple QoS flows.

[0170] c2, the transport layer protocol used for transmitting user plane data between the second RAN device and the core network device. The second RAN device and the core network device transmit user plane data through the first interface; that is, the T-PDU context information can include the transport layer protocol of the first interface. For example, if the first interface is an NG-U interface, the T-PDU context information can include the transport layer protocol of the NG-U interface. Different transport layer protocols or combinations of protocols can be understood as a transport layer protocol type, so the transport layer protocol of the first interface can also be understood as that type of transport layer protocol for the first interface. Optionally, the transport layer protocol can be one or more of UDP, GTP-U, TCP, SCTP, or QUIC. For example, the transport layer protocol can be UDP+GTP-U. Another example is UDP+QUIC. Yet another example is TCP.

[0171] It should be understood that the first UE may include one or more UEs, and correspondingly, the first information may include the T-PDU context information of one or more UEs respectively. Alternatively, the number of first UEs may be one or more. That is, the second RAN device may send the first information of one or more first UEs respectively, and correspondingly, the first RAN device may receive the first information of one or more first UEs.

[0172] In some embodiments, the first RAN device may also receive second information, which allows the first RAN device to determine (or identify) the T-PDU context information of the first UE. For example, the first RAN device may retain the T-PDU context information of one or more UEs, and based on the second information, the first RAN device can uniquely determine the T-PDU context information of the first UE from the T-PDU context information of one or more UEs. Optionally, the second information may include one or more of the following: the ID of the second RAN device, an ID assigned to the first UE by the second RAN device related to the first interface (such as the RAN UE NGAP ID), or an ID assigned to the first UE by the core network device related to the first interface (such as the AMF UE NGAP ID). Optionally, the second information may be sent by the second RAN device, or it may be sent by the core network device, or it may be sent to the first RAN device after the first UE establishes a communication connection with the first RAN device.

[0173] Step 303: The first UE switches from the second RAN device to the first RAN device to maintain the communication connection. Step 303 can also be described as the first UE performing a handover procedure, switching from the second RAN device to the first RAN device to connect to the first RAN device. Alternatively, step 303 can also be described as the first RAN device establishing a communication connection with the first UE.

[0174] Optionally, the steps of the communication method provided in this application embodiment can be appropriately adjusted, such as adjusting the order of the steps, or adding or removing steps. For example, there is no substantial order between the steps 301 to 303; each step can be executed simultaneously or sequentially. For instance, when executed sequentially, step 301 can be executed after step 302, or step 302 can be executed after step 303; there is no specific limitation on this.

[0175] Optionally, after establishing a communication connection with the first RAN device, the first RAN device may send (or instruct) second information to the core network device, so that the core network can determine the T-PDU context information of the first UE based on the second information. Alternatively, by sending the second information to the core network device, the first RAN device can inform the core network device that the first UE has switched to the first RAN device, and the core network device can send user data related to the first UE to the first RAN device.

[0176] Step 304: The first RAN device performs user plane data transmission with the core network device based on the T-PDU context information. Alternatively, the core network device performs user plane data transmission with the first RAN device based on the T-PDU context information.

[0177] In some embodiments, the first RAN device may perform one or more of the following:

[0178] d1, the first RAN device sends the first uplink T-PDU. The first uplink T-PDU is either a lost uplink T-PDU or an uplink T-PDU that needs to be retransmitted. It should be understood that while this is the first time the first RAN device is sending the first uplink T-PDU, it is essentially a retransmitted T-PDU. Therefore, the first RAN device sending the first uplink T-PDU can also be described as the first RAN device retransmitting the first uplink T-PDU.

[0179] In some embodiments, when the T-PDU status information indicated by the first information sent by the second RAN device to the first RAN device includes one or more of the above-mentioned b1 to b4, or when the core network device sends one or more of the above-mentioned b1 to b4 to the first RAN device, the T-PDU context information of the first UE retained by the first RAN device may include one or more of the above-mentioned b1 to b4. Then the first RAN device can determine the first uplink T-PDU accordingly and send the first uplink T-PDU to the core network device.

[0180] In some embodiments, the T-PDU context information retained by the first RAN device does not include one or more of a1 to a4 mentioned above, but the T-PDU context information retained by the core network device includes one or more of a1 to a4 mentioned above. Therefore, the core network device knows which uplink T-PDUs need to be retransmitted, and the core network device can request (or instruct) the first RAN device to retransmit these uplink T-PDUs.

[0181] d2, the first RAN device sends a second uplink T-PDU. The sequence number of the second uplink T-PDU is greater than or equal to the serial number (SN) of the next uplink T-PDU that the second RAN device needs to transmit. That is, the first RAN device can continue sending the first UE's uplink T-PDU to the core network device, following the second RAN device. Optionally, the T-PDU status information may include one or more of a5 to a6 above, based on which the first RAN device can determine the second uplink T-PDU and send it to the core network device. For example, if the T-PDU status information includes the SN of the next uplink T-PDU that the second RAN device needs to transmit, the first RAN device can start sending uplink T-PDUs to the core network device from that SN. For example, the T-PDU status information includes the SN of the last uplink T-PDU sent by the second RAN device. The first RAN device can use this information to determine the SN of the next uplink T-PDU that needs to be transmitted, and then continue to send uplink T-PDUs to the core network device starting from the SN of the next uplink T-PDU.

[0182] In some embodiments, the core network device may perform one or more of the following:

[0183] e1, the core network device sends the first downlink T-PDU, or it can be described as the core network device retransmitting the first downlink T-PDU. The first downlink T-PDU is either a lost downlink T-PDU or a downlink T-PDU that needs to be retransmitted.

[0184] In some embodiments, when the second RAN device sends fifth information to the core network device, and the fifth information includes one or more of a1 to a4 above, the T-PDU context information of the first UE retained by the core network device may include one or more of a1 to a4 above. Then the core network device can determine the first downlink T-PDU based on this and send the first downlink T-PDU to the first RAN device.

[0185] In some embodiments, the T-PDU context information retained by the core network device does not include one or more of a1 to a4 mentioned above, but the T-PDU context information retained by the first RAN device includes one or more of a1 to a4 mentioned above. Therefore, the first RAN device knows which downlink T-PDUs need to be retransmitted, and the first RAN device can request (or instruct) the core network device to retransmit these downlink T-PDUs.

[0186] e2, the core network device sends a second downlink T-PDU. The sequence number of the second downlink T-PDU is greater than or equal to the serial number (SN) of the next downlink T-PDU that the core network device needs to transmit. That is, the core network device can continue to send the first UE's downlink T-PDU to the first RAN network device. Optionally, the T-PDU status information may include one or more of the above b5 to b6, based on which the core network device can determine the second downlink T-PDU and send it to the first RAN device. For example, if the T-PDU status information includes the SN of the next downlink T-PDU that the core network device needs to transmit, the core network device can start sending downlink T-PDUs to the first RAN device from that next downlink T-PDU SN. Or, if the T-PDU status information includes the SN of the last downlink T-PDU sent by the core network device, the core network device can determine the SN of the next downlink T-PDU that needs to be transmitted, and then start sending downlink T-PDUs to the first RAN device from that next downlink T-PDU SN.

[0187] It should be understood that the above explanations are based on sending uplink or downlink T-PDUs. However, when sending uplink or downlink T-PDUs, other necessary data may also be transmitted. That is, the first RAN device performing user plane data transmission may also include sending other data, such as the G-PDU header, to the core network device. Similarly, the core network device performing user plane data transmission may also include sending other data, such as the G-PDU header, to the first RAN device.

[0188] Based on the above embodiments, when the RAN device connected to the first UE switches from the second RAN device to the first RAN device, the second RAN device can instruct the core network device to retain the first UE's T-PDU context information and to indicate the first UE's T-PDU context information to the first RAN device. This allows the first RAN device and the core network device to inherit (or continue to use) the first UE's T-PDU context information to perform user plane data transmission (such as retransmission and newtransmission). Therefore, when the user plane interface (such as the NG-U interface) data transmission supports a retransmission mechanism, the continuity of retransmission and newtransmission of user plane interface (such as the NG-U interface) data can be guaranteed after the handover, improving the efficiency of user plane data transmission and reducing data packet latency.

[0189] In real-world scenarios, flow control prevents the sender's data from filling the receiver's buffer. While flow control is implemented, it doesn't consider the network's overall condition, meaning communication between other hosts can cause network congestion. When the network is congested, continuing to send large numbers of data packets can lead to delays and packet loss, requiring retransmissions. However, retransmissions further burden the network, resulting in even greater latency and packet loss, creating a vicious cycle that amplifies the problem. Therefore, network congestion control is essential. The goal of congestion control is to prevent the sender's data from filling the entire network, reducing the probability of network slowdowns.

[0190] In some embodiments, a transport layer protocol supporting congestion control can be introduced at the user plane interface between the core network and the RAN to support congestion control during user plane data transmission. That is, the transport layer protocol included in the T-PDU context information mentioned above can include a first transport layer protocol that supports congestion control. For example, the first transport layer protocol can be TCP or QUIC, or other protocols that support congestion control; there are no limitations on this. It is understood that the following description uses congestion control as an example, and the methods described below can also use transport layer protocols that support flow control. Therefore, the content related to congestion control can be replaced with the content related to flow control.

[0191] After the introduction of transport layer protocols supporting congestion control, if the RAN device to which the UE is connected switches from the second RAN device to the first RAN device, the first RAN device and the core network device will typically restart congestion control. This will cause a sharp drop in user plane data transmission efficiency, potentially leading to network lag. Therefore, in the communication method provided in this application embodiment, when a switch occurs, the first RAN device and the core network device can inherit (or continue to use) the congestion control state before the switch to avoid the problem of a sharp drop in user plane data transmission efficiency caused by starting congestion control from scratch, thus reducing the probability of network lag. The congestion control state can also be referred to as congestion control parameters, etc.

[0192] Referring to Figure 4, which is a schematic flowchart of another communication method provided in an embodiment of this application, the method includes the following steps:

[0193] Step 401: The second RAN device or the first RAN device sends the fourth information. Correspondingly, the core network device receives the fourth information.

[0194] The fourth piece of information is used to indicate the retention of the T-PDU context information of the first UE. After the introduction of the first transport layer protocol, the T-PDU context information, in addition to the content included in the embodiment shown in Figure 3, may also include congestion control state information related to the first UE. This congestion control state information is used to control user plane data transmission between the RAN device (such as the second RAN device) and the core network device. For example, the T-PDU context information retained by the second RAN device may include congestion control state information related to the uplink transmission of user plane data for the first UE, and the T-PDU context information retained by the core network device may include congestion control state information related to the downlink transmission of user plane data for the first UE.

[0195] Step 402: The second RAN device sends the first information. Correspondingly, the first RAN device receives the first information.

[0196] The first information is used to indicate the T-PDU context information of the first UE. In addition to the content included in the embodiment shown in FIG3, the T-PDU context information may also include congestion control status information related to user plane data transmission of the first UE. This congestion control status information may include uplink transmission-related congestion control status information. Optionally, the congestion control status information may also include downlink transmission-related congestion control status information.

[0197] Step 403: The first UE switches from the second RAN device to the first RAN device to maintain the communication connection. Step 403 can also be described as the first UE performing a handover procedure, switching from a communication connection with the second RAN device to a communication connection with the first RAN device. Alternatively, step 403 can also be described as the first RAN device establishing a communication connection with the first UE.

[0198] Step 404: The first RAN device or core network device performs congestion control based on the congestion control status information.

[0199] For example, the first RAN device performs congestion control on the uplink transmission of the first UE's user plane data based on the congestion control status information related to the uplink transmission of the first UE's user plane data. Alternatively, the core network device performs congestion control on the downlink transmission of the first UE's user plane data based on the congestion control status information related to the downlink transmission of the first UE's user plane data.

[0200] For a description of the above steps, please refer to the description of the corresponding steps in the embodiment shown in Figure 3, which will not be repeated here.

[0201] In one possible implementation, the first transport layer protocol can be TCP. The core principle of TCP is to ensure that all data packets arrive, so TCP has a retransmission mechanism. This mechanism can include timeout retransmission, fast retransmission, selective acknowledgment (SACK), duplicate SACK, and delayed acknowledgment (ACK). TCP also supports congestion control. To regulate the amount of data sent by the sender, TCP defines the concept of a congestion window (cwnd). cwnd is a state variable maintained by the sender to control the data transmission rate and prevent excessive network congestion. It dynamically changes according to the degree of network congestion. The rule for cwnd is that it increases when there is no network congestion and decreases when congestion occurs. If the sender does not receive an ACK response within a specified time (i.e., a timeout retransmission occurs), it is considered that network congestion has occurred.

[0202] Referring to Figure 5A, this diagram illustrates the various control stages included in the TCP protocol's congestion control. The TCP protocol's congestion control can be divided into several stages, each employing a corresponding congestion control algorithm.

[0203] (1) Slow start

[0204] When using TCP as the transport layer protocol, after establishing a connection, a slow start phase begins, during which the number of data packets sent gradually increases. The algorithm for the slow start phase is as follows: for each ACK received by the receiver, the congestion window (cwnd) increments by 1. As shown in Figure 5B, which illustrates the slow start phase, the initial cwnd is 1. After receiving an ACK, cwnd is updated to 2. Two data packets are then sent, and two ACKs are received, updating cwnd to 4, and so on. Therefore, the number of packets sent during the slow start phase grows exponentially. However, the number of packets cannot grow indefinitely. Therefore, the TCP protocol defines a slow start threshold (ssthresh), also known as the congestion window threshold. ssthresh is a state variable maintained by the sender. When cwnd is less than sthresh, the slow start algorithm is used; however, when cwnd is greater than or equal to ssthresh, the congestion avoidance phase begins, where the congestion avoidance algorithm is used.

[0205] (2) Congestion avoidance

[0206] As shown in Figure 5A, the congestion avoidance phase begins when congestion limit (cwnd) is greater than or equal to ssthresh. For example, ssthresh can be 65535 bytes. Once in the congestion avoidance phase, cwnd increases by 1 / cwnd each time an ACK is received. For example, in Figure 5A, when cwnd reaches 8, the congestion avoidance phase begins, where cwnd increases by 1 each time. In other words, the congestion avoidance phase transforms the exponential growth of the slow start phase into linear growth; it's still in a growth phase, but the growth rate is slower. This continuous growth eventually leads to network congestion and packet loss, requiring retransmission of lost packets. When the retransmission mechanism is triggered, the congestion occurrence algorithm phase begins, where the congestion occurrence algorithm is used.

[0207] (3) Congestion occurs

[0208] When network congestion occurs, data packets will be retransmitted. There are two main retransmission mechanisms: retransmission timeout (RTO) and fast retransmit. These two retransmission mechanisms use different congestion initiation algorithms.

[0209] As shown in Figure 5A, if a timeout retransmission occurs, the values ​​of ssthresh and cwnd in the congestion prevention algorithm will change. Specifically, ssthresh will be set to cwnd / 2, and cwnd will be reset to 1. Then, slow start will restart, which abruptly reduces the data flow. It is evident that timeout retransmission has too aggressive an impact on the congestion window and data transmission window, potentially causing network congestion.

[0210] If a fast retransmission occurs, the congestion prevention algorithm used in the process sends three ACKs for the previous packet when the receiver detects a lost intermediate packet. The sender then quickly retransmits the packet without waiting for a timeout. In the TCP protocol, this situation is generally considered minor because most packets are not lost, only a small portion. Therefore, ssthresh and cwnd are not as aggressive as in the case of timeout retransmission; instead, cwnd is set to cwnd / 2 (half of its original value), and ssthresh is set to cwnd. After adjustments based on the congestion prevention algorithm, the process enters the fast recovery phase, where the fast recovery algorithm is used.

[0211] (4) Rapid recovery

[0212] Fast retransmission and fast recovery algorithms are generally used simultaneously. The fast recovery algorithm assumes that receiving three duplicate ACKs indicates the network isn't too bad, so there's no need for the same level of force as timeout retransmission. The fast recovery algorithm updates cwnd to ssthresh+3 (where 3 means three packets have been received) and retransmits the lost packets. If another duplicate ACK is received, cwnd is incremented by 1. If an ACK for new data is received, cwnd is set to the value of ssthresh from the first step. This is because the ACK confirms new data, meaning all data from the time of the duplicate acknowledgment (duplicated ACK) has been received, the recovery process is complete, and the network can return to its pre-recovery state, i.e., re-enter the congestion avoidance state. Therefore, when using the fast recovery algorithm, cwnd doesn't immediately set to 1 like in the timeout retransmission algorithm; instead, it remains at a relatively high value and subsequently increases linearly.

[0213] In this embodiment of the application, when the transport layer protocol used for user plane data transmission between the core network device and the RAN device includes the TCP protocol, if the RAN device connected to the UE is switched from the second RAN device to the first RAN device, the second RAN device and the core network device can negotiate to retain the TCP congestion control state. In this way, the first RAN device and the core network device can also inherit and switch the previous TCP congestion control state to perform congestion control.

[0214] Referring to Figures 6A and 6B, Figure 6A is a schematic diagram of an NG-U interface protocol stack provided in an embodiment of this application, and Figure 6B is a schematic diagram of another communication method provided in an embodiment of this application. It should be understood that Figures 6A and 6B both use a 5G NR system as an example, but this method can also be applied to other communication systems. When applied to other communication systems, the NG-U interface and the network elements involved can be replaced with corresponding interfaces and network elements in other communication systems, without specific limitations.

[0215] As shown in Figure 6A, the NG-U interface protocol stack uses TCP as the transport layer protocol. As shown in Figure 6B, taking the handover of a first UE from a second RAN device to a first RAN device as an example, the steps of this method are as follows:

[0216] S10: The second RAN device (i.e., RAN2 shown in Figure 6B) sends the fourth message. Correspondingly, the core network device (i.e., 5GC shown in Figure 6B) receives the fourth message.

[0217] The fourth piece of information is used to indicate the retention of the T-PDU context information of the first UE. This T-PDU context information may include one or more of the following: T-PDU status information, information indicating the transport layer protocol used, and TCP congestion control status information related to the first UE. The information indicating the transport layer protocol used specifically indicates that the transport layer protocol is TCP. The TCP congestion control status information is used to control user plane data transmission between the RAN device and the core network device. TCP congestion control status information refers to the congestion control status information related to congestion control when using TCP as the transport layer protocol. The TCP congestion control status information is used to indicate the congestion control status related to user plane data transmission between the RAN device and the core network device. For example, the TCP congestion control status information stored (or generated) in the core network device is used to implement congestion control when the core network device transmits user plane data to the second RAN device.

[0218] Optionally, the second RAN device can also send fifth information to the core network device. This fifth information includes T-PDU context information stored in the second RAN device. The T-PDU context information may also include T-PDU status information, information indicating the transport layer protocol used, and TCP congestion control status information stored (or generated) in the second RAN device, enabling the core network device to be aware of uplink congestion. The TCP congestion control status information stored in the second RAN device is used to implement congestion control when the second RAN device transmits user plane data to the core network device.

[0219] S11: The core network device sends the sixth message. Correspondingly, the second RAN device (or the first RAN device (i.e., RAN1 shown in Figure 6B)) receives the sixth message.

[0220] The sixth piece of information is used to indicate the T-PDU context information stored in the core network equipment. This T-PDU context information includes T-PDU status information, information indicating the transport layer protocol used, and TCP congestion control status information stored in the core network equipment. It should be understood that step S11 is optional and may not be performed.

[0221] S12: The second RAN device sends the first information. Correspondingly, the first RAN device receives the first information.

[0222] The first information is used to indicate the T-PDU context information of the first UE. This T-PDU context information may include T-PDU status information, information indicating the transport layer protocol used, and TCP congestion control status information related to the first UE. Optionally, the T-PDU status information may be the T-PDU status information for each PDU session, or it may be the T-PDU status information for each QoS flow of each PDU session.

[0223] Optionally, the T-PDU context information may include T-PDU context information stored in the second RAN device and / or T-PDU context information stored in the core network device. For example, the T-PDU context information indicated by the first information may include TCP congestion control status information stored in the second RAN device. As another example, the T-PDU context information indicated by the first information may include TCP congestion control status information stored in the core network device in addition to the TCP congestion control status information stored in the second RAN device, thus enabling the first RAN device to be aware of the downlink congestion situation.

[0224] In one possible implementation, the TCP congestion control status information stored by the second RAN device or core network device may indicate (or include) one or more of the following:

[0225] f1 indicates the current TCP congestion control phase. For example, the TCP congestion control phase could be the slow start phase, congestion avoidance phase, congestion occurrence phase, or fast recovery phase. Different congestion control algorithms can be used in different congestion control phases. By including information indicating the TCP congestion control phase in the TCP congestion control state, or in other words, indicating the TCP congestion control phase before the handover, the first RAN device or core network device can continue to perform congestion control from that TCP congestion control phase without having to start from the slow start phase.

[0226] For example, the TCP congestion control status information stored in the second RAN device can indicate the TCP congestion control phase of uplink transmission, and the TCP congestion control status information stored in the core network device can indicate the TCP congestion control phase of downlink transmission.

[0227] f2, the retransmission mechanism used. For example, the retransmission mechanism may include timeout retransmission or fast retransmission.

[0228] F3, sender's window (swnd) count. "Window count" refers to the value of a window used to indicate the amount of data. Window count can also be called data bytes, data volume, window value, window size, window space, or window data volume, etc. For example, sender window count refers to the amount of data that can be sent, the data size, or the number of data bytes.

[0229] f4, number of congested windows.

[0230] f5, the number of receiver's windows (rwnd).

[0231] It should be understood that, in addition to the above, TCP congestion control status information may also indicate (or include) other congestion control related information, without specific limitations.

[0232] S13: The first UE performs an air interface handover, switching from a communication connection with the second RAN device to a communication connection with the first RAN device.

[0233] S14: The first RAN device sends the second information. Correspondingly, the core network device receives the second information. It should be understood that step S11 is optional and can be omitted.

[0234] S15: The first RAN device and / or the core network device perform congestion control based on TCP congestion control status information. For example, the first RAN device can perform uplink congestion control based on TCP congestion control status information related to uplink transmission, or the core network device can perform downlink congestion control based on TCP congestion control status information related to downlink transmission.

[0235] Based on this implementation method, the first RAN device and / or core network device inherit the TCP congestion control state information before the switchover to perform congestion control, without having to start from scratch, ensuring the continuity of the congestion control function, avoiding the problem of reduced data volume caused by starting from scratch, and reducing the probability of network lag.

[0236] In another possible implementation, the first transport layer protocol could be the QUIC protocol. QUIC is a protocol for multiplexing concurrent transmission based on UDP. It reduces the time required for TCP three-way handshakes and TLS handshakes, uses improved congestion control, enables multiplexing to avoid head-of-line blocking, and features connection migration, forward redundancy error correction, and other functionalities.

[0237] Figure 7 illustrates one principle of the QUIC protocol. QUIC multiplexing allows multiple session streams to be sent concurrently over a single connection, with each stream independent of the others. As shown in Figure 7, a connection can include streams 1 through 3. If stream 2 loses a packet, it will not affect stream 3. Because QUIC supports multiplexing, it provides two flow control levels: Connection level and Stream level. QUIC's flow control function can be understood as its congestion control function. The principle behind QUIC's flow control is relatively simple: it uses window update frames to inform the peer of the number of bytes it can receive, preventing the sender from sending more data than that limit; and it uses block frames to inform the peer that data cannot be sent due to flow control limitations.

[0238] Compared to the TCP protocol, which, to ensure reliability, limits the length of the window sliding to the right from left to right based on the number of acknowledged bytes, the window cannot exceed a sequence number even if a TCP segment with a larger sequence number is received if packet loss occurs. However, the QUIC protocol's flow control is different. In QUIC, even if some packets have not been received previously, its sliding only depends on the maximum received offset, which is the rightmost position in the middle of each stream as shown in Figure 7. This rightmost position represents the maximum received offset of data. The maximum offset can also be called the maximum offset bytes or the maximum offset data volume, etc.

[0239] For each stream shown in Figure 7, the available window at the stream level can be calculated as follows:

[0240] Available windows = Maximum number of windows - Maximum number of received offsets

[0241] For the connection shown in Figure 7, the available window at the connection level can be calculated as follows:

[0242] Available windows = available space of stream1 + available space of stream2 + available space of stream3

[0243] Based on the QUIC protocol, flow control can be used to limit the transmission rate and ensure service availability when memory is insufficient or upstream processing performance issues occur. Regarding improved congestion control, the QUIC protocol supports various congestion control algorithms. For example, QUIC supports path delay-based congestion control algorithms such as Vegas and Westwood. It also supports packet loss-based congestion control algorithms such as Cubic and NewReno. Furthermore, QUIC supports bandwidth delay probing-based congestion control algorithms such as BBR.

[0244] Multi-path QUIC (MP-QUIC) is an extension of connection migration capabilities. MP-QUIC uses multiple network paths to form a single QUIC connection for data transmission, and can simultaneously utilize networks such as Wi-Fi, LTE / 4G, 5G, or IPv4 / IPv6 for data transmission. Multiple paths can transmit the same data or different data. Data packets from different paths within the same connection are individually numbered.

[0245] In this embodiment of the application, when the transport layer protocol used for user plane data transmission between the core network device and the RAN device includes the QUIC protocol, if the RAN device connected to the UE is switched from the second RAN device to the first RAN device, the second RAN device and the core network device can negotiate to retain the QUIC congestion control state. In this way, the first RAN device and the core network device can also inherit the previous QUIC congestion control state to perform congestion control.

[0246] Referring to Figures 8A and 8B, Figure 8A is another schematic diagram of the NG-U interface protocol stack provided in an embodiment of this application, and Figure 8B is another schematic diagram of the communication method provided in an embodiment of this application. It should be understood that Figures 8A and 8B also use a 5G NR system as an example, but this method can also be applied to other communication systems. When applied to other communication systems, the NG-U interface and the network elements involved can be replaced with the corresponding interfaces and network elements in other communication systems, without specific limitations.

[0247] As shown in Figure 8A, the NG-U interface protocol stack uses UDP protocol superimposed with QUIC protocol as the transport layer protocol. As shown in Figure 8B, taking the handover of the first UE from the second RAN device to the first RAN device as an example, the steps of this method are as follows:

[0248] S20: The second RAN device (i.e., RAN2 shown in Figure 8B) sends the fourth message. Correspondingly, the core network device (i.e., 5GC shown in Figure 8B) receives the fourth message.

[0249] The fourth piece of information is used to indicate the retention of the T-PDU context information of the first UE. This T-PDU context information may include one or more of the following: T-PDU status information, information indicating the transport layer protocol used, and QUIC congestion control status information related to the first UE. The information indicating the transport layer protocol used indicates that the transport layer protocol includes the QUIC protocol. The QUIC congestion control status information is used to control user plane data transmission between the RAN device and the core network device. The QUIC congestion control status information refers to the congestion control status information related to congestion control when using the QUIC protocol as the transport layer protocol. The QUIC congestion control status information is used to indicate the congestion control status related to user plane data transmission between the RAN device and the core network device. For example, the QUIC congestion control status information stored (or generated) in the core network device is used to implement congestion control when the core network device transmits user plane data to the second RAN device.

[0250] Optionally, the second RAN device can also send fifth information to the core network device. This fifth information includes T-PDU context information stored in the second RAN device. The T-PDU context information may also include T-PDU status information, information indicating the transport layer protocol used, and QUIC congestion control status information stored (or generated) in the second RAN device, enabling the core network device to be aware of uplink congestion. The QUIC congestion control status information stored in the second RAN device is used to implement congestion control when the second RAN device transmits user plane data to the core network device.

[0251] In one implementation, the second RAN device and / or core network device may further determine (or identify) the first UE based on the second information. The second information may include one or more of the following: the ID of the second RAN device, an identifier related to the first interface assigned to the first UE by the second RAN device (such as the RAN UE NGAP ID), or an identifier related to the first interface assigned to the first UE by the core network device (such as the AMF UE NGAP ID).

[0252] In another implementation, the second RAN device and / or core network device can also determine (or identify) the first UE based on third information. The third information may include one or more of the connection ID, stream ID, or path ID corresponding to the first UE. Alternatively, the first UE can be determined (or identified) based on one or more of the identifiers included in the second information and the identifiers included in the third information. For example, the core network device can determine the T-PDU context information of the first UE based on the second information and / or the third information.

[0253] S21: The core network equipment sends the sixth message. Correspondingly, the second RAN equipment (or the first RAN equipment (i.e., RAN1 shown in Figure 8B)) receives the sixth message.

[0254] The sixth piece of information is used to indicate the T-PDU context information stored in the core network equipment. This T-PDU context information includes T-PDU status information, information indicating the transport layer protocol used, and QUIC congestion control status information stored in the core network equipment. It should be understood that step S21 is optional and may not be performed.

[0255] S22: The second RAN device sends the first information. Correspondingly, the first RAN device receives the first information.

[0256] The first information is used to indicate the T-PDU context information of the first UE. The T-PDU context information may include T-PDU status information, information indicating the transport layer protocol used, and QUIC congestion control status information related to the first UE.

[0257] Optionally, the T-PDU context information may include T-PDU context information stored in the second RAN device and / or T-PDU context information stored in the core network device. For example, the T-PDU context information indicated by the first information may include QUIC congestion control status information stored in the second RAN device. As another example, in addition to the QUIC congestion control status information stored in the second RAN device, the T-PDU context information indicated by the first information may also include QUIC congestion control status information stored in the core network device, thus enabling the first RAN device to be aware of the downlink congestion situation.

[0258] In one possible implementation, the QUIC congestion control status information stored by the second RAN device or core network device may indicate (or include) one or more of the following:

[0259] g1, the congestion control algorithm used. For example, the congestion control algorithm can be a path delay-based congestion control algorithm, a packet loss-based congestion control algorithm, or a bandwidth delay detection-based congestion control algorithm.

[0260] g2, flow control level. For example, the flow control level can be either the stream level or the connection level.

[0261] g3, the number of available windows at the flow control level.

[0262] g4, the maximum number of windows for the flow control level.

[0263] g5, the maximum offset of the received data at the flow control level.

[0264] For example, if the flow control level is at the stream level, g3 to g5 above refer to the number of available windows, the maximum number of windows, and the maximum offset of received data at the stream level, respectively. Alternatively, if the flow control level is at the connection level, g3 to g5 above refer to the number of available windows, the maximum number of windows, and the maximum offset of received data at the connection level, respectively.

[0265] It should be understood that, in addition to the above, QUIC congestion control status information may also indicate (or include) other congestion control related information, without specific limitations.

[0266] As mentioned above, the QUIC protocol supports multiple paths, multiple connections, and multiple streams. Correspondingly, the granularity of T-PDU status information can be any of the following: PDU session, QoS flow, path, connection, or stream. That is, T-PDU status information can be the T-PDU status information for each PDU session; or, the T-PDU status information for each QoS flow of each PDU session; or, the T-PDU status information for each connection; or, the T-PDU status information for each stream of each connection; or, the T-PDU status information for each path of each connection; or, the T-PDU status information for each stream of each path of each connection.

[0267] In some embodiments, the second RAN device may also send third information to the first RAN device, thereby allowing the first RAN device to determine the T-PDU context information of the first UE based on the third information. Alternatively, the third information may be sent by the core network device or by the first UE to the first RAN device; there are no specific limitations.

[0268] S23: The first UE performs an air interface handover, switching from a communication connection with the second RAN device to a communication connection with the first RAN device.

[0269] S24: The first RAN device sends the second and / or third information. Correspondingly, the core network device receives the second and / or third information. It should be understood that step S24 is optional and may not be performed.

[0270] S25: The first RAN device and / or core network device perform congestion control based on QUIC congestion control status information. For example, the first RAN device can perform uplink congestion control based on QUIC congestion control status information related to uplink transmission, or the core network device can perform downlink congestion control based on QUIC congestion control status information related to downlink transmission.

[0271] Based on this implementation method, the first RAN device and / or core network device inherit the QUIC congestion control status information before the switchover to perform congestion control, without having to start from scratch, ensuring the continuity of the congestion control function, avoiding the problem of reduced data volume caused by starting from scratch, and reducing the probability of network lag.

[0272] The above example illustrates the introduction of the QUIC or TCP protocol into the user plane interface protocol stack. However, it should be understood that, in addition to the QUIC or TCP protocol, other protocols that support congestion control functions can also be introduced into the user plane interface protocol stack. Furthermore, the continuity of congestion control functions before and after handover can be improved based on the above-described approach.

[0273] Figure 9 shows a schematic diagram of the structure of an apparatus provided in an embodiment of this application. The communication device 900 can be the first RAN device or its circuit system as shown in the embodiments of Figures 3, 4, 6B, or 8B, used to implement the method corresponding to the first RAN device in the above method embodiments. Alternatively, the communication device 900 can be the second RAN device or its circuit system as shown in the embodiments of Figures 3, 4, 6B, or 8B, used to implement the method corresponding to the second RAN device in the above method embodiments. Alternatively, the communication device 900 can be the core network device or its circuit system as shown in the embodiments of Figures 3, 4, 6B, or 8B, used to implement the method corresponding to the core network device in the above method embodiments. For example, one type of circuit system is a chip system.

[0274] The communication device 900 includes at least one processor 901. The processor 901 can be used for internal processing within the device to implement certain control processing functions. Optionally, the processor 901 includes instructions. Optionally, the processor 901 can store data. Optionally, different processors can be independent devices, located in different physical locations, or located on different integrated circuits. Optionally, different processors can be integrated into one or more processors, for example, integrated on one or more integrated circuits.

[0275] Optionally, the communication device 900 includes one or more memories 903 for storing instructions. Optionally, the memories 903 may also store data. The processor and the memories may be separate or integrated together.

[0276] Optionally, the communication device 900 includes a communication line 902 and at least one communication interface 904. Since the memory 903, communication line 902, and communication interface 904 are all optional, they are all represented by dashed lines in Figure 9.

[0277] Optionally, the communication device 900 may further include a transceiver and / or an antenna. The transceiver can be used to send information to or receive information from other devices. The transceiver may be referred to as a transceiver unit, transceiver circuit, input / output interface, etc., and is used to realize the transmission and reception functions of the communication device 900 via the antenna. Optionally, the transceiver includes a transmitter and a receiver. For example, the transmitter can be used to generate a radio frequency (RF) signal from a baseband signal, and the receiver can be used to convert the RF signal back into a baseband signal.

[0278] The processor 901 may include a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of programs according to the present application.

[0279] Communication line 902 may include a path for transmitting information between the aforementioned components.

[0280] Communication interface 904 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area network (WLAN), wired access network, etc.

[0281] Memory 903 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Memory 903 may exist independently and be connected to processor 901 via communication line 902. Alternatively, memory 903 may be integrated with processor 901.

[0282] The memory 903 stores computer execution instructions for implementing the present application's solution, and its execution is controlled by the processor 901. The processor 901 executes the computer execution instructions stored in the memory 903, thereby implementing the steps performed by the network device or UE in the embodiment shown in FIG3.

[0283] Optionally, the computer execution instructions in the embodiments of this application may also be referred to as application code, and the embodiments of this application do not specifically limit this.

[0284] In a specific implementation, as one example, processor 901 may include one or more CPUs, such as CPU0 and CPU1 in FIG9.

[0285] In a specific implementation, as one embodiment, the communication device 900 may include multiple processors, such as processors 901 and 905 in FIG. 9. Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. Here, a processor may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0286] When the device shown in Figure 9 is a chip, such as a chip for a network device or a UE, the chip includes a processor 901 (and may also include a processor 905), a communication line 902, and a communication interface 904. Optionally, it may include a memory 903. Specifically, the communication interface 904 may be an input interface, pins, or circuits, etc. The memory 903 may be a register, cache, etc. The processor 901 and processor 905 may be a general-purpose CPU, microprocessor, ASIC, or one or more integrated circuits for controlling the execution of a program that controls the communication method of any of the above embodiments.

[0287] This application embodiment can divide the device into functional modules according to the above method examples. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware or software functional modules. The module division in this application embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods. For example, when dividing the device into functional modules according to each function, Figure 10 is a schematic diagram of a device. This device 1000 can be the first RAN device, the second RAN device, or the core network device involved in the above method embodiments, or it can be a chip in the first RAN device, the second RAN device, or the core network device. The device 1000 includes a processing unit 1002 and a transceiver unit 1001.

[0288] It should be understood that the device 1000 can be used to implement the steps performed by the first RAN device, the second RAN device, or the core network device in the communication method of the embodiments of this application. The relevant features can be referred to the embodiment shown in Figure 3 above, and will not be repeated here.

[0289] Optionally, the functions / implementation processes of the transceiver unit 1001 and processing unit 1002 in Figure 10 can be implemented by the processor 901 in Figure 9 calling computer execution instructions stored in memory 903. Alternatively, the functions / implementation processes of the processing unit 1002 in Figure 10 can be implemented by the processor 901 in Figure 9 calling computer execution instructions stored in memory 903, and the functions / implementation processes of the transceiver unit 1001 in Figure 10 can be implemented by the communication interface 904 in Figure 9.

[0290] Optionally, when the device 1000 is a chip or circuit, the function / implementation process of the transceiver unit 1001 can also be implemented through pins or circuits, etc. Optionally, the transceiver unit 1001 may include a transmitting unit and / or a receiving unit, whereby the transmitting unit implements the transmitting function and the receiving unit implements the receiving function; or, the transceiver unit 1001 may be an integral module capable of implementing both transmitting and / or receiving functions. Optionally, the transceiver unit 1001 can be implemented using a transceiver.

[0291] This application also provides a computer-readable storage medium storing a computer program or instructions that, when executed, implement the methods performed by the first RAN device, the second RAN device, or the core network device in the aforementioned method embodiments. Thus, the functions described in the above embodiments can be implemented as software functional units and sold or used as independent products. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to it, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0292] This application also provides a computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform the method executed by the first RAN device, the second RAN device, or the core network device in any of the foregoing method embodiments.

[0293] This application also provides a processing apparatus, including a processor and an interface; the processor is used to execute the methods performed by the first RAN device, the second RAN device, or the core network device involved in any of the above method embodiments.

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

[0295] The various illustrative logic units and circuits described in the embodiments of this application can be implemented or operate the described functions using a general-purpose processor, digital signal processor (DSP), ASIC, field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof. The general-purpose processor can be a microprocessor; alternatively, it can be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented using a combination of computing devices, such as a digital signal processor and a microprocessor, multiple microprocessors, one or more microprocessors combined with a digital signal processor core, or any other similar configuration.

[0296] The steps of the methods or algorithms described in the embodiments of this application can be directly embedded in hardware, software units executed by a processor, or a combination of both. The software units can be stored in RAM, flash memory, ROM, erasable programmable read-only memory (EPROM), EEPROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium in the art. Exemplarily, the storage medium can be connected to the processor so that the processor can read information from the storage medium and write information to the storage medium. Optionally, the storage medium can also be integrated into the processor. The processor and storage medium can be disposed in an ASIC, which can be disposed in the terminal device. Optionally, the processor and storage medium can also be disposed in different components of the terminal device.

[0297] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0298] The contents of the various embodiments of this application can be referenced to each other. Unless otherwise specified or there is a logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced to each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0299] It is understood that in the embodiments of this application, the network device and / or UE may perform some or all of the steps in the embodiments of this application. These steps or operations are merely examples. In the embodiments of this application, other operations or variations of various operations may also be performed. Furthermore, the steps may be performed in different orders as presented in the embodiments of this application, and it is not necessary to perform all the operations in the embodiments of this application.

Claims

1. A communication method, characterized in that, Applied to a first access network device, the method includes: Receive first information, the first information being used to indicate the user plane protocol data unit (T-PDU) context information of the first terminal device; Establish a communication connection with the first terminal device; User plane data transmission is performed between the user plane and the core network device based on the T-PDU context information.

2. The method according to claim 1, characterized in that, The T-PDU context information includes one or more of the following: The T-PDU status information of the first terminal device; or, The transport layer protocol used by the second access network device and the core network device to transmit user plane data.

3. The method according to claim 2, characterized in that, The T-PDU status information includes one or more of the following: The sequence numbers of the lost downlink T-PDU and / or uplink T-PDU; The sequence number of the first lost downlink T-PDU and / or uplink T-PDU; Receive status information of at least one downlink T-PDU and / or at least one uplink T-PDU; The sequence number of the downlink T-PDU and / or uplink T-PDU that needs to be retransmitted; The sequence number of the next downlink T-PDU that the core network device needs to transmit; The sequence number of the next uplink T-PDU that the second access network device needs to transmit; The sequence number of the last uplink T-PDU sent by the second access network device; or, The sequence number of the last downlink T-PDU transmitted by the core network device.

4. The method according to claim 3, characterized in that, The step of performing user plane data transmission with the core network device based on the T-PDU context information includes: Send a first uplink T-PDU, the first uplink T-PDU being the lost uplink T-PDU; and / or, Send a second uplink T-PDU, the sequence number of which is greater than or equal to the sequence number of the next uplink T-PDU.

5. The method according to any one of claims 2 to 4, characterized in that, The T-PDU status information is any one of the following: T-PDU status information for each PDU session; or, T-PDU status information for each Quality of Service (QoS) flow in each PDU session.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Receive the second information, and determine the T-PDU context information of the first terminal device based on the second information; The second information includes one or more of the following: The identifier of the second access network device; The second access network device assigns an identifier related to the first interface to the first terminal device, where the first interface is the interface between the second access network device and the core network device; or, The core network device assigns an identifier related to the first interface to the first terminal device.

7. The method according to any one of claims 2 to 5, characterized in that, The transport layer protocol includes a first transport layer protocol, which is a protocol that supports congestion control. The T-PDU context information also includes congestion control status information related to the first terminal device. The congestion control status information is used to control user plane data transmission with the core network device. The method further includes: Congestion control is performed based on the congestion control status information.

8. The method according to claim 7, characterized in that, The first transport layer protocol is Transmission Control Protocol (TCP), and the congestion control status information indicates one or more of the following: The current TCP congestion control phase; The retransmission mechanism used; Number of sending windows; Congestion window count; or, Number of receive windows.

9. The method according to claim 7, characterized in that, The first transport layer protocol is the Fast UDP Internet Connection (QUIC) protocol, and the congestion control status information indicates one or more of the following: The congestion control algorithm used; Flow control level; The number of available windows at the flow control level; Maximum number of windows for the flow control level; or, The maximum offset of the received data at the flow control level.

10. The method according to claim 9, characterized in that, The T-PDU status information is any one of the following: T-PDU status information for each connection; T-PDU status information for each session stream of each connection; T-PDU status information for each path of each connection; or, T-PDU status information for each session stream of each path for each connection.

11. The method according to claim 9 or 10, characterized in that, The method further includes: Receive third information and determine the T-PDU context information of the first terminal device based on the third information; The third information includes one or more of the following: The connection identifier corresponding to the first terminal device; The session stream identifier corresponding to the first terminal device; or, The path identifier corresponding to the first terminal device.

12. A communication method, characterized in that, Applied to core network devices, the method includes: Receive fourth information, the fourth information being used to instruct the retention of the T-PDU context information of the first terminal device; Based on the T-PDU context information, user plane data transmission is performed with the first access network device.

13. The method according to claim 12, characterized in that, The T-PDU context information includes one or more of the following: The T-PDU status information of the first terminal device; or, The transport layer protocol used by the second access network device and the core network device to transmit user plane data.

14. The method according to claim 13, characterized in that, The T-PDU status information includes one or more of the following: The sequence numbers of the lost downlink T-PDU and / or uplink T-PDU; The sequence number of the first lost downlink T-PDU and / or uplink T-PDU; Receive status information of at least one downlink T-PDU and / or at least one uplink T-PDU; The sequence number of the downlink T-PDU and / or uplink T-PDU that needs to be retransmitted; The sequence number of the next downlink T-PDU that the core network device needs to transmit; The sequence number of the next uplink T-PDU that the second access network device needs to transmit; The sequence number of the last uplink T-PDU sent by the second access network device; or, The sequence number of the last downlink T-PDU transmitted by the core network device.

15. The method according to claim 14, characterized in that, The step of performing user plane data transmission with the first access network device based on the T-PDU context information includes: Send a first downlink T-PDU, the first downlink T-PDU being the lost downlink T-PDU; and / or, Send a second downlink T-PDU, the sequence number of which is greater than or equal to the sequence number of the next downlink T-PDU.

16. The method according to any one of claims 13 to 15, characterized in that, The T-PDU status information is any one of the following: T-PDU status information for each PDU session; or, T-PDU status information for each QoS flow in each PDU session.

17. The method according to any one of claims 12 to 16, characterized in that, The method further includes: Based on the second information, the T-PDU context information of the first terminal device is determined; The second information includes one or more of the following: The identifier of the second access network device; The second access network device assigns an identifier related to the first interface to the first terminal device, where the first interface is the interface between the second access network device and the core network device; or, The core network device assigns an identifier related to the first interface to the first terminal device.

18. The method according to any one of claims 13 to 16, characterized in that, The transport layer protocol includes a first transport layer protocol, which is a protocol that supports congestion control. The T-PDU context information also includes congestion control status information related to the first terminal device. The congestion control status information is used to control user plane data transmission with the second access network device. The method further includes: Congestion control is performed based on the congestion control status information.

19. The method according to claim 18, characterized in that, The first transport layer protocol is TCP, and the congestion control status information indicates one or more of the following: Currently in the TCP congestion control phase; The retransmission mechanism used; Number of sending windows; Congestion window count; or, Number of receive windows.

20. The method according to claim 18, characterized in that, The first transport layer protocol is the QUIC protocol, and the congestion control status information indicates one or more of the following: The congestion control algorithm used; Flow control level; The number of available windows at the flow control level; Maximum number of windows for the flow control level; or, The maximum offset of the received data at the flow control level.

21. The method according to claim 20, characterized in that, The T-PDU status information may also be any of the following: T-PDU status information for each connection; T-PDU status information for each session stream of each connection; T-PDU status information for each path of each connection; or, T-PDU status information for each session stream of each path for each connection.

22. The method according to claim 20 or 21, characterized in that, The method further includes: Based on the third information, the T-PDU context information of the first terminal device is determined; wherein the third information includes one or more of the following: The connection identifier corresponding to the first terminal device; The stream identifier corresponding to the first terminal device; or, The path identifier corresponding to the first terminal device.

23. A communication method, characterized in that, Applied to a second access network device, the method includes: Send first information to a first access network device, the first information being used to indicate the T-PDU context information of the first terminal device; wherein, the first terminal device switches from a communication connection with the second access network device to a communication connection with the first access network device.

24. The method according to claim 23, characterized in that, The method further includes: Send a fourth message to the core network device, the fourth message being used to instruct the retention of the T-PDU context information of the first terminal device.

25. The method according to claim 23 or 24, characterized in that, The T-PDU context information includes one or more of the following: The T-PDU status information of the first terminal device; or, The transport layer protocol used by the second access network device and the core network device to transmit user plane data.

26. The method according to claim 25, characterized in that, The T-PDU status information includes one or more of the following: The sequence numbers of the lost downlink T-PDU and / or uplink T-PDU; The sequence number of the first lost downlink T-PDU and / or uplink T-PDU; Receive status information of at least one downlink T-PDU and / or at least one uplink T-PDU; The sequence number of the downlink T-PDU and / or uplink T-PDU that needs to be retransmitted; The sequence number of the next downlink T-PDU that the core network device needs to transmit; The sequence number of the next uplink T-PDU that the second access network device needs to transmit; The sequence number of the last uplink T-PDU sent by the second access network device; or, The sequence number of the last downlink T-PDU transmitted by the core network device.

27. The method according to claim 25 or 26, characterized in that, The T-PDU status information is any one of the following: T-PDU status information for each PDU session; or, T-PDU status information for each QoS flow in each PDU session.

28. The method according to any one of claims 25-27, characterized in that, The transport layer protocol includes a first transport layer protocol, which is a protocol that supports congestion control. The T-PDU context information also includes congestion control status information related to the first terminal device. The congestion control status information is used to control user plane data transmission with the core network device.

29. The method according to claim 28, characterized in that, The first transport layer protocol is TCP, and the congestion control status information indicates one or more of the following: Currently in the TCP congestion control phase; The retransmission mechanism used; Number of sending windows; Congestion window count; or, Number of receive windows.

30. The method according to claim 28, characterized in that, The first transport layer protocol is the QUIC protocol, and the congestion control status information indicates one or more of the following: The congestion control algorithm used; Flow control level; The number of available windows at the flow control level; Maximum number of windows for the flow control level; or, The maximum offset of the received data at the flow control level.

31. The method according to claim 30, characterized in that, The T-PDU status information may also be any of the following: T-PDU status information for each connection; T-PDU status information for each session stream of each connection; T-PDU status information for each path of each connection; or, T-PDU status information for each session stream of each path for each connection.

32. A communication device, characterized in that, The communication device includes a module for performing the method as described in any one of claims 1 to 11, or a module for performing the method as described in any one of claims 12 to 22, or a module for performing the method as described in any one of claims 23 to 31.

33. A communication device, characterized in that, The communication device includes a processor, which is configured to perform the method as described in any one of claims 1 to 11, or the method as described in any one of claims 12 to 22, or the method as described in any one of claims 23 to 31.

34. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program that, when run on a computer, causes the method as described in any one of claims 1 to 11 to be performed, or causes the method as described in any one of claims 12 to 22 to be performed, or causes the method as described in any one of claims 23 to 31 to be performed.

35. A computer program product, characterized in that, The computer program product includes a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 11, or causes the computer to perform the method as described in any one of claims 12 to 22, or causes the computer to perform the method as described in any one of claims 23 to 31.

Images