Data transmission method and communication device

Abstract

This application provides a data transmission method and communication apparatus, applicable to scenarios where at least one service bearer of a terminal device is migrated from a first network device to a second network device. The method includes: the second network device receiving a first data stream from at least one service bearer of the first network device. The first data stream comprises a plurality of data packets arranged consecutively in ascending order of PDCP sequence numbers, with the starting data packet being the first data packet sent by the first network device to the terminal device but for which no acknowledgment instruction has been received from the terminal device; the second network device then sends a second data stream to the terminal device based on the first data stream. The second data stream comprises a plurality of data packets arranged consecutively in ascending order of PDCP sequence numbers. Using this application embodiment, the terminal device can obtain a continuous and complete data stream during or after the service bearer migration process.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a data transmission method and communication device. Background Technology

[0002] In mobile communication systems, the coverage area of ​​a base station is limited. When a terminal device moves from the coverage area of ​​one base station to the coverage area of ​​another, at least one service bearer can be migrated to the other base station to ensure the quality of service (QoS) of data transmission on that service bearer. The base station the terminal device was connected to before the migration can be called the source base station, and the base station it is connected to after the migration can be called the target base station. The process of migrating all the terminal device's service bearers to the target base station is also called the handover process between different base stations. After the handover is completed, the terminal device releases the resources allocated by the source base station.

[0003] During the migration of at least one service bearer, the source base station can perform a data forwarding process with the target base station to send service data that the source base station has not yet sent or has not successfully sent to the terminal device to the terminal device. However, how to perform data forwarding is a technical problem that needs to be solved. Summary of the Invention

[0004] This application provides a data transmission method and communication device that enables data forwarding in scenarios involving service migration, allowing terminal devices to obtain continuous and complete data streams.

[0005] This application provides a data transmission method applicable to a scenario where at least one service bearer of a terminal device is migrated from a first network device to a second network device. The method can be executed by the second network device or by a device within the second network device (e.g., a processor or chip). Taking the second network device as an example, the method includes the following:

[0006] The second network device receives a first data stream from at least one service bearer from the first network device. The first data stream includes multiple data packets arranged in ascending order of Packet Data Convergence Protocol (PDCP) sequence numbers. Based on the first data stream, the second data stream is sent to the terminal device. The second data stream includes multiple data packets arranged in ascending order of PDCP sequence numbers.

[0007] The first data stream includes the first data packet that the first network device has sent to the terminal device but has not received an acknowledgment instruction from the terminal device; the first data stream includes data packets that the first network device has sent to the terminal device but has not received an acknowledgment instruction from the terminal device and data packets that the first network device has sent to the terminal device and has received an acknowledgment instruction from the terminal device.

[0008] In the first aspect of this application, during the migration of service bearers, the second network device sends a data stream to the terminal device based on the data stream continuously forwarded by the first network device, which can ensure that the terminal device receives a continuous and complete data stream and reduce data packet loss.

[0009] In one possible implementation, the second network device sends a first indication message to the first network device. This first indication message indicates a forwarding rule: data packets are forwarded continuously in ascending order of PDCP sequence numbers. This forwarding rule can be understood as a continuous data forwarding rule. The second network device instructs the first network device to perform continuous data forwarding through the first indication message, ensuring that the second and first network devices have a consistent understanding of how to forward data. This allows the terminal device to receive a continuous and complete data stream during or after the migration of service bearer operations.

[0010] In one possible implementation, the second network device receives a request message from the first network device. This request message indicates a forwarding rule: data packets are forwarded continuously in ascending order of PDCP sequence numbers. Understandably, the first network device requests continuous data forwarding via the request message. If the second network device agrees, the first network device performs continuous data forwarding, sending a first data stream to the second network device. The second network device then sends a second data stream to the terminal device based on the first data stream. This ensures that the second and first network devices have a consistent understanding of how to perform data forwarding, allowing the terminal device to receive a continuous and complete data stream during or after the service migration process.

[0011] In one possible implementation, the second network device sends a second indication message to the first network device. The second indication message is used to instruct the terminal device to discard data packets that were directly received from the first network device and stored in the PDCP receive buffer before accessing the second network device. This is so that when the terminal device receives a second data stream from the second network device, it can determine the data stream stored in the PDCP receive buffer based on the second data stream, thereby avoiding the terminal device receiving duplicate data packets.

[0012] The first and second instruction information mentioned above can be sent in the same message, for example, in a handover request confirmation message during a mobile handover process.

[0013] In one possible implementation, the second network device receives status report information from the terminal device, the status report information including a reference PDCP sequence number, which is the PDCP sequence number of the first data packet from the first network device that the terminal device has not received; generates a second data stream, the second data stream including the data stream from the first data stream starting with the data packet with the reference PDCP sequence number; and sends the second data stream to the terminal device. The second network device generates the second data stream based on the reference PDCP sequence number and sends the second data stream to the terminal device, thus avoiding the second network device sending data packets that the terminal device has already received to the terminal device.

[0014] In one possible implementation, the second data stream sent from the second network device to the terminal device is a data stream that has undergone PDCP layer compression processing on the second network device. This PDCP layer compression of the second data stream enables data forwarding during the migration process and allows the terminal device to receive a continuous and complete data stream. Furthermore, the compression mechanism is applied to the service migration process to achieve efficient data transmission with continuous data forwarding.

[0015] In one possible implementation, the second network device receives a first threshold from the first network device, and sends a third data stream to the terminal device based on the first data stream and the first threshold. The PDCP sequence number of the data packets in the third data stream is less than or equal to the first threshold, and the third data stream is a data stream that has not undergone PDCP layer compression processing in the second network device. When the terminal device receives the third data stream, it does not need to decompress it and directly submits it to the protocol layer above the PDCP layer to improve processing efficiency.

[0016] In one possible implementation, the second network device sends a third indication message to the terminal device. This third indication message indicates a second threshold. Data packets in the second data stream with PDCP sequence numbers greater than or equal to the second threshold are data packets that have undergone PDCP layer compression processing by the second network device. The second network device uses the third indication message to inform the terminal device that data packets with PDCP sequence numbers starting from the second threshold are data packets that have undergone PDCP layer compression processing. This allows the terminal device to directly and explicitly perform PDCP layer decompression processing based on the second threshold, eliminating the need for multiple attempts to determine from which data packet to begin decompression processing.

[0017] In one possible implementation, the second data stream sent by the second network device to the terminal device is a data stream that has not undergone PDCP layer compression processing on the second network device. The PDCP sequence number of the starting data packet in the second data stream is the same as the PDCP sequence number of the starting data packet in the first data stream. It is understood that the second network device forwards the entire first data stream received from the first network device to the terminal device without performing PDCP layer compression processing on the forwarded first data stream. This way, when the terminal device receives the data stream forwarded by the second network device, it does not need to perform PDCP layer decompression processing on the data stream, which can improve processing efficiency.

[0018] A second aspect of this application provides a data transmission method applied to a scenario where at least one service bearer of a terminal device is migrated from a first network device to a second network device. The method can be executed by the terminal device or by a device within the terminal device (e.g., a processor or chip). The method includes the following:

[0019] The terminal device receives a second indication information from the first network device, and according to the second indication information, discards the data packets received from the first network device and stored in the PDCP receive buffer before accessing the second network device; receives a second data stream from the second network device, the second data stream including multiple data packets ordered in ascending order of PDCP sequence number; determines a first data stream to be saved according to the second data stream; and saves the first data stream to be saved in the PDCP receive buffer.

[0020] In a second aspect of this application, the terminal device discards data packets according to the second instruction information, thereby avoiding the terminal device receiving duplicate data packets. Since the second data stream includes multiple consecutive data packets ordered in ascending order of PDCP sequence numbers, the terminal device does not need to reorder them and can quickly obtain a continuous and complete data stream.

[0021] In one possible implementation, the terminal device updates the PDCP count of the next expected data packet to the PDCP count of the first data packet waiting to be delivered to a protocol layer above the PDCP layer, based on the dropped data packet, so that the terminal device can normally receive the second data stream from the second network device.

[0022] In one possible implementation, the terminal device sends a status report to the second network device. This status report includes a reference PDCP sequence number, which is the PDCP sequence number of the first data packet from the first network device that the terminal device has not yet received. Thus, the PDCP sequence number of the starting data packet in the second data stream received by the terminal device from the second network device is the reference PDCP sequence number. This can be understood as the second network device sending the second data stream to the terminal device based on the status report information, thereby avoiding the second network device sending data packets that the terminal device has already received.

[0023] In one possible implementation, the second data stream received by the terminal device from the second network device is a data stream that has undergone PDCP layer compression processing on the second network device. The terminal device performs PDCP layer decompression processing on the second data stream in ascending and consecutive order of PDCP sequence numbers to obtain the first data stream to be saved. Even if the second data stream is a data stream that has undergone PDCP layer compression processing on the second network device, the terminal device can still obtain the complete data stream by performing corresponding PDCP layer decompression processing on the terminal device, thereby reducing data packet loss.

[0024] In one possible implementation, the terminal device receives a third data stream from a second network device. This third data stream is a data stream that has not undergone PDCP layer compression processing on the second network device. The terminal device discards data packets in the third data stream that are identical to data packets stored in the PDCP receive buffer, obtaining a second data stream to be stored, and stores the second data stream in the PDCP receive buffer. This avoids the terminal device receiving duplicate data packets.

[0025] In one possible implementation, the terminal device receives third indication information from the second network device. This third indication information indicates a second threshold. Data packets in the second data stream with PDCP sequence numbers greater than or equal to the second threshold are data packets that have undergone PDCP layer compression processing by the second network device. Following a sequential order of ascending PDCP sequence numbers, the data packets in the second data stream corresponding to PDCP sequence numbers greater than or equal to the second threshold are decompressed using the PDCP layer to obtain a first data stream to be saved. The second network device uses the third indication information to inform the terminal device from which data packet the PDCP layer compression processing should begin, so that the terminal device can perform the corresponding PDCP layer decompression processing without having to repeatedly try to determine which data packet to start the decompression process from.

[0026] In one possible implementation, the second data stream received by the terminal device from the second network device is a data stream that has not undergone PDCP layer compression processing in the second network device, so that the terminal device does not need to perform PDCP layer decompression processing.

[0027] A third aspect of this application provides a data transmission method applied to a scenario where at least one service bearer of a terminal device is migrated from a first network device to a second network device. This method can be executed by the first network device or by a device within the first network device (e.g., a processor or chip). Taking the first network device as an example, the method includes the following:

[0028] The first network device sends a migration request to the second network device, the migration request being used to request the migration of at least one service bearer of the terminal device from the first network device to the second network device; receives a migration request confirmation from the second network device, and sends a first data stream to the second network device, the first data stream including multiple data packets ordered in ascending order of PDCP sequence number;

[0029] The first data stream includes the first data packet that the first network device has sent to the terminal device but has not received an acknowledgment instruction from the terminal device; the first data stream includes data packets that the first network device has sent to the terminal device but has not received an acknowledgment instruction from the terminal device and data packets that the first network device has sent to the terminal device and has received an acknowledgment instruction from the terminal device.

[0030] In a third aspect of this application, the first network device performs continuous data forwarding and sends a first data stream to the second network device so that the second network device can forward the data stream to the terminal device without loss, thereby ensuring that the terminal device receives a continuous and complete data stream and reducing data packet loss.

[0031] Among them, the migration request can be a handover request message during the mobile handover process, and the migration request confirmation can be a handover request confirmation message; the migration request can also be a traffic offloading request message during the traffic offloading process, such as a secondary base station addition request message, and the migration request confirmation can be a traffic offloading request confirmation message, such as a secondary base station addition confirmation message.

[0032] In one possible implementation, the first network device receives first indication information from the second network device. This first indication information indicates a forwarding rule: data packets are forwarded continuously in ascending order of PDCP sequence numbers. The second network device uses the first indication information to instruct the first network device to perform continuous data forwarding, ensuring that the second and first network devices have a consistent understanding of how to forward data. This allows the terminal device to receive a continuous and complete data stream during or after the migration of service bearer operations.

[0033] The first instruction information can be included in the migration request confirmation.

[0034] In one possible implementation, the first network device sends a request message to the second network device. This request message indicates a forwarding rule: data packets are forwarded continuously in ascending order of PDCP sequence numbers. By requesting continuous data forwarding, the first network device ensures that the second and first network devices have a consistent understanding of how to perform data forwarding, allowing the terminal device to receive a continuous and complete data stream during or after the service migration process. Optionally, upon receiving a response message from the second network device, the first network device performs continuous data forwarding. The response message acknowledges the request message and indicates that the second network device agrees to the first network device's request for continuous data forwarding.

[0035] The request message can be the migration request mentioned above, or the request message can be carried in the migration request mentioned above.

[0036] In one possible implementation, the first network device receives second indication information from the second network device and sends the second indication information to the terminal device. The second indication information is used to instruct the terminal device to discard data packets received from the first network device and stored in the PDCP receive buffer before accessing the second network device, so as to avoid the terminal device receiving duplicate data packets.

[0037] In one possible implementation, the first network device sends a first threshold to the second network device. This first threshold limits the PDCP sequence number of data packets in the third data stream sent by the second network device to the terminal device to be less than or equal to the first threshold. The third data stream is a data stream that has not undergone PDCP layer compression processing by the second network device. This way, when the terminal device receives the third data stream, it does not need to decompress it and can directly deliver it to a protocol layer above the PDCP layer, thereby improving processing efficiency.

[0038] A fourth aspect of this application provides a data transmission method applied to a scenario where at least one service bearer of a terminal device is migrated from a first network device to a second network device. The method can be executed by the second network device or by a device (e.g., a processor or chip) within the second network device. Taking the second network device as an example, the method includes:

[0039] The second network device receives compressed cache information from the first network device; based on the compressed cache information, it performs PDCP layer compression processing on the first data stream on at least one service bearer to obtain a second data stream; and sends the second data stream to the terminal device; wherein the first data stream originates from the first network device.

[0040] In a fourth aspect of this application, the first network device directly sends its compression cache information to the second network device so that the second network device can use the compression cache information to perform PDCP layer compression processing on the first data stream. This makes the compression cache information used by the second network device match the decompression cache information used by the terminal device. When the terminal device receives the second data stream from the second network device, it can successfully perform PDCP layer decompression processing. Thus, during the migration process of applying the compression mechanism to service bearer, lossless data transmission can be achieved, avoiding the loss or damage of data packets.

[0041] In one possible implementation, the second network device receives status report information from the terminal device, which includes the PDCP sequence numbers of data packets from the first network device that the terminal device did not receive. Based on compression buffer information and the status report information, the second network device performs PDCP layer compression processing on the first data stream. By performing PDCP layer compression processing based on the status report information from the terminal device and the compression buffer information from the first network device, the second network device can avoid the terminal device receiving duplicate data packets, and the terminal device can successfully perform PDCP layer decompression processing.

[0042] In one possible implementation, the second network device sends an instruction to the first network device, instructing the terminal device to maintain decompression cache information corresponding to the compressed cache information. The first network device can then send this instruction to the terminal device, so that the terminal device uses the same decompression cache information for data packets from the second network device as it uses for data packets from the first network device, enabling the terminal device to quickly obtain data packets from the second network device.

[0043] In one possible implementation, the second network device receives a first threshold from the first network device. The first threshold is used to indicate the PDCP sequence number of the first data packet that the first network device performs PDCP layer compression processing based on the compression cache information, so that the terminal device performs PDCP layer decompression processing based on the decompression cache information corresponding to the compression cache information according to the first threshold.

[0044] In one possible implementation, the second network device sends a third data stream to the terminal device. The PDCP sequence number of the data packets in the third data stream is less than or equal to a first threshold. The third data stream is a data stream that has not undergone PDCP layer compression processing in the second network device. In this way, the first threshold is used to identify the data stream that does not need to be decompressed, thereby improving processing efficiency.

