CN113543217A

CN113543217A - Data transmission method and communication device

Info

Publication number: CN113543217A
Application number: CN202110062553.XA
Authority: CN
Inventors: 范强; 娄崇
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-04-16
Filing date: 2021-01-18
Publication date: 2021-10-22

Abstract

The embodiment of the application provides a data transmission method and a communication device, which can be applied to a scenario that at least one service bearer of a terminal device is migrated from a first network device to a second network device. Wherein, the method can comprise the following steps: the second network equipment receives a first data flow on at least one service bearer from the first network equipment, wherein the first data flow comprises a plurality of continuous data packets which are arranged from small to large according to the sequence of the PDCP sequence numbers, and a starting data packet in the first data flow is a first data packet which is sent to the terminal equipment by the first network equipment but does not receive a confirmation instruction from the terminal equipment; and the second network equipment sends a second data stream to the terminal equipment according to the first data stream, wherein the second data stream comprises a plurality of continuous data packets which are arranged in the sequence from the small to the large of the PDCP sequence number. By adopting the embodiment of the application, the terminal equipment can obtain continuous and complete data flow in the service bearing migration process or after the service bearing migration process is completed.

Description

Data transmission method and communication device

Technical Field

The present application relates to the field of communications technologies, and in particular, to a data transmission method and a communications apparatus.

Background

In a mobile communication system, the coverage area of one base station is limited, and during the process that a terminal device moves from the coverage area of the base station to the coverage area of another base station, at least one service bearer can be migrated to the another base station, so as to ensure the service quality of data transmission on the at least one service bearer. The base station to which the terminal device is connected before migration may be referred to as a source base station, and the base station to which the terminal device is connected after migration may be referred to as a target base station. The process of migrating all the service bearers of the terminal device to the target base station is also called a mobile handover process of the terminal device in different base stations. And after the switching is finished, the terminal equipment releases the resources distributed by the source base station.

In the migration process of at least one service bearer, the source base station may perform a data forwarding (data forwarding) process with the target base station, so as to send, to the terminal device, service data that the source base station has not sent or has not successfully sent to the terminal device through the target base station. However, how to forward data is a technical problem to be solved.

Disclosure of Invention

The application provides a data transmission method and a communication device, which realize data forwarding in a migration scene of service bearing, so that terminal equipment can obtain continuous and complete data streams.

A first aspect of the present application provides a data transmission method, which is applied to a scenario in which at least one service bearer of a terminal device is migrated from a first network device to a second network device. The method may be performed by the second network device, or may be performed by an apparatus (e.g., a processor or a chip, etc.) in the second network device. The method, taking the second network device as an example, includes the following.

The second network equipment receives a first data stream carried by at least one service from the first network equipment, wherein the first data stream comprises a plurality of continuous data packets which are arranged in the sequence from small to large according to a Packet Data Convergence Protocol (PDCP) sequence number; and sending a second data stream to the terminal equipment according to the first data stream, wherein the second data stream comprises a plurality of continuous data packets which are sequenced from small to large according to the PDCP sequence number.

The initial data packet in the first data stream is a first data packet which is sent to the terminal equipment by the first network equipment but does not receive a confirmation instruction from the terminal equipment; the first data flow comprises a data packet which is sent to the terminal equipment by the first network equipment but does not receive the confirmation instruction from the terminal equipment and a data packet which is sent to the terminal equipment by the first network equipment and receives the confirmation instruction from the terminal equipment.

In the first aspect of the present application, in the service bearer migration process, the second network device sends the data stream to the terminal device according to the data stream forwarded by the continuous data of the first network device, so as to ensure that the terminal device receives the continuous and complete data stream, and reduce the data packet loss.

In a possible implementation manner, the second network device sends first indication information to the first network device, where the first indication information is used to indicate a forwarding rule, and the forwarding rule is to continuously forward data packets according to a sequence from a small PDCP sequence number to a large PDCP sequence number. The forwarding rule may be understood as a continuous data forwarding rule, and the second network device instructs the first network device to perform continuous data forwarding through the first indication information, so as to ensure that the second network device and the first network device understand consistently how to perform data forwarding, so that the terminal device may receive a continuous and complete data stream during or after the migration process of the service bearer is completed.

In a possible implementation manner, the second network device receives request information from the first network device, where the request information is used to indicate a forwarding rule, and the forwarding rule is to forward data packets continuously according to the sequence of the PDCP sequence numbers from small to large. It can be understood that the first network device requests to perform continuous data forwarding through the request message, and if the second network device agrees, the first network device performs continuous data forwarding and sends the first data stream to the second network device, and the second network device sends the second data stream to the terminal device according to the first data stream, so as to ensure that the second network device and the first network device understand consistently how to perform data forwarding, so that the terminal device can receive a continuous and complete data stream in a service bearer migration process or after the migration process is completed.

In a possible implementation manner, the second network device sends second indication information to the first network device, where the second indication information is used to instruct the terminal device to discard a data packet that is directly received from the first network device and stored in the PDCP receive buffer before accessing the second network device, so that when the terminal device receives a second data stream from the second network device, the terminal device determines, according to the second data stream, a data stream stored in the PDCP receive buffer, and avoids the terminal device receiving a duplicate data packet.

The first indication information and the second indication information may be transmitted in the same message, for example, may be carried in a handover request acknowledgement message in a mobile handover procedure.

In a possible implementation manner, the second network device receives status report information from the terminal device, where the status report information includes a reference PDCP sequence number, and the reference PDCP sequence number is a PDCP sequence number of a first data packet from the first network device that is not received by the terminal device; generating a second data flow, wherein the second data flow comprises the data flow starting from the data packet which refers to the PDCP sequence number in the first data flow; and sending the second data stream to the terminal equipment. And the second network equipment generates a second data stream according to the reference PDCP serial number and sends the second data stream to the terminal equipment, so that the second network equipment is prevented from sending the data packet which is already received by the terminal equipment to the terminal equipment.

In a possible implementation manner, the second data stream sent by the second network device to the terminal device is a data stream after the second network device has undergone PDCP layer compression processing. The second data flow is compressed at the second network device through the PDCP layer, so as to implement data forwarding during the migration process, and the terminal device can receive a scheme of continuous and complete data flow, and further apply the compression mechanism to the migration process of the service bearer, thereby implementing the data transmission efficiency of continuous data forwarding.

In a possible implementation manner, the second network device receives the first threshold from the first network device, and sends a third data flow to the terminal device according to the first data flow and the first threshold, where a PDCP sequence number of a packet in the third data flow is less than or equal to the first threshold, and the third data flow is a data flow that is not subjected to PDCP layer compression processing in the second network device. When receiving the third data stream, the terminal device directly delivers the third data stream to a protocol layer above the PDCP layer without decompressing the third data stream, so as to improve the processing efficiency.

In a possible implementation manner, the second network device sends third indication information to the terminal device, where the third indication information is used to indicate the second threshold, and a data packet with a PDCP sequence number greater than or equal to the second threshold in the second data stream is a data packet after the second network device has undergone PDCP layer compression processing. The second network device informs the terminal device of the third indication information that the packet with the PDCP sequence number starting from the second threshold is a packet after the PDCP layer decompression processing, so that the terminal device can perform the PDCP layer decompression processing according to the second threshold, and the terminal device can directly determine the packet from which the decompression processing is started without trying to determine many times.

In a possible implementation manner, the second data flow sent by the second network device to the terminal device is a data flow that is not subjected to the PDCP layer compression processing at the second network device, and a PDCP sequence number of a starting data packet in the second data flow is the same as a PDCP sequence number of a starting data packet in the first data flow. It can be understood that, the second network device forwards all the first data stream received from the first network device to the terminal device, and does not perform PDCP layer compression on the forwarded first data stream, so that when the terminal device receives the data stream forwarded by the second network device, the terminal device may not perform PDCP layer decompression on the data stream, and the processing efficiency may be improved.

A second aspect of the present application provides a data transmission method, which is applied to a scenario in which at least one service bearer of a terminal device is migrated from a first network device to a second network device. The method may be performed by the terminal device, or may be performed by an apparatus (e.g., a processor or a chip) in the terminal device. The method includes the following.

The terminal equipment receives second indication information from the first network equipment, and discards a data packet which is received from the first network equipment and stored in a PDCP receiving cache before accessing the second network equipment according to the second indication information; receiving a second data flow from a second network device, wherein the second data flow comprises a plurality of data packets which are sequenced and continuous from small to large according to the PDCP sequence number; determining a first data stream to be stored according to the second data stream; and storing the first data flow to be stored in a PDCP receiving buffer.

In the second aspect of the present application, the terminal device discards the data packet according to the second indication information, so that the terminal device can be prevented from receiving the repeated data packet. Since the second data stream includes a plurality of consecutive data packets ordered in the order of the PDCP sequence number from small to large, the terminal device can quickly obtain a continuous and complete data stream without reordering.

In one possible implementation, the terminal device updates the PDCP count value of the next expected received packet to the PDCP count value of the first packet waiting to be delivered to the protocol layer above the PDCP layer according to the discarded packet, so that the terminal device can normally receive the second data flow from the second network device.

In a possible implementation manner, the terminal device sends status report information to the second network device, where the status report information includes a reference PDCP sequence number, where the reference PDCP sequence number is a PDCP sequence number of a first data packet that is not received by the terminal device from the first network device, and thus a PDCP sequence number of a starting data packet in a second data stream that is received by the terminal device from the second network device is the reference PDCP sequence number. It can be understood that, when the second network device sends the second data stream to the terminal device according to the status report information, the second network device can avoid sending the data packet that has been received by the terminal device to the terminal device.

In a possible implementation manner, the second data stream received by the terminal device from the second network device is a data stream after the second network device has undergone PDCP layer decompression processing, and the terminal device performs PDCP layer decompression processing on the second data stream according to a sequence in which PDCP sequence numbers are consecutive from small to large, so as to obtain the first data stream to be stored. Even if the second data stream is a data stream after the second network device is subjected to the PDCP layer compression processing, the terminal device can perform decompression processing on the terminal device through the corresponding PDCP layer to obtain a complete data stream, thereby reducing the loss of data packets.

In a possible implementation manner, the terminal device receives a third data stream from the second network device, where the third data stream is a data stream that is not subjected to PDCP layer compression processing in the second network device, and discards a data packet in the third data stream that is the same as a data packet stored in the PDCP receiving buffer to obtain a second data stream to be stored, and stores the second data stream to be stored in the PDCP receiving buffer. This prevents the terminal device from receiving duplicate packets.

In a possible implementation manner, the terminal device receives third indication information from the second network device, where the third indication information is used to indicate a second threshold, and a data packet with a PDCP sequence number greater than or equal to the second threshold in the second data stream is a data packet after being compressed by a PDCP layer in the second network device; and according to the sequence that the PDCP sequence numbers are from small to large and are continuous, carrying out PDCP layer decompression processing on the data packets corresponding to the PDCP sequence numbers which are greater than or equal to the second threshold value in the second data flow to obtain the first data flow to be stored. The second network device informs the terminal device of the PDCP layer compression process to be performed from which packet through the third indication information, so that the terminal device performs the corresponding PDCP layer decompression process, so that the terminal device does not have to try multiple times to determine from which packet to perform the decompression process.

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

A third aspect of the present application provides a data transmission method, which is applied to a scenario in which at least one service bearer of a terminal device is migrated from a first network device to a second network device. The method may be performed by the first network device, or may be performed by an apparatus (e.g., a processor or a chip) in the first network device. The method takes the first network device as an example and comprises the following contents.

The method comprises the steps that a first network device sends a migration request to a second network device, wherein the migration request is used for requesting to migrate at least one service bearer of a terminal device from the first network device to the second network device; receiving a migration request confirmation from the second network equipment, and sending a first data flow to the second network equipment, wherein the first data flow comprises a plurality of continuous data packets which are sequenced from small to large according to the PDCP sequence number;

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

The migration request may be a handover request message in a mobile handover process, and correspondingly, the migration request acknowledgement may be a handover request acknowledgement message; the migration request may also be a offloading request message in an offloading process, for example, a secondary base station addition request message, and correspondingly, the migration request acknowledgement may be an offloading request acknowledgement message, for example, a secondary base station addition acknowledgement message.

In a possible implementation manner, the first network device receives first indication information from the second network device, where the first indication information is used to indicate a forwarding rule, and the forwarding rule is to forward data packets continuously according to a sequence from a smaller PDCP sequence number to a larger PDCP sequence number. The second network device instructs the first network device to perform continuous data forwarding through the first indication information, so as to ensure that the second network device and the first network device understand how to perform data forwarding consistently, so that the terminal device can receive continuous and complete data streams during or after the migration process of the service bearer is completed.

Wherein the first indication information may be carried in a migration request acknowledgement.

In a possible implementation manner, the first network device sends a request message to the second network device, where the request message is used to indicate a forwarding rule, and the forwarding rule is to continuously forward data packets according to a sequence from a PDCP sequence number to a PDCP sequence number. The first network device requests continuous data forwarding through the request message to ensure that the second network device and the first network device have consistent understanding on how to forward data, so that the terminal device can receive continuous and complete data streams in the migration process of the service bearer or after the migration process is completed. Optionally, the first network device performs continuous data forwarding when receiving a response message from the second network device, where the response message is used for responding to the request message, and indicates that the second network device agrees to the first network device to perform continuous data forwarding.

The request message may be the migration request, or the request message is carried in the migration request.

In a possible implementation manner, the first network device receives second indication information from the second network device, and sends the second indication information to the terminal device, where the second indication information is used to indicate the terminal device to discard a data packet that is 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 a duplicate data packet.

In a possible implementation manner, the first network device sends a first threshold to the second network device, where the first threshold is used to limit that a PDCP sequence number of a packet in a third data flow sent by the second network device to the terminal device is less than or equal to the first threshold, and the third data flow is a data flow that is not subjected to PDCP layer compression processing at the second network device. Therefore, when receiving the third data stream, the terminal device does not need to decompress the third data stream, and directly delivers the third data stream to a protocol layer above a PDCP layer, so as to improve the processing efficiency.

A fourth aspect of the present application provides a data transmission method, which is 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 may be performed by the second network device, or may be performed by an apparatus (e.g., a processor or a chip, etc.) in the second network device. Taking the second network device as an example, the method includes:

the second network equipment receives the compressed cache information from the first network equipment; performing PDCP layer compression processing on a first data flow on at least one service bearer based on the compression cache information to obtain a second data flow; sending the second data stream to the terminal equipment; wherein the first data stream is from a first network device.

In the fourth aspect of the present application, the first network device directly sends the compression cache information used by the first network device to the second network device, so that the second network device can use the compression cache information to perform PDCP layer compression on the first data stream, so that the compression cache information used by the second network device matches with the decompression cache information used by the terminal device, and the terminal device can successfully perform PDCP layer decompression when receiving the second data stream from the second network device, thereby implementing lossless transmission of data and avoiding loss or damage of data packets when the compression mechanism is applied to the migration process of service bearers.

In a possible implementation manner, the second network device receives status report information from the terminal device, where the status report information includes PDCP sequence numbers of data packets from the first network device that are not received by the terminal device; and performing PDCP layer compression processing on the first data stream based on the compression cache information and the status report information. The second network device performs PDCP layer decompression according to the status report information from the terminal device and the compression buffer information from the first network device, so that the terminal device can avoid receiving repeated packets, and the terminal device can successfully perform PDCP layer decompression.

In a possible implementation manner, the second network device sends indication information to the first network device, where the indication information is used to indicate the terminal device to maintain decompression cache information corresponding to the compression cache information. The first network device may send the indication information to the terminal device, so that the decompression cache information used by the terminal device for the data packet from the second network device is the same as the decompression cache information used for the data packet from the first network device, so that the terminal device may quickly obtain the data packet from the second network device.