[0045] A fifth aspect of this application provides a data transmission method applied to a scenario where at least one service bearer of a terminal device is migrated from a first network device to a second network device. This method can be executed by the terminal device or by a device within the terminal device (e.g., a processor or chip). Taking a terminal device as an example, the method includes:

[0046] The terminal device receives a second data stream from a second network device. The second data stream is a data stream obtained by performing PDCP layer compression processing on the first data stream based on compression buffer information. The second data stream is decompressed to obtain a first data stream to be saved. The first data stream to be saved is saved in the PDCP receive buffer.

[0047] In a fifth aspect of this application, since the compressed cache information used by the second network device is the same as that used by the first network device, the terminal device does not need to redetermine the decompressed cache information and can quickly obtain data packets from the second network device. Furthermore, during the migration process in which the compression mechanism is applied to service carrying, lossless data transmission can be achieved, avoiding the loss or damage of data packets.

[0048] In one possible implementation, the terminal device sends status report information to the second network device. The status report information includes the PDCP sequence number of data packets from the first network device that the terminal device has not received, so that the second network device can send a second data stream to the terminal device based on the status report information.

[0049] In one possible implementation, the terminal device maintains decompression cache information corresponding to the compressed cache information according to the received instruction information; based on the decompression cache information, it decompresses the first data stream to obtain a first data stream to be saved. This ensures that the decompression cache information used by the terminal device matches the compressed cache information used by the second network device, allowing the terminal device to quickly obtain a continuous and complete data stream.

[0050] In one possible implementation, the terminal device receives a third data stream from the second network device. The third data stream is a data stream that has not undergone PDCP layer compression processing in the second network device. The third data stream is stored in the PDCP receive buffer without decompression processing, which can improve the processing efficiency of the third data stream.

[0051] A sixth aspect of this application provides a communication device, which may be a second network device or a device within a second network device. In one design, the device may include a module corresponding to performing the methods / operations / steps / actions described in the first or fourth aspect and various possible implementations. This module may be hardware circuitry, software, or a combination of hardware circuitry and software implementation. In another design, the device may include a receiving module and a transmitting module.

[0052] For example,

[0053] The receiving module is configured to receive a first data stream from at least one service bearer of a first network device, the first data stream comprising a plurality of data packets arranged in ascending order of PDCP sequence number;

[0054] The sending module is used to send a second data stream to the terminal device according to the first data stream; the second data stream includes multiple data packets ordered in ascending order of PDCP sequence number;

[0055] The first data stream includes the first data packet that the first network device has sent to the terminal device but has not received an acknowledgment instruction from the terminal device; the first data stream includes data packets that the first network device has sent to the terminal device but has not received an acknowledgment instruction from the terminal device and data packets that the first network device has sent to the terminal device and has received an acknowledgment instruction from the terminal device.

[0056] A seventh aspect of this application provides a communication device, which includes a processor for implementing the methods described in the first or fourth aspect above. The device may further include a memory for storing instructions and data. The memory is coupled to the processor, and when the processor executes the instructions stored in the memory, it enables the device to implement the methods described in the first aspect and its various possible implementations, or the fourth aspect and its various possible implementations. The device may also include a communication interface for communicating with other devices. For example, the communication interface may be a transceiver, a bus, or other circuit hardware module, and the other devices may be terminal devices, etc. In one possible design, the device includes:

[0057] Memory, used to store program instructions;

[0058] A processor is configured to receive a first data stream from at least one service bearer of a first network device, the first data stream comprising a plurality of data packets arranged consecutively in ascending order of PDCP sequence numbers; and to send a second data stream to a terminal device based on the first data stream; the second data stream comprising a plurality of data packets arranged consecutively in ascending order of PDCP sequence numbers.

[0059] The first data stream includes the first data packet that the first network device has sent to the terminal device but has not received an acknowledgment instruction from the terminal device; the first data stream includes data packets that the first network device has sent to the terminal device but has not received an acknowledgment instruction from the terminal device and data packets that the first network device has sent to the terminal device and has received an acknowledgment instruction from the terminal device.

[0060] The eighth aspect of this application provides a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the methods provided by the first aspect and various possible implementations of the first aspect, or the fourth aspect and various possible implementations of the fourth aspect.

[0061] A ninth aspect of this application provides a chip system including a processor and potentially a memory, for implementing the methods provided in the first aspect and its various possible implementations, or the fourth aspect and its various possible implementations. The chip system may be composed of chips or may include chips and other discrete devices.

[0062] This application provides a communication device in a tenth aspect. The communication device can be a terminal device or a component within a terminal device. In one design, the device may include a module corresponding to the method / operation / step / action described in the second aspect and its various possible implementations, or the fifth aspect and its various possible implementations. This module may be hardware circuitry, software, or a combination of hardware circuitry and software implementation. In one design, the device may include a receiving module and a processing module. For example...

[0063] The receiving module is used to receive second indication information from the first network device;

[0064] The processing module is used to discard data packets received from the first network device and stored in the PDCP receive buffer before accessing the second network device, according to the second instruction information;

[0065] The receiving module is also used to receive a second data stream from a second network device, the second data stream comprising multiple consecutive data packets ordered in ascending order of PDCP sequence number;

[0066] The processing module is also used to determine the first data stream to be saved based on the second data stream; and to save the first data stream to be saved in the PDCP receive buffer.

[0067] The eleventh aspect of this application provides a communication device, which includes a processor for implementing the methods described in the second aspect and its various possible implementations, or the fifth aspect and its various possible implementations. The device may further include a memory for storing instructions and data. The memory is coupled to the processor, and when the processor executes the instructions stored in the memory, it enables the device to implement the methods described in the second aspect and its various possible implementations, or the fifth aspect and its various possible implementations. The device may also include a communication interface for communicating with other devices. For example, the communication interface may be a transceiver, a bus, or other circuit hardware module, and the other devices may be network devices, etc. In one possible design, the device includes:

[0068] Memory, used to store program instructions;

[0069] The processor is configured to receive second indication information from a first network device; discard data packets received from the first network device and stored in a PDCP receive buffer before accessing the second network device, according to the second indication information; receive a second data stream from the second network device, the second data stream comprising multiple consecutive data packets ordered in ascending order of PDCP sequence numbers; and further configured to determine a first data stream to be saved based on the second data stream; and save the first data stream to be saved in the PDCP receive buffer.

[0070] The twelfth aspect of this application provides a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the methods provided by the second aspect and various possible implementations of the second aspect, or the fifth aspect and various possible implementations of the fifth aspect.

[0071] The thirteenth aspect of this application provides a chip system including a processor and potentially a memory for implementing the methods provided in the second aspect and its various possible implementations, or the fifth aspect and its various possible implementations. The chip system may be composed of chips or may include chips and other discrete devices.

[0072] The fourteenth aspect of this application provides a communication device, which may be a first network device or a device within the first network device. In one design, the device may include a module corresponding to performing the methods / operations / steps / actions described in the third aspect and its various possible implementations. This module may be hardware circuitry, software, or a combination of hardware circuitry and software implementation. In another design, the device may include a transmitting module and a receiving module.

[0073] For example,

[0074] The sending module is used to send a migration request to the second network device. The migration request is used to request the migration of at least one service bearer of the terminal device from the first network device to the second network device.

[0075] The receiving module is used to receive migration request confirmations from the second network device;

[0076] The sending module is also used to send a first data stream to a second network device; the first data stream includes multiple data packets arranged consecutively in ascending order of PDCP sequence number;

[0077] The first data stream includes the first data packet that the first network device has sent to the terminal device but has not received an acknowledgment instruction from the terminal device; the first data stream includes data packets that the first network device has sent to the terminal device but has not received an acknowledgment instruction from the terminal device and data packets that the first network device has sent to the terminal device and has received an acknowledgment instruction from the terminal device.

[0078] The fifteenth aspect of this application provides a communication device, which includes a processor for implementing the method described in the third aspect and various possible implementations of the third aspect. The device may further include a memory for storing instructions and data. The memory is coupled to the processor, and when the processor executes the instructions stored in the memory, it enables the device to implement the method described in the third aspect and various possible implementations of the third aspect. The device may also include a communication interface for communicating with other devices. For example, the communication interface may be a transceiver, a bus, or other circuit hardware module, and the other devices may be terminal devices, etc. In one possible design, the device includes:

[0079] Memory, used to store program instructions;

[0080] The processor is configured to send a migration request to a second network device, the migration request being used to request the migration of at least one service bearer of the terminal device from the first network device to the second network device; receive a migration request confirmation from the second network device; and send a first data stream to the second network device; the first data stream comprising a plurality of data packets arranged consecutively in ascending order of PDCP sequence number;

[0081] The first data stream includes the first data packet that the first network device has sent to the terminal device but has not received an acknowledgment instruction from the terminal device; the first data stream includes data packets that the first network device has sent to the terminal device but has not received an acknowledgment instruction from the terminal device and data packets that the first network device has sent to the terminal device and has received an acknowledgment instruction from the terminal device.

[0082] The sixteenth aspect of this application provides a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the methods provided by the third aspect and various possible implementations of the third aspect.

[0083] The seventeenth aspect of this application provides a chip system including a processor and potentially a memory for implementing the methods provided in the third aspect and various possible implementations thereof. The chip system may be composed of chips or may include chips and other discrete devices.

[0084] The eighteenth aspect of this application provides a communication system including a first network device and a second network device. The communication system is applied to a scenario where the first network device switches at least one service bearer of a terminal device from the first network device to the second network device. In one design, the communication system includes a second network device for implementing the method provided in the first aspect, and a first network device for implementing the method provided in the third aspect and various possible implementations of the third aspect. In one design, the communication system includes a second network device for implementing the method provided in the fourth aspect and various possible implementations of the fourth aspect. Attached Figure Description

[0085] Figure 1a This is an example diagram of a mobile handover process;

[0086] Figure 1b This is an example diagram of a dual-connection architecture;

[0087] Figure 1c An example diagram of adding an SN to the UE in a dual-connectivity architecture;

[0088] Figure 2 An example diagram of data forwarding for downlink transmission;

[0089] Figure 2a An example diagram illustrating data forwarding for uplink transmission;

[0090] Figure 3 This is a schematic diagram of the network architecture for applying embodiments of this application;

[0091] Figure 4 A flowchart illustrating the data transmission method provided in Embodiment 1 of this application;

[0092] Figure 5 This is a flowchart illustrating the data transmission method provided in Embodiment 2 of this application;

[0093] Figure 6 This is a flowchart illustrating the data transmission method provided in Embodiment 3 of this application;

[0094] Figure 6a This is a schematic diagram of a PDCP control PDU format;

[0095] Figure 7 This is a flowchart illustrating the data transmission method provided in Embodiment 4 of this application;

[0096] Figure 7a A flowchart illustrating an uplink data transmission method provided in an embodiment of this application;

[0097] Figure 8 This is a schematic diagram of the structure of the communication device provided in the embodiments of this application;

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

[0099] Figure 10 This is another schematic diagram of the communication device provided in the embodiments of this application. Detailed Implementation

[0100] To better understand the technical solutions provided in the embodiments of this application, the technical terms involved in the embodiments of this application will be introduced first.

[0101] (1) The migration process of business carriers

[0102] The service bearer migration process refers to the process of migrating at least one service bearer of a terminal device from one base station to another. Before the migration, the base station providing services for at least one service bearer of the terminal device can be called the source base station; after the migration, the base station providing services for at least one service bearer of the terminal device can be called the target base station. Here, at least one service bearer can be all the service bearers currently running on the terminal device, and all the service bearers of the terminal device are migrated from the source base station to the target base station; this situation can be called the terminal device's mobile handover process. Alternatively, it can be a portion of the service bearers among all the service bearers currently running on the terminal device. For example, if the running service bearers include high-definition video services and Voice over Internet Protocol (VoIP) services, the VoIP services can be migrated from the source base station to the target base station, while the high-definition video service bearer remains at the source base station; this situation can be considered a data offloading scenario for the terminal device.

[0103] In one possible implementation, the mobile handover process of the terminal device can be as follows: Figure 1a As shown, the steps may include the following.

[0104] Step 1, Measurement Control and Reporting. The source base station configures the measurement process for the terminal equipment, and the terminal equipment reports based on the measurement configuration.

[0105] Before the terminal device disconnects from the source base station, it can perform uplink transmissions, such as sending data packets to the source base station and the source base station forwarding the data packets to the user plane function (UPF) in the core network. Before the terminal device disconnects from the source base station, it can also perform downlink transmissions with the source base station, such as the UPF sending data packets to the source base station and the source base station forwarding the data packets to the terminal device.

[0106] Step 2: Determine if handover is needed. The source base station determines whether the terminal device needs to handover based on the measurement report reported by the terminal device.

[0107] Step 3: If a handover is required, the source base station sends a handover request message to the target base station; correspondingly, the target base station receives the handover request message from the source base station.

[0108] Step 4, Access Control. The target base station performs access control, determining whether to allow the terminal device to access the network based on its own connectable capacity or load.

[0109] Step 5: If the terminal device is allowed to access, the target base station prepares for handover and sends a handover request acknowledge message to the source base station. Correspondingly, the source base station receives the handover request acknowledge message from the target base station. The handover request acknowledge message may include a radio resource control (RRC) reconfiguration message generated by the target base station for the terminal device, which includes the configuration required for the terminal device to access the target base station.

[0110] Step 6, Access Network Side Handover Initialization. The source base station sends a handover command to the terminal device, which includes an RRC reconfiguration message sent by the target base station. The terminal device performs a handover according to the handover command: the terminal device disconnects from the source base station and accesses the target base station through a random access procedure.

[0111] Step 7: To ensure service continuity during handover, the source base station forwards data to the target base station. For downlink data forwarding, the source base station can deliver data packets that were not sent or were not successfully transmitted (sent but without receiving confirmation from the terminal device) to the target base station, which then continues to send them to the terminal device. For uplink data forwarding, the source base station can send out-of-order PDCP data packets received from the UPF to the target base station, which then performs PDCP reordering.

[0112] Step 8, handover complete. The terminal device ends the handover process by sending an RRC reconfiguration complete message to the target base station.

[0113] After step 8, the terminal device can perform uplink transmission, such as sending data packets to the target base station and the target base station forwarding the data packets to the UPF; it can also perform downlink transmission, such as the UPF sending data packets to the target base station and the target base station forwarding the data packets to the terminal device.

[0114] In another possible implementation, in a data offloading scenario, if the source base station is overloaded due to providing too many services to the terminal equipment, some of the terminal equipment's service bearers can be migrated from the source base station to the target base station, where the target base station provides services for these partial service bearers. In this data offloading scenario, the source base station can also be called the master node (MN), and the target base station can be called the secondary node (SN). When the MN adds an SN to a terminal equipment (e.g., user equipment, UE), forming a structure like this... Figure 1b In the dual-connectivity (DC) architecture shown, a new service bearer, such as a data radio bearer (DRB), can be established for the UE on the SN side for data transmission. The MN can also migrate at least one DRB previously established on the MN side to the SN side for data transmission. An example diagram of the MN adding an SN to the UE can be found here. Figure 1c As shown, the steps may include the following:

[0115] Step 1: The MN sends an SN Addition Request message, such as an SN Addition Request, to the SN. This message requests the SN to provide partial service bearer services for the UE.

[0116] Step 2: If the SN agrees to serve the UE, it sends an SN Addition Request Ack message to the MN. This message may carry SN RRC configuration information generated for the UE's access to the SN.

[0117] Step 3: The MN sends an RRC connection reconfiguration message to the UE, which may carry SN RRC configuration information.

[0118] Step 4: The UE sends an RRC connection reconfiguration complete message to the MN, which may carry the message "SN RRC configuration complete".

[0119] Step 5: MN sends an SN reconfiguration complete message to SN, which may include the message that SN RRC configuration is complete.

[0120] Step 6: The UE performs a random access procedure to access the SN.

[0121] In steps 7 and 8, MN forwards data to SN. The specific process is as follows: Figure 1a The data forwarding process is similar.

[0122] Steps 9-12: Path update process. Part of the UE's service bearers are migrated from the corresponding transport tunnel between the MN and UPF to the transport tunnel between the SN and UPF. This transport tunnel can be a GPRS tunneling protocol (GTP) tunnel established according to each protocol data unit (PDU) session.

[0123] (2) Data forwarding

[0124] For service data with high reliability requirements, terminal equipment is typically configured with an Acknowledge Mode (AM) data radio bearer (DRB) (i.e., a DRB configured with AM radio link control (RLC)) for data transmission on the air interface. The AM DRB can ensure the reliability of data packet transmission through the RLC automatic repeat request (ARQ) mechanism, and lossless data transmission must also be guaranteed during migration. Taking downlink data transmission as an example during migration, for PDCP service data units (SDUs) that have been sent by the AM DRB at the source base station's Packet Data Convergence Protocol (PDCP) layer but have not been acknowledged, the source base station needs to forward them to the target base station through the inter-base station interface, and then the target base station's PDCP layer will send them to the terminal equipment. This process can be called the AM DRB data forwarding process.

[0125] Both the PDCP count (COUNT) value and the PDCP sequence number (SN) can be used to represent the sequence number of a PDCPSDU or PDCP PDU. The COUNT is 32 bits long, the SN is the lower 12 or lower 18 bits of the COUNT, and the hyperframe number (HFN) is the part of the COUNT excluding the SN, which is the higher 20 or higher 14 bits of the COUNT.

[0126] The source base station transmits the SN and HFN status of the uplink / downlink PDCPSDU to the target base station through SN status transfer messages, and transmits the uplink / downlink PDCP SDU to the target station through data forwarding.

[0127] For downlink transmission:

[0128] The source base station can inform the target base station via SN status transfer messages about the COUNT value that needs to be allocated to the next downlink PDCP SDU without an assigned SN in the corresponding AM DRB. When performing downlink data forwarding, the source base station first sends all PDCP SDUs that have not received an acknowledgment (ACK) from the terminal device, along with their corresponding SNs, to the target base station. Then, it sends the PDCP SDUs received from the UPF to the target base station. The target base station first assembles the PDCP SDUs with SNs forwarded by the source base station into a first PDCP PDU set (which may include one or more PDCP PDUs), and sends this first PDCP PDU set to the terminal device. Then, it assembles the PDCP SDUs without SNs forwarded by the source base station into a second PDCP PDU set (which may include one or more PDCP PDUs), and sends this second PDCP PDU set to the terminal device. If the target base station receives a PDCP status report from the terminal device, it can determine which SNs the terminal device has successfully received and which SNs it has not successfully received based on the PDCP status report. For PDCP PDUs that the terminal device has successfully received but has not sent an acknowledgment command back to the source base station, the target base station does not need to send them to the terminal device again. After receiving PDCP PDUs that the source base station failed to send or did not send from the target base station and parsing them, the terminal device can reorder the PDCP SDUs in the PDCP receive buffer and deliver the corresponding PDCP SDUs to the upper layer of the PDCP layer in order.

[0129] For example, see Figure 2 The diagram shown illustrates data forwarding in downlink transmission, using the mobile handover process as an example. Figure 2In this scenario, when a terminal device disconnects from the source base station, on the terminal device side, for an AM DRB, the PDCP PDUs corresponding to SN=0, SN=2, and SN=4 have been successfully received by the terminal device, and the RLC layer of the terminal device has sent an acknowledgment command back to the source base station. The PDCP PDU corresponding to SN=0 has been delivered to the upper layer of the PDCP layer; however, the PDCP PDUs corresponding to SN=1 and SN=3 have not yet been received. At this time, the source base station can forward the PDCP SDUs of SN=1 and SN=3 to the target base station during downlink data forwarding. The target base station will generate new PDCP PDUs (one PDCP SDU can form one PDCP PDU) from the PDCP SDUs of SN=1 and SN=3 respectively, and send the new PDCP PDUs to the terminal device. Upon receiving the PDCP PDUs corresponding to SN=1 and SN=3 from the target base station, the terminal device can deliver the PDCP SDUs starting from SN=1 to the upper layer of the PDCP layer in sequence.

[0130] For uplink transmission:

[0131] If the target base station does not request data forwarding from the source base station, or if the source base station does not accept the uplink data forwarding request from the target base station, the source base station can discard all out-of-order PDCP SDUs received from the terminal device. If the source base station accepts the uplink data forwarding request from the target base station, it can inform the target base station via an SN status transfer message of the COUNT value corresponding to the first unreceived PDCP SDU, and a bit sequence indicating the reception status of the source base station's PDCP SDU. The Nth bit of this bit sequence indicates the reception status of the Nth PDCP SDU after the first unreceived PDCP SDU; for example, a bit value of 1 indicates successful reception, and a bit value of 0 indicates unreceived reception. The target base station can use this information in the SN status transfer message to generate a PDCP status report and send it to the terminal device.

[0132] When the source base station is performing data forwarding, it sends the received out-of-order PDCP SDU and the corresponding SN to the target base station.