In a possible implementation manner, the second network device receives a first threshold from the first network device, where the first threshold is used to instruct the first network device to perform a PDCP sequence number of a first packet of a PDCP layer compression process based on the compression cache information, so that the terminal device performs a PDCP layer decompression process based on decompression cache information corresponding to the compression cache information according to the first threshold.

In a possible implementation manner, the second network device sends a third data flow to the terminal device, a PDCP sequence number of a packet in the third data flow is less than or equal to a first threshold, and the third data flow is a data flow that is not subjected to PDCP layer compression processing in the second network device, so that it is clear that decompression processing is not required through the first threshold, and thus processing efficiency can be improved.

A fifth aspect of the present application provides a data transmission method, which is 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 may be performed by the terminal device, or may be performed by an apparatus (e.g., a processor or a chip) in the terminal device. Taking a terminal device as an example, the method comprises the following steps:

the terminal equipment receives a second data stream from second network equipment, wherein the second data stream is a data stream obtained by carrying out PDCP layer compression processing on the first data stream based on the compression cache information; decompressing the second data stream to obtain a first data stream to be stored; and storing the first data flow to be stored in a PDCP receiving buffer.

In the fifth aspect of the present application, since the compressed cache information adopted by the second network device is the same as the compressed cache information adopted by the first network device, the terminal device does not need to determine the decompressed cache information again, can quickly obtain the data packet from the second network device, and can realize lossless transmission of data and avoid loss or damage of the data packet in the migration process of applying the compression mechanism to the service bearer.

In a possible implementation manner, the terminal device sends status report information to the second network device, where the status report information includes PDCP sequence numbers of data packets that the terminal device has not received from the first network device, so that the second network device sends the second data stream to the terminal device according to the status report information.

In a possible implementation manner, the terminal device maintains the decompression cache information corresponding to the compression cache information according to the received indication information; and decompressing the first data stream based on the decompression cache information to obtain a first data stream to be stored. Therefore, the decompression cache information adopted by the terminal equipment is matched with the compression cache information adopted by the second network equipment, and the terminal equipment can quickly obtain continuous and complete data flow.

In a possible implementation manner, the terminal device receives a third data stream from the second network device, where the third data stream in the third data stream is a data stream that is not subjected to PDCP layer compression processing in the second network device; the third data flow is stored in the PDCP receiving buffer without decompression, so that the processing efficiency of the third data flow can be improved.

A sixth aspect of the present application provides a communication apparatus, which may be a second network device or an apparatus in the second network device. In one design, the apparatus may include a module corresponding to the method/operation/step/action described in the first aspect or the fourth aspect and various possible implementations, and the module may be a hardware circuit, a software circuit, or a combination of a hardware circuit and a software circuit. In one design, the apparatus may include a receiving module and a transmitting module.

In an exemplary manner, the first and second electrodes are,

a receiving module, configured to receive a first data flow on at least one service bearer from a first network device, where the first data flow includes a plurality of consecutive data packets arranged in a descending order of PDCP sequence numbers;

the sending module is used for sending a second data stream to the terminal equipment according to the first data stream; the second data flow comprises a plurality of continuous data packets which are sequenced from small to large according to the PDCP sequence number;

A seventh aspect of the present application provides a communication device comprising a processor configured to implement the method described in the first or fourth aspect. The apparatus may also include a memory to store instructions and data. The memory is coupled to the processor, and the processor, when executing the instructions stored in the memory, may cause the apparatus to implement the method described in the first aspect and the various possible implementations of the first aspect, or the fourth aspect and the various possible implementations of the fourth aspect. The apparatus may further include a communication interface, which is used for the apparatus to communicate with other devices, for example, the communication interface may be a circuit hardware module such as a transceiver and a bus, and the other devices may be terminal devices. In one possible design, the apparatus includes:

a memory for storing program instructions;

a processor, configured to receive a first data flow on at least one traffic bearer from a first network device, where the first data flow includes a plurality of consecutive data packets arranged in a descending order of PDCP sequence numbers; sending a second data stream to the terminal equipment according to the first data stream; the second data flow comprises a plurality of continuous data packets which are sequenced from small to large according to the PDCP sequence number;

An eighth aspect of the present application provides a computer-readable storage medium comprising instructions that, when executed on a computer, cause the computer to perform the first aspect and each of the possible implementations of the first aspect, or the methods provided by the fourth aspect and each of the possible implementations of the fourth aspect.

A ninth aspect of the present application provides a chip system, which includes a processor and may further include a memory, and is configured to implement the first aspect and each of the possible implementations of the first aspect, or the method provided by each of the possible implementations of the fourth aspect and the fourth aspect. The chip system may be formed by a chip, and may also include a chip and other discrete devices.

A tenth aspect of the present application provides a communication apparatus, which may be a terminal device or an apparatus in a terminal device. In one design, the apparatus may include a module corresponding to performing the method/operation/step/action described in the second aspect and the various possible implementations of the second aspect, or the fifth aspect and the various possible implementations of the fifth aspect, where the module may be a hardware circuit, a software circuit, or a combination of a hardware circuit and a software circuit. In one design, the apparatus may include a receiving module and a processing module. In an exemplary manner, the first and second electrodes are,

a receiving module, configured to receive second indication information from the first network device;

the processing module is used for discarding the data packet which is received from the first network equipment and stored in the PDCP receiving cache before the second network equipment is accessed according to the second indication information;

the receiving module is further configured to receive a second data stream from the second network device, where the second data stream includes a plurality of consecutive data packets that are ordered in the sequence from the small to the large according to the PDCP sequence number;

the processing module is further used for determining a first data stream to be stored according to the second data stream; and storing the first data flow to be stored in a PDCP receiving buffer.

An eleventh aspect of the present application provides a communication apparatus comprising a processor configured to implement the methods described in the second aspect and the various possible implementations of the second aspect, or the fifth aspect and the various possible implementations of the fifth aspect. The apparatus may also include a memory to store instructions and data. The memory is coupled to the processor, and the processor, when executing the instructions stored in the memory, may cause the apparatus to implement the methods described in the second aspect and the various possible implementations of the second aspect, or the fifth aspect and the various possible implementations of the fifth aspect. The apparatus may further include a communication interface for the apparatus to communicate with other devices, for example, a transceiver, a bus, and other circuit hardware modules, and other devices may be network devices. In one possible design, the apparatus includes:

a memory for storing program instructions;

a processor for receiving second indication information from the first network device; discarding the data packet which is received from the first network equipment and stored in the PDCP receiving buffer before accessing the second network equipment according to the second indication information; receiving a second data flow from a second network device, wherein the second data flow comprises a plurality of data packets which are sequenced and continuous from small to large according to the PDCP sequence number; the first data stream to be stored is determined according to the second data stream; and storing the first data flow to be stored in a PDCP receiving buffer.

A twelfth aspect of the present application provides a computer-readable storage medium comprising instructions that, when executed on a computer, cause the computer to perform the second aspect and each of the possible implementations of the second aspect, or the methods provided by each of the possible implementations of the fifth aspect and the fifth aspect.

A thirteenth aspect of the present application provides a chip system, which includes a processor and may further include a memory, and is configured to implement the second aspect and each of the possible implementations of the second aspect, or the method provided by each of the possible implementations of the fifth aspect and the fifth aspect. The chip system may be formed by a chip, and may also include a chip and other discrete devices.

A fourteenth aspect of the present application provides a communication apparatus, which may be a first network device or an apparatus in the first network device. In one design, the apparatus may include a module corresponding to performing the method/operation/step/action described in each possible implementation manner of the third aspect and the third aspect, and the module may be a hardware circuit, a software circuit, or a combination of a hardware circuit and a software circuit. In one design, the apparatus may include a transmitting module and a receiving module.

In an exemplary manner, the first and second electrodes are,

a sending module, configured to send a migration request to a second network device, where the migration request is used to request that at least one service bearer of a terminal device be migrated from a first network device to the second network device;

a receiving module, configured to receive a migration request acknowledgement from a second network device;

the sending module is further used for sending the first data stream to the second network equipment; the first data flow comprises a plurality of continuous data packets which are arranged from small to large according to the PDCP sequence number;

A fifteenth aspect of the present application provides a communications apparatus comprising a processor configured to implement the methods described in the third aspect and in each possible implementation manner of the third aspect. The apparatus may also include a memory to store instructions and data. The memory is coupled to the processor, and the processor, when executing the instructions stored in the memory, may cause the apparatus to implement the methods described in the third aspect and the various possible implementations of the third aspect. The apparatus may further include a communication interface, which is used for the apparatus to communicate with other devices, for example, the communication interface may be a circuit hardware module such as a transceiver and a bus, and the other devices may be terminal devices. In one possible design, the apparatus includes:

a memory for storing program instructions;

the processor is used for sending a migration request to the second network equipment, wherein the migration request is used for requesting to migrate at least one service bearer of the terminal equipment from the first network equipment to the second network equipment; receiving a migration request acknowledgement from the second network device; sending the first data stream to a second network device; the first data flow comprises a plurality of continuous data packets which are arranged from small to large according to the PDCP sequence number;

A sixteenth aspect of the present application provides a computer-readable storage medium comprising instructions that, when executed on a computer, cause the computer to perform the third aspect and the methods provided by the various possible implementations of the third aspect.

A seventeenth aspect of the present application provides a chip system, where the chip system includes a processor and may further include a memory, and is configured to implement the method provided in the third aspect and each possible implementation manner of the third aspect. The chip system may be formed by a chip, and may also include a chip and other discrete devices.

An eighteenth aspect of the present application provides a communication system including a first network device and a second network device, where 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 third aspect and the methods provided in the various possible implementations of the third aspect. In one design, the communication system includes a second network device to implement the methods provided by the fourth aspect and various possible implementations of the fourth aspect.

Drawings

FIG. 1a is an exemplary diagram of a mobile handoff process;

FIG. 1b is an exemplary diagram of a dual connectivity architecture;

FIG. 1c is a diagram illustrating an example of a dual connectivity architecture in which a MN adds SNs to a UE;

fig. 2 is a diagram illustrating an example of data forwarding for downlink transmission;

fig. 2a is an exemplary diagram of data forwarding for uplink transmission;

FIG. 3 is a schematic diagram of a network architecture to which embodiments of the present application are applied;

fig. 4 is a schematic flowchart of a data transmission method according to an embodiment of the present application;

fig. 5 is a schematic flowchart of a data transmission method according to a second embodiment of the present application;

fig. 6 is a schematic flowchart of a data transmission method according to a third embodiment of the present application;

FIG. 6a is a diagram illustrating a format of a PDCP control PDU;

fig. 7 is a schematic flowchart of a data transmission method according to a fourth embodiment of the present application;

fig. 7a is a schematic flowchart of an uplink data transmission method according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a communication device according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of a terminal device according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a communication device according to an embodiment of the present application.

Detailed Description

In order to better understand the technical solutions provided by the embodiments of the present application, first, technical terms related to the embodiments of the present application are introduced.

(1) Migration procedure of service bearer

The migration process of the service bearer refers to a process of migrating at least one service bearer of the terminal device from one base station to another base station. Before migration, a base station serving at least one service bearer of the terminal device may be referred to as a source base station; after the migration, the base station serving the at least one traffic bearer of the terminal device may be referred to as a target base station. Wherein, at least one service bearer may be all service bearers that the terminal device is running, and all service bearers of the terminal device are migrated from the source base station to the target base station, which may be referred to as a mobile handover procedure of the terminal device; or may be a part of all the service bearers in which the terminal device is operating, where the operating service bearers include, for example, a high definition video service and a Voice over Internet Protocol (VoIP) service, the VoIP service may be migrated from the source base station to the target base station, and the service bearer of the high definition video service still remains in the source base station, which may be a data offloading scenario of the terminal device.

In one possible implementation, the mobile handover procedure of the terminal device may be as shown in fig. 1a, and may include the following steps.

Step 1, measurement control and reporting. The source base station configures a measurement process for the terminal equipment, and the terminal equipment reports based on the measurement configuration.

Before the terminal device disconnects from the source base station, the terminal device may perform uplink transmission, for example, the terminal device sends a data packet to the source base station, and the source base station forwards the data packet to a User Plane Function (UPF) in a core network; before the terminal device disconnects from the source base station, the terminal device and the source base station may also perform downlink transmission, for example, the UPF sends a data packet to the source base station, and the source base station forwards the data packet to the terminal device.

And step 2, determining whether to switch. And the source base station determines whether the terminal equipment needs to be switched or not based on the measurement report reported by the terminal equipment.

Step 3, if the switching is needed, the source base station sends a switching request (handover request) message to the target base station; accordingly, the target base station receives the handover request message from the source base station.

And step 4, access control. The target base station executes access control, and determines whether to allow the terminal device to access according to the connectable number or load of the target base station.

Step 5, if the terminal equipment is allowed to access, the target base station performs handover preparation and sends a handover request acknowledgement (handover request acknowledge) message to the source base station; correspondingly, the source base station receives a switching request confirmation message from the target base station; the handover request confirm message may include a Radio Resource Control (RRC) reconfiguration message generated by the target base station for the terminal device, where the RRC reconfiguration message includes a configuration required by the terminal device to access the target base station.

And 6, switching and initializing the access network side. And the source base station sends a switching command to the terminal equipment, wherein the switching command comprises the RRC reconfiguration message sent by the target base station. The terminal equipment executes switching according to the switching command: the terminal device disconnects from the source base station and accesses to the target base station through a random access process.

And 7, in order to ensure the continuity of the service during switching, the source base station transmits data to the target base station (data forwarding). For downlink data forwarding, the source base station may deliver a data packet that is not sent or is not successfully transmitted (a confirmation instruction of the terminal device is sent but not received) to the target base station, and the target base station continues to send the data packet to the terminal device; for uplink data forwarding, the source base station may send the PDCP out-of-order data packet received from the UPF to the target base station, and the target base station performs PDCP reordering.

And 8, finishing the switching. The terminal equipment finishes the switching process by sending an RRC reconfiguration complete message to the target base station.

After step 8, the terminal device may perform uplink transmission, for example, the terminal device sends a data packet to the target base station, and the target base station forwards the data packet to the UPF; downlink transmission may also be performed, for example, the UPF sends a data packet to the target base station, and the target base station forwards the data packet to the terminal device.

In another possible implementation manner, in a data offloading scenario, due to reasons such as too much service required to be provided for the terminal device by the source base station, which results in too heavy load, a part of service bearers of the terminal device may be migrated from the source base station to the target base station, and the target base station provides services for the part of service bearers of the terminal device. In a data offloading scenario, a source base station may also be referred to as a Master Node (MN), and a target base station may also be referred to as a Secondary Node (SN). When the MN adds an SN to a terminal device (e.g., a user equipment, UE) to form a dual-connectivity (DC) architecture as shown in fig. 1b, a new service bearer, e.g., a Data Radio Bearer (DRB), may 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 exemplary diagram of adding a SN for a UE by a MN can be seen in fig. 1c, which may include the following steps:

in step 1, the MN sends a SN Addition Request message, such as a SN Addition Request, to the SN. The SN addition request message is used for requesting the SN to be a part of service bearing service of the UE.

And step 2, if the SN agrees to serve the UE, sending a SN Addition Request acknowledgement message, such as an SN Addition Request Ack, to the MN. The SN addition request acknowledgement message may carry SN RRC configuration information generated for the UE to access the SN.

And step 3, the MN sends RRC connection reconfiguration information to the UE, and can carry SN RRC configuration information.

And step 4, the UE sends an RRC connection reconfiguration completion message to the MN, and the SN RRC configuration completion can be carried.

And step 5, the MN sends a SN reconfiguration completion message to the SN, and the SN RRC configuration completion can be carried.

And 6, the UE executes a random access process to access the SN.

Step 7 and step 8, the MN forwards data to the SN, and the specific process is similar to the data forwarding process in fig. 1 a.

Step 9-step 12, path update procedure. Part of the traffic bearer of the UE is migrated from the corresponding transport tunnel between the MN and the UPF to the transport tunnel between the SN and the UPF. The transmission tunnel may be a GPRS Tunneling Protocol (GTP) tunnel established according to each Protocol Data Unit (PDU) session.

(2) Data forwarding (data forwarding)

For service data with higher reliability requirement, the terminal device is usually configured with an Acknowledged Mode (AM) Data Radio Bearer (DRB) (i.e., a DRB configured with AM Radio Link Control (RLC)) on the air interface side for data transmission. The AM DRB may ensure reliability of packet transmission through an RLC automatic repeat request (ARQ) mechanism, and also needs to ensure lossless transmission of data during the migration process. In the migration process, for example, with downlink data transmission, for a Packet Data Convergence Protocol (PDCP) unit that has been sent by an AM DRB in a Packet Data Convergence Protocol (PDCP) layer of a source base station but has not been confirmed to be sent successfully, the source base station needs to forward the Service Data Unit (SDU) to a target base station through an inter-base station interface, and the PDCP layer of the target base station sends the Service Data Unit (SDU) to a terminal device. The above procedure may be referred to as the data forwarding procedure of AM DRB.

Both a PDCP COUNT (COUNT) value and a PDCP Sequence Number (SN) may be used to indicate a sequence number of a PDCP SDU or PDCP PDU, the COUNT is 32 bits (bit) in length, the SN is the lower 12 bits or the lower 18 bits of the COUNT, and a Hyper Frame Number (HFN) is a portion of the COUNT except for the SN, i.e., the upper 20 bits or the upper 14 bits of the COUNT.

The source base station transmits SN and HFN states of uplink/downlink PDCP SDUs to the target base station through an SN state transfer (status transfer) message, and transmits the uplink/downlink PDCP SDUs to the target station through data forwarding.

For downlink transmission:

the source base station can inform the target base station through an SN status transfer message, and the COUNT value which is required to be distributed corresponding to the next downlink PDCP SDU without distributed SN of the AM DRB; when performing downlink data forwarding, the source base station first sends all PDCP SDUs that do not receive Acknowledgement (ACK) from the terminal device and corresponding SNs to the target base station, and then sends PDCP SDUs received from the UPF to the target base station. The target base station firstly forms PDCP SDUs with SNs forwarded by the source base station into a first PDCP PDU set (the first PDCP PDU set can comprise one or more PDCP PDUs), and sends the first PDCP PDU set to the terminal equipment; and then, the PDCP SDUs forwarded by the source base station without the SNs are formed into a second PDCP PDU set (the second PDCP PDU set can comprise one or more PDCP PDUs), and the second PDCP PDU set is sent to the terminal equipment. If the target base station receives the PDCP status report from the terminal equipment, the target base station can determine which PDCP PDUs corresponding to the SNs are successfully received by the terminal equipment and which PDCP PDUs corresponding to the SNs are not successfully received by the terminal equipment according to the PDCP status report. For the PDCP PDUs which have been successfully received by the terminal device but have not been fed back to the source base station, the target base station does not need to send the PDCP PDUs to the terminal device. After receiving the PDCP PDU which is not successfully or successfully transmitted by the source base station from the target base station and analyzing the PDCP PDU, the terminal device may reorder the PDCP SDUs in the PDCP receiving buffer and deliver the corresponding PDCP SDUs to the upper layer of the PDCP layer in sequence.

For example, refer to the exemplary diagram of data forwarding in downlink shown in fig. 2, which takes a mobile handover procedure as an example. In fig. 2, when the terminal device disconnects from the source base station, on the terminal device side, for one 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 fed back an acknowledgement instruction to the source base station, and the PDCP PDU corresponding to SN 0 has been delivered to the upper layer of the PDCP layer; and the PDCP PDUs with SN 1 and SN 3 have not been received. At this time, the source base station may forward PDCP SDUs with SN 1 and SN 3 to the target base station when performing downlink data forwarding; the target base station generates new PDCP PDUs from the PDCP SDUs with SN 1 and SN 3 (one PDCP SDU may constitute one PDCP PDU), and transmits the new PDCP PDUs to the terminal device. The terminal device receives PDCP PDUs corresponding to SN 1 and SN 3 from the target base station, and may deliver PDCP SDUs starting from SN 1 to an upper layer of the PDCP layer in sequence.

For uplink transmission:

if the target base station does not request the source base station to perform data forwarding, or the source base station does not accept an uplink data forwarding request from the target base station, the source base station may discard all out-of-order PDCP SDUs received from the terminal device; if the source base station receives an uplink data forwarding request of the target base station, the source base station may notify the target base station through an SN status transfer message that the first non-received PDCP PDU corresponds to a COUNT value, and a bit sequence indicating a receiving status of the PDCP SDU of the source base station, where an nth bit of the bit sequence indicates a receiving status of an nth PDCP SDU subsequent to the first non-received PDCP SDU, for example, a bit value of the receiving status is 1 indicating that the receiving is successful, and a bit value of the receiving status is 0 indicating that the receiving is not received. The target base station may generate a PDCP status report using the part of the information in the SN status transfer message and send the PDCP status report to the terminal device.

And when performing data forwarding, the source base station sends the received out-of-order PDCP SDU and the corresponding SN to the target base station.

And when the base station indicates the terminal equipment to switch, the base station indicates the terminal equipment to perform PDCP reestablishment. After finishing the PDCP re-establishment, the terminal device continuously retransmits or transmits PDCP SDUs to the target base station in ascending order from the first PDCP SDU which does not receive the acknowledgement feedback from the source base station (which may be a feedback indicating successful reception of acknowledgement data by the RLC layer of the source base station). If the terminal device receives the PDCP status report sent by the target base station, for the PDCP SDU indicated in the PDCP status report as successfully received, the terminal device performs a PDCP SDU discard (discard) procedure, i.e., discards the PDCP SDU and the corresponding PDCP SDU.

For example, referring to an exemplary diagram of data forwarding for uplink transmission shown in fig. 2a, taking an intra-station handover (that is, a terminal device switches a Primary cell (Pcell) in one base station, and a source base station and a target base station are the same base station) process as an example, uplink data processing of the terminal device in a handover process is described. After the PDCP re-establishment is completed, the terminal device continuously transmits to the base station PDCP PDUs grouped by the PDCP SDUs with SN 101,102,103,104,105 101,102,103,104,105 …, starting from the first packet not acknowledged by the RLC layer, i.e. the PDCP SDU with SN 101. In fact, the base station has successfully received the PDCP SDU with SN 101,102,103,105 before, and has not yet had time to feed back the RLC status report, but the terminal device still retransmits the data packets. At this time, the base station receives the PDCP PDUs with the repeated SNs 101,102, and 103 and discards them without analysis.

Optionally, the base station may send a downlink PDCP status report to the terminal device, where the COUNT corresponding to the first non-received PDCP SDU is 104, and a bitmap, where each bit corresponds to a receiving status of each PDCP SDU after the PDCP SDU corresponding to the FMC in sequence, 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 sent by the base station, the terminal device may perform PDCP SDU discard operation based on the information in the status report, thereby reducing the sending of duplicate packets.

(3) Compression mechanism

In order to enhance uplink coverage and improve the utilization rate of uplink resources, an Uplink Data Compression (UDC) mechanism may be used.

In the UDC mechanism, a compression side needs to maintain a compression cache, and a decompression side needs to maintain a decompression cache. The compression side compresses a data packet to be compressed based on a compression cache, and the basic principle is that if a character string exists in the data packet and the character string exists in the compression cache, the position and length information of the character string in the compression cache are used for replacing the character string in the data packet; the decompression side decompresses the compressed data packet based on the decompression cache, and the basic principle is to take out the corresponding character string from the decompression cache by using the character string position and the length information indicated in the compressed data packet to reconstruct the original data packet. Based on the above description, it can be seen that when the compression buffer used by the compression side to compress the data packet a and the decompression buffer used by the decompression side to decompress the compressed packet a contain completely consistent data contents, the correct decompression of the data packet a can be ensured. After an original data packet is compressed by the compression mechanism, the compression side updates the compression cache by using the original data packet, specifically, pushes the original data packet into a compression cache based on First In First Out (FIFO) operation to be used as a character string in the compression cache used when the next original data packet is compressed. If the size of the compressed buffer is fixed, data previously stored in the compressed buffer may be pushed out of the compressed buffer due to capacity overload. Similarly, the decompression side decompresses the compressed data packet to obtain an original data packet, and similarly updates the decompression cache by using the original data packet to serve as a character string in the decompression cache used when the next compressed data packet is decompressed.

Based on the above description, the sequence of decompressing the compressed data packets by the decompressing side must be completely consistent with the sequence of compressing the data packets by the compressing side; the occurrence of packet loss during transmission will cause failure of decompression of subsequent packets of the dropped packets. In a Long Term Evolution (LTE) system, the UDC mechanism may only be configured for AM DRB to perform uplink data transmission compression.

To avoid cache inconsistencies that result in data decompression failures, UDC introduces a checking mechanism. Before a data packet is compressed by a compression side, a 4-bit checksum (checksum) is generated by using the current compression cache state and is carried in the UDC header of the compressed data packet. Before decompressing a compressed data packet, a decompression side first generates checksum based on a current decompression cache state, and compares the generated checksum with the checksum carried in the compressed packet, if the generated checksum is consistent, decompression operation can be performed, and if the generated checksum is inconsistent, it indicates that a compression side cache and a decompression side cache are out of step, and cache alignment needs to be performed again.

The UDC is a compression mechanism, and robust header compression (RoHC) is another compression mechanism.

Internet Protocol (IP) is generally used above a protocol stack of a mobile communication system, and thus data transmitted in an actual mobile communication network is mostly IP packets. For an IP data stream distinguished by five packets of < source IP address, source port, destination IP address, destination port and transport layer protocol >, the number field in the IP header is fixed and unchanged, so to improve the radio resource utilization, the IP header can be compressed, wherein the IP header compression protocol adopted in LTE and New Radio (NR) networks is RoHC protocol. In the RoHC protocol, the compression side needs to send a compression context to the decompression side in a data packet, and after the decompression side is sure to receive the compression context, it performs compression on the subsequent data packet. Context may be information that can be used for IP header compression or decompression, such as possible values of compressible fields. Different context information may be distinguished by a Context ID (CID).

There are several modes in the RoHC mechanism: u mode, O mode, and R mode. In the U mode, the compression side sends L (L is a preset positive integer) times to one context, and the decompression side is ensured to successfully receive without receiving feedback of the decompression side; in the O mode and the R mode, the compression side receives feedback from the decompression side to be sure that the context reception is successful. The RoHC mechanism always works from U mode and can be switched to other modes by the control of the decompression side. In each mode, there are three states on the compression side, namely an Initial and Refresh (IR) state, a middle state (FO), and a desired State (SO). The compression side sends RoHC IR packets in the IR state, which carry the complete IP header.

In the current protocol, the network can reconfigure RoHC when instructing the terminal device to perform PDCP re-establishment. In RoHC reconfiguration, the drb-conteinurohc parameter can indicate whether the RoHC header compression protocol is reset or kept unchanged (i.e., RoHC context) at PDCP re-establishment time.

The compression mechanism according to the embodiment of the present application is applied to downlink data transmission, and may be a Downlink Data Compression (DDC) compression mechanism that is the same as the UDC compression mechanism, a RoHC compression mechanism, or another compression mechanism, such as an Ethernet Header Compression (EHC) compression mechanism that compresses an Ethernet header, without specific limitations. In the embodiment of the present application, a compression mechanism for downlink data transmission is mainly described by taking DDC as an example. The DDC functions similarly to the UDC, except that the DDC is for downstream data and the UDC is for upstream data. The compression mechanism for uplink data transmission is mainly described by taking the RoHC mechanism as an example.

In order to improve the utilization rate of the downlink resources, an uplink compression mechanism may be used for transmitting downlink data. However, as described above, when the compression mechanism is applied to the service bearer migration process, it may cause the terminal device to fail to decompress the downlink data, resulting in packet loss and failing to receive the complete downlink data.

Example 1, the DDC mechanism is adopted for the transmission of downlink data, and a mobile handover procedure is taken as an example. Assuming that the source base station configures the DDC for the terminal device for downlink data transmission, the target base station may reconfigure the DDC for the terminal device for downlink data transmission during handover, or not configure the DDC for the terminal device for downlink data transmission. Taking fig. 2 as an example, data packets from SN 0 to SN 4 are sequentially compressed by the source base station and transmitted to the terminal device. The terminal device successfully receives the data packets with SN being 0, SN being 2 and SN being 4, and does not receive the data packets with SN being 1 and SN being 3. According to the data forwarding process, the source base station forwards the PDCP SDUs with SN 1 and SN 3 to the target base station, and the target base station forms a new PDCP PDU to be sent to the terminal equipment. However, the PDCP PDU corresponding to SN 1 formed by the target base station is different from the PDCP PDU corresponding to SN 1 formed by the source base station (for example, the target base station reconfigures the DDC, and both the compression buffer and the decompression buffer are empty, the compression buffer used when the source base station compresses the PDCP SDU with SN 1 is different from the compression buffer used when the target base station compresses the PDCP SDU with SN 1, so that the compressed PDCP PDU is different), so that the terminal device cannot successfully decompress SN 2 and the subsequent PDCP PDUs, resulting in packet loss, and thus failing to receive complete downlink data.

Example 2, the transmission of downlink data adopts a RoHC mechanism, and takes a mobile handover procedure as an example. Taking fig. 2 as an example, a data packet with SN ═ 1 sent by the source base station carries context information, and a data packet with SN ═ 2 is compressed according to the context information; in the mobile handover process, the terminal device does not receive the data packet with SN 1, and then the source base station forwards the PDCP SDU with SN 1 to the target base station when performing data forwarding, and the target base station forms a new PDCP PDU and sends the new PDCP PDU to the terminal device. The PDCP PDU corresponding to SN 1 formed by the target base station may not carry context information, which results in that the terminal device cannot decompress the data packet with SN 2, resulting in packet loss, and thus failing to receive complete downlink data.

Currently, a terminal device receives a first data stream from one network device and a second data stream from another network device, where the first data stream and the second data stream have a dependency relationship, for example, in a migration process of a service bearer, the terminal device receives the data streams out of order and discontinuously. In view of this, embodiments of the present application provide a data transmission method and a communication device, which can implement data forwarding during a service bearer migration process, and enable a terminal device to obtain a continuous and complete data stream.

In the drawings in the embodiments of the present application, the steps shown in each embodiment and the sequence between the steps are used for example and do not constitute a limitation to the embodiments of the present application. It should be understood that the specific implementation of some steps or the order of adjusting the steps in the figures is within the scope of the present application.

The techniques described in this embodiment may be used in various communication systems, such as a 4th generation (4G) communication system, a 4.5G communication system, a 5G communication system, a system in which multiple communication systems are merged, or a future-evolution communication system. For example, LTE systems, NR systems, wireless fidelity (WiFi) systems, time-sensitive networking (TSN) systems, Integrated Access and Backhaul (IAB) systems, and the like, have been developed for communication systems organized by 3rd generation partnership project (3 GPP).