[0133] When the base station instructs the terminal device to perform a handover, it instructs the terminal device to re-establish PDCP. After completing PDCP re-establishment, the terminal device, starting from the first PDCP SDU that has not received an acknowledgment from the source base station (which could be an acknowledgment of successful data reception indicated by the source base station's RLC layer), continuously retransmits or transmits PDCP SDUs to the target base station in ascending order of COUNT. If the terminal device receives a PDCP status report from the target base station, for PDCP SDUs indicated in the PDCP status report as successfully received, the terminal device executes a PDCP SDU discard procedure, i.e., discards the PDCP SDU and its corresponding PDCP SDU.

[0134] For example, see Figure 2a The diagram illustrating uplink data forwarding uses an intra-site handover process (i.e., the terminal device switches primary cells (Pcells) within a single base station, where the source and target base stations are the same) as an example to explain the uplink data processing during the handover process. After PDCP re-establishment is complete, the terminal device continuously sends PDCP PDUs consisting of PDCP SDUs corresponding to SN=101, 102, 103, 104, 105… to the base station, starting with the first data packet not acknowledged by the RLC layer (i.e., the PDCP SDU corresponding to SN=101). However, the base station has already successfully received the PDCP SDUs corresponding to SN=101, 102, 103, and 105, but has not yet had time to send an RLC status report. Nevertheless, the terminal device still retransmits these data packets. Upon receiving duplicate PDCP PDUs corresponding to SN=101, 102, and 103, the base station discards them directly without parsing.

[0135] Optionally, the base station can send a downlink PDCP status report to the terminal device, including a COUNT=104 corresponding to the first unreceived PDCP SDU, and a bitmap. Each bit in the bitmap corresponds sequentially to the reception status of each subsequent PDCP SDU after the one corresponding to the FMC. A bit value of 1 indicates that the corresponding PDCP SDU has been successfully received, and a bit value of 0 indicates that the corresponding PDCP SDU has not been received. After receiving the PDCP status report from the base station, the terminal device can perform a PDCP SDU discard operation based on the information in the report, thereby reducing the transmission of duplicate packets.

[0136] (3) Compression mechanism

[0137] To enhance uplink coverage and improve the utilization of uplink resources, an uplink data compression (UDC) mechanism can be adopted.

[0138] In the UDC mechanism, the compression side needs to maintain a compression buffer, and the decompression side needs to maintain a decompression buffer. The compression side compresses the data packets to be compressed based on the compression buffer. The basic principle is that if a string in the data packet matches a string in the compression buffer, the string in the data packet is replaced with the one whose position and length information is found in the compression buffer. The decompression side decompresses the compressed data packets based on the decompression buffer. The basic principle is to retrieve the corresponding string from the decompression buffer using the position and length information of the string indicated in the compressed data packet to reconstruct the original data packet. Based on the above description, it can be seen that if the compression buffer used by the compression side when compressing data packet A and the decompression buffer used by the decompression side when decompressing the compressed packet of A contain completely identical data, the correct decompression of data packet A can be guaranteed. After the compression side compresses an original data packet using the above compression mechanism, it updates the compression buffer using the original data packet. Specifically, the original data packet is pushed into the compression buffer based on a first-in-first-out (FIFO) operation, so that it can be used as the string in the compression buffer when compressing the next original data packet. If the compression cache size is fixed, data previously stored in the compression cache may be pushed out due to capacity overload. Similarly, after the decompression side decompresses the compressed data packet to obtain the original data packet, it will use the original data packet to update the decompression cache, so as to use the string in the decompression cache when the next compressed data packet is decompressed.

[0139] As described above, the order in which the decompression side decompresses compressed data packets must be exactly the same as the order in which the compression side compresses these data packets; packet loss during transmission will cause subsequent data packets of the dropped packets to fail to decompress. In Long Term Evolution (LTE) systems, the UDC mechanism can be configured only for uplink data transmission compression by the AM DRB.

[0140] To prevent decompression failure due to cache inconsistency, UDC introduces a verification mechanism. Before compressing a data packet, the compression side generates a 4-bit checksum using the current compression cache state and includes it in the UDC header of the compressed data packet. Before decompressing the compressed data packet, the decompression side first generates a checksum based on the current decompression cache state and compares it with the checksum carried in the compressed packet. If they match, decompression can proceed; otherwise, it indicates that the compression and decompression caches are out of sync, and cache alignment needs to be performed again.

[0141] The aforementioned UDC is a compression mechanism, while robust header compression (RoHC) is another compression mechanism.

[0142] The Internet Protocol (IP) is typically used on top of the protocol stack of mobile communication systems. Therefore, most data transmitted in actual mobile communication networks is in the form of IP packets. For an IP data stream distinguished by the five-tuple <source IP address, source port, destination IP address, destination port, and transport layer protocol>, most fields in the IP header are fixed. Therefore, to improve the utilization of radio resources, the IP header can be compressed. The IP header compression protocol used in LTE and New Radio (NR) networks is RoHC. In the RoHC protocol, the compression side needs to send the compression context to the decompression side in the data packet, and only after the decompression side receives the compression context will it perform compression on subsequent data packets. Context can be information that can be used for IP header compression or decompression, such as the possible values ​​of compressible fields. Different context information can be distinguished by context ID (CID).

[0143] The RoHC mechanism has several modes: U mode, O mode, and R mode. In U mode, the compression side sends a context L times (L is a preset positive integer) times and is certain that the decompression side has successfully received it without receiving feedback from the decompression side. In O and R modes, the compression side is only certain that the context has been successfully received after receiving feedback from the decompression side. The RoHC mechanism always starts operating in U mode and can be switched to other modes by the decompression side. In each mode, the compression side has three states: initialization and refresh (IR) state, first order (FO) intermediate state, and second order (SO) ideal state. In the IR state, the compression side sends RoHC IR packets, which carry the complete IP header.

[0144] In the current protocol, the network can reconfigure RoHC when instructing terminal devices to re-establish PDCP. During RoHC reconfiguration, the drb-ContinueRoHC parameter can indicate whether to reset the RoHC header compression protocol or keep the RoHC header compression protocol unchanged (i.e., the RoHC context) during PDCP re-establishment.

[0145] The compression mechanism involved in this application embodiment is applied to downlink data transmission. It can be the same downlink data compression (DDC) mechanism as the UDC compression mechanism, or it can be the RoHC mechanism, or other compression mechanisms, such as Ethernet header compression (EHC) for compressing Ethernet frame headers; no specific limitation is made. In this application embodiment, the downlink data transmission compression mechanism is mainly described using DDC as an example. The function of DDC is similar to that of UDC, the difference being that DDC is for downlink data, while UDC is for uplink data. The uplink data transmission compression mechanism is mainly described using the RoHC mechanism as an example.

[0146] To improve the utilization of downlink resources, uplink compression mechanisms can be used for downlink data transmission. However, as analyzed above, applying this compression mechanism during the migration of service bearers may cause terminal devices to fail to decompress downlink data, resulting in packet loss and the inability to receive complete downlink data.

[0147] Example 1: Downlink data transmission uses the DDC (Data Distribution Control) mechanism, taking the mobile handover process as an example. Assume the source base station configures DDC for the terminal device for downlink data transmission. During handover, the target base station can either reconfigure DDC for the terminal device for downlink data transmission or not configure DDC for it. Figure 2For example, data packets from SN=0 to SN=4 are compressed sequentially by the source base station and sent to the terminal device. The terminal device successfully receives data packets SN=0, SN=2, and SN=4, but does not receive data packets SN=1 and SN=3. Following the data forwarding process described above, the source base station forwards the PDCP SDUs SN=1 and SN=3 to the target base station, which then assembles them into a new PDCP PDU and sends it to the terminal device. However, the PDCP PDU for SN=1 assembled by the target base station is different from the PDCP PDU for SN=1 assembled by the source base station (for example, the target base station reconfigured the DDC, clearing both the compression and decompression buffers; the compression buffer used by the source base station when compressing the PDCP SDU for SN=1 is different from the compression buffer used by the target base station, resulting in a different compressed PDCP PDU). Therefore, the terminal device cannot successfully decompress SN=2 and subsequent PDCP PDUs, leading to packet loss and the inability to receive complete downlink data.

[0148] Example 2: Downlink data transmission uses the RoHC mechanism, taking the mobile handover process as an example. Figure 2 For example, the data packet with SN=1 sent by the source base station carries context information, and the data packet with SN=2 is compressed based on this context information. During mobile handover, if the terminal device does not receive the data packet with SN=1, the source base station, during data forwarding, forwards the PDCP SDU with SN=1 to the target base station, which then assembles a new PDCP PDU and sends it to the terminal device. The PDCP PDU with SN=1 assembled by the target base station may not carry context information, causing the terminal device to be unable to decompress the data packet with SN=2, resulting in packet loss and the inability to receive complete downlink data.

[0149] Currently, in scenarios where a terminal device receives a first data stream from one network device and a second data stream from another network device, and the first and second data streams are dependent on each other (e.g., during service migration), the terminal device receives out-of-order and discontinuous data streams. Therefore, embodiments of this application provide a data transmission method and communication apparatus that enable data forwarding during service migration, allowing the terminal device to obtain a continuous and complete data stream.

[0150] In the accompanying drawings of the embodiments of this application, the steps shown in the various embodiments, and the order of the steps, are for illustrative purposes only and do not constitute a limitation on the embodiments of this application. It should be understood that performing some of the steps in the drawings or adjusting the order of the steps for specific implementation falls within the protection scope of this application.

[0151] The technologies described in this application can be used in various communication systems, such as fourth-generation (4G) communication systems, 4.5G communication systems, 5G communication systems, systems integrating multiple communication systems, or future evolved communication systems. Examples include LTE systems, NR systems, wireless-fidelity (WiFi) systems, time-sensitive networking (TSN) systems, integrated access and backhaul (IAB) systems, and other communication systems developed by the 3rd Generation Partnership Project (3GPP).

[0152] The terminal device (also referred to as a terminal) involved in the embodiments of this application can be a device with wireless transceiver capabilities, which can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; it can also be deployed on water (such as ships); and it can also be deployed in the air (e.g., on airplanes, balloons, and artificial satellites). The terminal device can be a user equipment (UE), wherein the UE includes a handheld device, vehicle-mounted device, wearable device, or computing device with wireless communication capabilities. For example, the UE can be a mobile phone, tablet computer, or computer with wireless transceiver capabilities. The terminal device can also be a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a smart vehicle terminal device, a wireless terminal in industrial control, a wireless terminal in autonomous driving, a wireless terminal in telemedicine, a wireless terminal in a smart grid, a wireless terminal in a smart city, a wireless terminal in a smart home, and so on. In this application embodiment, the device for implementing the functions of the terminal device can be the terminal device itself; it can also be a device capable of supporting the terminal device in implementing the functions, such as a chip system. This device can be installed in or used in conjunction with the terminal device, such as a processor. 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.

[0153] By way of example and not limitation, in this application, the terminal can be a wearable device. Wearable devices, also known as wearable smart devices, are a general term for devices that utilize wearable technology to intelligently design and develop everyday wearables, such as glasses, gloves, watches, clothing, and shoes. Wearable devices are portable devices that are worn directly on the body or integrated into the user's clothing or accessories. Wearable devices are not merely hardware devices, but also achieve powerful functions through software support, data interaction, and cloud interaction. Broadly speaking, wearable smart devices include those that are feature-rich, large in size, and can achieve complete or partial functions without relying on a smartphone, such as smartwatches or smart glasses, as well as those that focus on a specific type of application function and require the use of other devices such as smartphones, such as various smart bracelets and smart jewelry for vital sign monitoring.

[0154] In this application, the terminal can be a terminal in an Internet of Things (IoT) system. IoT is an important component of future information technology development, and its main technical feature is connecting objects to networks through communication technologies, thereby realizing an intelligent network of human-machine interconnection and machine-to-machine interconnection. The terminal in this application can be a terminal in machine-type communication (MTC). The terminal in this application can be an on-board module built into a vehicle as one or more components or units, and the vehicle can implement the method of this application through the built-in on-board module. Therefore, the embodiments of this application can be applied to vehicle networking, such as vehicle to everything (V2X), long term evolution vehicle (LTE-V), vehicle to vehicle (V2V), etc.

[0155] The network devices involved in this application embodiment may include base stations (BS), which are devices deployed in a wireless access network capable of wirelessly communicating with terminal devices. Base stations may take various forms, such as macro base stations, micro base stations, relay stations, and access points. For example, the network devices involved in this application embodiment may be base stations in 5G or Long Term Evolution (LTE) systems. In 5G, a base station may also be called a transmission reception point (TRP) or a next-generation node B (gNB). In this application embodiment, the apparatus for implementing the functions of the network device may be the network device itself; it may also be an apparatus capable of supporting the network device in implementing these functions, such as a chip system. This apparatus may be installed in or used in conjunction with the network device, such as a processor. In this application embodiment, the chip system may consist of chips or may include chips and other discrete components. In the technical solutions provided in this application embodiment, the example of a network device being used to implement the functions of the network device is used to describe the technical solutions provided in this application embodiment.

[0156] Please see Figure 3 This is a schematic diagram of a network architecture using embodiments of this application. The network architecture may include a first network device 301, a second network device 302, and a terminal device 303. It should be noted that... Figure 3 The form and quantity of the devices shown are for illustrative purposes only and do not constitute a limitation on the embodiments of this application.

[0157] In this process, the first network device 301 can be the source base station, and the second network device 302 can be the target base station. The first network device 301 can migrate at least one service bearer of the terminal device 303 from the first network device 301 to the second network device 302. For example, during a handover, if the first network device 301 determines that the terminal device 303 has moved from its coverage area to the coverage area of ​​the second network device 302, it can switch at least one service bearer of the terminal device 303 from the first network device 301 to the second network device 302, whereby the second network device 302 provides service for the at least one service bearer of the terminal device 303. As another example, if the first network device 301 is overloaded, it can switch at least one service bearer of the terminal device 303 from the first network device 301 to the second network device 302, whereby the second network device 302 provides service for the at least one service bearer of the terminal device 303.

[0158] The services carried may include, but are not limited to, high-definition video services, VoIP services, Internet protocol television (IPTV) services, and voice communication services.

[0159] In one implementation, during the migration of service bearers, the first network device 301 can perform continuous data forwarding, sending data to the second network device 302. When the second network device 302 receives the continuously forwarded data, it sends data to the terminal device 303 based on the continuously forwarded data. Even if the DDC configured on the second network device 302 is different from that on the first network device 301, the continuous data forwarding by the first network device 301 can prevent packet loss when the terminal device 303 receives downlink data, thus achieving lossless data transmission.

[0160] In another implementation, during the service bearer migration process, the first network device 301 can inform the second network device 302 of its compression cache information. The second network device 302 can then perform PDCP layer compression processing on the data packets based on this compression cache information, ensuring that the compression cache information used by the second network device 302 is the same as that used by the first network device 301, and corresponds to the decompression cache information used by the terminal device before the service bearer migration. This allows the terminal device 303 to successfully decompress the data packets sent by the second network device 302, avoiding packet loss and achieving lossless data transmission.

[0161] The data transmission method provided in the embodiments of this application will now be described with reference to the accompanying drawings. It should be noted that the names of the information or data exchanged between the terminal device and the network device are used as examples and do not constitute a limitation on the embodiments of this application.

[0162] Please see Figure 4 This is a flowchart illustrating the data transmission method provided in Embodiment 1 of this application. The method describes an AM DRB based on the mobile handover process. Figure 4 The process shown may include, but is not limited to, the following steps:

[0163] Step 401: The first network device sends a handover request message to the second network device. Correspondingly, the second network device receives the handover request message from the first network device.

[0164] When the first network device determines that a terminal device needs to be switched, it sends a switch request message to the second network device. The switch request message requests the establishment of a connection between the second network device and the terminal device to migrate at least one service bearer of the terminal device from the first network device to the second network device. The at least one service bearer can be all the service bearers currently in operation by the terminal device, or it can be a subset of all the service bearers.

[0165] In step 402, the second network device sends a handover request confirmation message to the first network device. Correspondingly, the first network device receives the handover request confirmation message from the second network device.

[0166] If the second network device agrees to establish a connection with the terminal device upon receiving the handover request message, it will perform the handover and send a handover request confirmation message to the first network device.

[0167] In one implementation, the handover request confirmation message may include first indication information, which indicates a forwarding rule for continuously forwarding data packets in ascending order of PDCP sequence number. The first indication information may instruct the first network device to send data packets to the second network device according to this forwarding rule. It is understood that this forwarding rule is continuous data forwarding, and the first indication information instructs the first network device to perform continuous data forwarding of downlink data packets and send data packets to the second network device.

[0168] For example, when a first network device configures the DDC function for the AM DRB, or when a second network device decides to configure the DDC function for the AM DRB, the second network device may carry first indication information in the handover request confirmation message, such as a continuous data forwarding indication. Optionally, the handover request confirmation message can indicate whether the first network device needs to perform continuous data forwarding by carrying the first indication information. For example, carrying the first indication information indicates that the first network device needs to perform continuous data forwarding; not carrying the first indication information indicates that the first network device does not need to perform continuous data forwarding. Optionally, the value of the bit corresponding to the first indication information indicates whether the first network device needs to perform continuous data forwarding. For example, a bit value of "1" or "true" indicates that the first network device needs to perform continuous data forwarding; a bit value of "0" or "false" indicates that the first network device does not need to perform continuous data forwarding.

[0169] The aforementioned continuous data forwarding indication can be applied to each AM DRB separately, meaning that one AM DRB can correspond to one continuous data forwarding indication. For example, the specific cell representation can be shown in Table 1 below.

[0170]

[0171] Table 1

[0172] The data forwarding response DRB list shown in Table 1 can be the data forwarding response DRB list indicated in the data forwarding info from target NG-RANnode information cell included in the handover request confirmation message sent by the second network device to the first network device. In this embodiment, the data forwarding response DRB list includes a continuous data forwarding indication, which can indicate whether the first network device needs to perform continuous data forwarding for the DRB indicated by the DBR ID; or, the continuous data forwarding indication can be applied to the terminal device, that is, it applies to all AM DRBs of the terminal device.

[0173] The first indication information can be carried in the handover request confirmation message or in other messages sent by the second network device to the first network device. The second network device uses the first indication information to instruct the first network device to perform continuous data forwarding.

[0174] In another implementation, the first network device sends a request message to the second network device. This request message indicates a forwarding rule: data packets are forwarded continuously in ascending order of PDCP sequence numbers. Essentially, the first network device proactively informs the second network device via the request message that it will perform continuous data forwarding. Optionally, the second network device can further indicate to the first network device whether it accepts the continuous data forwarding request; if the second network device indicates acceptance, the first network device forwards data packets continuously in ascending order of PDCP sequence numbers; otherwise, the first network device does not perform continuous data forwarding.

[0175] In both implementations described above, continuous data forwarding by the first network device means that, for this AMDRB, the first network device, starting from the PDCP SDU that has been sent to the terminal device at the first PDCP layer but for which no acknowledgment instruction has been received, sends PDCPSDUs and their corresponding PDCP sequence numbers to the second network device in ascending and consecutive order of PDCP sequence numbers. The PDCP sequence number can be a COUNT value or an SN value. Conversely, if the first network device does not perform continuous data forwarding, it means that, for this AMDRB, the first network device, in ascending and consecutive order of PDCP sequence numbers, sends PDCPSDUs and their corresponding PDCP sequence numbers to the second network device. Figure 1a In the data forwarding process, the PDCP SDU is sent to the second network device. That is, the first network device sends the PDCP SDU and the corresponding SN value to the second network device, which has been sent to the terminal device but has not received an acknowledgment instruction from the terminal device.

[0176] For example, when the terminal device disconnects from the first network device, on the terminal device side, for an AM DRB, the PDCP PDUs corresponding to SN=0, SN=2, and SN=4 have been successfully received, and the terminal device's RLC layer has sent an acknowledgment command to the first network device; the PDCP PDU corresponding to SN=0 has been delivered to the upper layer; however, the PDCP PDUs corresponding to SN=1 and SN=3 have not yet been received. Figure 1a In the data forwarding process, the first network device forwards PDCP SDUs with SN=1 and SN=3 to the second network device. If data forwarding is continuous, the first network device forwards PDCP SDUs with SN=1, SN=2, and SN=3 to the second network device.

[0177] visible, Figure 1a In the previous data forwarding, the PDCP sequence numbers of the forwarded data packets were not consecutive. However, the continuous data forwarding provided in this application ensures that the PDCP sequence numbers of the forwarded data packets are consecutive. "Consecutive" can be understood as the PDCP sequence numbers being uninterrupted.

[0178] In one implementation, the handover request confirmation message may further include second indication information. This second indication information instructs the terminal device to discard data packets received from the first network device and stored in the PDCP receive buffer before accessing the second network device. For example, this could be out-of-order data packets received from the first network device after DDC processing, for which the terminal device cannot parse the corresponding PDCP SDU and deliver it to the upper layer. These data packets may not be entirely the original data packets received by the terminal device; they may be data packets that have undergone decryption and integrity protection but have not yet been decompressed. These data packets are collectively referred to as PDCP SDUs. The PDCP receive buffer can also be described as the PDCP buffer or the PDCP receive buffer state.

[0179] For example, the second indication information may be discardStoredPDU information as specified by 3GPP. Optionally, the handover request confirmation message may indicate whether the terminal device should discard data packets received from the first network device and stored in the PDCP receive buffer before accessing the second network device by carrying the second indication information. For example, carrying the second indication information indicates that the terminal device should discard the data packets; if it does not carry the second indication information, it indicates that the terminal device does not need to discard them. Optionally, the value of the corresponding bit in the second indication information may indicate whether the terminal device should discard data packets received from the first network device and stored in the PDCP receive buffer before accessing the second network device. For example, if the value of the corresponding bit in the second indication information is "1" or "true", it indicates that the terminal device should discard the data packets; if the value of the corresponding bit in the second indication information is "0" or "false", it indicates that the terminal device does not need to discard them.

[0180] The discardStoredPDU can be specified for each AM DRB, meaning one discardStoredPDU corresponds to one AM DRB. For example, the discardStoredPDU can be carried in the handover command within a handover request confirmation message, or it can be carried in the PDCP configuration cell (PDCP-config) or radio bearer configuration cell (radio bearer configuration) within the handover command. Alternatively, the discardStoredPDU can be applied to the terminal device, meaning it applies to all AM DRBs of the terminal device.

[0181] The second indication information can be carried in the handover request confirmation message or in other messages sent by the second network device to the first network device. The second network device uses the second indication information to instruct the terminal device to discard data packets received from the first network device and stored in the PDCP receive buffer before accessing the second network device.

[0182] The time before the terminal device accesses the second network device can be after the first network device receives a migration request confirmation (e.g., a handover request confirmation message) from the second network device and before the terminal device initiates a random access procedure to the second network device; or it can be before the terminal device initiates a random access procedure to the second network device to establish an RRC connection.

[0183] Optionally, the first indication information and the second indication information can be the same indication information, that is, one indication information indicates both continuous data forwarding and the discarding of saved PDCP SDUs.

[0184] Upon receiving the second indication information, the first network device may send the second indication information to the terminal device, so that the terminal device may discard data packets received from the first network device and stored in the PDCP receive buffer before accessing the second network device. Alternatively, the first network device may send an indication message to the terminal device instructing it to discard data packets received from the first network device and stored in the PDCP receive buffer; for example, the first network device may send the indication message to the terminal device after receiving the first indication information, after sending the first indication information to the second network device, or after receiving a continuous data forwarding request message from the second network device.

[0185] Step 403: The first network device sends a first data stream to the second network device. Correspondingly, the second network device receives the first data stream from the first network device.

[0186] The first data stream can be a data stream corresponding to at least one service bearer, or it can be described as at least one service bearer carrying the first data stream. The first data stream includes multiple consecutive data packets arranged in ascending order of PDCP sequence numbers. This can be understood as the first network device sending the first data stream to the second network device according to a continuous data forwarding rule. The starting data packet in the first data stream is the first data packet that the first network device has sent to the terminal device but has not received an acknowledgment instruction from the terminal device. This can be understood as the first network device starting from the PDCP SDU that has been sent to the terminal device at the first PDCP layer but has not received an acknowledgment instruction from the terminal device, and sending the PDCP SDU and its corresponding PDCP sequence number to the second network device in ascending and consecutive order of PDCP sequence numbers. The acknowledgment instruction from the terminal device can specifically be an ARQ ACK instruction from the RLC layer, or an acknowledgment instruction from another layer, without specific limitations.

[0187] For example, such as Figure 4 As shown, for this AM DRB, the terminal device's PDCP layer receives PDCP PDUs with SN=0, SN=2, and SN=4. However, the terminal device's RLC layer has not yet, or has not had time, sent an acknowledgment command to the first network device. The terminal device does not receive PDCP PDUs with SN=1 and SN=3. The terminal device can successfully decompress the PDCP data packet with SN=0 and deliver the PDCP SDU to the upper-layer entity. At this time, starting from the PDCP SDU with SN=0, the first network device sends PDCP SDUs and their corresponding SNs to the second network device in ascending and consecutive PDCP sequence numbers. For example, it sends PDCP SDUs and their corresponding SNs to the second network device in the order of SN=0, SN=1, SN=2, ...

[0188] In one implementation, the first network device sends a first data stream to the second network device according to a first instruction. This can be understood as the first network device performing continuous data forwarding according to the instruction from the second network device. Optionally, if the first network device has not configured a Data Distribution Center (DDC) for the AM DRB of the terminal device, it determines whether to perform continuous data forwarding based on the instruction from the second network device; otherwise, the first network device performs continuous data forwarding by default.

[0189] In another implementation, the first network device determines whether to perform continuous data forwarding based on its configuration of the terminal device and the configuration of the terminal device by the second network device. If the first network device and / or the second network device configures a Data Distribution Code (DDC) for the AM DRB of the terminal device, the first network device may perform continuous data forwarding; if neither the first nor the second network device configures a DDC for the AM DRB of the terminal device, the first network device may perform... Figure 1a The data forwarding is shown.

[0190] Upon receiving the second indication information, the first network device may send the second indication information to the terminal device. Alternatively, if the first network device does not receive the second indication information, it may generate indication information and send it to the terminal device. This indication information instructs the terminal device to discard data packets received from the first network device and stored in its PDCP receive buffer. For example, the first network device may send an RRC reconfiguration message to the terminal device, which carries the second indication information.

[0191] In one implementation, when a terminal device receives a handover command from a first network device, which includes an indication to discard data packets received from the first network device, it can execute step 404-2 to discard the data packets. Specifically, it can discard data packets received from the first network device and stored in the PDCP receive buffer before accessing the second network device. For example,... Figure 4 As shown, before the terminal device accesses the second network device, the data packets received from the first network device and stored in the PDCP receive buffer are PDCP PDUs corresponding to SN=2 and SN=4. Therefore, the terminal device discards the PDCP PDUs corresponding to SN=2 and SN=4.

[0192] In one implementation, upon receiving a handover command from a first network device, the terminal device can determine whether to execute step 404-2 based on the configurations of the first and second network devices. If the first and / or second network devices configure a DDC for the terminal device's AM DRB, the terminal device can execute step 404-2; if neither the first nor the second network device configures a DDC for the terminal device's AM DRB, the terminal device may not discard the data packets stored in the PDCP receive buffer.

[0193] It should be noted that the embodiments of this application do not limit the order in which steps 403 and 404-2 are executed. For example, steps 403 and 404-2 can be performed simultaneously, or step 404-2 can be executed before step 403.

[0194] Optionally, upon receiving a handover command from the first network device, the terminal device may clear its DDC decompression cache when switching from the first network device to the second network device; or, as instructed by the first / second network device, clear the DDC decompression cache or update it to a specified decompression cache. The decompression cache can also be described as its state.

[0195] For a DRB, if the terminal device has already received a PDCP PDU corresponding to a COUNT, it will discard the newly received PDCP PDU. In step 404-2, the terminal device considers the discarded data packet to be a data packet that has not been received before. Therefore, when the terminal device receives a data packet with the same COUNT from the second network device, it will not discard the data packet, but will save it in the PDCP receive buffer for subsequent processing.

[0196] After dropping a data packet, the terminal device can update the maintained PDCP variables and / or stop the running timer maintained by the PDCP entity based on the dropped data packet. The receiving-side PDCP entity can maintain two PDCP variables, RX_NEXT and RX_DELIV, where RX_NEXT represents the COUNT value of the next expected PDCP SDU, and RX_DELIV represents the COUNT value of the first PDCP SDU that has not yet been delivered to the protocol layer above the PDCP layer. Optionally, the receiving-side PDCP entity can also maintain a timer, t-Reordering, which is used to detect PDCP PDU packet loss. Each time this timer is started, the PDCP entity updates the variable RX_REORD (which represents the COUNT value that triggers t-Reordering). When the timer expires, if there are still data packets with a COUNT value less than RX_REORD that have not been received, the receiving side will no longer wait. Figure 4 For example, for the PDCP receiving side of this AM DRB, RX_DELIV = 1 and RX_NEXT = 5. In step 404-2 above, when the terminal device, as the receiving side, discards data packets stored in the PDCP receive buffer, it can update the variables maintained by the PDCP entity of the terminal device. RX_NEXT can be updated to be equal to RX_DELIV, for example, after the update, RX_NEXT = 1. In addition, the PDCP entity of the terminal device can stop t-Reordering.

[0197] After discarding a data packet, the terminal device updates the maintained PDCP variables to facilitate receiving data packets from the second network device based on the updated PDCP variables.

[0198] In step 404, the second network device sends a second data stream to the terminal device based on the first data stream. Correspondingly, the terminal device receives the second data stream from the second network device.

[0199] In one implementation, if the second network device does not configure DDC for the AM DRB of the terminal device, then the PDCP sequence number of the starting data packet in the second data stream sent by the second network device to the terminal device is the same as the PDCP sequence number of the starting data packet in the first data stream. Since the second network device does not configure DDC for the AM DRB of the terminal device, the second data stream is a data stream that has not undergone PDCP layer compression processing in the second network device; for example, the PDCP layer of the second network device does not perform DDC compression processing on the first data stream.

[0200] For example, with Figure 4 For example, if the starting data packet in the first data stream is a PDCP SDU with SN=0, then the second network device will assemble a new PDCP PDU starting from the PDCP SDU with SN=0 and send the new PDCP PDU to the terminal device. Since the terminal device has already received a data packet with SN=0, when it receives a data packet with SN=0 from the second network device, the terminal device will directly discard the data packet.

[0201] In one implementation, the second network device configures a DDC for the AM DRB of the terminal device. The second data stream can then be a data stream compressed by the PDCP layer on the second network device. The PDCP sequence number of the starting data packet in the second data stream can be the same as the PDCP sequence number of the starting data packet in the first data stream, for example, both being SN=0; or they can be different, for example, the PDCP sequence number of the starting data packet in the second data stream is SN=1, while the PDCP sequence number of the starting data packet in the first data stream is SN=0.

[0202] Optionally, before executing step 404, the terminal device may execute step 404-1 to send a PDCP status report to the second network device. Correspondingly, the second network device receives the PDCP status report from the terminal device.

[0203] The handover command sent by the first network device to the terminal device can instruct the terminal device to report a PDCP status report. The PDCP status report includes a reference PDCP sequence number, which is the PDCP sequence number of the first data packet from the first network device that the terminal device has not received. For example, Figure 4In this context, the reference PDCP sequence number is SN=1. The reference PDCP sequence number can be the COUNT (first missing COUNT, FMC) corresponding to the first unsuccessfully received PDCP data packet waiting to be received in the current PDCP receive buffer.

[0204] Upon receiving a PDCP status report, the second network device can generate a second data stream corresponding to the data stream in the first data stream, starting from the data packet corresponding to the reference PDCP sequence number. For example, if the reference PDCP sequence number is SN=1 and the sequence number of the starting data packet in the first data stream is SN=0, then the second network device can start from the PDCP SDU with SN=1 and send a new PDCP PDU generated by the second network device to the terminal device. When the second network device configures DDC for this AM DRB of the terminal device, the second network device can perform DDC compression starting from the PDCP SDU with SN=1 to generate the second data stream. At this time, the second data stream is a data stream that has undergone PDCP layer compression processing by the second network device.

[0205] Upon receiving the second data stream, the terminal device determines the first data stream to be saved based on the second data stream and saves the first data stream to be saved in the PDCP receive buffer.

[0206] If the second data stream is a data stream that has not undergone PDCP layer compression processing on the second network device, then the terminal device can directly use the second data stream as the first data stream to be saved and save it in the PDCP receive buffer.

[0207] If the second data stream is a data stream that has undergone PDCP layer compression processing on the second network device, then the terminal device can perform PDCP layer decompression processing on the second data stream. For example, if the reference PDCP sequence number reported by the terminal device is SN=1, then after the terminal device receives the PDCP PDU starting from SN=1 from the second network device, after the sorting is completed, it can perform DDC decompression processing and deliver the PDCP SDU to the upper layer entity.

[0208] exist Figure 4 In the illustrated embodiment, the compression mechanism is applied during the mobile handover process. By performing continuous data forwarding through the first network device, packet loss can be avoided when the terminal device receives data from the second network device, thereby achieving lossless data transmission.

[0209] Figure 4The embodiment shown applies the compression mechanism during mobile handover. If this embodiment is applied to the data offloading process, such as the establishment of dual connections, then the handover request message and handover request response message in steps 401 and 402 can be replaced by the secondary node add request message and the secondary node add request confirmation message, respectively.

[0210] Please see Figure 5 This is a flowchart illustrating the data transmission method provided in Embodiment 2 of this application. The method describes an AM DRB based on the mobile handover process. Figure 5 The process shown may include, but is not limited to, the following steps:

[0211] Step 501: The first network device sends a handover request message to the second network device. Correspondingly, the second network device receives the handover request message from the first network device.

[0212] Step 502: The second network device sends a handover request confirmation message to the first network device. Correspondingly, the first network device receives the handover request confirmation message from the second network device.

[0213] The implementation process of steps 501-502 can be found in [reference needed]. Figure 4 The specific descriptions of steps 401-402 in the illustrated embodiment will not be repeated here.

[0214] Step 503: The first network device sends a first threshold value to the second network device. Correspondingly, the second network device receives the first threshold value from the first network device.

[0215] The first threshold can be the sequence number corresponding to the data packet actually sent by the first network device, for example, it can be the maximum SN value corresponding to the data packet. Alternatively, the first threshold can be the PDCP count value corresponding to the data packet actually sent by the first network device, for example, it can be the maximum COUNT value corresponding to the data packet. Both SN and COUNT can be used to represent the sequence number of the data packet.

[0216] In one implementation, the first network device can send a first threshold to the second network device via an SN status transfer message; that is, the first threshold is carried in the SN status transfer message. Specifically, it can be carried in the DRBs Subject To Status Transfer List information element of the SN status transfer message. For example, the specific information element representation can be shown in Table 2 below. In Table 2, the maximum DL COUNT value can represent the first threshold for downlink data transmission.

[0217]

[0218] Table 2

[0219] In another implementation, the first network device can send a first threshold to the second network device via a handover request message, i.e., the first threshold is carried in the handover request message.

[0220] Step 504: The first network device sends a first data stream to the second network device. Correspondingly, the second network device receives the first data stream from the first network device.

[0221] The implementation process of step 504 can be found in [reference needed]. Figure 4 The specific description of step 403 in the illustrated embodiment will not be repeated here.

[0222] Step 505-1: The terminal device discards the data packets received from the first network device and stored in the PDCP receive buffer before accessing the second network device. The implementation process of step 505-1 can be found in [link to documentation]. Figure 4 The specific description of step 404-2 in the illustrated embodiment will not be repeated here.

[0223] Optionally, when switching from the first network device to the second network device, the terminal device may clear its DDC decompression cache; or, as instructed by the first network device / second network device, clear the DDC decompression cache or update it to the specified decompression cache.

[0224] Step 505: The second network device sends a third data stream to the terminal device. Correspondingly, the terminal device receives the third data stream from the second network device.

[0225] In one implementation, after the terminal device switches to the second network device, and before the second network device receives a PDCP status report from the terminal device, it may send a third data stream to the terminal device based on the first data stream. The second network device may assemble a new PDCP PDU starting from the first PDCP SDU forwarded by the first network device and send it to the terminal device. The PDCP sequence number of the data packets in the third data stream is less than or equal to a first threshold, and the third data stream is a data stream that has not undergone PDCP layer compression processing in the second network device.

[0226] For example, the second network device assembles new PDCP PDUs from PDCP SDUs starting at SN=0 and sends them to the terminal device. Taking the second network device configuring DDC for this AM DRB as an example, the second network device sends newly assembled PDCP PDUs starting at SN=0 as data packets without DDC compression. Since the PDCP SDU corresponding to SN=0 has already been successfully received, parsed, and delivered to the upper-layer entity above the PDCP layer by the first network device on the terminal device side, the terminal device can directly discard the PDCP PDU sent by the second network device with SN=0. For PDCP data packets starting at SN=1, the terminal device can receive and store them in the PDCP receive buffer. Since these PDCP data packets sent by the second network device are uncompressed data packets, the terminal device does not need to perform decompression operations based on the decompression buffer after sorting, and can directly deliver them to the upper-layer entity above the PDCP layer, such as the Service Data Adaptation Protocol (SDAP) layer entity and the IP layer entity, etc. The second network device can refer to the first threshold and perform DDC compression on the PDCP SDUs starting from the first threshold before sending them.

[0227] Step 506: The second network device sends a second data stream to the terminal device based on the first data stream. Correspondingly, the terminal device receives the second data stream from the second network device.

[0228] Optionally, in step 506-1, the terminal device sends a PDCP status report to the second network device. The implementation process of step 506-1 can be found in [reference needed]. Figure 4 The specific description of step 404-1 in the illustrated embodiment is as follows: The reference PDCP sequence number included in the PDCP status report is less than or equal to a first threshold. If the PDCP SDU corresponding to SN=FMC has not yet been sent, the second network device can directly compress and send the PDCP SDU starting from SN=FMC. At this time, the terminal device can perform DDC decompression on the PDCP SDU starting from SN=FMC.

[0229] It is understandable that, if the terminal device does not execute step 506-1, the second network device may refer to the first threshold, perform DDC compression on PDCP SDUs starting from the first threshold, and send them; if the terminal device executes step 506-1, the second network device does not refer to the first threshold, but instead refers to the reference PDCP sequence number carried in the PDCP status report to perform DDC compression; if the first network device does not execute step 503, but the terminal device executes step 506-1, the second network device refers to the reference PDCP sequence number carried in the PDCP status report to perform DDC compression.

[0230] exist Figure 5 In the illustrated embodiment, a compression mechanism is applied during mobile handover. Continuous data forwarding via the first network device avoids packet loss when the terminal device receives data from the second network device, thus achieving lossless data transmission. The second network device can perform downlink data transmission without waiting for a PDCP status report, avoiding latency in downlink data transmission.

[0231] As an optional embodiment, the first network device may not inform the second network device of the first threshold. When the second network device receives a PDCP SDU with a serial number (SN) from the first network device, it does not perform DDC compression when grouping PDCP PDUs. Only when the second network device receives a PDCP SDU from the first network device without a SN can it determine that these PDCP SDUs without SNs have not been sent by the PDCP entity on the first network device's side, and these data packets will not be stored in the PDCP receive buffer of the terminal device. The second network device can then perform DDC compression when grouping these PDCP SDUs without SNs into PDCP PDUs.

[0232] As an optional embodiment, if the second network device carries a request message for requesting the first threshold in the handover request confirmation message, then the first network device determines to send the first threshold to the second network device.

[0233] Figure 5 The embodiment shown applies the compression mechanism during mobile handover. If this embodiment is applied to the data offloading process, such as the establishment process of dual connectivity, then the handover request message and handover request response message in steps 501 and 502 can be replaced by the secondary node add request message and the secondary node add request confirmation message, respectively.

[0234] Please see Figure 6 This is a flowchart illustrating the data transmission method provided in Embodiment 3 of this application. The method describes an AM DRB based on the mobile handover process. Figure 6 The process shown may include, but is not limited to, the following steps:

[0235] Step 601: The first network device sends a handover request message to the second network device. Correspondingly, the second network device receives the handover request message from the first network device.

[0236] Step 602: The second network device sends a handover request confirmation message to the first network device. Correspondingly, the first network device receives the handover request confirmation message from the second network device.

[0237] Step 603: The first network device sends a first data stream to the second network device. Correspondingly, the second network device receives the first data stream from the first network device.

[0238] Step 604-1: The terminal device discards the data packets received from the first network device and stored in the PDCP receive buffer before accessing the second network device.

[0239] The implementation process of steps 601-603 can be found in [reference needed]. Figure 4 For a detailed description of steps 401-403 in the illustrated embodiment, see step 604-1. Figure 4 The specific description of step 404-2 in the illustrated embodiment will not be repeated here.

[0240] Optionally, when switching from the first network device to the second network device, the terminal device may clear its DDC decompression cache; or, as instructed by the first network device / second network device, clear the DDC decompression cache or update it to the specified decompression cache.

[0241] Step 605: The second network device sends third instruction information to the terminal device. Correspondingly, the terminal device receives the third instruction information from the second network device.

[0242] The third indication information includes a second threshold. Data packets in the second data stream with PDCP sequence numbers greater than or equal to the second threshold are data packets that have undergone PDCP layer compression processing on the second network device. It can be understood that the second threshold is used to inform the terminal device from which PDCP sequence number corresponding to the PDCP SDU the second network device should begin performing DDC compression.

[0243] For example, the second network device can indicate the second threshold via a PDCP control PDU. See also Figure 6a The diagram illustrates a format of a PDCP control PDU, where the D / C field value of "1" represents a PDCP data PDU and "0" represents a PDCP control PDU; in this embodiment, the value is "0". The PDU type indicates the type of control PDU; a PDU type of 000 indicates a PDCP status report, 001 indicates RoHC feedback, and other values ​​are reserved. In this embodiment, the PDU type can be any value other than 000 and 001; R represents a reserved bit. For example, the third indication information / second threshold can be carried in other control signaling, such as a handover request confirmation message.

[0244] The PDCP data PDU sent by the second network device to the terminal device carries third indication information to indicate the second threshold. Method 1: Carrying the third indication information indicates whether the current PDCP data PDU is the starting point for DDC compression by the second network device. This can be indicated, for example, by reserved bits in the PDCP frame header. Method 2: Carrying the second threshold, indicating that the second network device will start DDC compression from the PDCP SDU corresponding to the second threshold. This can also be indicated, for example, by reserved bits in the PDCP frame header to show whether the PDCP data PDU carries the second threshold.

[0245] Step 606: The second network device sends a second data stream to the terminal device based on the first data stream. Correspondingly, the terminal device receives the second data stream from the second network device.

[0246] The terminal device performs PDCP layer decompression processing based on the second threshold. For example, it performs DDC decompression processing sequentially starting from the data packets corresponding to the second threshold. If the data packets corresponding to the second threshold were previously submitted to the upper layer, the terminal device performs DDC decompression processing on the data packets, updates the decompression buffer, and discards the decompressed PDCP SDUs. Otherwise, it stores them in the PDCP receive buffer, performs DDC decompression after sorting, and submits the PDCP SDUs to the upper layer.

[0247] As an optional embodiment, when the first network device is not configured with DDC and the second network device is configured with DDC, the terminal device does not discard the data packets stored in the PDCP receive buffer. These data packets are received from the first network device and have not undergone DDC compression processing. Therefore, the data packets stored in the PDCP receive buffer are the corresponding PDCPSDUs. After receiving the PDCP status report sent by the terminal device, the second network device sends the PDCP SDUs that the terminal device failed to receive from the first network device. The terminal device performs decompression processing on the PDCP PDUs received from the second network device in sequence to obtain the corresponding PDCP SDUs. The terminal device delivers the PDCP SDUs to the upper layer in sequence.

[0248] For example, the terminal device successfully receives uncompressed data packets with SN=0,2,4 from the first network device. The data packet with SN=0 can be successfully delivered to the upper layer, while the other data packets are stored in the PDCP receive buffer because they are not yet sorted. The terminal device receives compressed data packets with SN=1 and 3 from the second network device. The UE decompresses these data packets in order to obtain the corresponding PDCP SDUs, and then delivers the PDCP SDUs to the upper layer in order.

[0249] exist Figure 6In the illustrated embodiment, the compression mechanism is applied during mobile handover. Continuous data forwarding via the first network device avoids packet loss when the terminal device receives data from the second network device, thus achieving lossless data transmission. The second network device can perform downlink data transmission without waiting for a PDCP status report, avoiding latency in downlink data transmission and the waste of resources caused by sending uncompressed data packets.

[0250] Figure 6 The embodiment shown applies the compression mechanism to the mobile handover process. If this embodiment is applied to the data offloading process, such as the establishment of dual connections, then the handover request message and handover request response message in steps 601 and 602 can be replaced by the secondary node add request message and the secondary node add request confirmation message, respectively.

[0251] Please see Figure 7 This is a flowchart illustrating the data transmission method provided in Embodiment 4 of this application. The method describes an AM DRB based on the mobile handover process. Figure 7 The process shown may include, but is not limited to, the following steps:

[0252] Step 701: The first network device sends a handover request message to the second network device. Correspondingly, the second network device receives the handover request message from the first network device.

[0253] In step 702, the second network device sends a handover request confirmation message to the first network device. Correspondingly, the first network device receives the handover request confirmation message from the second network device.

[0254] The handover request confirmation message may carry request information, which is used to request the transmission of compressed cache information of the first network device. For example, the request information may be "request DDC buffer status transfer", which is used to request the first network device to transmit the DDC buffer status of the first network device to the second network device.

[0255] Optionally, the first network device can be instructed whether to transmit compressed cache information by whether the switch request confirmation message carries request information. For example, carrying request information instructs the first network device to transmit compressed cache information; not carrying request information instructs the first network device not to transmit compressed cache information. Optionally, the value of the bit corresponding to the request information can indicate whether the first network device transmits compressed cache information. For example, a bit value of "1" or "true" instructs the first network device to transmit compressed cache information; a bit value of "0" or "false" instructs the first network device not to transmit compressed cache information.

[0256] In one implementation, the handover request confirmation message may include indication information, which instructs the terminal device to maintain decompression cache information corresponding to the compressed cache information. It is understood that before connecting to the second network device, the terminal device uses the same decompression cache information as the first network device, and after connecting to the second network device, the terminal device continues to use the decompression cache information used when transmitting data with the first network device, according to this indication information.

[0257] In another implementation, the first network device sends a handover request message to the second network device, carrying request information that instructs the first network device to transmit compressed cache information to the second network device. Optionally, the second network device may further indicate to the first network device whether it accepts the request to transmit compressed cache information. When the second network device indicates that it accepts the request to transmit compressed cache information, the first network device transmits compressed cache information to the second network device; otherwise, it determines not to transmit compressed cache information to the second network device.

[0258] In step 703, the first network device sends compressed cache information to the second network device through the interface between the first and second network devices. Correspondingly, the second network device receives the compressed cache information from the first network device.

[0259] The first network device can send compressed cache information to the second network device through a base station inter-interface message. The compressed cache information is the compressed cache information used by the first network device and the terminal device when transmitting data, and may include the compressed cache status.

[0260] Optionally, the inter-base station interface message includes a first threshold, which indicates the PDCP sequence number of the first data packet processed by the first network device for PDCP layer compression based on compressed cache information. When the second network device sends data packets with PDCP sequence numbers less than the first threshold to the terminal device, the second network device may not perform DDC compression on these data packets.

[0261] In step 704, the second network device sends a second data stream to the terminal device based on the compressed cache information. Correspondingly, the terminal device receives the second data stream from the second network device.

[0262] Optionally, in step 704-1, the terminal device sends a PDCP status report to the second network device. Correspondingly, the second network device receives the PDCP status report from the terminal device.

[0263] The second network device, based on compressed cache information, performs PDCP layer compression processing on the first data stream to obtain a second data stream, and then sends the second data stream to the terminal device. The first data stream can be processed by the first network device according to... Figure 1a The data forwarding shown is a data stream. At least one service bearer is used to carry the first data stream.

[0264] For example, with Figure 7 For example, a terminal device successfully receives PDCPPDUs with SN=2 and SN=4 from the first network device, but does not receive PDCP PDUs with SN=1 and SN=3. After connecting to the second network device, the terminal device's decompression cache information remains unchanged. The second network device sends compressed data packets corresponding to the PDCPSDUs with SN=1 and SN=3 to the terminal device based on the PDCP status report. Since the compression cache information used by the second network device is consistent with the compression cache information maintained by the terminal device, the terminal device can correctly decompress the received PDCP PDUs, avoiding packet loss.

[0265] exist Figure 7 In the illustrated embodiment, a compression mechanism is applied during mobile handover. By transmitting the compressed cache information of the first network device to the second network device, packet loss can be avoided when the terminal device receives data from the second network device, thereby achieving lossless data transmission.

[0266] Figure 7 The embodiment shown applies the compression mechanism to the mobile handover process. If this embodiment is applied to the data offloading process, the handover request message and handover request response message in steps 701 and 702 can be replaced by the secondary node add request message and the secondary node add request confirmation message, respectively.

[0267] Figures 4 to 7 The illustrated embodiment uses DDC as an example for downlink data transmission compression mechanism. It also applies to RoHC compression mechanisms for downlink data transmission. For example, if the compression mechanism is RoHC... Figures 4 to 7 In the illustrated embodiment, sending uncompressed data packets can be sending RoHC IR data packets, or the RoHC instance / protocol can maintain the RoHC IR state while sending data packets. The above embodiments are applicable not only to scenarios involving service bearer migration due to inter-site handover or data offloading, but also to other scenarios involving PDCP re-establishment, such as intra-site handover and key updates.

[0268] It should be noted that, in various embodiments of the present invention, the UE sending RoHC IR data packets, or the RoHC instance / protocol maintaining in the RoHC IR state, may refer to the RoHC mode being limited to U mode, or the RoHC mode being limited to O mode, or the RoHC mode being limited to R mode, or the RoHC mode being limited to one of U mode and O mode, or the RoHC mode being limited to one of U mode and R mode, or the RoHC mode being limited to one of O mode and R mode, or the RoHC mode being limited to one of U mode, O mode and R mode.

[0269] The following section uses RoHC as an example to introduce the compression mechanism for uplink data transmission. Using RoHC as an example, the compression mechanism for uplink data transmission is applicable not only to mobile handover scenarios (such as intra-site or inter-site handover) but also to other scenarios involving PDCP re-establishment.

[0270] During intra-site handover, for an AM DRB, if the base station instructs the UE to activate RoHC after PDCP re-establishment, the UE will continuously retransmit or transmit starting from the first PDCP SDU that has not been successfully acknowledged by the RLC layer. These PDCP SDUs need to undergo RoHC processing when assembling into a PDCP PDU, and may carry a newly established RoHC context. If the base station has already successfully received some PDCP SDUs before the handover, it will discard duplicate PDCP PDUs directly after receiving them (determining whether they are duplicate packets based on the SN), and thus will not be able to obtain the RoHC context carried in these PDCP PDUs. When the base station receives a previously non-duplicate PDCP PDU, if this PDCP PDU has been compressed using the newly established RoHC context on the UE side, the base station cannot correctly decompress the PDCP PDU because it has not established the corresponding RoHC context, resulting in data decompression failure. Figure 2a As shown, after PDCP re-establishment is completed, the PDCP PDUs corresponding to SN=101, 102, and 103 sent by the UE carry the RoHC context. The PDCP PDU corresponding to SN=104 is compressed using this RoHC context. When the base station receives the PDCP PDUs corresponding to SN=101, 102, and 103, it considers them to be duplicate data packets and discards them directly. Therefore, the base station cannot correctly decompress the RoHC after receiving the PDCP PDU corresponding to SN=104.

[0271] Furthermore, after PDCP reconstruction, the UE sends PDCP PDUs with SN=101, 102, and 103 (carrying RoHC context) and PDCP PDU with SN=104 (compressed using RoHC context). Due to air interface out-of-order delivery, the gNB receives PDCP PDU with SN=104 first. Since this data packet corresponds to the lower boundary of the receive window, the gNB will directly process the PDU, but the gNB cannot decompress it using RoHC.

[0272] Similarly, the same problem exists for downlink data transmission after the handover. Compared to uplink data transmission, it is equivalent to the roles of the UE and the base station being swapped.

[0273] Therefore, after PDCP is re-established, the UE retransmits data packets that have not been ACKed by RLC. How to prevent the base station from discarding duplicate packets carrying the RoHC context, which would prevent the base station from establishing the RoHC context and thus from decompressing subsequent PDCP PDUs using RoHC, is a technical problem that urgently needs to be solved.

[0274] Please see Figure 7a The following is a flowchart illustrating an uplink data transmission method provided in an embodiment of this application, which may include, but is not limited to, the following steps.

[0275] In step S101, the UE sends UE capability information to the base station. Correspondingly, the base station receives the UE capability information from the UE.

[0276] The UE capability information may include the maintainIR-State capability parameter, which indicates whether the UE supports sending RoHC IR packets after PDCP re-establishment until the first condition is met, or whether the RoHC instance / protocol remains in the RoHC IR state. The name of this capability parameter, maintainIR-State, is only an example and is not limited.

[0277] The period from PDCP re-establishment to the satisfaction of the first condition can be understood as the process from the completion of PDCP re-establishment until the first condition is met. This process begins when PDCP re-establishment is completed and ends when the first condition is met; the first condition is not met during this process.

[0278] In step S102, the base station sends an RRC reconfiguration message to the UE. Correspondingly, the UE receives the RRC reconfiguration message from the base station.

[0279] The RRC reconfiguration message is used to instruct a PDCP entity corresponding to an AM DRB of the UE to re-establish PDCP and activate RoHC. The RRC reconfiguration message may include the maintainIR-StateInPDCP-Reest parameter, which indicates whether the UE should send a RoHC IR data packet after PDCP re-establishment until the first condition is met, or whether the RoHC instance should remain in the RoHC IR state. The name of this configuration parameter, maintainIR-StateInPDCP-Reest, is merely an example and is not intended to be limiting.

[0280] When the base station includes the above parameters in the RRC reconfiguration message, it indicates that the UE needs to send a RoHC IR data packet after PDCP re-establishment until the first condition is met; otherwise, it indicates that the UE does not need to send a RoHC IR data packet during this process. This parameter is optional when re-establishing the PDCP entity of the AM DRB and RoHC is in effect; otherwise, it is not included in the RRC reconfiguration message.

[0281] Upon receiving an RRC reconfiguration message, the UE can either send a RoHC IR data packet after the PDCP re-establishment is complete, or maintain the RoHC instance / protocol in the RoHC IR state.

[0282] Optionally, the base station can also indicate whether the UE needs to send RoHC IR data packets in the above process by the value of this parameter carried in the RRC reconfiguration message. For example, when the parameter is carried and the value is 'true' or '1', it means that the UE needs to send RoHC IR data packets in the above process; when the parameter is 'false' or '0' or is not carried, it means that the UE does not need to send RoHC IR data packets in the above process.

[0283] It should be noted that in one implementation, at least one of steps S101 and S102 is executed, for example, either step S101 or step S102, or both steps S101 and S102. In another implementation, steps S101 and S102 are not executed. In this case, the UE re-establishes the PDCP entity of the AM DRB, and after RoHC takes effect, the RoHC instance / protocol always needs to be maintained in the RoHC IR state, without the need for UE capability support or base station control via parameters.

[0284] In step S103, the UE performs PDCP re-establishment.

[0285] In step S104, the UE starts from the first PDCP SDU that has not been confirmed by the RLC layer and sends data packets to the base station in ascending and continuous order of PDCP sequence number. These data packets are RoHC IR data packets or RoHC instances / protocols maintained in the RoHC IR state.

[0286] For AM DRB, when the UE performs PDCP re-establishment and RoHC takes effect after PDCP re-establishment, the UE sends RoHC IR data packets when retransmitting / sending PDCP SDU, or the UE's RoHC instance / protocol remains in RoHC IR state until the first condition is met.

[0287] The first condition can be one of the following:

[0288] A. Starting with the first PDCP SDU not acknowledged by the RLC layer, all PDCP SDUs that had been assigned a SN before PDCP re-establishment were retransmitted. B. Starting with the first PDCP SDU not acknowledged by the RLC layer, all PDCP SDUs that had been transmitted over the air interface before PDCP re-establishment were retransmitted. C. The UE receives a PDCP status report from the base station, or the UE performs PDCP SDU discard processing on PDCP SDUs indicating successful delivery to the base station based on the received status report. D. The base station receives a first indication signaling message from the base station, indicating that the UE can send non-RoHC IR packets or indicating that the UE's RoHC instance / protocol does not need to be maintained in the RoHC IR state. The first indication signaling message can be carried by a PDCP control PDU.

[0289] The UE is instructed by the base station to take RoHC into effect after PDCP re-establishment, which can be one of the following situations:

[0290] 1) The UE was not configured with RoHC function before PDCP re-establishment. The base station instructed the UE to perform PDCP re-establishment and configured RoHC function through RRC reconfiguration message; 2) The UE had already configured RoHC function before PDCP reconfiguration. The base station instructed the UE to perform PDCP re-establishment and reconfigured relevant RoHC parameters, such as maxCID or profiles, through RRC reconfiguration message; 3) The UE had already configured RoHC function before PDCP reconfiguration. The base station instructed the UE to perform PDCP re-establishment through RRC reconfiguration message and instructed the UE to keep the RoHC header compression protocol unchanged through the drb-ContinueRoHC parameter.

[0291] In step S105, the UE determines whether the first condition is met.

[0292] In step S106, if the first condition is met, the UE sends a non-RoHC IR data packet to the base station, or the RoHC instance / protocol may not be maintained in the RoHC IR state.

[0293] Figure 7a In the illustrated embodiment, after PDCP re-establishment is completed, RoHC takes effect and sends RoHC IR data packets, or the UE's RoHC instance / protocol remains in the RoHC IR state until the first condition is met. After the first condition is met, non-RoHC IR data packets are sent. This can avoid the UE retransmitting too many PDCP data packets carrying the RoHC context after handover, and avoid the receiving side directly discarding duplicate packets. This allows the base station and UE to maintain the synchronization of the RoHC context, and the base station / UE side can successfully perform RoHC decompression on the received compressed data packets.

[0294] Figure 7a The illustrated embodiment can also be applied to downlink data transmission. For example, during mobile handover, the target base station instructs the UE to re-establish PDCP, and RoHC takes effect after the PDCP re-establishment is completed. After the UE completes random access, when the corresponding PDCP entity retransmits / sends the PDCP SDU to the UE, the target base station sends a RoHC IR data packet, or the RoHC instance / protocol of the corresponding PDCP entity of the base station remains in the RoHC IR state until the second condition is met.