The terminal device (also referred to as a terminal) related to the embodiment of the application may be a device with a wireless transceiving function, and may be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; can also be deployed on the water surface (such as a ship and the like); and may also be deployed in the air (e.g., airplanes, balloons, satellites, etc.). The terminal device may be a User Equipment (UE), wherein the UE includes a handheld device, a vehicle-mounted device, a wearable device, or a computing device having a wireless communication function. Illustratively, the UE may be a mobile phone (mobile phone), a tablet computer, or a computer with wireless transceiving function. The terminal device may also be a Virtual Reality (VR) terminal device, an Augmented Reality (AR) terminal device, a smart car (smart vehicle) terminal device, a wireless terminal in industrial control, a wireless terminal in unmanned driving, a wireless terminal in telemedicine, a wireless terminal in a smart grid, a wireless terminal in a smart city (smart city), a wireless terminal in a smart home (smart home), and so on. In the embodiment of the present application, the apparatus for implementing the function of the terminal device may be the terminal device; it may also be a device, such as a chip system, capable of supporting the terminal device to realize the function, and the device may be installed in the terminal device or used in cooperation with the terminal device, such as a processor. In the technical solution provided in the embodiment of the present application, a device for implementing a function of a terminal device is taken as an example of a terminal device, and the technical solution provided in the embodiment of the present application is described.

By way of example, and not limitation, in the present application, the terminal may be a wearable device. Wearable equipment can also be called wearable intelligent equipment, is the general term of applying wearable technique to carry out intelligent design, develop the equipment that can dress to daily wearing, like glasses, gloves, wrist-watch, dress and shoes etc.. A wearable device is a portable device that is worn directly on the body or integrated into the clothing or accessories of the user. The wearable device is not only a hardware device, but also realizes powerful functions through software support, data interaction and cloud interaction. The generalized wearable smart device includes full functionality, large size, and can implement full or partial functionality without relying on a smart phone, such as: smart watches or smart glasses and the like, and only focus on a certain type of application functions, and need to be used in cooperation with other devices such as smart phones, such as various smart bracelets for physical sign monitoring, smart jewelry and the like.

In the application, the terminal may be a terminal in an internet of things (IoT) system, the IoT is an important component of future information technology development, and the main technical feature of the IoT is to connect an article with a network through a communication technology, so as to implement an intelligent network of human-computer interconnection and article-object interconnection. The terminal in the present application may be a terminal in Machine Type Communication (MTC). The terminal of the present application may be an on-board module built into a vehicle as one or more components or units, through which the vehicle may implement the method of the present application. Therefore, the embodiments of the present application may be applied to vehicle networking, such as vehicle to vehicle (V2X), vehicle communication long term evolution (LTE-V), vehicle to vehicle (V2V), and the like.

The network device according to the embodiment of the present application may include a Base Station (BS), which may be a device deployed in a radio access network and capable of performing wireless communication with a terminal device. The base station may have various forms, such as a macro base station, a micro base station, a relay station, an access point, and the like. For example, the network device related to the embodiment of the present application may be a base station in 5G or a base station in Long Term Evolution (LTE), where the base station in 5G may also be referred to as a Transmission Reception Point (TRP) or a next generation base station Node (gNB). In the embodiment of the present application, the apparatus for implementing the function of the network device may be a network device; or may be a device, such as a system-on-chip, capable of supporting a network device to implement the function, and the device may be installed in the network device or used in cooperation with the network device, such as a processor. In the embodiment of the present application, the chip system may be composed of a chip, and may also include a chip and other discrete devices. In the technical solution provided in the embodiment of the present application, a device for implementing a function of a network device is taken as an example of a network device, and the technical solution provided in the embodiment of the present application is described.

Please refer to fig. 3, which is a schematic diagram of a network architecture to which the present invention is applied. 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 the form and number of the apparatuses shown in fig. 3 are for example and do not limit the embodiments of the present application.

The first network device 301 may be a source base station in the migration process of the service bearer, and the second network device 302 may be a target base station in the migration process. The first network device 301 may migrate at least one traffic bearer of the terminal device 303 from the first network device 301 to the second network device 302. For example, in the mobile handover process, when it is determined that the terminal device 303 moves from the coverage of the first network device 301 to the coverage of the second network device 302, the first network device 301 may handover at least one service bearer of the terminal device 303 from the first network device 301 to the second network device 302, and the second network device 302 provides a service for the at least one service bearer of the terminal device 303. For another example, when the load of the first network device 301 is excessive, at least one service bearer of the terminal device 303 may be switched from the first network device 301 to the second network device 302, and the second network device 302 provides a service for the at least one service bearer of the terminal device 303.

The service bearer may include, but is not limited to, a bearer of high definition video service, VoIP service, Internet Protocol Television (IPTV) service, voice communication service, and the like.

In an implementation manner, in the migration process of the service bearer, the first network device 301 may perform continuous data forwarding and send data to the second network device 302; when receiving the continuous data forwarding data, the second network device 302 sends data to the terminal device 303 according to the continuous data forwarding data. The first network device 301 performs continuous data forwarding, and even if the DDC configured by the second network device 302 is different from that of the first network device 301, the terminal device 303 can be prevented from losing packets when receiving downlink data, so that lossless transmission of data can be realized.

In another implementation, during the service bearer migration process, the first network device 301 may notify the second network device 302 of the compression cache information of the first network device 301, and the second network device 302 may perform PDCP layer compression processing on the data packet based on the compression cache information, so that the compression cache information used by the second network device 302 is the same as the compression cache information used by the first network device 301 and corresponds to the decompression cache information used by the terminal device before the service bearer migration. In this way, the terminal device 303 can decompress the data packet sent by the second network device 302 successfully, so as to avoid packet loss, thereby implementing lossless transmission of data.

The data transmission method provided by the embodiment of the present application will be described below with reference to the accompanying drawings. It should be noted that, in the description process, names of information or data interacted between the terminal device and the network device are used for example, and do not form a limitation on the embodiment of the present application.

Please refer to fig. 4, which is a flowchart illustrating a data transmission method according to an embodiment of the present application. The method describes an AM DRB based on a mobile handover procedure. The flow shown in fig. 4 may include, but is not limited to, the following steps:

step 401, a first network device sends a handover request message to a second network device. Accordingly, the second network device receives a handover request message from the first network device.

And the first network equipment sends a switching request message to the second network equipment when determining that the terminal equipment needs to be switched. The handover request message is used to request to establish a connection between the second network device and the terminal device, so as 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 may be all service bearers currently performed by the terminal device, or may be a part of all service bearers.

Step 402, the second network device sends a handover request acknowledge message to the first network device. Accordingly, the first network device receives a handover request acknowledge message from the second network device.

And the second network equipment performs switching and sends a switching request confirmation message to the first network equipment if the second network equipment agrees to establish connection with the terminal equipment under the condition of receiving the switching request message.

In one implementation, the handover request acknowledge message may include first indication information, where the first indication information is used to indicate a forwarding rule, and the forwarding rule is to continuously forward the data packets according to the sequence of the PDCP sequence numbers from small to large. The first indication information may instruct the first network device to send the data packet to the second network device according to the forwarding rule. It can be understood that the forwarding rule is continuous data forwarding, and the first indication information is used to indicate that the first network device performs continuous data forwarding on the downlink data packet, and sends the data packet to the second network device.

For example, when the first network device configures a DDC function for the AM DRB, or the second network device determines to configure a DDC function for the AM DRB, the second network device may carry the first indication information in the handover request acknowledgement message, for example, the first indication information may be a continuous data forwarding indication. Optionally, whether the first network device needs to perform continuous data forwarding may be indicated by whether the handover request acknowledgement message carries the first indication information. For example, when the first indication information is carried, the first network device is indicated to need to perform continuous data forwarding; and if the first indication information is not carried, indicating that the first network equipment 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 value of the bit corresponding to the first indication information is "1" or "true", which indicates that the first network device needs to perform continuous data forwarding; the value of the bit corresponding to the first indication information is "0" or "false", which indicates that the first network device does not need to perform continuous data forwarding.

The continuous data forwarding indication may be used to indicate each AM DRB, that is, one AM DRB may correspond to one continuous data forwarding indication. For example, the specific cell representation can be as shown in table 1 below.

TABLE 1

The data forwarding response DRB list shown in table 1 may be the data forwarding response DRB list indicated in the data forwarding info from target NG-RAN node cell included in the handover request acknowledgement message sent by the second network device to the first network device. In the embodiment of the application, the data forwarding response DRB list comprises a continuous data forwarding indication which can indicate whether the DRB indicated by the DBR ID needs continuous data forwarding of the first network equipment; alternatively, the continuous data forwarding indication may be applicable to the terminal device, that is, the continuous data forwarding indication is applicable to all AM DRBs of the terminal device.

The first indication information may be carried in the handover request acknowledgement message, or may be carried in another message sent by the second network device to the first network device. And the second network equipment indicates the first network equipment to perform continuous data forwarding through the first indication information.

In another implementation, a first network device sends a request message to a second network device, where the request message is used to indicate a forwarding rule, and the forwarding rule is to continuously forward data packets according to a sequence from a PDCP sequence number to a PDCP sequence number. It can be understood that the first network device actively informs the second network device through the request message, and the first network device will perform continuous data forwarding. Optionally, the second network device may further indicate to the first network device whether to accept the continuous data forwarding request; when the second network equipment indicates to accept the continuous data forwarding requests, the first network equipment continuously forwards the data packets according to the sequence of the PDCP sequence numbers from small to large, otherwise, the first network equipment does not perform continuous data forwarding.

In the two implementation manners, the first network device performs continuous data forwarding, that is, for the AM DRB, the first network device sends PDCP SDUs and corresponding PDCP sequence numbers to the second network device in a sequence from small to large and continuous PDCP sequence numbers from the PDCP SDU that the first PDCP layer has sent to the terminal device but has not received the acknowledgement instruction from the terminal device. Wherein, the PDCP sequence number may be a COUNT value or an SN value. On the contrary, the first network device does not perform continuous data forwarding, which means that for the AM DRB, the first network device sends PDCP SDUs to the second network device according to the data forwarding in fig. 1a, that is, the first network device sends PDCP SDUs, which have been sent to the terminal device but have not received the acknowledgement instruction from the terminal device, and corresponding SN values to the second network device.

For example, when the terminal device disconnects from the first network device, at the terminal device side, for one AM DRB, PDCP PDUs corresponding to SN 0, SN 2, and SN 4 have been successfully received, and the RLC layer of the terminal device has fed back an acknowledgement instruction to the first network device, and the PDCP PDU corresponding to SN 0 has been delivered to the upper layer; and the PDCP PDUs with SN 1 and SN 3 have not been received. According to data forwarding in fig. 1a, the first network device forwards PDCP SDUs with SN 1 and SN 3 to the second network device. If the PDCP SDUs with SN 1, SN 2, and SN 3 are forwarded by the first network device to the second network device according to the consecutive data forwarding.

As can be seen, in data forwarding in fig. 1a, the PDCP sequence numbers of forwarded data packets are not consecutive, but the PDCP sequence numbers of forwarded data packets are consecutive in the consecutive data forwarding provided in this application. Continuous can be understood as a PDCP sequence number without discontinuity.

In one implementation, the handover request acknowledge message may further include second indication information, where the second indication information is used to indicate that the terminal device discards a data packet that is received from the first network device and stored in the PDCP receive buffer before accessing the second network device, for example, an out-of-order data packet that is processed by the DDC is received from the first network device, and the terminal device cannot parse out the corresponding PDCP SDU and deliver the data packet to the upper layer. These data packets may not be completely original data packets received by the terminal device, and may be data packets after decryption and integrity protection are performed on the original data packets, but are not decompressed yet, and these data packets are collectively referred to as PDCP SDUs. The PDCP reception buffer may also be described as a PDCP buffer or a PDCP reception buffer status.

Illustratively, the second indication information may be discardstoreedpdu information specified by 3 GPP. Optionally, whether the handover request acknowledgement message carries the second indication information may indicate whether the terminal device discards the data packet received from the first network device and stored in the PDCP reception buffer before accessing the second network device, for example, the data packet carries the second indication information and indicates that the terminal device discards the data packet; and if the second indication information is not carried, indicating the terminal equipment to be not discarded. Optionally, whether the terminal device discards the data packet received from the first network device and stored in the PDCP receiving buffer before accessing the second network device may be indicated by a value of a bit corresponding to the second indication information, for example, the value of the bit corresponding to the second indication information is "1" or "true", and the terminal device is indicated to discard the data packet; the value of the bit corresponding to the second indication information is "0" or "false", which indicates that the terminal device does not need to discard.

The discardStoredPDU may indicate each AM DRB, that is, one AM DRB corresponds to one discardStoredPDU, for example, the discardStoredPDU may be carried in a handover command in a handover request acknowledgement message, and for example, the discardStoredPDU may be carried in a PDCP configuration cell (PDCP-config) or a data radio bearer configuration cell (radio bearer config) in the handover command. Alternatively, the discardstoreedpdu may be applicable to the terminal device, i.e., the discardstoreedpdu may be applicable to all AM DRBs of the terminal device.

The second indication information may be carried in the handover request acknowledgement message, or may be carried in another message sent by the second network device to the first network device. And the second network equipment instructs the terminal equipment to discard the data packet which is received from the first network equipment and stored in the PDCP receiving buffer before accessing the second network equipment through the second indication information.

Before the terminal device accesses the second network device, it may be before the terminal device initiates a random access procedure to the second network device after the first network device receives a migration request acknowledgement (e.g., a handover request acknowledgement message) from the second network device; it is also possible that the terminal device initiates a random access procedure to the second network device to establish the RRC connection, but before the RRC connection establishment is completed.

Optionally, the first indication information and the second indication information may be the same indication information, that is, one indication information indicates both consecutive data forwarding and discarding of the stored PDCP SDUs.

The first network device may send the second indication information to the terminal device in case of receiving the second indication information, so that the terminal device discards the data packet received from the first network device and stored in the PDCP receive buffer before accessing the second network device. Optionally, in an alternative manner, the first network device may send an indication message to the terminal device, indicating to discard the data packet received from the first network device and stored in the PDCP receive buffer; for example, the first network device may send the indication information to the terminal device after receiving the first indication information or sending the first indication information to the second network device, or after receiving continuous data forwarding request information sent by the second network device.

In step 403, the first network device sends the first data stream to the second network device. Accordingly, the second network device receives the first data stream from the first network device.

The first data flow may be a data flow corresponding to at least one service bearer, or may be described as at least one service bearer for carrying the first data flow. The first data stream includes a plurality of consecutive data packets arranged in the order from the PDCP sequence number to the PDCP sequence number, which can be understood as that the first network device sends the first data stream to the second network device according to the forwarding rule of consecutive data forwarding. The starting data packet in the first data flow is a first data packet that has been sent to the terminal device by the first network device but has not received the acknowledgement instruction from the terminal device, and it can be understood that the first network device sends the PDCP SDUs and the corresponding PDCP sequence numbers to the second network device in order from the first PDCP layer to the terminal device but has not received the acknowledgement instruction from the terminal device. The acknowledgement command of the terminal device may specifically be an ARQ ACK command of the RLC layer, or an acknowledgement command of another layer, which is not specifically limited.

Illustratively, as shown in fig. 4, for this AM DRB, the PDCP layer of the terminal device receives PDCP PDUs with SN 0, SN 2, and SN 4, but the RLC layer of the terminal device has not yet or has not yet come to feedback an acknowledgement instruction to the first network device, the terminal device has not received PDCP PDUs with SN 1 and SN 3, and 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, the first network device transmits PDCP SDUs and corresponding SNs to the second network device in order of PDCP sequence numbers that are continuous from small to large, starting from the PDCP SDU with SN of 0. For example, the PDCP SDU and the corresponding SN are transmitted to the second network device according to SN-0, SN-1, SN-2, ….

In one implementation, the first network device sends the first data stream to the second network device according to the first indication information. It can be understood that the first network device performs continuous data forwarding according to the indication of the second network device. Optionally, the first network device determines whether to perform continuous data forwarding based on the indication of the second network device when the DDC is not configured for the AM DRB of the terminal device; otherwise, the first network device performs continuous data forwarding by default.