[0295] The second condition can be one of the following:

[0296] A. PDCP SDUs carrying SNs forwarded by the source station during data forwarding are all retransmitted; B. The base station receives a PDCP status report sent by the UE, or the base station performs PDCP SDU discard processing on PDCP SDUs that indicate they have been successfully delivered to the base station based on the received PDCP status report.

[0297] If it is an in-station handover scenario, the second condition can also be: starting from the first PDCP SDU that has not been confirmed by the RLC layer, all PDCP SDUs that have been assigned SN before PDCP re-establishment are retransmitted, or all PDCP SDUs that have been transmitted over the air interface before PDCP re-establishment are retransmitted.

[0298] In another uplink data transmission method, for AM DRB, when the UE performs PDCP re-establishment and RoHC takes effect after PDCP re-establishment, the UE starts a timer X after retransmission. When the UE receives a PDCP status report sent by the base station, or when the UE performs PDCPSDU discard processing on the PDCP SDU indicating that it has been successfully delivered to the base station based on the received status report, timer X is stopped.

[0299] While timer X is running, the UE does not retransmit / transmit PDCP SDUs; that is, the UE does not perform RoHC processing and transmission operations on PDCP SDUs. When the timer expires or does not run, the UE can process and transmit PDCP SDUs. Optionally, while timer X is running, the UE transmits data RoHC IR packets or maintains the RoHC instance / protocol in the RoHC IR state. When the timer expires or does not run, the UE can transmit non-RoHC IR data packets, or it is not required that the RoHC instance / protocol be in the RoHC IR state.