In another implementation manner, the first network device determines whether to perform continuous data forwarding according to the configuration of the first network device to the terminal device and the configuration of the second network device to the terminal device. If the first network device and/or the second network device configures DDC for the AM DRB of the terminal device, the first network device can perform continuous data forwarding; if neither the first network device nor the second network device configures DDC for the AM DRB of the terminal device, the first network device may perform data forwarding as shown in fig. 1 a.

The first network device may transmit the second indication information to the terminal device in a case where the second indication information is received. Optionally, in a case that the first network device does not receive the second indication information, the first network device generates indication information, and sends the indication information to the terminal device, where the indication information is used to instruct the terminal device to discard a data packet that is received from the first network device and stored in the PDCP receive buffer. For example, the first network device sends an RRC reconfiguration message to the terminal device, where the RRC reconfiguration message carries the second indication information.

In one implementation, the terminal device may perform step 404-2, in case of receiving a handover command from the first network device, where the handover command includes indication information indicating to discard a data packet received from the first network device, and discard the data packet, and may specifically discard the data packet received from the first network device and stored in the PDCP receive buffer before accessing the second network device. Illustratively, as shown in fig. 4, before accessing the second network device, the data packets received from the first network device and stored in the PDCP receiving buffer are PDCP PDUs corresponding to SN-2 and SN-4, and then the terminal device discards the PDCP PDUs corresponding to SN-2 and SN-4.

In one implementation, the terminal device may determine whether to perform step 404-2 according to the configuration of the first network device and the configuration of the second network device when receiving the handover command from the first network device. If the first network device and/or the second network device configures DDC for the AM DRB of the terminal device, the terminal device may perform step 404-2; if neither the first network device nor the second network device configures the DDC for the AM DRB of the terminal device, the terminal device may not discard the data packet stored in the PDCP reception buffer.

It should be noted that, in the embodiment of the present application, the order of executing the step 403 and the step 404-2 is not limited, for example, the step 403 and the step 404-2 may be performed simultaneously, or the step 404-2 is performed before the step 403.

Optionally, when the terminal device receives a handover command from the first network device, and when the terminal device is handed over from the first network device to the second network device, the DDC decompression cache of the terminal device is cleared; or according to the instruction of the first network equipment/the second network equipment, emptying the DDC decompression cache or updating the DDC decompression cache to the specified decompression cache. Decompression cache may also be described as a decompression cache state.

For a DRB, if the terminal device has already received a PDCP PDU corresponding to COUNT, and when the terminal device receives the PDCP PDU corresponding to COUNT again, the terminal device will directly discard the PDCP PDU received again. In step 404-2, the terminal device considers the discarded packet as a packet that has not been received before, so that when the terminal device receives a packet with the same COUNT from the second network device, the terminal device does not discard the packet, but stores the packet in the PDCP reception buffer for subsequent processing.

After discarding the data packet, the terminal device may update the maintained PDCP variable according to the discarded data packet and/or stop a running timer maintained by the PDCP entity. The receiving side PDCP entity may maintain two PDCP variables, RX _ NEXT and RX _ DELIV, respectively, where RX _ NEXT represents the COUNT value of the NEXT expected received PDCP SDU and RX _ DELIV represents the COUNT value of the first PDCP SDU that has not yet been delivered to the protocol layers above the PDCP layer. In addition, optionally, the receiving side PDCP entity may further maintain a timer t-Reordering for detecting packet loss of the PDCP PDU, and each time the timer is started, the PDCP entity may update a variable RX _ REORD (the variable represents a COUNT value for triggering t-Reordering), and when the timer expires, if no packet with a COUNT value smaller than RX _ REORD is received, the receiving side may not continue to wait. Taking fig. 4 as an example, RX _ DELIV is 1 and RX _ NEXT is 5 for the PDCP receiving side of the AM DRB. In step 404-2, the terminal device as a receiving side may update a variable maintained by the PDCP entity of the terminal device when discarding the data packet stored in the PDCP receive buffer, wherein RX _ NEXT may be updated to be equal to RX _ DELIV, for example, RX _ NEXT is equal to 1 after update, and further, the PDCP entity of the terminal device may stop t-Reordering.

After discarding the data packet, the terminal device updates the maintained PDCP variable, so as to receive the data packet from the second network device according to the updated PDCP variable.

Step 404, the second network device sends a second data stream to the terminal device according to the first data stream. Accordingly, the terminal device receives a second data stream from the second network device.

In one implementation, the second network device does not configure a DDC for the AM DRB of the terminal device, and then the PDCP sequence number of the starting packet in the second data flow sent by the second network device to the terminal device is the same as the PDCP sequence number of the starting packet in the first data flow. 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 a PDCP layer compression process at the second network device, e.g., the PDCP layer of the second network device has not performed a DDC compression process on the first data stream.

Illustratively, taking fig. 4 as an example, the starting data packet in the first data flow is a PDCP SDU with SN equal to 0, and then the second network device composes a new PDCP PDU starting from the PDCP SDU with SN equal to 0 and sends the new PDCP PDU to the terminal device. Since the terminal device has already received the data packet with SN 0, when receiving the data packet with SN 0 from the second network device, the terminal device directly discards the data packet.

In one implementation, the second network device configures DDC for the AM DRB of the terminal device, and then the second data stream may be a data stream that is subjected to PDCP layer compression processing at the second network device. The PDCP sequence number of the starting packet in the second data flow may be the same as the PDCP sequence number of the starting packet in the first data flow, e.g., both are SN ═ 0; for example, the PDCP sequence number of the initial packet in the second data flow may be SN-1, and the PDCP sequence number of the initial packet in the first data flow may be SN-0.

Optionally, the terminal device may perform step 404-1 to send a PDCP status report to the second network device before performing step 404. Accordingly, the second network device receives a PDCP status report from the terminal device.

The handover command sent by the first network device to the terminal device may instruct the terminal device to report the PDCP status report. The PDCP status report includes a reference PDCP sequence number, which is the PDCP sequence number of the first packet from the first network device that was not received by the terminal device. For example, in fig. 4, the reference PDCP sequence number is SN-1. The reference PDCP sequence number may be a First Missing COUNT (FMC) corresponding to a first unsuccessfully received PDCP packet waiting to be received in the current PDCP reception buffer.

The second network device may generate a second data flow corresponding to a data flow of the first data flow starting from a data packet corresponding to the reference PDCP sequence number, upon receiving the PDCP status report. For example, if the reference PDCP sequence number is SN 1 and the sequence number of the start packet in the first data flow is SN 0, the second network device may 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 the AM DRB of the terminal device, the second network device may perform DDC compression starting from the PDCP SDU with SN of 1, and generate a second data stream, where the second data stream is a data stream that is subjected to PDCP layer compression processing at the second network device.

And under the condition that the terminal equipment receives the second data stream, determining the first data stream to be stored according to the second data stream, and storing the first data stream to be stored in the PDCP receiving buffer.

If the second data flow is a data flow which is not subjected to the PDCP layer compression processing in the second network device, the terminal device may directly store the second data flow in the PDCP receiving buffer as the first data flow to be stored.

If the second data flow is a data flow that has undergone PDCP layer decompression processing at the second network device, the terminal device may perform PDCP layer decompression processing on the second data flow. For example, if the reference PDCP sequence number reported by the terminal device is SN 1, the terminal device may perform DDC decompression after receiving the PDCP PDU starting from SN 1 from the second network device and completing the sorting, and deliver the PDCP SDU to the upper layer entity.

In the embodiment shown in fig. 4, a compression mechanism is applied to the mobile handover process, and continuous data forwarding is performed by the first network device, so that packet loss when the terminal device receives data from the second network device can be avoided, and lossless transmission of data is realized.

In the embodiment shown in fig. 4, a compression mechanism is applied to the mobile handover process, and if the embodiment is applied to the data offloading process, for example, the dual connectivity establishment process, the handover request message and the handover request response message in steps 401 and 402 may be replaced by the secondary node addition request message and the secondary node addition request acknowledgement message, respectively.

Please refer to fig. 5, which is a flowchart illustrating a data transmission method according to a second embodiment of the present application. The method describes an AM DRB based on a mobile handover procedure. The flow shown in fig. 5 may include, but is not limited to, the following steps:

step 501, a first network device sends a handover request message to a second network device. Accordingly, the second network device receives a handover request message from the first network device.

Step 502, the second network device sends a handover request acknowledge message to the first network device. Accordingly, the first network device receives a handover request acknowledge message from the second network device.

The implementation process of step 501 to step 502 can refer to the detailed description of step 401 to step 402 in the embodiment shown in fig. 4, and is not described herein again.

In step 503, the first network device sends the first threshold to the second network device. Accordingly, the second network device receives the first threshold from the first network device.

The first threshold may be a sequence number corresponding to a data packet actually sent by the first network device, and may be, for example, a maximum SN value corresponding to the data packet. The first threshold may also be a PDCP COUNT value corresponding to a packet actually sent by the first network device, for example, a maximum COUNT value corresponding to the packet. Both SN and COUNT may be used to indicate the sequence number of the packet.

In one implementation, the first network device may send the first threshold to the second network device through the SN status transfer message, that is, the first threshold is carried in the SN status transfer message. Specifically, the information can be carried in DRBs _ Subject To Status Transfer List cell in SN Status Transfer message. For example, the specific cell representation can be as shown in table 2 below. In table 2, maximum DL COUNT value may represent a first threshold value for downlink data transmission.

TABLE 2

In another implementation manner, the first network device may send the first threshold to the second network device through the handover request message, that is, the first threshold is carried in the handover request message.

In step 504, the first network device sends a first data stream to the second network device. Accordingly, the second network device receives the first data stream from the first network device.

The implementation process of step 504 can refer to the detailed description of step 403 in the embodiment shown in fig. 4, and is not described herein again.

In step 505-1, the terminal device discards the data packet 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 refer to the detailed description of step 404-2 in the embodiment shown in fig. 4, and is not described herein again.

Optionally, when the terminal device is switched from the first network device to the second network device, emptying the DDC decompression cache of the terminal device; or according to the instruction of the first network equipment/the second network equipment, emptying the DDC decompression cache or updating the DDC decompression cache to the specified decompression cache.

Step 505, the second network device sends a third data stream to the terminal device. Accordingly, the terminal device receives a third data stream from the second network device.

In one implementation, after the terminal device is handed over to the second network device, the second network device may send a third data stream to the terminal device according to the first data stream before receiving the PDCP status report from the terminal device. The second network device may form a new PDCP PDU starting with the first PDCP SDU forwarded by the first network device and send it to the terminal device. The PDCP sequence number of the packet in the third data flow is less than or equal to the first threshold, and the third data flow is a data flow that has not undergone the PDCP layer compression processing at the second network device.

Illustratively, the second network device composes a new PDCP PDU from PDCP SDUs starting with SN-0 and transmits it to the terminal device. Taking the example that the second network device configures DDC for the AM DRB, the second network device starts to send the newly composed PDCP PDU from SN ═ 0 as a packet without performing DDC compression. Because the PDCP SDU with SN 0 has been successfully received, parsed and delivered from the first network device to the upper layer entity above the PDCP layer at the terminal device side, the terminal device may directly discard the PDCP PDU with SN 0 sent by the second network device after receiving the PDCP PDU; for the PDCP data packets starting from SN 1, the terminal device may receive and store the PDCP data packets in the PDCP receiving buffer, and since the PDCP data packets sent by the second network device are uncompressed data packets, the terminal device side does not need to perform decompression operation based on the decompression buffer after finishing the sorting, and may directly deliver the uncompressed data packets to an upper layer entity above the PDCP layer, such as a Service Data Adaptation Protocol (SDAP) layer entity and an IP layer entity. The second network device may perform DDC compression and transmit PDCP SDUs starting from the first threshold with reference to the first threshold.

Step 506, the second network device sends the second data stream to the terminal device according to the first data stream. Accordingly, the terminal device receives a second data stream from the second network device.

Optionally, in step 506-1, the terminal device sends a PDCP status report to the second network device. The implementation of step 506-1 can be seen in the detailed description of step 404-1 in the embodiment shown in FIG. 4. Wherein, the PDCP status report includes a reference PDCP sequence number smaller than or equal to the first threshold, if the PDCP SDU corresponding to SN ═ FMC has not been transmitted, the second network device may directly perform compression and transmission from the PDCP SDU starting from SN ═ FMC, at which time the terminal device may perform DDC decompression on the PDCP SDU starting from SN ═ FMC.

It can be appreciated that, in case the terminal device does not perform step 506-1, the second network device may perform DDC compression and transmit PDCP SDUs starting from the first threshold with reference to the first threshold; under the condition that the terminal equipment executes the step 506-1, the second network equipment does not refer to the first threshold value, but refers to a reference PDCP sequence number carried by the PDCP status report to execute DDC compression; and in the case that the first network equipment does not execute the step 503 and the terminal equipment executes the step 506-1, the second network equipment refers to the reference PDCP sequence number carried by the PDCP status report to execute DDC compression.

In the embodiment shown in fig. 5, a compression mechanism is applied to the mobile handover process, and continuous data forwarding is performed by the first network device, so that packet loss when the terminal device receives data from the second network device can be avoided, and lossless transmission of data is realized. The second network device can transmit downlink data without waiting for receiving the PDCP status report, thereby avoiding time delay brought to the downlink data transmission.

As an alternative embodiment, the first network device may not inform the second network device of the first threshold. The second network device receives the PDCP SDU with SN from the first network device, and then does not perform DDC compression when grouping the PDCP PDUs, and when the second network device receives the PDCP SDU without SN from the first network device, it can be determined that the PDCP SDU without SN has not been sent by the PDCP entity on the first network device side, and the PDCP receiving buffer of the terminal device does not store these data packets, and the second network device can perform DDC compression when grouping the PDCP SDUs without SN.

As an optional embodiment, the second network device carries a request message for requesting the first threshold in the handover request acknowledgement message, and then the first network device determines to send the first threshold to the second network device.

In the embodiment shown in fig. 5, a compression mechanism is applied to the mobile handover process, and if the embodiment is applied to the data offloading process, for example, the dual connectivity establishment process, the handover request message and the handover request response message in steps 501 and 502 may be replaced by the secondary node addition request message and the secondary node addition request acknowledgement message, respectively.

Please refer to fig. 6, which is a flowchart illustrating a data transmission method according to a third embodiment of the present application. The method describes an AM DRB based on a mobile handover procedure. The flow shown in fig. 6 may include, but is not limited to, the following steps:

step 601, the first network device sends a handover request message to the second network device. Accordingly, the second network device receives a handover request message from the first network device.

Step 602, the second network device sends a handover request acknowledgement message to the first network device. Accordingly, the first network device receives a handover request acknowledge message from the second network device.

Step 603, the first network device sends the first data stream to the second network device. Accordingly, the second network device receives the first data stream from the first network device.

In step 604-1, the terminal device discards the data packet received from the first network device and stored in the PDCP receive buffer before accessing the second network device.

The implementation process of step 601-step 603 may refer to the specific description of step 401-step 403 in the embodiment shown in fig. 4, and step 604-1 may refer to the specific description of step 404-2 in the embodiment shown in fig. 4, which is not described herein again.

Step 605, the second network device sends the third indication information to the terminal device. Correspondingly, the terminal device receives the third indication information from the second network device.

The third indication information includes a second threshold, and the data packet corresponding to the PDCP sequence number in the second data stream being greater than or equal to the second threshold is a data packet after the second network device has undergone PDCP layer compression processing. It is to be understood that the second threshold is used to inform the terminal device from which PDCP SDU the second network device starts to perform DDC compression.