[0300] The duration of Timer X can be configured by the base station. For example, the base station can choose to configure the duration of Timer X only when PDCP re-establishment is performed on the AM DRB and RoHC is enabled; otherwise, the base station does not configure it. When the base station does not configure the duration of Timer X, the UE does not need to start Timer X after re-establishment; that is, the UE performs the actions involved in the PDCP re-establishment process defined in the existing protocol. Optionally, when the base station does not configure the duration of Timer X, it can be assumed that the duration of Timer X = 0, that is, Timer X times out immediately after starting. In this case, the UE's actions are consistent whether the duration of Timer X is configured or not.

[0301] Optionally, when reporting its capability information, the UE may include a capability parameter indicating whether it supports timer operation. This parameter could be, for example, maintainTimerX, which indicates whether the UE supports starting timer X after PDCP re-establishment, and is used to control the processing of PDCP SDUs during the timer's runtime. Only when the UE reports support for this timing parameter can the base station configure the timing duration of timer X for the UE. The name maintainTimerX is merely an example and is not limited to this.

[0302] For downlink data transmission, during mobile handover, the target base station instructs the UE to re-establish PDCP, and RoHC takes effect after PDCP re-establishment. After the UE randomly accesses the network, the target base station starts a timer Y. When the base station receives a PDCP status report from the UE, or when the base station performs PDCP SDU discard processing on a PDCPSDU indicating successful delivery to the base station based on the received status report, timer Y stops. While timer Y is running, the base station does not retransmit / transmit PDCPSDUs, i.e., the base station does not perform RoHC processing or transmission operations on PDCP SDUs. When the timer expires or does not run, the base station can process and transmit PDCP SDUs. Optionally, while timer Y is running, the base station only sends RoHC IR data packets or maintains the RoHC instance / protocol in the RoHC IR state; when the timer expires or does not run, the base station can send non-RoHC IR data packets, or does not need to restrict the RoHC instance / protocol to the RoHC IR state.

[0303] In this uplink data transmission method, the UE waits for a period of time after PDCP re-establishment to receive PDCP status reports, thereby reducing the possibility that the UE sends too many duplicate packets that are discarded by the base station, and minimizing the possibility that the base station cannot maintain RoHC context alignment with the UE, which would cause the base station to fail to perform RoHC decompression on the received compressed data packets.

[0304] In another uplink data transmission method, for AM DRB, when the UE performs PDCP re-establishment and RoHC takes effect after PDCP re-establishment, the PDCP receiver (which can be the base station or the UE) can save the data packets received within a period T and reorder these data packets based on the SN. The PDCP receiver parses the reordered data packets in order. If the data packet is determined to be a duplicate received data packet based on the SN, the PDCP receiver performs a RoHC decompression operation before discarding the data packet to obtain the RoHC context that may be carried within it. If the data packet is a data packet within the current PDCP receive window, the UE processes the data packet according to the PDCP receive processing procedure in the existing protocol.

[0305] If the PDCP receiver is at the UE, the aforementioned time T can be configured by the base station. Optionally, the UE can introduce a new capability parameter, such as maintainTimeT, to indicate whether the UE supports the above operations.

[0306] In this method, the PDCP receiver can sequentially obtain the RoHC context carried in the duplicate data packets, thereby avoiding the failure of compressed data packet decompression caused by the inconsistency of the RoHC context between the base station side and the UE side.

[0307] In another uplink data transmission method, for AM DRB, when the UE performs PDCP re-establishment and RoHC takes effect after PDCP re-establishment, the base station sends a PDCP status report to the UE after the UE completes random access. Before confirming that the UE has received the PDCP status report, the base station does not schedule uplink resources for the UE, or for that AM DRB of the UE.

[0308] The base station can determine that the UE has received the PDCP status report in the following ways: Method 1: The UE sends a HARQ ACK response to the TB containing the PDCP status report. Method 2: The UE sends an RLC ACK response to the RLC SDU containing the PDCP status report.

[0309] By employing this scheduling method, the base station can prevent the UE from retransmitting a large number of PDCPSDUs before receiving the PDCP status report, thereby avoiding decompression failure of compressed data packets caused by inconsistencies in the RoHC context between the base station and the UE. Furthermore, in this method, the base station can not completely avoid scheduling uplink resources for the UE, but rather control the frequency of scheduling uplink resources, such as scheduling a maximum of N uplink grants within one radio frame, or scheduling a maximum of M uplink grants with a TBS of M. This method requires no modification to the protocol and is simple and convenient to implement.

[0310] Corresponding to the methods described in the above embodiments, this application also provides corresponding apparatus, including modules for executing the corresponding methods in the above embodiments. The modules may be software, hardware, or a combination of software and hardware.

[0311] Figure 8 A schematic diagram of a communication device is provided. The communication device 800 can be a network device (a first network device or a second network device), a terminal device, a chip, chip system, or processor that supports the network device in implementing the above methods, or a chip, chip system, or processor that supports the terminal device in implementing the above methods. This device can be used to implement the methods described in the above method embodiments; for details, please refer to the descriptions in the above method embodiments.

[0312] The communication device 800 may include one or more processors 801, which may also be referred to as processing units or processing modules, and can implement certain control functions. The processor 801 may be a general-purpose processor or a dedicated processor. A general-purpose processor may be, for example, a central processing unit (CPU), while a dedicated processor may be, for example, a baseband processor. The baseband processor can be used to process communication protocols and communication data, while the CPU can be used to control the communication device (e.g., base station, baseband chip, terminal, terminal chip, distributed unit (DU), or centralized unit (CU), execute software programs, and process data from the software programs.

[0313] In an alternative design, the processor 801 may also store instructions 803, which can be executed by the processor 801 to cause the communication device 800 to perform the method described in the above method embodiments.

[0314] In another alternative design, the processor 801 may include a transceiver unit for implementing receive and transmit functions. For example, this transceiver unit may be a transceiver circuit or an interface. The transceiver circuit, interface, or interface circuitry used to implement receive and transmit functions may be separate or integrated. The aforementioned transceiver circuit or interface may be used for reading and writing instructions, or it may be used for transmitting signals.

[0315] Optionally, the communication device 800 may include one or more memories 802, which may store instructions 804. The instructions 804 can be executed on the processor 801, causing the communication device 800 to perform the methods described in the above method embodiments. Optionally, the memory 802 may also store data. Optionally, the processor 801 may also store instructions and / or data. The processor 801 and the memory 802 may be configured separately or integrated together. For example, the correspondence described in the above method embodiments may be stored in the memory 802 or in the processor 801.

[0316] Optionally, the communication device 800 may also include a transceiver 805 and / or an antenna 806. The transceiver 805 may be referred to as a transceiver unit, transceiver, transceiver circuit, transceiver device, or transceiver module, etc., and is used to implement transceiver functions.

[0317] Optionally, in this embodiment of the application, when the communication device 800 is a terminal device, it may include various functional modules for performing... Figure 4 Steps 404-2, 404-1, and 404 in the above; or Figure 5 Steps 505-1, 505, 506-1, and 506 in the above; or Figure 6Steps 604-1, 604, and 605 in the above; or Figure 7 Steps 704-1 and 704 in the process. When the communication device 800 is a first network device, it can be used to perform... Figure 4 Steps 401 to 403 in the above; or Figure 5 Steps 501 to 504 in the above; or Figure 6 Steps 601 to 603 in the above; or Figure 7 Steps 701 to 703 in the process. When the communication device 800 is a second network device, it can be used to perform... Figure 4 Steps 401 to 403, and steps 404-1 and 404; or Figure 5 Steps 501 to 504, and steps 505, 506-1, and 506; or Figure 6 Steps 601 to 603, and steps 604 and 605; or Figure 7 Steps 701 to 703, and steps 704-1 and 704.

[0318] The processors and transceivers described in this application can be implemented on integrated circuits (ICs). ICs can include analog ICs, radio frequency integrated circuits (RFICs), mixed-signal ICs, application-specific integrated circuits (ASICs), etc. ICs can also be implemented by printing circuits on a printed circuit board (PCB).

[0319] The communication device described in the above embodiments may be a network device or a terminal device, but the scope of the device described in this application is not limited thereto, and the structure of the communication device may vary. Figure 8 The limitations. The communication device can be:

[0320] (1) A standalone integrated circuit IC, or chip, or chip system or its subsystem;

[0321] (2) Receivers, terminals, cellular phones, wireless devices, handheld devices, mobile units, vehicle-mounted devices, network devices, cloud devices, artificial intelligence devices, machinery, home devices, medical devices, industrial devices, etc.

[0322] Figure 9 A schematic diagram of a terminal device is provided. For ease of explanation, Figure 9 Only the main components of the terminal device are shown. For example... Figure 9As shown, the terminal device 900 includes a processor, memory, control circuitry, antenna, and input / output devices. The processor is primarily used for processing communication protocols and data, controlling the entire terminal, executing software programs, and processing software program data. The memory is mainly used to store software programs and data. The radio frequency (RF) circuitry is mainly used for converting baseband signals to RF signals and processing RF signals. The antenna is mainly used for transmitting and receiving RF signals in the form of electromagnetic waves. Input / output devices, such as touchscreens, displays, and keyboards, are mainly used for receiving user input data and outputting data to the user.

[0323] When the terminal device is powered on, the processor can read the software program from the storage unit, parse and execute the instructions of the software program, and process the data of the software program. When data needs to be transmitted wirelessly, the processor performs baseband processing on the data to be transmitted and outputs the baseband signal to the radio frequency (RF) circuit. The RF circuit processes the baseband signal to obtain the RF signal and transmits the RF signal outward in the form of electromagnetic waves through the antenna. When data is sent to the terminal device, the RF circuit receives the RF signal through the antenna. This RF signal is further converted into a baseband signal and output to the processor. The processor converts the baseband signal back into data and processes the data.

[0324] For ease of explanation, Figure 9 Only one memory and processor are shown. In actual terminal devices, multiple processors and memories may exist. Memory can also be called storage medium or storage device, etc., and this application embodiment does not limit this.

[0325] As an optional implementation, the processor may include a baseband processor and a central processing unit (CPU). The baseband processor is mainly used to process communication protocols and communication data, while the CPU is mainly used to control the entire terminal device, execute software programs, and process the data of the software programs. Figure 9 The processor in the device integrates the functions of a baseband processor and a central processing unit (CPU). Those skilled in the art will understand that the baseband processor and CPU can also be independent processors interconnected via technologies such as buses. It will also be understood that a terminal device can include multiple baseband processors to adapt to different network standards, and multiple CPUs to enhance its processing capabilities. The various components of the terminal device can be connected via various buses. The baseband processor can also be described as a baseband processing circuit or a baseband processing chip. Similarly, the CPU can be described as a central processing circuit or a central processing chip. The function of processing communication protocols and communication data can be built into the processor or stored as a software program in a storage unit, with the processor executing the software program to implement the baseband processing function.

[0326] In one example, the antenna and control circuit with transceiver functions can be considered as the transceiver module 911 of the terminal device 900, and the processor with processing functions can be considered as the processing module 912 of the terminal device 900. For example... Figure 9 As shown, the terminal device 900 includes a transceiver module 911 and a processing module 912. The transceiver module can also be referred to as a transceiver, transceiver unit, transceiver device, or transceiver unit, etc. Optionally, the device in the transceiver module 911 used to implement the receiving function can be considered as a receiving module, and the device in the transceiver module 911 used to implement the transmitting function can be considered as a transmitting module; that is, the transceiver module 911 includes a receiving module and a transmitting module. For example, the receiving module can also be referred to as a receiver, receiver circuit, or receiving unit, etc., and the transmitting module can be referred to as a transmitter, transmitter circuit, or transmitting unit, etc. Optionally, the above-mentioned receiving module and transmitting module can be integrated into a single module, or they can be multiple independent modules. The above-mentioned receiving module and transmitting module can be located in one geographical location or distributed across multiple geographical locations.

[0327] like Figure 10 As shown, another embodiment of this application provides a communication device 1000. This device can be a terminal device or a component of a terminal device (e.g., an integrated circuit, a chip, etc.). Alternatively, the device can be a network device (a first network device or a second network device) or a component of a network device (e.g., an integrated circuit, a chip, etc.). The device can also be other communication modules used to implement the methods in the method embodiments of this application. The communication device 1000 may include: a processing module 1001 (or processing unit). Optionally, it may also include a receiving module 1002 (or receiving unit) and a transmitting module 1003 (or transmitting unit). Optionally, it may also include a storage module (or storage unit).

[0328] In one possible design, such as Figure 10 One or more modules may be implemented by one or more processors, or by one or more processors and memory; or by one or more processors and transceivers; or by one or more processors, memory, and transceivers. This application does not limit the implementation in this way. The processors, memory, and transceivers can be configured individually or integrated.

[0329] The communication device 1000 has the functions of the terminal device described in the embodiments of this application. For example, the communication device 1000 includes modules, units, or means corresponding to the steps involved in the terminal device described in the embodiments of this application. These functions, units, or means can be implemented by software, hardware, or hardware executing corresponding software, or a combination of software and hardware. Further details can be found in the corresponding descriptions in the foregoing method embodiments. Alternatively, the communication device 1000 has the functions of the network device described in the embodiments of this application. For example, the communication device 1000 includes a second network device executing modules, units, or means corresponding to the steps involved in the second network device described in the embodiments of this application. These functions, units, or means can be implemented by software, hardware, or hardware executing corresponding software, or a combination of software and hardware. Further details can be found in the corresponding descriptions in the foregoing method embodiments.

[0330] Optionally, each module in the communication device 1000 in this application embodiment can be used to execute the functions described in this application embodiment. Figure 4 , Figure 5 , Figure 6 or Figure 7 The methods described can also be used to perform a combination of the methods described in the two or more diagrams above.

[0331] In one possible design, the communication device 1000 is a second network device, which may include a receiving module 1002 and a transmitting module 1003. The receiving module 1002 can be used to perform... Figure 4 Steps 401, 403, and 404-1 in the illustrated embodiment; Figure 5 Steps 501, 503, 504, and 506-1 in the illustrated embodiment; Figure 6 Steps 601 and 603 in the illustrated embodiment; Figure 7 Steps 701, 703, and 704-1 in the illustrated embodiment. The sending module 1003 can be used to perform... Figure 4 Steps 402 and 404 in the illustrated embodiment; Figure 5 Steps 502, 505, and 506 in the illustrated embodiment; Figure 6 Steps 602, 604, and 605 in the illustrated embodiment; Figure 7 Steps 702 and 704 in the illustrated embodiment.

[0332] In one possible design, the communication device 1000 is a first network device, which may include a receiving module 1002 and a transmitting module 1003. The receiving module 1002 can be used to perform... Figure 4 Step 402 in the illustrated embodiment; Figure 5 Step 502 in the illustrated embodiment; Figure 6 Step 602 in the illustrated embodiment; Figure 7 Step 702 in the illustrated embodiment. The sending module 1003 can be used to perform... Figure 4 Steps 401 and 403 in the illustrated embodiment; Figure 5 Steps 501, 503, and 504 in the illustrated embodiment; Figure 6 Steps 601 and 603 in the illustrated embodiment; Figure 7 Steps 701 and 703 in the illustrated embodiment.

[0333] In one possible design, the communication device 1000 is a terminal device, which may include a receiving module 1002 and a processing module 1001. The receiving module 1002 can be used to perform... Figure 4 Step 404 in the illustrated embodiment; Figure 5 Steps 505 and 506 in the illustrated embodiment; Figure 6 Steps 604 and 605 in the illustrated embodiment; Figure 7 Step 704 in the illustrated embodiment. Processing module 1001 can be used to execute Figure 4 Step 404-2 in the illustrated embodiment; Figure 5 Step 505-1 in the illustrated embodiment; Figure 6 Step 604-1 in the illustrated embodiment. Optionally, the communication device 1000 further includes a transmitting module 1003, which can be used to perform... Figure 4 Step 404-1 in the illustrated embodiment; Figure 5 Step 506-1 in the illustrated embodiment; Figure 7 Step 704-1 in the illustrated embodiment.

[0334] It is understood that some optional features in the embodiments of this application can be implemented independently in certain scenarios without relying on other features, such as the current solution on which they are based, to solve the corresponding technical problems and achieve the corresponding effects. Alternatively, they can be combined with other features as needed in certain scenarios. Correspondingly, the apparatus given in the embodiments of this application can also implement these features or functions, which will not be elaborated here.

[0335] Those skilled in the art will also understand that the various illustrative logical blocks and steps listed in the embodiments of this application can be implemented by electronic hardware, computer software, or a combination of both. Whether such functionality is implemented through hardware or software depends on the specific application and the overall system design requirements. Those skilled in the art can use various methods to implement the described functionality for corresponding applications, but such implementation should not be construed as exceeding the scope of protection of the embodiments of this application.

[0336] It is understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0337] The solutions described in this application can be implemented in various ways. For example, these technologies can be implemented in hardware, software, or a combination of hardware. For hardware implementation, the processing unit for executing these technologies at a communication device (e.g., a base station, terminal, network entity, or chip) can be implemented in one or more general-purpose processors, DSPs, digital signal processing devices, ASICs, programmable logic devices, FPGAs, or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof. The general-purpose processor can be a microprocessor; alternatively, it can also be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented through 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.

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