Illustratively, the second network device may indicate the second threshold value through one PDCP control PDU. Referring to a format schematic diagram of the PDCP control PDU shown in fig. 6a, where a value of the D/C field is "1" indicates a PDCP data PDU, and a value of "0" indicates a PDCP control PDU, the embodiment of the present application takes a value of "0". The PDU type indicates the type of control PDU, a PDU type of 000 can be represented as a PDCP status report, 001 can be represented as RoHC feedback, and other values are reserved values, in this embodiment of the present application, the PDU type can be some value other than 000 and 001; and R is a reserved bit. For another example, the third indication information/the second threshold may be carried in other control signaling, such as a handover request acknowledgement message.

And the second network equipment carries third indication information used for indicating a second threshold value in the PDCP data PDU sent to the terminal equipment. In the first mode, the first indication information is carried to indicate whether the current PDCP data PDU is the second network device side to perform DDC compression from the beginning of the packet, for example, the indication may be performed through a reserved bit in a subheader of a PDCP frame. And in a second mode, the second network device side is instructed to perform DDC compression from the PDCP SDU corresponding to the second threshold, for example, whether the PDCP data PDU carries the second threshold may be instructed by a reserved bit in a subheader of the PDCP frame.

Step 606, the second network device sends the second data stream to the terminal device according to the first data stream. Accordingly, the terminal device receives a second data stream from the second network device.

The terminal device performs PDCP layer decompression according to the second threshold, for example, performs DDC decompression in sequence from a packet corresponding to the second threshold. If the data packet corresponding to the second threshold value is delivered to the upper layer, the terminal device performs DDC decompression processing on the data packet, and discards the decompressed PDCP SDU after updating the decompression cache; otherwise, it is stored in PDCP receiving buffer, after sorting, DDC decompression is executed, and PDCP SDU is delivered to upper layer.

As an optional embodiment, in a case that the first network device does not configure the DDC and the second network device configures the DDC, the terminal device does not discard the data packet stored in the PDCP receiving buffer, where the data packet is received from the first network device and is not subjected to the DDC compression processing, and thus the data packet stored in the PDCP receiving buffer is the corresponding PDCP SDU; after receiving the PDCP status report sent by the terminal equipment, the second network equipment sends PDCP SDU which is not successfully received by the terminal equipment from the first network equipment; the terminal equipment carries out decompression processing on the PDCP PDU received from the second network equipment in sequence to obtain a corresponding PDCP SDU; the terminal device delivers the PDCP SDUs to the upper layer in order.

Illustratively, the terminal device successfully receives an uncompressed data packet with

SN

0,2,4 from the first network device, where the data packet with SN 0 may be successfully delivered to an upper layer, and other data packets are stored in the PDCP receiving buffer because they are not already ordered; and the terminal equipment receives the compressed data packets with SN 1 and SN 3 from the second network equipment, and after the UE decompresses the data packets in sequence to obtain the corresponding PDCP SDU, the PDCP SDU is submitted to an upper layer in sequence.

In the embodiment shown in fig. 6, a compression mechanism is applied to the mobile handover process, and continuous data forwarding is performed by the first network device, so that packet loss when the terminal device receives data from the second network device can be avoided, and lossless transmission of data is realized. The second network device can transmit downlink data without waiting for receiving the PDCP status report, thereby avoiding time delay brought to the downlink data transmission and avoiding resource waste brought by sending uncompressed data packets.

In the embodiment shown in fig. 6, a compression mechanism is applied to the mobile handover process, and if the embodiment is applied to the data offloading process, for example, the dual connectivity establishment process, the handover request message and the handover request response message in steps 601 and 602 may be replaced by the secondary node addition request message and the secondary node addition request acknowledgement message, respectively.

Please refer to fig. 7, which is a flowchart illustrating a data transmission method according to a fourth embodiment of the present application. The method describes an AM DRB based on a mobile handover procedure. The flow shown in fig. 7 may include, but is not limited to, the following steps:

in step 701, a first network device sends a handover request message to a second network device. Accordingly, the second network device receives a handover request message from the first network device.

In step 702, the second network device sends a handover request acknowledge message to the first network device. Accordingly, the first network device receives a handover request acknowledge message from the second network device.

Wherein the handover request acknowledge message may carry request information for requesting transmission of the compressed cache information of the first network device. For example, the request information may be a request DDC buffer status transfer for requesting the first network device to transmit the DDC buffer status of the first network device to the second network device.

Optionally, whether the handover request acknowledgement message carries the request information may indicate whether the first network device transmits the compressed cache information, for example, whether the handover request acknowledgement message carries the request information may indicate that the first network device transmits the compressed cache information; and if the first network equipment does not carry the request information, indicating the first network equipment not to transmit the compressed cache information. Optionally, the value of the bit corresponding to the request information may indicate whether the first network device transmits the compressed cache information, for example, the value of the bit corresponding to the request information is "1" or "true", and indicates that the first network device transmits the compressed cache information; and the value of the bit corresponding to the request information is '0' or 'false', and the first network equipment is indicated not to transmit the compressed cache information.

In one implementation, the handover request acknowledge message may include indication information, where the indication information is used to instruct the terminal device to maintain decompression cache information corresponding to the compression cache information. It can be understood that, before the terminal device accesses the second network device, the adopted decompression cache information is consistent with the compression cache information adopted by the first network device, and after the terminal device accesses the second network device, the decompression cache information adopted when performing data transmission with the first network device is still used according to the indication information.

In another implementation manner, a first network device sends a handover request message to a second network device, where the handover request message carries request information, and the request information indicates that the first network device transmits compressed cache information to the second network device; optionally, the second network device may further indicate to the first network device whether to accept the request for transmitting the compressed cache information; and when the second network equipment indicates to accept the request for transmitting the compressed cache information, the first network equipment transmits the compressed cache information to the second network equipment, otherwise, the first network equipment determines not to transmit the compressed cache information to the second network equipment.

In step 703, the first network device sends the compressed cache information to the second network device through an interface between the first network device and the second network device. Accordingly, the second network device receives the compressed cache information from the first network device.

The first network device may send the compressed cache information to the second network device via an inter-base station interface message. The compressed cache information is the compressed cache information adopted when the first network device and the terminal device perform data transmission, and may include a compressed cache state.

Optionally, the inter-base station interface message includes a first threshold, where the first threshold is used to instruct the first network device to perform PDCP sequence number of the first data packet compressed by the PDCP layer based on the compression cache information. When the second network device sends data packets with PDCP sequence numbers smaller than the first threshold to the terminal device, the second network device may not perform DDC compression on the data packets.

Step 704, the second network device sends the second data stream to the terminal device based on the compressed cache information. Accordingly, the terminal device receives a second data stream from the second network device.

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

And the second network equipment performs PDCP layer compression processing on the first data flow based on the compression cache information to obtain a second data flow, and sends the second data flow to the terminal equipment. The first data stream may be a data forwarding data stream as illustrated in fig. 1a for the first network device. At least one traffic bearer is used to carry the first data flow.

Illustratively, taking fig. 7 as an example, the terminal device successfully receives PDCP PDUs with SN 2 and SN 4 from the first network device, and does not receive PDCP PDUs with SN 1 and SN 3, after accessing the second network device, the decompression buffer information of the terminal device remains unchanged, and the second network device sends compressed data packets corresponding to PDCP SDUs with SN 1 and SN 3 to the terminal device based on the PDCP status report. Because the compression cache information adopted by the second network device during compression is consistent with the compression cache information maintained by the terminal device, the terminal device can correctly decompress the received PDCP PDU, and packet loss is avoided.

In the embodiment shown in fig. 7, a compression mechanism is applied to the mobile handover process, and the compressed cache information of the first network device is transmitted to the second network device, so that packet loss when the terminal device receives data from the second network device can be avoided, and thus lossless transmission of the data is achieved.

In the embodiment shown in fig. 7, a compression mechanism is applied to the mobile handover process, and if the embodiment is applied to the data offloading process, the handover request message and the handover request response message in steps 701 and 702 may be replaced by the secondary node addition request message and the secondary node addition request acknowledgement message, respectively.

In the embodiments shown in fig. 4 to fig. 7, the compression mechanism of downlink data transmission is DDC for example, and the compression mechanism of downlink data transmission is RoHC, for example, the compression mechanism is RoHC, and in the embodiments shown in fig. 4 to fig. 7, sending an uncompressed packet may be sending an RoHC IR packet, or sending a packet with the RoHC instance/protocol maintained in RoHC IR state. The above embodiment is not only applicable to the scenario of service bearer migration due to inter-station handover or data offloading, but also applicable to other scenarios involving PDCP re-establishment, such as intra-station handover, key update, and the like.

It should be noted that, in each embodiment of the present invention, the UE transmits the RoHC IR packet, or the RoHC instance/protocol is maintained in the RoHC IR state, and the RoHC mode may be limited to the U mode, the RoHC mode is limited to the O mode, the RoHC mode is limited to the R mode, or the RoHC mode is limited to one of the U mode and the O mode, or the RoHC mode is limited to one of the U mode and the R mode, or the RoHC mode is limited to one of the O mode and the R mode, or the RoHC mode is limited to one of the U mode, the O mode, and the R mode.

The following description takes the compression mechanism of uplink data transmission as RoHC. The compression mechanism of uplink data transmission is RoHC, for example, and is applicable not only to mobile handover scenarios (e.g., intra-station handover or inter-station handover), but also to other scenarios involving PDCP re-establishment.

When switching in the station, for an AM DRB, if the base station indicates the UE to generate RoHC after finishing the PDCP reconstruction, the UE continuously retransmits or transmits the first PDCP SDU which is not successfully received by the RLC layer, and the PDCP SDUs need to be subjected to RoHC treatment when forming the PDCP PDU and possibly carry newly-established RoHC context. If the base station side has successfully received partial PDCP SDUs before the handover, the base station directly discards the received repeated PDCP PDUs (judges whether the packets are repeated according to the SNs), and the RoHC context carried in the PDCP PDUs cannot be acquired. When the base station receives a previous non-repeated PDCP PDU, if the PDCP PDU is compressed by using a RoHC context newly established at the UE side, the base station side cannot correctly decompress the PDCP PDU because the corresponding RoHC context is not established, and the data decompression processing fails. As shown in fig. 2a, after PDCP re-establishment is completed, the PDCP PDUs corresponding to SN 101,102,103 sent by the UE carry RoHC context, the PDCP PDU corresponding to SN 104 sent is compressed by using the RoHC context, the base station side receives the PDCP PDUs corresponding to SN 101,102,103, and considers that the packets are repeatedly received and directly discarded, and then the base station cannot correctly perform RoHC decompression after receiving the PDCP PDU corresponding to SN 104.

In addition, since the UE sends PDCP PDUs with SN 101,102,103 (carrying RoHC context) and PDCP PDUs with SN 104 (compressed using RoHC context) after PDCP re-establishment, because the gbb receives PDCP PDUs with SN 104 first due to out-of-order air interface, because the packet corresponds to the lower boundary of the receive window, the gbb will directly process the PDU, but the gbb cannot perform RoHC decompression on the PDU.

Similarly, the above problem also exists for downlink data transmission after handover, which is equivalent to the role of the UE and the base station being interchanged compared to uplink data transmission.

Therefore, after PDCP is re-established, the UE retransmits a data packet that is not acknowledged by the RLC, so as to avoid how to avoid that the base station side discards a duplicate packet carrying the RoHC context, which results in that the base station side cannot establish the RoHC context, and thus cannot perform RoHC decompression on subsequent PDCP PDUs.

Referring to fig. 7a, a flow chart of an uplink data transmission method provided in the embodiment of the present application may include, but is not limited to, the following steps.

Step S101, the UE sends UE capability information to the base station. Accordingly, the base station receives UE capability information from the UE.

Wherein, the UE capability information may include a mainainir-State capability parameter for indicating whether the UE supports transmitting the RoHC IR packet after PDCP re-establishment until the first condition is satisfied, or the RoHC instance/protocol is maintained in the RoHC IR State. The capability parameter name mainainir-State is only an example and not a limitation.

When the first condition is satisfied after the PDCP re-establishment, it can be understood as a procedure until the first condition is satisfied after the PDCP re-establishment is completed. The starting time of the process is to complete the PDCP re-establishment, the terminating time is to meet the first condition, and the first condition is not met in the process.

Step S102, the base station sends RRC reconfiguration information to the UE. Accordingly, the UE receives an RRC reconfiguration message from the base station.

Wherein, the RRC reconfiguration message is used to instruct a PDCP entity corresponding to one AM DRB of the UE to perform PDCP re-establishment and take effect RoHC. The RRC reconfiguration message may include a mainainir-statelnpdcp-Reest parameter that indicates whether the UE transmits a RoHC IR packet after PDCP re-establishment until the first condition is satisfied, or the RoHC instance remains in the RoHC IR state. The configuration parameter name maintainIR-statelnpdcp-Reest is only an example and is not limited.

And when the base station carries the parameters in the RRC reconfiguration message and indicates that the UE needs to send the RoHC IR data packet after the PDCP is reestablished until the first condition is met, otherwise, the base station indicates that the UE does not need to send the RoHC IR data packet in the process. The parameter is carried optionally when the PDCP entity of the AM DRB is reestablished and RoHC is in effect, otherwise the parameter is not carried in the RRC reconfiguration message.

The UE may send the RoHC IR packet after completion of PDCP re-establishment or the RoHC instance/protocol remains in RoHC IR state, upon receiving the RRC reconfiguration message.

Optionally, the base station may also indicate, through the value of the parameter carried in the RRC reconfiguration message, whether the UE needs to send the RoHC IR packet in the foregoing process, for example, when the parameter is carried and the value is 'true' or '1', it indicates that the UE needs to send the RoHC IR packet in the foregoing process; when the parameter takes the value of 'false' or '0' or is not carried, it indicates that the UE does not need to send the RoHC IR packet in the above process.

It should be noted that, in one implementation, step S101 and step S102 perform at least one, for example, step S101 or step S102, or step S101 and step S102. In another implementation, step S101 and step S102 are not performed, and at this time, the UE re-establishes the PDCP entity of the AM DRB, and after RoHC is validated, the RoHC instance/protocol always needs to be maintained in the RoHC IR state without the support of UE capability, and the base station performs control through parameters.

Step S103, the UE performs PDCP reestablishment.

Step S104, the UE sends data packets to the base station from the first PDCP SDU not acknowledged by the RLC layer according to the sequence of the PDCP sequence numbers from small to large and continuous, and the data packets are RoHC IR data packets or RoHC instances/protocols and are maintained in the RoHC IR state.

For AM DRB, when the UE performs PDCP re-establishment and generates RoHC after PDCP re-establishment is completed, the UE transmits RoHC IR packets or the RoHC instance/protocol of the UE remains in RoHC IR state until the first condition is satisfied when it retransmits/transmits PDCP SDUs.

Wherein the first condition may be one of:

a, starting from the first PDCP SDU which is not confirmed by the RLC layer, all PDCP SDUs which are distributed with SN before PDCP reestablishment are retransmitted; b, starting from the first PDCP SDU which is not confirmed by the RLC layer, all PDCP SDUs which are transmitted on an air interface before the PDCP is reestablished are retransmitted; c, the UE receives a PDCP status report sent by the base station, or the UE carries out PDCP SDU discard processing on PDCP SDU which indicates that the PDCP SDU is successfully delivered to the base station side based on the received status report; and D, the base station receives first indication signaling sent by the base station, and indicates that the UE can send a non-RoHC IR packet or indicates that the RoHC instance/protocol of the UE can not be maintained in the RoHC IR state. Wherein the first indication signaling may be carried through a PDCP control PDU.

The UE is instructed by the base station to generate RoHC after completion of PDCP re-establishment, which may be one of the following situations:

1) the UE is not configured with the RoHC function before the PDCP is reestablished, and the base station indicates the UE to carry out PDCP reestablishment and is configured with the RoHC function through an RRC reconfiguration message; 2) the UE is configured with a RoHC function before PDCP reconfiguration, and the base station indicates the UE to perform PDCP reconstruction and reconfigure related parameters of RoHC, such as maxCID or profiles and the like, through an RRC reconfiguration message; 3) the UE is configured with a RoHC function before PDCP reconfiguration, and the base station instructs the UE to perform PDCP reestablishment through an RRC reconfiguration message and instructs the UE to keep the RoHC header compression protocol unchanged through a drb-ContinueRoHC parameter.

In step S105, the UE determines whether a first condition is satisfied.

In step S106, the UE transmits a non-RoHC IR packet to the base station if the first condition is satisfied, or the RoHC instance/protocol may not be maintained in the RoHC IR state.

In the embodiment shown in fig. 7a, the UE generates RoHC after completion of PDCP re-establishment, transmits RoHC IR packets, or the RoHC instance/protocol of the UE remains in RoHC IR state until the first condition is met; after the first condition is met, the non-RoHC IR data packet is sent, the situation that the PDCP data packet carrying too much RoHC context is retransmitted after the UE is switched can be avoided, the situation that a receiving side directly discards repeated packets is avoided, the base station UE can keep the synchronization of the RoHC context, and the base station side/the UE side can successfully execute RoHC decompression on the received compressed data packet.

The embodiment shown in fig. 7a can also be applied to downlink data transmission. For example, in the mobile handover, the target base station instructs the UE to perform PDCP re-establishment, and generates RoHC after PDCP re-establishment is completed, and the target base station transmits a RoHC IR packet when the corresponding PDCP entity retransmits/transmits PDCP SDU to the UE after the UE completes random access, or the RoHC instance/protocol of the corresponding PDCP entity of the base station is maintained in RoHC IR state until the second condition is satisfied.

Wherein the second condition may be one of:

a, the source station retransmits PDCP SDUs which carry SNs and are forwarded in the data forwarding process; and B, the base station receives the PDCP status report sent by the UE, or the base station carries out PDCP SDU discard processing on the PDCP SDU which indicates that the PDCP SDU is successfully delivered to the base station side based on the received PDCP status report.

In case of an intra-site handover scenario, the second condition may also be: starting from the first PDCP SDU which is not confirmed by the RLC layer, all PDCP SDUs which are distributed with SN before PDCP reestablishment are retransmitted, or all PDCP SDUs which are transmitted on the air interface before PDCP reestablishment are retransmitted.

In another uplink data transmission method, for AM DRB, when the UE performs PDCP re-establishment and generates RoHC after completion of PDCP re-establishment, the UE starts a timer X after retransmission. And when the UE receives the PDCP status report sent by the base station or the UE carries out PDCP SDU discard processing on the PDCP SDU which indicates that the PDCP SDU is successfully delivered to the base station side based on the received status report, the timer X is stopped.

When the timer X runs, the UE does not retransmit/transmit the PDCP SDU, namely the UE does not perform RoHC processing and transmitting operation on the PDCP SDU; when the timer times out or is not running, the UE may process and transmit PDCP SDUs. Optionally, when the timer X runs, the UE sends a data RoHC IR packet or the RoHC instance/protocol is maintained in the RoHC IR state; when the timer times out or is not running, the UE may send non-RoHC IR packets or need not be restricted to have the RoHC instance/protocol in the RoHC IR state.

The timing duration of the timer X may be configured by the base station. For example, the base station may select to configure the timing duration of the timer X only when PDCP re-establishment and RoHC are in effect for the AM DRB, otherwise the base station does not configure. When the base station does not configure the timing duration of the timer X, the UE does not need to start the timer X after the reestablishment, namely the UE executes the actions related to the PDCP reestablishment process defined in the existing protocol. Optionally, when the base station does not configure the timing duration of the timer X, it may be considered that the timing duration of the timer X is 0, that is, the timer X immediately times out after starting, so that the UE acts in the same manner in the case of configuring and not configuring the timing duration of the timer X.

Optionally, when reporting the capability information of the UE, the UE may carry a capability parameter whether to support timer operation, where the capability parameter may be mainaintimerx, for indicating whether the UE supports starting the timer X after PDCP re-establishment, and for controlling processing of PDCP SDUs within the timer running time. When the UE reports and supports the timing parameter, the base station may configure the timing duration of the timer X for the UE. The ability parameter name mainaintimerx is only an example and is not limited.

For downlink data transmission, when mobile switching is carried out, a target base station indicates UE to carry out PDCP reestablishment, RoHC is generated after the PDCP reestablishment is finished, and the target base station starts a timer Y after the UE is randomly accessed; and when the base station receives the PDCP status report sent by the UE, or the base station performs PDCP SDU discard processing on the PDCP SDU which indicates that the PDCP SDU is successfully delivered to the base station side based on the received status report, the timer Y is stopped. When the timer Y runs, the base station does not retransmit/transmit the PDCP SDU, namely the base station does not perform RoHC processing and transmitting operation on the PDCP SDU; when the timer times out or is not running, the base station can process and transmit the PDCP SDUs. Optionally, when the timer Y runs, the base station only sends the RoHC IR packet or the RoHC instance/protocol is maintained in the RoHC IR state; when the timer times out or is not running, the base station can transmit non-RoHC IR packets or need not restrict the RoHC instance/protocol to be in the RoHC IR state.

In the uplink data transmission method, the UE waits for a period of time after the PDCP is reestablished and is used for receiving the PDCP status report, so that the possibility that the UE sends too many repeated packets but is discarded by the base station is reduced, and the failure of the base station to perform RoHC decompression on the received compressed data packets due to the fact that the base station cannot keep the RoHC context aligned with the UE is avoided as much as possible.

In another uplink data transmission method, for AM DRB, when UE performs PDCP re-establishment and RoHC is generated after PDCP re-establishment is completed, a PDCP receiving side (which may be a base station or UE) may store data packets received within a period of time T and reorder the data packets based on SN. The PDCP receiving side analyzes the reordered data packets in sequence, and if the data packets are judged to be the data packets which are repeatedly received based on the SN, the PDCP receiving side executes RoHC decompression operation before executing discarding operation on the data packets to acquire RoHC context which can be carried in the data packets; and if the data packet is the data packet in the current PDCP receiving window, the UE processes the data packet according to the receiving processing flow of the PDCP in the existing protocol.

If the PDCP receiving side is at the UE, the time T can be configured by the base station. Optionally, the UE may introduce a new capability parameter, which may be referred to as mainaintimet, for example, to indicate whether the UE supports the above operation.

In the method, the PDCP receiving side can obtain the RoHC context carried in the repeated data packet in sequence, thereby avoiding the decompression failure of the compressed data packet caused by the inconsistency of the RoHC context of the base station side and the UE side.

In another uplink data transmission method, for AM DRB, when the UE performs PDCP re-establishment and generates RoHC after PDCP re-establishment is completed, the base station sends a PDCP status report to the UE after the UE completes random access. Before confirming that the UE receives the PDCP status report, the base station does not schedule the uplink resource to the UE or does not schedule the uplink resource to the AM DRB of the UE.

The base station may determine that the UE has received the PDCP status report as follows. In a first mode, the UE performs HARQ ACK feedback for the TB where the PDCP status report is located. In the second mode, the UE performs RLC ACK feedback on the RLC SDU where the PDCP status report is located.

The base station can avoid retransmitting a large number of PDCP SDUs before the UE receives the PDCP status report through the scheduling mode, thereby avoiding the decompression failure of compressed data packets caused by the inconsistency of RoHC contexts of the base station side and the UE side. In addition, in this method, the base station may control the frequency of scheduling the uplink resource for the UE, for example, control to schedule N uplink grants at most in 1 radio frame, or control to schedule uplink grants with TBS of M at most, instead of completely avoiding scheduling the uplink resource for the UE. The method does not need to change the protocol, and is simple and convenient to implement.

Corresponding to the method provided by the above method embodiment, the embodiment of the present application further provides a corresponding apparatus, which includes a module for executing the above embodiment. The module may be software, hardware, or a combination of software and hardware.

Fig. 8 shows a schematic structural diagram of a communication apparatus. The communication apparatus 800 may be a network device (a first network device or a second network device), a terminal device, a chip system, a processor, or the like supporting the network device to implement the method, or a chip, a chip system, a processor, or the like supporting the terminal device to implement the method. The apparatus may be configured to implement the method described in the method embodiment, and refer to the description in the method embodiment.

The communication device 800 may include one or more processors 801, and the processors 801 may also be referred to as processing units or processing modules, etc. to implement certain control functions. The processor 801 may be a general purpose processor, a special purpose processor, or the like. A general-purpose processor may be, for example, a central processing unit and a special-purpose processor may be, for example, a baseband processor. The baseband processor may be configured to process communication protocols and communication data, and the central processor may be configured to control a communication device (e.g., a base station, a baseband chip, a terminal chip, a Distributed Unit (DU) or a Centralized Unit (CU)), execute a software program, and process data of the software program.

In an alternative design, the processor 801 may also have stored therein instructions 803, and the instructions 803 may be executed by the processor 801 to cause the communication apparatus 800 to perform the method described in the above method embodiment.

In an alternative design, processor 801 may include a transceiver unit to perform receive and transmit functions. The transceiving unit may be a transceiving circuit, or an interface, for example. The transmit and receive circuitry, interfaces or interface circuitry used to implement the receive and transmit functions may be separate or integrated. The transceiver circuit or the interface may be used for reading and writing instructions, or the transceiver circuit or the interface may be used for transmitting signals.

Optionally, one or more memories 802 may be included in the communication apparatus 800, and instructions 804 may be stored thereon, where the instructions 804 may be executed on the processor 801, so that the communication apparatus 800 performs the methods described in the above method embodiments. Optionally, the memory 802 may also store data. Optionally, instructions and/or data may also be stored in the processor 801. The processor 801 and the memory 802 may be provided separately or may be integrated together. For example, the correspondence described in the above method embodiments may be stored in the memory 802 or stored in the processor 801.

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 transceiving unit, a transceiver, a transceiving circuit, a transceiving device, a transceiving module, or the like, for implementing transceiving function.

Optionally, in this embodiment, when the communication apparatus 800 is a terminal device, the communication apparatus may include various functional modules, which are used to execute step 404-2, step 404-1, and step 404 in fig. 4; or step 505-1, step 505, step 506-1 and step 506 in FIG. 5; or step 604-1, step 604 and step 605 in FIG. 6; or step 704-1 and step 704 in fig. 7. When the communication apparatus 800 is a first network device, it may be configured to perform steps 401 to 403 in fig. 4; or step 501 to step 504 in fig. 5; or steps 601 to 603 in fig. 6; or steps 701 to 703 in fig. 7. When the communication apparatus 800 is a second network device, it may be configured to perform steps 401 to 403, and steps 404-1 and 404 in fig. 4; or step 501 to step 504, and step 505, step 506-1 and step 506 in fig. 5; or steps 601 to 603 in fig. 6, and steps 604 and 605; or steps 701 to 703 in fig. 7, and steps 704-1 and 704.

The processors and transceivers described herein may be implemented on an Integrated Circuit (IC). The IC may include an analog IC, a radio frequency integrated circuit RFIC, a mixed signal IC, an Application Specific Integrated Circuit (ASIC), and the like. The IC may be implemented as a printed circuit on a Printed Circuit Board (PCB).

The communication apparatus in the above description of the embodiment may be a network device or a terminal device, but the scope of the apparatus described in the present application is not limited thereto, and the structure of the communication apparatus may not be limited by fig. 8. The communication means may be:

(1) a stand-alone integrated circuit IC, or chip, or system-on-chip or subsystem thereof;

(2) receivers, terminals, cellular phones, wireless devices, handsets, mobile units, in-vehicle devices, network devices, cloud devices, artificial intelligence devices, machine devices, home devices, medical devices, industrial devices, and the like.

Fig. 9 provides a schematic structural diagram of a terminal device. For convenience of explanation, fig. 9 shows only main components of the terminal device. As shown in fig. 9, the terminal apparatus 900 includes a processor, a memory, a control circuit, an antenna, and an input-output device. The processor is mainly used for processing communication protocols and communication data, controlling the whole terminal, executing software programs and processing data of the software programs. The memory is used primarily for storing software programs and data. The radio frequency circuit is mainly used for converting baseband signals and radio frequency signals and processing the radio frequency signals. The antenna is mainly used for receiving and transmitting radio frequency signals in the form of electromagnetic waves. Input and output devices, such as touch screens, display screens, keyboards, etc., are used primarily for receiving data input by a user and for outputting data to the user.

When the terminal device is started, the processor can read the software program in the storage unit, analyze and execute the instruction of the software program, and process the data of the software program. When data needs to be sent wirelessly, the processor performs baseband processing on the data to be sent and outputs baseband signals to the radio frequency circuit, and the radio frequency circuit processes the baseband signals to obtain radio frequency signals and sends the radio frequency signals outwards in the form of electromagnetic waves through the antenna. When data is transmitted to the terminal device, the radio frequency circuit receives a radio frequency signal through the antenna, the radio frequency signal is further converted into a baseband signal, the baseband signal is output to the processor, and the processor converts the baseband signal into the data and processes the data.

For ease of illustration, fig. 9 shows only one memory and processor. In an actual terminal device, there may be multiple processors and memories. The memory may also be referred to as a storage medium or a storage device, and the like, which is not limited in this application.

As an alternative implementation manner, the processor may include a baseband processor and a central processing unit, where the baseband processor is mainly used to process a communication protocol and communication data, and the central processing unit is mainly used to control the whole terminal device, execute a software program, and process data of the software program. The processor in fig. 9 integrates the functions of the baseband processor and the central processing unit, and those skilled in the art will understand that the baseband processor and the central processing unit may also be independent processors, and are interconnected through a bus or the like. Those skilled in the art will appreciate that the terminal device may include a plurality of baseband processors to accommodate different network formats, the terminal device may include a plurality of central processors to enhance its processing capability, and various components of the terminal device may be connected by various buses. The baseband processor can also be expressed as a baseband processing circuit or a baseband processing chip. The central processing unit can also be expressed as a central processing circuit or a central processing chip. The function of processing the communication protocol and the communication data may be built in the processor, or may be stored in the storage unit in the form of a software program, and the processor executes the software program to realize the baseband processing function.

In one example, the antenna and the control circuit with transceiving functions can be considered as a transceiving module 911 of the terminal device 900, and the processor with processing functions can be considered as a processing module 912 of the terminal device 900. As shown in fig. 9, the terminal device 900 includes a transceiver module 911 and a processing module 912. A transceiver module may also be referred to as a transceiver, a transceiving means, a transceiving unit, or the like. Optionally, a device for implementing a receiving function in the transceiver module 911 may be regarded as a receiving module, and a device for implementing a transmitting function in the transceiver module 911 may be regarded as a transmitting module, that is, the transceiver module 911 includes a receiving module and a transmitting module. For example, the receiving module may also be referred to as a receiver, a receiving circuit, a receiving unit, or the like, and the transmitting module may be referred to as a transmitter, a transmitting circuit, a transmitting unit, or the like. Optionally, the receiving module and the sending module may be integrated into one module, or may be multiple modules independent of each other. The receiving module and the sending module may be in one geographical location or may be dispersed in a plurality of geographical locations.

As shown in fig. 10, another embodiment of the present application provides a communication device 1000. The apparatus may be a terminal device or a component of a terminal device (e.g., an integrated circuit, a chip, etc.). Alternatively, the apparatus may be a network device (either the first network device or the second network device) or a component of a network device (e.g., an integrated circuit, a chip, etc.). The apparatus may also be another communication module, which is used to implement the method in the embodiment of the method of the present application. The communication device 1000 may include: the processing module 1001 (or referred to as a processing unit). Optionally, the system may further include a receiving module 1002 (or referred to as a receiving unit) and a sending module 1003 (or referred to as a sending unit). Optionally, a storage module (or referred to as a storage unit) may be further included.