[0339] It is understood that the term "embodiment" used throughout the specification means that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, various embodiments throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It is understood that in the various embodiments of this application, the sequence number of the above-described processes does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0340] It is understood that in this application, "when," "if," and "if" all refer to the device making a corresponding action under certain objective circumstances, and are not time-limited, nor do they require the device to make a judgment when it is implemented, nor do they imply any other limitations.

[0341] In this application, "simultaneously" can be understood as at the same point in time, within a period of time, or within the same cycle.

[0342] In this application, the use of singular pronouns to denote "one or more" rather than "one and only one," unless otherwise specified. In this application, unless otherwise specified, "at least one" is intended to mean "one or more," and "more than" is intended to mean "two or more."

[0343] Furthermore, the terms "system" and "network" are often used interchangeably in this paper. The term "and / or" in this paper is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three cases: A exists alone, A and B exist simultaneously, and B exists alone. Here, A can be singular or plural, and B can be singular or plural.

[0344] It is understood that in the various embodiments of this application, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0345] The correspondences shown in the tables of this application can be configured or predefined. The values ​​of the information in each table are merely examples and can be configured to other values; this application is not limited to these values. When configuring the correspondences between information and parameters, it is not necessarily required to configure all the correspondences shown in each table. For example, the correspondences shown in some rows of the tables in this application may not be configured. Furthermore, appropriate modifications and adjustments can be made based on the above tables, such as splitting, merging, etc. The names of the parameters shown in the headings of the above tables can also use other names that the communication device can understand, and the values ​​or representations of the parameters can also be other values ​​or representations that the communication device can understand. In the implementation of the above tables, other data structures can also be used, such as arrays, queues, containers, stacks, linear lists, pointers, linked lists, trees, graphs, structures, classes, heaps, hash tables, or hash tables, etc.

[0346] The term "predefined" in this application can be understood as definition, pre-defined, stored, pre-stored, pre-negotiated, pre-configured, solidified, or pre-burned.

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

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

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

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

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

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

[0353] The same or similar parts between the various embodiments in this application can be referred to mutually. In the various embodiments of this application, and in the various implementation methods / methods / implementations within each embodiment, unless otherwise specified or logically conflicting, the terminology and / or descriptions between different embodiments and between the various implementation methods / methods / implementations within each embodiment are consistent and can be mutually referenced. The technical features in different embodiments and the various implementation methods / methods / implementations within each embodiment can be combined according to their inherent logical relationships to form new embodiments, implementation methods, methods, or implementation approaches. The above-described embodiments of this application do not constitute a limitation on the scope of protection of this application.

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

Claims

1. A data transmission method, characterized by, The method is applied to migration of at least one service bearer of a terminal device from a first network device to a second network device, and the method comprises: The second network device receives a first data stream on the at least one service bearer from the first network device; the first data stream comprises a plurality of data packets arranged in ascending order of PDCP sequence numbers and in succession; The second network device sends a second data stream to the terminal device according to the first data stream; the second data stream comprises a plurality of data packets arranged in ascending order of PDCP sequence numbers and in succession; the second data stream comprises a data stream starting from a data packet with a reference PDCP sequence number in the first data stream, the reference PDCP sequence number being a PDCP sequence number of a first data packet from the first network device that has not been received by the terminal device; The starting data packet in the first data stream is a first data packet that has been sent by the first network device to the terminal device but for which no acknowledgement instruction has been received from the terminal device; the first data stream comprises data packets that have been sent by the first network device to the terminal device but for which no acknowledgement instruction has been received from the terminal device and data packets that have been sent by the first network device to the terminal device and for which an acknowledgement instruction has been received from the terminal device.

2. The method of claim 1, wherein, The method further comprises: The second network device sends first indication information to the first network device, the first indication information being used to indicate a forwarding rule, the forwarding rule being to forward data packets in succession in ascending order of PDCP sequence numbers.

3. The method of claim 1, wherein, The method further comprises: The second network device receives request information from the first network device, the request information being used to indicate a forwarding rule, the forwarding rule being to forward data packets in succession in ascending order of PDCP sequence numbers.

4. The method according to any one of claims 1 to 3, characterized in that, The method further comprises: The second network device sends second indication information to the first network device, the second indication information being used to instruct the terminal device to discard data packets received from the first network device before accessing the second network device and saved in a PDCP receiving buffer.

5. The method according to any one of claims 1 to 3, characterized in that, The second network device sends a second data stream to the terminal device according to the first data stream, comprising: The second network device receives status report information from the terminal device, the status report information comprising the reference PDCP sequence number; The second network device generates a second data stream according to the reference PDCP sequence number; The second network device sends the second data stream to the terminal device.

6. The method of claim 5, wherein, The second data stream is a data stream after PDCP layer compression processing by the second network device.

7. The method according to any one of claims 1 to 3, characterized in that, The method further comprises: The second network device receives a first threshold value from the first network device; The second network device sends a third data stream to the terminal device according to the first data stream and the first threshold; a PDCP sequence number of a data packet in the third data stream is less than or equal to the first threshold; and the third data stream is a data stream that has not been compressed by the PDCP layer in the second network device.

8. A data transmission method, characterized by, The method is applied to migration of at least one service bearer of a terminal device from a first network device to a second network device, and the method comprises: The terminal device receives second indication information from the first network device; The terminal device discards, according to the second indication information, a data packet received from the first network device before accessing the second network device and saved in a PDCP receiving buffer; The terminal device receives a second data stream from the second network device; the second data stream comprises a plurality of data packets in ascending order of PDCP sequence numbers; and the second data stream comprises a data stream starting from a data packet with a reference PDCP sequence number in the first data stream, the reference PDCP sequence number being a PDCP sequence number of a first data packet from the first network device that has not been received by the terminal device; The terminal device determines a first to-be-saved data stream according to the second data stream; The terminal device saves the first to-be-saved data stream in the PDCP receiving buffer.

9. The method of claim 8, wherein, The method further comprises: The terminal device updates a PDCP count value of a next expected receiving data packet to a PDCP count value of a first data packet waiting to be submitted to a protocol layer above the PDCP layer according to the discarded data packet.

10. The method according to claim 8 or 9, characterized in that, The method further comprises: The terminal device sends state report information to the second network device, the state report information comprising the reference PDCP sequence number.

11. The method of claim 10, wherein, The second data stream is a data stream compressed by the PDCP layer in the second network device; The terminal device determines a first to-be-saved data stream according to the second data stream, comprising: The terminal device performs PDCP layer decompression processing on the second data stream in ascending order of PDCP sequence numbers to obtain the first to-be-saved data stream.

12. The method of claim 8 or 9, wherein, The method further comprises: The terminal device receives a third data stream from the second network device; the third data stream is a data stream that has not been compressed by the PDCP layer in the second network device; The terminal device discards a data packet in the third data stream that is the same as a data packet saved in the PDCP receiving buffer to obtain a second to-be-saved data stream, and saves the second to-be-saved data stream in the PDCP receiving buffer.

13. A data transmission method, characterized by, The method is applied to migration of at least one service bearer of a terminal device from a first network device to a second network device, and the method comprises: The first network device sends a migration request to the second network device, the migration request being used to request migration of at least one service bearer of the terminal device from the first network device to the second network device; The first network device receives a migration request confirmation from the second network device, and sends a first data stream on the at least one service bearer to the second network device; the first data stream includes a plurality of data packets arranged in ascending order of PDCP sequence numbers and in succession. The starting data packet in the first data stream is the first data packet that the first network device has sent to the terminal device but has not received an acknowledgement instruction from the terminal device; the first data stream includes data packets that the first network device has sent to the terminal device but has not received an acknowledgement instruction from the terminal device and data packets that the first network device has sent to the terminal device and has received an acknowledgement instruction from the terminal device.

14. The method of claim 13, wherein, The method further includes: The first network device receives first indication information from the second network device; the first indication information is used to indicate a forwarding rule, and the forwarding rule is to forward data packets in succession in ascending order of PDCP sequence numbers.

15. The method of claim 13, wherein, The method further includes: The first network device sends a request message to the second network device, and the request message is used to indicate a forwarding rule, and the forwarding rule is to forward data packets in succession in ascending order of PDCP sequence numbers.

16. The method according to any one of claims 13-15, characterized in that, The method further includes: The first network device receives second indication information from the second network device. The first network device sends the second indication information to the terminal device, and the second indication information is used to instruct the terminal device to discard data packets received from the first network device before accessing the second network device and saved in a PDCP receiving buffer.

17. The method according to any one of claims 13-15, characterized by, The method further includes: The first network device sends a first threshold to the second network device; the first threshold is used to limit PDCP sequence numbers of data packets in a third data stream sent by the second network device to the terminal device to be less than or equal to the first threshold; the third data stream is a data stream that has not been compressed by a PDCP layer in the second network device.

18. A second network device, comprising: At least one service bearer of a terminal device is migrated from a first network device to a second network device, and the second network device includes a receiving module and a sending module. The receiving module is configured to receive a first data stream on the at least one service bearer from the first network device; the first data stream includes a plurality of data packets arranged in ascending order of PDCP sequence numbers and in succession. The sending module is configured to send a second data stream to the terminal device according to the first data stream; the second data stream includes a plurality of data packets arranged in ascending order of PDCP sequence numbers and in succession; and the second data stream includes a data stream starting from a data packet with a reference PDCP sequence number in the first data stream, and the reference PDCP sequence number is a PDCP sequence number of a first data packet that the terminal device has not received from the first network device. The starting data packet in the first data stream is the first data packet that has been sent by the first network device to the terminal device but for which no confirmation instruction from the terminal device has been received. The first data stream includes data packets that have been sent by the first network device to the terminal device but for which no confirmation instruction from the terminal device has been received and data packets that have been sent by the first network device to the terminal device and for which a confirmation instruction from the terminal device has been received.

19. A terminal device, comprising: The terminal device includes a receiving module and a processing module. The receiving module is configured to receive second indication information from the first network device. The processing module is configured to discard, according to the second indication information, data packets received from the first network device before accessing the second network device and saved in a PDCP receiving buffer. The receiving module is further configured to receive a second data stream from the second network device. The second data stream includes a plurality of data packets arranged in ascending order of PDCP sequence numbers and in succession. The second data stream includes a data stream starting from a data packet with a reference PDCP sequence number in the first data stream, the reference PDCP sequence number being a PDCP sequence number of the first data packet that has not been received by the terminal device from the first network device. The processing module is further configured to determine a first to-be-saved data stream according to the second data stream and save the first to-be-saved data stream in the PDCP receiving buffer.

20. A first network device, comprising: The first network device includes a sending module and a receiving module. The sending module is configured to send a migration request to the second network device, the migration request being used to request migration of at least one service bearer of the terminal device from the first network device to the second network device. The receiving module is configured to receive a migration request confirmation from the second network device. The sending module is further configured to send a first data stream to the second network device. The first data stream includes a plurality of data packets arranged in ascending order of PDCP sequence numbers and in succession. The starting data packet in the first data stream is the first data packet that has been sent by the first network device to the terminal device but for which no confirmation instruction from the terminal device has been received. The first data stream includes data packets that have been sent by the first network device to the terminal device but for which no confirmation instruction from the terminal device has been received and data packets that have been sent by the first network device to the terminal device and for which a confirmation instruction from the terminal device has been received.

21. A communications device, characterized by The apparatus is configured to perform the method of any one of claims 1 to 7, or configured to perform the method of any one of claims 8 to 12, or configured to perform the method of any one of claims 13 to 17.

22. A communications device comprising: a processor coupled to a memory, the memory for storing a program or instructions, when executed by the processor, cause the apparatus to perform the method of any one of claims 1 to 7, or, perform the method of any one of claims 8 to 12, or, perform the method of any one of claims 13 to 17.

23. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program, when executed, causes a computer to perform the method of any one of claims 1 to 7, or, the method of any one of claims 8 to 12, or, the method of any one of claims 13 to 17.

24. A chip, characterized by a processor coupled to a memory, the memory for storing a program, when executed by the processor, cause the apparatus comprising the chip to perform the method of any one of claims 1 to 7, or, the method of any one of claims 8 to 12, or, the method of any one of claims 13 to 17.

25. A communication system, characterized by The system comprises a second network device performing the method of any one of claims 1 to 7 and a first network device as any one of claims 13 to 17.

Images