In one possible design, one or more of the modules in FIG. 10 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, memories, and transceivers, which are not limited in this application. The processor, the memory and the transceiver can be arranged independently or integrated.

The communication apparatus 1000 has a function of implementing the terminal device described in the embodiment of the present application, for example, the communication apparatus 1000 includes a module or a unit or means (means) corresponding to the terminal device executing the steps related to the terminal device described in the embodiment of the present application, and the function or the unit or the means (means) may be implemented by software or hardware, or may be implemented by hardware executing corresponding software, or may be implemented by a combination of software and hardware. Reference may be made in detail to the respective description of the corresponding method embodiments hereinbefore. Alternatively, the communication apparatus 1000 has a function of implementing the network device described in the embodiment of the present application, for example, the communication apparatus 1000 includes a module or a unit or means (means) corresponding to the step of executing the second network device described in the embodiment of the present application by the second network device, and the function or the unit or the means (means) may be implemented by software or hardware, or may be implemented by hardware executing corresponding software, or may be implemented by a combination of software and hardware. Reference may be made in detail to the respective description of the corresponding method embodiments hereinbefore.

Optionally, each module in the communication apparatus 1000 in the embodiment of the present application may be configured to execute the method described in fig. 4, fig. 5, fig. 6, or fig. 7 in the embodiment of the present application, and may also be configured to execute a method in which the methods described in the two or more diagrams are combined with each other.

In one possible design, communications apparatus 1000 is a second network device and may include: a receiving module 1002 and a transmitting module 1003. The receiving module 1002 may be configured to perform step 401, step 403, and step 404-1 in the embodiment shown in fig. 4; step 501, step 503, step 504 and step 506-1 in the embodiment shown in FIG. 5; step 601 and step 603 in the embodiment shown in fig. 6; step 701, step 703 and step 704-1 in the embodiment shown in fig. 7. The sending module 1003 may be configured to perform step 402 and step 404 in the embodiment shown in fig. 4; step 502, step 505 and step 506 in the embodiment shown in FIG. 5; step 602, step 604 and step 605 in the embodiment shown in fig. 6; step 702 and step 704 in the embodiment shown in fig. 7.

In one possible design, communications apparatus 1000 is a first network device and may include: a receiving module 1002 and a transmitting module 1003. The receiving module 1002 may be configured to perform step 402 in the embodiment shown in fig. 4; step 502 in the embodiment shown in FIG. 5; step 602 in the embodiment shown in FIG. 6; step 702 in the embodiment shown in fig. 7. The sending module 1003 may be configured to perform steps 401 and 403 in the embodiment shown in fig. 4; step 501, step 503 and step 504 in the embodiment shown in fig. 5; step 601 and step 603 in the embodiment shown in fig. 6; steps 701 and 703 in the embodiment shown in fig. 7.

In one possible design, communications apparatus 1000 is a terminal device and may include: a receiving module 1002 and a processing module 1001. The receiving module 1002 may be configured to perform step 404 in the embodiment shown in fig. 4; step 505 and step 506 in the embodiment shown in FIG. 5; step 604 and step 605 in the embodiment shown in FIG. 6; step 704 in the embodiment shown in fig. 7. The processing module 1001 may be used to perform step 404-2 in the embodiment shown in fig. 4; step 505-1 in the embodiment shown in FIG. 5; step 604-1 in the embodiment shown in fig. 6. Optionally, the communication apparatus 1000 further includes a sending module 1003, configured to perform step 404-1 in the embodiment shown in fig. 4; step 506-1 in the embodiment shown in FIG. 5; step 704-1 in the embodiment shown in fig. 7.

It is understood that some optional features in the embodiments of the present application may be implemented independently without depending on other features in some scenarios, such as a currently-based solution, to solve corresponding technical problems and achieve corresponding effects, or may be combined with other features according to requirements in some scenarios. Accordingly, the apparatuses provided in the embodiments of the present application may also implement these features or functions, which are not described herein again.

Those skilled in the art will also appreciate that the various illustrative logical blocks and steps (step) set forth in the embodiments of the present application may be implemented in electronic hardware, computer software, or combinations of both. Whether such functionality is implemented as hardware or software depends upon the particular application and design requirements of the overall system. Those skilled in the art can implement the described functions in various ways for corresponding applications, but such implementation decisions should not be interpreted as causing a departure from the scope of the embodiments of the present application.

It is understood that the processor in the embodiments of the present application may be an integrated circuit chip having signal processing capability. In implementation, the steps of the above method embodiments may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The processor may 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 device, discrete gate or transistor logic device, or discrete hardware components.

The approaches described herein may be implemented in a variety of ways. For example, these techniques may be implemented in hardware, software, or a combination of hardware and software. For a hardware implementation, the processing units used to perform these techniques at a communication device (e.g., a base station, terminal, network entity, or chip) may 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 combinations of the above. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other similar configuration.

It will be appreciated that the memory in the embodiments of the subject application can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. The non-volatile memory may be a read-only memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an electrically Erasable EPROM (EEPROM), or a flash memory. Volatile memory can be Random Access Memory (RAM), which acts as external cache memory. 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 SDRAM, enhanced SDRAM, SLDRAM, Synchronous Link DRAM (SLDRAM), and direct bus RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

It should be appreciated that reference throughout this specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Thus, the various embodiments are not necessarily referring to the same embodiment throughout the specification. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. It should be understood that, in the various embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

It should be understood that, in the present application, "when …", "if" and "if" all refer to the fact that the device performs the corresponding processing under certain objective conditions, and are not limited to time, and do not require any judgment action for the device to perform, nor do they imply other limitations.

The term "simultaneously" in this application is to be understood as being at the same point in time, as well as being within a period of time, and also being within the same period.

Reference in the present application to an element using the singular is intended to mean "one or more" rather than "one and only one" unless specifically stated otherwise. In the present application, unless otherwise specified, "at least one" is intended to mean "one or more" and "a plurality" is intended to mean "two or more".

Additionally, the terms "system" and "network" are often used interchangeably herein. The term "and/or" herein is merely an association describing an associated object, meaning that three relationships may exist, e.g., a and/or B, may mean: a exists alone, A and B exist simultaneously, and B exists alone, wherein A can be singular or plural, and B can be singular or plural.

It is understood that in the embodiments of the present application, "B corresponding to a" means that B is associated with a, from which B can be determined. It should also be understood that determining B from a does not mean determining B from a alone, but may be determined from a and/or other information.

The correspondence shown in the tables in the present application may be configured or predefined. The values of the information in each table are only examples, and may be configured to other values, which is not limited in the present application. When the correspondence between the information and each parameter is configured, it is not always necessary to configure all the correspondences indicated in each table. For example, in the table in the present application, the correspondence shown in some rows may not be configured. For another example, appropriate modification adjustments, such as splitting, merging, etc., can be made based on the above tables. The names of the parameters in the tables may be other names understandable by the communication device, and the values or the expression of the parameters may be other values or expressions understandable by the communication device. When the above tables are implemented, other data structures may be used, for example, arrays, queues, containers, stacks, linear tables, pointers, linked lists, trees, graphs, structures, classes, heaps, hash tables, or hash tables may be used.

Predefinition in this application may be understood as defining, predefining, storing, pre-negotiating, pre-configuring, curing, or pre-firing.

Those of ordinary skill in the art would appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

For convenience and brevity of description, a person skilled in the art may refer to the corresponding processes in the foregoing method embodiments for specific working processes of the system, the apparatus, and the unit described above, which are not described herein again.

It will be appreciated that the systems, apparatus and methods described herein may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The same or similar parts between the various embodiments in this application may be referred to each other. In the embodiments and the implementation methods/implementation methods in the embodiments in the present application, unless otherwise specified or conflicting in logic, terms and/or descriptions between different embodiments and between various implementation methods/implementation methods in various embodiments have consistency and can be mutually cited, and technical features in different embodiments and various implementation methods/implementation methods in various embodiments can be combined to form new embodiments, implementation methods, or implementation methods according to the inherent logic relationships thereof. The above-described embodiments of the present application do not limit the scope of the present application.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application.

Claims

1. A data transmission 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 following steps:

the second network device receiving a first data flow on the at least one traffic bearer from the first network device; the first data flow comprises a plurality of continuous data packets which are arranged in the sequence from the small to the big of the PDCP sequence number;

the second network equipment sends a second data stream to the terminal equipment according to the first data stream; the second data flow comprises a plurality of continuous data packets which are sequenced from small to large according to the PDCP sequence number;

wherein, the initial data packet in the first data flow is a first data packet that has been sent to the terminal device by the first network device but has not received a confirmation instruction from the terminal device; the first data flow comprises data packets which are sent to the terminal equipment by the first network equipment but do not receive the confirmation instruction from the terminal equipment, and data packets which are sent to the terminal equipment by the first network equipment and receive the confirmation instruction from the terminal equipment.

2. The method of claim 1, further comprising:

and the second network equipment sends first indication information to the first network equipment, wherein the first indication information is used for indicating a forwarding rule, and the forwarding rule is to continuously forward data packets according to the sequence of the PDCP sequence numbers from small to large.

3. The method of claim 1, further comprising:

the second network device receives request information from the first network device, wherein the request information is used for indicating a forwarding rule, and the forwarding rule is to continuously forward data packets according to the sequence of the PDCP sequence numbers from small to large.

4. The method according to any one of claims 1-3, further comprising:

and the second network equipment sends second indication information to the first network equipment, wherein the second indication information is used for indicating the terminal equipment to discard the data packet which is received from the first network equipment and stored in the PDCP receiving cache before accessing the second network equipment.

5. The method according to any of claims 1-3, wherein the second network device sends a second data stream to the terminal device according to the first data stream, comprising:

the second network equipment receives status report information from the terminal equipment, wherein the status report information comprises a reference PDCP sequence number, and the reference PDCP sequence number is a PDCP sequence number of a first data packet from the first network equipment, which is not received by the terminal equipment;

generating, by the second network device, a second data flow comprising data flows of the first data flow starting from the packet of the reference PDCP sequence number;

and the second network equipment sends the second data stream to the terminal equipment.

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

7. The method according to any one of claims 1-3, further comprising:

the second network device receiving a first threshold from the first network device;

the second network equipment sends a third data stream to the terminal equipment according to the first data stream and the first threshold; the PDCP sequence number of the packet in the third data flow is less than or equal to the first threshold, and the third data flow is a data flow that is not subjected to the PDCP layer compression processing in the second network device.

8. A data transmission 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 following steps:

the terminal equipment receives second indication information from the first network equipment;

the terminal equipment discards the data packet which is received from the first network equipment and stored in the PDCP receiving cache before accessing the second network equipment according to the second indication information;

the terminal equipment receives a second data stream from the second network equipment; the second data flow comprises a plurality of continuous data packets which are sequenced from small to large according to the PDCP sequence number;

the terminal equipment determines a first data stream to be stored according to the second data stream;

and the terminal equipment stores the first data stream to be stored in a PDCP receiving buffer.

9. The method of claim 8, further comprising:

and the terminal equipment updates the PDCP count value of the next expected received data packet into the PDCP count value of the first data packet waiting to be delivered to the protocol layer above the PDCP layer according to the discarded data packet.

10. The method according to claim 8 or 9, wherein the terminal device receives the second data stream from the second network device, comprising:

the terminal equipment sends status report information to the second network equipment, wherein the status report information comprises a reference PDCP sequence number, and the reference PDCP sequence number is the PDCP sequence number of a first data packet from the first network equipment, which is not received by the terminal equipment;

and the terminal equipment receives a second data flow from the second network equipment, wherein the PDCP sequence number of the initial data packet in the second data flow is the reference PDCP sequence number.

11. The method of claim 10, wherein the second data flow is a data flow after PDCP layer compression processing at the second network device;

the terminal device determines a first data stream to be stored according to the second data stream, and the determining includes:

and the terminal equipment carries out PDCP layer decompression processing on the second data flow according to the sequence that the PDCP sequence numbers are continuous from small to large to obtain a first data flow to be stored.

12. The method according to claim 8 or 9, characterized in that the method further comprises:

the terminal equipment receives a third data stream from the second network equipment; the third data flow is a data flow which is not subjected to the PDCP layer compression processing in the second network equipment;

and the terminal equipment discards a data packet in the third data stream, which is the same as the data packet stored in the PDCP receiving cache, to obtain a second data stream to be stored, and stores the second data stream to be stored in the PDCP receiving cache.

13. A data transmission 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 comprises the following steps:

the first network device sends a migration request to the second network device, wherein the migration request is used for requesting to migrate 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 flow on the at least one service bearer to the second network device; the first data flow comprises a plurality of continuous data packets which are arranged in the sequence from the small to the big of the PDCP sequence number;

14. The method of claim 13, further comprising:

the first network equipment receives first indication information from the second network equipment; the first indication information is used for indicating a forwarding rule, and the forwarding rule is to continuously forward data packets according to the sequence of the PDCP sequence numbers from small to large.

15. The method of claim 13, further comprising:

the first network equipment sends a request message to the second network equipment, wherein the request message is used for indicating a forwarding rule, and the forwarding rule is to continuously forward data packets according to the sequence of the PDCP sequence numbers from small to large.

16. The method according to any one of claims 13-15, further comprising:

the first network equipment receives second indication information from the second network equipment;

and the first network equipment sends the second indication information to the terminal equipment, wherein the second indication information is used for indicating the terminal equipment to discard the data packet which is received from the first network equipment and stored in the PDCP receiving cache before accessing the second network equipment.

17. The method according to any one of claims 13-15, further comprising:

the first network device sending a first threshold to the second network device; the first threshold is used for limiting the PDCP sequence number of a data packet in a third data flow sent to the terminal device by the second network device to be less than or equal to the first threshold; the third data flow is a data flow that has not undergone PDCP layer compression processing at the second network device.

18. The second network equipment is characterized in that at least one service bearer applied to the terminal equipment is migrated from the first network equipment to the second network equipment, and the second network equipment comprises a receiving module and a sending module;

the receiving module: for receiving a first data flow on the at least one traffic bearer from the first network device; the first data flow comprises a plurality of continuous data packets which are arranged in the sequence from the small to the big of the PDCP sequence number;

the sending module is configured to send a second data stream to the terminal device according to the first data stream; the second data flow comprises a plurality of continuous data packets which are sequenced from small to large according to the PDCP sequence number;

19. A terminal device, wherein at least one service bearer of the terminal device is migrated from the first network device to a second network device, and the terminal device comprises a receiving module and a processing module;

the receiving module is used for receiving second indication information from the first network equipment;

the processing module is configured to discard, according to the second indication information, a data packet that is received from the first network device and stored in the PDCP reception buffer before accessing the second network device;

the receiving module is further configured to receive a second data stream from the second network device; the second data flow comprises a plurality of continuous data packets which are sequenced from small to large according to the PDCP sequence number;

the processing module is further configured to determine a first data stream to be stored according to the second data stream; and storing the first data flow to be stored in a PDCP receiving buffer.

20. A first network device is characterized in that at least one service bearer applied to a terminal device is migrated from the first network device to a second network device, and the first network device comprises a sending module and a receiving module;

the sending module is configured to send a migration request to the second network device, where the migration request is used to request that at least one service bearer of the terminal device be migrated from the first network device to the second network device;

the receiving module is configured to receive a migration request acknowledgement from the second network device;

the sending module is further configured to send a first data stream to a second network device; the first data flow comprises a plurality of continuous data packets which are arranged in the sequence from the small to the big of the PDCP sequence number;

21. A communications apparatus for performing the method of any one of claims 1 to 7, or for performing the method of any one of claims 8 to 12, or for performing the method of any one of claims 13 to 17.

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

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

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

25. A communication system, characterized in that the system comprises a second network device performing the method of any of claims 1 to 7 and a first network device according to any of claims 13 to 17.