Wireless communication method and communication device

Abstract

Provided are a wireless communication method and a communication device. The wireless communication method comprises: before receiving an acknowledgement from a second device, a first device sends a first-type data packet to the second device. The first-type data packet comprises: a data packet that has been transmitted but for which it has not been determined whether transmission was successful.

Description

Wireless communication method and communication device Technical Field

[0001] The present application relates to the field of communication technology, and more particularly, to a wireless communication method and a communication device. Background Art

[0002] The radio link control (RLC) layer is responsible for data forwarding, segmentation, retransmission, discarding, and RLC reestablishment. The RLC layer operates in three modes: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM).

[0003] In AM mode, after a communication device sends a data packet and receives a negative acknowledgment (NACK) from the peer device, it retransmits the packet, ensuring reliable transmission. However, the current retransmission mechanism results in significant packet transmission latency. This is particularly true for certain data services requiring high reliability and low latency, and the existing AM mode may not meet their quality of service (QoS) requirements.

[0004] Summary of the Invention

[0005] The present application provides a wireless communication method and a communication device. The following introduces various aspects involved in the present application.

[0006] In a first aspect, a wireless communication method is provided, comprising: before receiving confirmation from the second device, a first device sends a first type of data packet to the second device, wherein the first type of data packet includes: a data packet that has been transmitted but it is not determined whether the transmission is successful.

[0007] In a second aspect, a wireless communication method is provided, comprising: a second device receiving a first type of data packet sent by a first device, wherein the first type of data packet includes: a data packet that has been transmitted but it is not determined whether the transmission is successful.

[0008] According to a third aspect, a communication device is provided, which is a first device and includes: a first sending unit for sending a first type of data packet to a second device before receiving a radio link control RLC status report, wherein the first type of data packet includes: a data packet that has been transmitted but it is not determined whether the transmission is successful.

[0009] In a fourth aspect, a communication device is provided, which is a second device, and includes: a first receiving unit, used to receive a first type of data packet sent by the first device, and the first type of data packet includes: a data packet that has been transmitted but it is not determined whether the transmission is successful.

[0010] In a fifth aspect, a communication device is provided, comprising a transceiver, a memory and a processor, wherein the memory is used to store programs, and the processor is used to call the programs in the memory and control the transceiver to receive or send signals so that the terminal executes the method described in the first aspect or the second aspect.

[0011] In a sixth aspect, a device is provided, comprising a processor for calling a program from a memory so that the device executes the method as described in the first aspect or the second aspect.

[0012] In a seventh aspect, a chip is provided, comprising a processor for calling a program from a memory so that a device equipped with the chip executes the method as described in the first aspect or the second aspect.

[0013] In an eighth aspect, a computer-readable storage medium is provided, on which a program is stored, wherein the program enables a computer to execute the method as described in the first aspect or the second aspect.

[0014] In a ninth aspect, a computer program product is provided, comprising a program, wherein the program enables a computer to execute the method as described in the first aspect or the second aspect.

[0015] In a tenth aspect, a computer program is provided, which enables a computer to execute the method as described in the first aspect or the second aspect.

[0016] The embodiment of the present application provides a wireless communication method, in which a first device (transmitter) sends a first type of data packet to a second device (receiver), and the first type of data packet is one or more of the following: a data packet that has been transmitted, but it is not determined whether the transmission is successful. That is, in the embodiment of the present application, the first device retransmits "a data packet that has been initially transmitted, but it is not determined whether the transmission is successful and / or a data packet that has been retransmitted and is waiting for confirmation by the second device" to the second device. Compared with the traditional scheme of relying on RLC status reports for retransmission, this scheme helps to reduce the data packet transmission delay in AM mode; compared with the traditional scheme of blindly retransmitting all data packets, this scheme helps to reduce wireless data packet transmission, thereby helping to save wireless resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] FIG1 is a diagram illustrating an example of a system architecture of a wireless communication system to which an embodiment of the present application may be applied.

[0018] FIG2 is a schematic diagram of the structure of a protocol stack provided by an embodiment of the present application.

[0019] FIG3 is a flow chart of a method for transmitting data packets in an AM mode according to an embodiment of the present application.

[0020] FIG4 is a flow chart of a wireless communication method provided in one embodiment of the present application.

[0021] FIG5 is a flow chart of a wireless communication method provided in another embodiment of the present application.

[0022] FIG6 is a flowchart of a wireless communication method provided in another embodiment of the present application.

[0023] FIG7 is a flowchart of a wireless communication method provided in another embodiment of the present application.

[0024] FIG8 is a schematic diagram of the structure of a communication device provided in one embodiment of the present application.

[0025] FIG9 is a schematic structural diagram of a communication device provided in another embodiment of the present application.

[0026] FIG10 is a schematic diagram of the structure of the device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] Communication system architecture

[0028] FIG1 is a diagram illustrating an exemplary system architecture of a wireless communication system 100 to which embodiments of the present application may be applied. The wireless communication system 100 may include a network device 110 and a terminal device 120. The network device 110 may be a device that communicates with the terminal device 120. The network device 110 may provide communication coverage for a specific geographic area and may communicate with the terminal device 120 within the coverage area.

[0029] FIG1 exemplarily shows a network device and a terminal device. Optionally, the wireless communication system 100 may include one or more network devices 110 and / or one or more terminal devices 120. For a network device 110, the one or more terminal devices 120 may all be located within the network coverage of the network device 110, or all be located outside the network coverage of the network device 110, or some may be located within the coverage of the network device 110 and others outside the network coverage of the network device 110. This is not limited in the embodiments of the present application.

[0030] Optionally, the wireless communication system 100 may further include other network entities such as a network controller and a mobility management entity, which is not limited in the embodiment of the present application.

[0031] It should be understood that the technical solutions of the embodiments of the present application can be applied to various communication systems, such as: fifth generation (5G) system or new radio (NR), long term evolution (LTE) system, LTE frequency division duplex (FDD) system, LTE time division duplex (TDD), etc. The technical solutions provided in this application can also be applied to future communication systems, such as the sixth generation mobile communication system, satellite communication system, etc.

[0032] The terminal device in the embodiment of the present application may also be referred to as user equipment (UE), access terminal, user unit, user station, mobile station, mobile station (MS), mobile terminal (MT), remote station, remote terminal device, mobile device, user terminal, wireless communication device, user agent or user device. The terminal device in the embodiment of the present application may be a device that provides voice and / or data connectivity to a user, and can be used to connect people, objects and machines, such as a handheld device with wireless connection function, a vehicle-mounted device, etc. The terminal device in the embodiment of the present application may be a mobile phone, a tablet computer (Pad), a laptop computer, a PDA, a mobile internet device (MID), a wearable device, a vehicle, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical surgery, a wireless terminal in smart grid, a wireless terminal in transportation safety, a wireless terminal in smart city, a wireless terminal in smart home, etc. For example, a terminal device can act as a dispatching entity, providing sidelink signals between terminal devices in vehicle-to-everything (V2X) or device-to-device (D2D) communications. For example, a cell phone and a car can communicate with each other using sidelink signals. A cell phone and a smart home device can also communicate without relaying the communication signal through a base station. Alternatively, the terminal device can be used to act as a base station.

[0033] The network device in the embodiments of the present application may be a device for communicating with a terminal device, and may also be referred to as an access network device or a radio access network device. For example, the network device may be a base station. The network device in the embodiments of the present application may refer to a radio access network (RAN) node (or device) that connects a terminal device to a wireless network. A base station may broadly cover various names as follows, or be replaced with the following names, such as: NodeB, evolved NodeB (eNB), next generation NodeB (gNB), relay station, access point, transmitting and receiving point (TRP), transmitting point (TP), master station MeNB, secondary station SeNB, multi-standard radio (MSR) node, home base station, network controller, access node, wireless node, access point (AP), transmission node, transceiver node, baseband unit (BBU), remote radio unit (RRU), active antenna unit (AAU), remote radio head (RRH), central unit (CU), distributed unit (DU), positioning node, etc. A base station may be a macro base station, a micro base station, a relay node, a donor node, or the like, or a combination thereof. A base station may also refer to a communication module, modem, or chip used to be set in the aforementioned device or apparatus. A base station may also be a mobile switching center and a device that performs base station functions in device-to-device D2D, V2X, or machine-to-machine (M2M) communications, a network-side device in a 6G network, or a device that performs base station functions in future communication systems. A base station may support networks with the same or different access technologies. The embodiments of this application do not limit the specific technology and specific device form used by network devices.

[0034] Base stations can be fixed or mobile. For example, a helicopter or drone can be configured to act as a mobile base station, and one or more cells can move based on the location of the mobile base station. In other examples, a helicopter or drone can be configured to act as a device that communicates with another base station.

[0035] In some deployments, the network device in the embodiments of the present application may refer to a CU or a DU, or the network device may include a CU and a DU. The gNB may also include an AAU.

[0036] The network equipment and terminal devices can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; they can also be deployed in the air on aircraft, balloons, and satellites. The embodiments of this application do not limit the scenarios in which the network equipment and terminal devices are located.

[0037] Currently, in order to achieve data transmission over the air interface, wireless cellular networks set up protocol stack structures on network devices (such as base stations) and terminal devices respectively. The network devices and terminal devices can communicate based on the protocol stack.

[0038] As shown in Figure 2, the above-mentioned protocol stack structure may include a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, a media access link control (MAC) layer, and a physical layer (PHY). The PDCP layer is responsible for security, integrity protection, and in-order transmission; the RLC layer is responsible for data packet segmentation and retransmission; and the MAC layer is responsible for allocating transmission opportunities to each data radio bearer (DRB) and organizing transmission blocks for transmission. The PHY layer is responsible for transmitting data on the wireless interface. In some embodiments, the embodiments of the present application mainly relate to the RLC layer, and the RLC layer is described in more detail below with reference to examples.

[0039] RLC layer

[0040] The RLC layer is located between the PDCP layer and the MAC layer. It communicates with the PDCP layer through RLC channels and with the MAC layer through logical channels. The RLC layer is primarily responsible for data forwarding, segmentation, retransmission, discarding, and RLC reestablishment. The functions of the RLC layer are implemented by RLC entities, which are created when an RLC bearer is established and deleted when the RLC bearer is released. Each RLC entity can be configured by the radio resource control (RRC) layer and is divided into three operating modes: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM).

[0041] TM mode, also known as transparent transmission mode, is transparent to the RLC entity using TM mode. The RLC entity does not modify the data in any way (for example, it does not segment RLC service data units (SDUs) or add any header information). The TM entity consists solely of a transmission buffer that stores RLC SDUs, and its sole function is to buffer and forward data. When the MAC layer notifies the TM entity of a transmission opportunity, the TM entity directly sends an RLC SDU from the transmission buffer to the MAC layer without modification.

[0042] UM mode provides an unreliable service. When a UM entity receives data packets from higher layers, it generates an unacknowledged mode data (UMD) protocol data unit (PDU) (including header information) for each RLC SDU and caches the generated UMD PDU in the transmission buffer. When the MAC layer instructs it to send an RLC PDU, it segments some RLC SDUs as necessary and regenerates the RLC header and RLC PDU, ensuring that the total size of the transmitted RLC PDU matches the total size indicated by the MAC layer. In UM mode, the transmitter is solely responsible for sending data and does not care whether the peer end successfully receives it. After receiving data, the receiver does not send a confirmation message to the transmitter to confirm that the data has been correctly received. Therefore, UM mode can deliver data packets to the peer entity in sequence with the shortest latency. UM mode is primarily suitable for services that are delay-sensitive but can tolerate a certain packet loss rate, such as voice over new radio (VoNR).

[0043] AM mode provides a reliable service. Compared to UM mode, AM mode primarily features an automatic repeat request (ARQ) error correction function, based on the UM function. This means that after sending a data packet, the sender must wait for the receiver to confirm whether the packet was received correctly. In the case of a negative acknowledgment, the sender must resend the failed data packet. Therefore, AM mode provides reliable data transmission for the upper layer, ensuring that data is correctly delivered to the peer end. AM mode is primarily suitable for services that are not sensitive to delay but are sensitive to errors, such as file transfer protocol (FTP) services.

[0044] In some embodiments, the wireless communication method provided in the embodiments of the present application mainly relates to a data packet transmission method in an RLC AM mode. The data packet transmission method in the above AM mode is described in detail below in conjunction with FIG. 3 .

[0045] As shown in FIG3 , the data packet transmission method in the RLC AM mode may include steps S310 to S350 .

[0046] In step S310, the transmitting end may send multiple data packets to the receiving end, for example, data packets 1 to 20. It should be understood that if there are many data packets and transmission resources are limited, the multiple data packets may be transmitted in multiple times.

[0047] In step S320, when the amount of data or data packets sent is greater than a preset threshold or other conditions are met (such as the last data packet in the buffer has been sent), the transmitting end may send a polling message to the receiving end. The polling message may be used to indicate that the receiving end needs to feedback an RLC status report. For example, when the Poll value is 1, the receiving end feedbacks an RLC status report; when the Poll value is 0, the receiving end does not feedback an RLC status report.

[0048] In step S330, the receiving end determines whether a trigger condition for sending a status report is met.

[0049] In some implementations, the triggering conditions may include two aspects. First, the transmitting end triggers the receiving end to send an RLC status report, as in step S320 of Figure 3 . The triggering conditions for sending the poll may include one or more of the following: all data in the transmitting end's buffer has been transmitted; or the transmitting end's RLC send window is in a blocked state, meaning the transmitting end has sent the maximum number of in-transit data packets.

[0050] The receiving end triggers this process. For example, the receiving end sets a timer to periodically send RLC status reports. Alternatively, if the receiving end determines that a packet has been sent for a certain period of time, exceeding a threshold, but has not yet received the packet, it will also send an RLC status report. For example, the receiving end may receive packet 5 but not packet 4. Since packet 5 has been received, the receiving end assumes that the sending end must have sent packet 4. If, after a certain period of time, the receiving end still has not received packet 4, it will send an RLC status report.

[0051] In step S340, in response to the triggering condition for sending the status report being met, the receiving end sends an RLC status report to the transmitting end. The RLC status report may, for example, indicate that packets 1-15 and packets 17-20 are received as acknowledged (ACK) packets, and packet 16 is received as negatively acknowledged (NACK) packets.

[0052] In step S350, after receiving the status report in step S340, the sender determines that data 16 was not correctly transmitted. Based on the NACK information in the status report, the sender retransmits the data packet 16 that failed to be received to the receiver. The sender can record the number of retransmissions of the data packet, for example, if data packet 16 was retransmitted twice.

[0053] As described above, in AM mode, after the sender sends a data packet, if it receives a status report (including a NACK for the data packet) from the receiver, it retransmits the data packet, ensuring reliable data transmission. However, the sender must wait for the receiver to send back a status report before retransmitting the data packet, resulting in significant data packet transmission latency. In particular, for certain data services requiring high reliability and low latency, the existing AM mode may not meet their QoS requirements.

[0054] In order to reduce the data packet transmission delay in the AM mode, a blind retransmission mechanism is proposed in the relevant technology, that is, the sending end retransmits all data packets when it is not sure whether the receiving end has correctly received the data packet. For example, before step S340 in Figure 3 above, the sending end can send data packets 1-20 to the receiving end again. It can be seen that this method increases the probability of successful data packet transmission at the expense of wireless resource utilization. It is applicable to services with small data volumes of ultra-reliable low-latency communications (URLLC). However, for services with large data volumes of URLLC (such as XR services), the data volume of XR services themselves is very large, and the use of blind retransmission is not appropriate.

[0055] In other words, for URLLC services, how to balance reducing the packet transmission delay in AM mode and saving wireless resources (i.e., improving the utilization of wireless resources) is a technical problem that needs to be solved urgently.

[0056] In response to the above-mentioned problem, an embodiment of the present application provides a wireless communication method, in which a first device (transmitting end) sends a first type of data packet to a second device (receiving end), and the first type of data packet is one or more of the following: a data packet that has been transmitted, but it is not determined whether the transmission is successful. That is to say, in an embodiment of the present application, the first device retransmits "a data packet that has been initially transmitted, but it is not determined whether the transmission is successful and / or a data packet that has been retransmitted and is waiting for confirmation by the second device" to the second device. Compared with the traditional scheme of relying on RLC status reports for retransmission, this scheme helps to reduce the data packet transmission delay in the AM mode; compared with the traditional scheme of blindly retransmitting all data packets, this scheme helps to reduce wireless data packet transmission, thereby helping to save wireless resources. The above-mentioned wireless communication method is described in more detail below in conjunction with Figure 4.

[0057] Figure 4 is a schematic flow chart of the wireless communication method proposed in an embodiment of the present application. The non-communication method shown in Figure 4 is introduced from the perspective of communication between a first device and a second device. The first device and the second device in Figure 4 can be two communication devices at both ends of a communication link. The first device can be the transmitting end of the communication link, and the second device can be the receiving end of the communication link. The first device can be, for example, the network device 110 mentioned in Figure 1. The second device can be, for example, the terminal device 120 mentioned in Figure 1. Of course, the first device can also be the terminal device 120 mentioned in Figure 1. The second device can be the network device 110 mentioned in Figure 1.

[0058] 4 , in step S410, the first device sends a first type of data packet to the second device before receiving confirmation from the second device, wherein the first type of data packet includes: a data packet that has been transmitted but the transmission success is not confirmed.

[0059] In some embodiments, a "data packet that has been transmitted but the transmission success is not yet determined" may include one or more of the following: a data packet that has been initially transmitted but the transmission success is not yet determined; a data packet that has been retransmitted and is waiting for confirmation from the second device.

[0060] In some implementations, "a data packet that has been initially transmitted but for which it is not determined whether the transmission is successful" may refer to a data packet that is received in an RLC status report after the first device has initially transmitted the data packet, but is not indicated in the RLC status report, or the first device has not received the RLC status report at all (neither an ACK indication nor a NACK indication is received).

[0061] In some embodiments, a "data packet that has been retransmitted and is waiting for confirmation by the second device" may refer to a data packet that has been retransmitted and for which no RLC status report indication (neither ACK indication nor NACK indication) has been received.

[0062] In some implementations, before sending the first category of data packets to the second device, the first device further includes: determining a second category of data packets, where the second category of data packets includes one or more of the following: data packets that have not been transmitted (new data packets); and data packets that have failed to transmit (e.g., received a NACK indication) and are awaiting retransmission. It should be understood that the data packets awaiting retransmission may refer to data packets placed in a retransmission buffer.

[0063] In some implementations, the second-category data packet may further include a portion of the first-category data packet.

[0064] The present application takes into account that during the process of data packet assembly, an indication message (such as an RLC status report) may be received again from the second device, indicating that some or all of the first-class data packets have been confirmed received. At this time, if the first-class data packets are transmitted again, it will inevitably cause a waste of wireless resources. Therefore, before transmission, the first device can generate N transmission blocks, each of the N transmission blocks can include a different first-class data packet, and then send the corresponding transmission block to the second device based on the received first information (the transmission block does not include the data packet that has been indicated to be confirmed received), thereby helping to improve the utilization of wireless resources.

[0065] For example, the N transmission blocks may include a first transmission block, a second transmission block, and a third transmission block. The first transmission block contains a first-category data packet 1A and a second-category data packet 1B; the second transmission block contains a first-category data packet 2A and a second-category data packet 2B; and the third transmission block contains a first-category data packet 3A and a second-category data packet 3B. The first-category data packets contained in the first-category data packets 1A, 2A, and 3A are not identical; that is, they may or may not overlap. When sending a transmission block, if the first device has already received the first information sent by the second device, indicating that the first-category data packet 1A has been received, the first device selects a transmission block from the second or third transmission block to send. If, when sending a transmission block, the first device has already received the first information sent by the second device, indicating that the first-category data packet 2A has been received, the first device selects a transmission block from the first or third transmission block to send. This allows the first device to avoid sending data packets for which it has already received an acknowledgement, thereby improving resource utilization.

[0066] In some implementations, as shown in FIG5 , at step 510, if the first device receives first information before sending the first category data packet to the second device, the first device sends a second category data packet to the second device; wherein the first information indicates that the second device has received some or all of the data packets in the first category data packet. In other words, if confirmation indications for some or all of the first category data packets are received before the packet assembly is complete, the second category data packet is sent to the second device, and the second category data packet only includes some of the data packets in the first category data packet.

[0067] In some implementations, as shown in FIG6 , if the first device does not receive the first information before sending the first-class data packet to the second device, the first device sends the first-class data packet to the second device in step 610. In other words, if the first device does not receive an acknowledgment indication for some or all of the first-class data packets before completing the packet assembly, the first device continues to send the first-class data packet to the second device.

[0068] In order to deepen the understanding of the wireless communication method in the embodiment of the present application, the wireless communication method is introduced in more detail below with reference to FIG7 .

[0069] As shown in FIG. 7 , in step S710 , the first device may send multiple data packets to the second device. The multiple data packets may be, for example, data packets 1-5.

[0070] In step S720, the second device sends a first RLC status report to the first device. This first RLC status report may, for example, indicate that data packets 1 and 4 were successfully received, but data packets 2 and 3 were not. As for data packet 5, the second device cannot determine whether the first device did not send it or whether the first device sent it but the second device did not receive it. Therefore, the first RLC status report does not indicate data packet 5.

[0071] In step S730, after receiving the first status report, the first device retransmits data packet 2. In some implementations, due to limited wireless resources, data packet 3 has not yet been retransmitted.

[0072] It should be understood that after steps S710-S730, if authorized radio resources exist, multiple data packets can be grouped to generate first-category data packets and second-category data packets. For example, first-category data packets may include data packets 2, 3, and 5, while second-category data packets may include data packets 3, 6, and 7. It should be understood that data packet 3 is a data packet for which the RLC status report indicates a negative acknowledgment (NACK), and is therefore the preferred data packet for transmission. Considering that acknowledgments for data packets 2 and 5 may be received later, and to fully utilize radio resources, new data packets 6 and 7 are grouped into the second-category data packets.

[0073] In step S740, if the second device is a network device, the second device may allocate wireless resources of a UL grant to the first device.

[0074] In step S750, during the packet assembly process, if the first device receives first information (such as a second RLC status report) sent by the second device, the first information may be used to indicate that the second device has confirmed receipt of some of the first-category data packets (such as data packet 2 and data packet 5).

[0075] In step S760, the first device sends a second type of data packet to the second device.

[0076] It should be understood that in step S750, if the first device does not receive the first information before sending the first type of data packet to the second device, then in step S760, the first device may send the first type of data packet to the second device.

[0077] In some implementations, the method further includes: the first device deleting a third type of data packet, wherein a discard timer corresponding to the third type of data packet has timed out. In other words, the third type of data packet may refer to a data packet whose discard timer has timed out.

[0078] It should be noted that the first and second category data packets mentioned above can correspond to either a complete RLC SDU or an RLC segment. However, the third category data packet can only be a complete RLC SDU. In other words, in the embodiments of the present application, the first and second category data packets may include data packet fragments, but the third category data packet must be a complete data packet and does not include data packet fragments.

[0079] Referring back to Figure 7 , if the discard timer for Data Packet 2 has expired at time T1 before packet assembly is complete, Data Packet 2 can be skipped during the packet assembly process, thus saving radio resources. This is primarily because retransmission of a packet that has timed out is pointless.

[0080] In some implementations, the third type of data packet may be determined based on second information sent by the PDCP layer, where the second information is used to indicate in advance the timeout of the data packet at the RLC layer. For example, the second information may be used to indicate that data packet 2 has timed out at the aforementioned time T1.

[0081] In some implementations, the advance time for the PDCP layer to send the second information to the RLC layer can be determined based on protocol predefined information or network device configuration information. In other words, the time difference between the time the second information is sent and the timeout period for the third type of data packet is determined based on the protocol predefined information or network device configuration information. For example, the time the second information is sent can be before the first device receives the allocation of radio resources for the uplink authorization, as shown in Figure 7 above.

[0082] It should be noted that if RLC enhanced DRB is not adopted, the above time difference will not be used. If the time difference is configured by a network device (such as a base station), it may not be configured.

[0083] In some implementations, the timeliness of data packet transmission is taken into consideration. If the PDCP layer notifies the RLC layer of the expiration of the discard timer of the first data packet (e.g., the data packet 2 whose discard timer has expired), or instructs the RLC layer to discard a data packet for other reasons, the RLC layer will not retransmit the first data packet regardless of its type.

[0084] In some implementations, after the discard timer of the third data packet expires, the first device may delete the third data packet, thereby helping to save wireless resources.

[0085] It is understandable that after deleting the first data packet, the first device no longer expects to receive an RLC status report regarding the first data packet from the second device. Therefore, the first device can send third information to the second device, where the third information is used to indicate one or more of the following: the first data packet in the RLC layer has been deleted; and there is no need to retransmit the first data packet.

[0086] In some implementations, the third information may include the RLC SN of the first data packet, that is, the first device may notify the receiver that "the data packet with RLC SN=XXX has been deleted" and will not retransmit the data packet.

[0087] In some implementations, the transmission method of the third information may include one or more of the following: it can be transmitted in the RLC packet header of the data packet; it can be transmitted through an RLC control PDU. It should be understood that, similar to the RLC status report, the RLC status report is an RLC control PDU.

[0088] In some implementations, the third information may indicate that one data packet is deleted at a time, or may indicate that multiple data packets are deleted at a time. For example, in XR service data, the third information may indicate that all data packets in a PDU set are deleted.

[0089] In some embodiments, after the second device receives the third information, the second device may determine that the first data packet has been successfully received, or may not indicate whether the first data packet has been successfully received in the RLC status report, thereby saving wireless transmission resources. For example, after the second device receives the third information, it may determine that the data packet with RLC SN=XXX has been successfully received, and may update the RLC parameters of the second device.

[0090] In some implementations, whether a data packet in the RLC layer is successfully transmitted may be determined based on one or more of the following: an RLC status report; and hybrid automatic repeat request (HARQ) feedback information.

[0091] That is to say, the RLC layer of the first device can determine whether the data packet it has sent has been successfully received by the second device based on the received RLC status report. In addition, the first device can also determine whether the data packet transmission is successful through HARQ feedback or other HARQ behaviors. For example, the first device transmits data packets 1-5 through HARQ process No. 3. After the transmission, it receives uplink resources allocated by the second device (such as a network device), requiring the first device to retransmit the data of HARQ process No. 3. At this time, the first device can infer that data packets 1-5 have not been transmitted successfully. The first device can internally update the status of data packets 1-5 from the type of "data packet for which it is not determined whether the transmission is successful" (which can be called type 2A) to the type of "data packet for which transmission failure is confirmed and waiting for retransmission" (which can be called type 2B). It should be understood that if an ACK indication is subsequently received for data packet 1-5, the status of data packet 1-5 can be updated from type 2B to the type of "data packet for which transmission is confirmed to be successful" (which can be called type 3).

[0092] By using HARQ feedback, or other feedback that can determine whether the data packet is successfully transmitted, the first device can perform RLC retransmission in advance for data that has not been successfully transmitted before receiving the RLC status report, thereby achieving effective RLC AM enhancement, thereby taking into account both reducing the transmission delay of the data packet and saving wireless resources.

[0093] It should be noted that the HARQ feedback in the embodiments of the present application does not necessarily require actual feedback signal transmission. Any feedback information from the second device, as long as it can achieve the purpose of notifying the first device whether the data packet is successfully transmitted, can be used by the RLC to infer the transmission status of the data packet.

[0094] It should be noted that in the embodiment of the present application, data packets in different states can be divided into multiple types. For example, the type of "data packet that has not been transmitted" can be called type 1, the type of "data packet whose transmission is not determined to be successful" can be called type 2A, the type of "data packet whose transmission is confirmed to have failed and is waiting for retransmission" can be called type 2B, the type of "data packet whose transmission has failed and has been retransmitted" can be called type 2C, and the type of "data packet whose transmission is confirmed to be successful" can be called type 3.

[0095] In some implementations, the first category of data packets includes multiple data packets, and the order in which the multiple data packets are placed in the transmission block is determined based on one or more of the following: types of the multiple data packets; RLC SNs of the multiple data packets; and residual delay budgets of the multiple data packets.

[0096] For example, the first device may place the data packets into the transmission block in the order of “Type 2B, Type 2C, Type 2A, Type 1”.

[0097] For another example, the first device may also place the data packet into a transmission block according to the RLC SN of the data packet.

[0098] For another example, the first device may place the data packets into the transmission block in the order of the remaining transmission delay budget of each data packet without distinguishing the type of the data packets.

[0099] For another example, the first device may also place the data packets into the transmission block in other orders (such as multiple combinations of the above-mentioned multiple sorting conditions), for example, the data packets may be placed into the transmission block in the order of the remaining transmission delay budget of each data packet and the RLC SN of the data packet, wherein the order priority of the remaining transmission delay budget is higher than the order priority of the RLC SN of the data packet.

[0100] It should be noted that the order of placing the multiple data packets into the transmission block may be determined based on protocol predefined information or configuration information of the network device.

[0101] It should be noted that the above-mentioned determination of the order of placing multiple data packets into the transmission block does not refer to the arrangement order of multiple data packets in the transmission block, but refers to the order of "determining" this behavior when determining to place multiple data packets into the transmission block in the logical channel prioritization (LCP) process.

[0102] It is understandable that the use of the wireless communication method described above in the present application can speed up the transmission of RLC data packets, but it will also increase the number of RLC retransmissions. If the number of RLC retransmissions reaches the maximum value, the first device will consider that a radio link failure (RLF) has occurred, thereby triggering an RRC re-establishment process. To prevent the RRC re-establishment process, in an embodiment of the present application, the number of retransmissions of data packets in the RLC layer reaching the maximum value is not used to trigger the RRC re-establishment process.

[0103] In some implementations, the number of retransmissions of a data packet in the RLC layer is determined based on an RLC status report. That is, the first device may increment the RLC retransmission counter only for retransmissions in certain situations. For example, the first device increments the RLC retransmission counter only when it receives an RLC status report indicating a negative acknowledgement (NACK) of a data packet, triggering an RLC retransmission. The first device does not increment the RLC retransmission counter for RLC retransmissions in other situations.

[0104] In some implementations, before sending the first-category data packet to the second device, the method further includes: the first device obtaining fourth information, where the fourth information is used to indicate whether to allow transmission of the first-category data packet via a transport block before confirming successful transmission. In other words, the fourth information can be used to indicate whether to perform RLC enhancement to reduce data packet retransmission latency.

[0105] In some implementations, the first device may obtain the fourth information from a core network element or from a network device (such as a base station), and this application does not impose specific limitations on this. The core network element may be, for example, an access and mobility management function (AMF), or other types of network elements, as long as they can send the fourth information to the first device.

[0106] In some implementations, the fourth information may be explicit configuration information or implicit configuration information. For example, for explicit configuration, the fourth information may include a Boolean parameter "whether to perform RLC AM enhancement", for example, a value of 1 indicates that RLC AM enhancement is performed, and a value of 0 indicates that RLC AM enhancement is not performed. The fourth information may also include an enumeration parameter, which, if present, indicates that RLC AM enhancement is to be performed, and if not present, indicates that RLC AM enhancement is not to be performed. For implicit configuration, the fourth information may include the service type, and "whether it is an enhanced XR service" may be determined based on the protocol predefined information or the configuration information of the network device. If the service type included in the fourth information is an enhanced service, the protocol defaults to the requirement that RLC AM enhancement be performed for such service.

[0107] It should be noted that the fourth information can be configured separately for each DRB, that is, each DRB can be configured with different fourth information.

[0108] In some implementations, the fourth information satisfies one or more of the following: the fourth information is configuration information for uplink transmission; the fourth information is configuration information for downlink transmission; the fourth information is configuration information for part or all of the data packets in downlink transmission and / or uplink transmission.

[0109] In some implementations, if the fourth information is configuration information for some data packets in downlink transmission and / or uplink transmission, the some data packets may be indicated based on a header of the data packet.

[0110] In some implementations, the packet header indication based on the data packet may refer to an indication by a data packet header of a user plane.

[0111] In some implementations, an upper layer protocol stack of the first device may provide the indication, such as a protocol header of a real-time transport protocol (RTP).

[0112] In some implementations, the first device may determine which data packets require RLC AM enhancement based on other information in the packet headers. For example, the first device may determine which data packets require RLC AM enhancement based on a priority parameter in the RTP packet header. For example, RLC AM enhancement may be performed on high-priority data packets, while not performed on low-priority data packets.

[0113] In some implementations, the fourth information may be carried in a non-access stratum (NAS) message, or in an RRC message, or a MAC CE message.

[0114] In some implementations, before the first device sends the first category data packet to the second device (i.e., before starting to transmit service data), the first device may further send fifth information. The fifth information may carry capability information of the first device and may be used to indicate whether the first device supports transmission of the first category data packet using a transport block. In other words, the first device may report its own capability information.

[0115] The method embodiment of the present application is described in detail above in conjunction with Figures 1 to 7 . The device embodiment of the present application is described in detail below in conjunction with Figures 8 to 10 . It should be understood that the description of the method embodiment corresponds to the description of the device embodiment. Therefore, for parts not described in detail, reference can be made to the above method embodiment.

[0116] FIG8 is a schematic diagram of the structure of a communication device according to an embodiment of the present application. The communication device shown in FIG8 is a first device, and the communication device 800 includes a first sending unit 810. The first sending unit 810 is configured to send a first type of data packet to a second device before receiving a radio link control (RLC) status report. The first type of data packet includes: a data packet that has been transmitted but for which it is not determined whether the transmission is successful.

[0117] In some implementations, before sending the first type of data packet to the second device, the method further includes: a determination unit for determining a second type of data packet, wherein the second type of data packet includes one or more of the following: a data packet that has not been transmitted; a data packet that is confirmed to have failed transmission and is waiting for retransmission.

[0118] In some implementations, the communication device further includes: a second sending unit, configured to send the second type of data packet to the second device if the first device receives the first information; wherein the first information is used to indicate that the second device has received part or all of the first type of data packets, and the second type of data packets include part of the first type of data packets.

[0119] In some implementations, the communication device further includes: a third sending unit, configured to send the first type of data packet to the second device if the first device does not receive the first information.

[0120] In some implementations, the method further includes: a deleting unit, configured to delete a third type of data packet, wherein a discard timer corresponding to the third type of data packet has timed out.

[0121] In some implementations, the third type of data packet is determined based on second information sent by the PDCP layer, where the second information is used to indicate in advance the timeout period of the data packet of the RLC layer.

[0122] In some implementations, the time difference between the sending time of the second information and the timeout time of the third type of data packet is determined based on protocol predefined information or configuration information of the network device.

[0123] In some implementations, whether the data packet in the RLC layer is successfully transmitted is determined based on one or more of the following: RLC status report; HARQ feedback information.

[0124] In some implementations, the first category of data packets includes multiple data packets, and the order in which the multiple data packets are placed in the transmission block is determined based on one or more of the following: the type of the multiple data packets; the RLC SN of the multiple data packets; and the remaining delay budget of the multiple data packets.

[0125] In some implementations, the communication device further includes: a third sending unit, configured to send third information to the second device, wherein the third information is configured to indicate one or more of the following: the first data packet in the RLC layer has been deleted; and there is no need to retransmit the first data packet.

[0126] In some implementations, the number of retransmissions of the data packet in the RLC layer reaching a maximum value is not used to trigger the RRC re-establishment process.

[0127] In some implementations, the number of retransmissions of the data packet in the RLC layer is determined based on an RLC status report.

[0128] In some implementations, the communication device further includes: a receiving unit configured to obtain fourth information before sending the first type of data packet to the second device, wherein the fourth information is used to indicate whether the first type of data packet is allowed to be transmitted through the transmission block before confirming that the transmission is successful.

[0129] In some implementations, the fourth information satisfies one or more of the following: the fourth information is configuration information for uplink transmission; the fourth information is configuration information for downlink transmission; the fourth information is configuration information for part or all of the data packets in the downlink transmission and / or the uplink transmission.

[0130] In some implementations, the fourth information is configuration information for some data packets in the downlink transmission and / or the uplink transmission, and the some data packets are indicated based on packet headers of the data packets.

[0131] In some implementations, the communication device further includes: a fourth sending unit, configured to send fifth information before sending the first type of data packet to the second device, wherein the fifth information is used to indicate whether the first device supports transmission of the first type of data packet through a transmission block.

[0132] FIG9 is a schematic diagram of the structure of a communication device according to an embodiment of the present application. The communication device shown in FIG9 is a second device, and the communication device 900 includes a first receiving unit 910. The first receiving unit 910 is configured to receive a first type of data packet sent by the first device, wherein the first type of data packet includes a data packet that has been transmitted but for which it is not determined whether the transmission is successful.

[0133] In some implementations, the first device further includes a second category of data packets in the RLC layer, where the second category of data packets includes one or more of the following: data packets that have not been transmitted; and data packets that are confirmed to have failed transmission and are waiting for retransmission.

[0134] In some implementations, the first device further includes a third type of data packet in the RLC layer, and a discard timer corresponding to the third type of data packet has timed out.

[0135] In some implementations, the third type of data packet is determined based on second information sent by the PDCP layer, where the second information is used to indicate in advance the timeout period of the data packet of the RLC layer.

[0136] In some implementations, the time difference between the sending time of the second information and the timeout time of the third type of data packet is determined based on protocol predefined information or configuration information of the network device.

[0137] In some implementations, whether the data packet in the RLC layer is successfully transmitted is determined based on one or more of the following: RLC status report; HARQ feedback information.

[0138] In some implementations, the first category of data packets includes multiple data packets, and the order in which the multiple data packets are placed in the transmission block is determined based on one or more of the following: the type of the multiple data packets; the RLC SN of the multiple data packets; and the remaining delay budget of the multiple data packets.

[0139] In some implementations, the communication device further includes: a second receiving unit for receiving third information sent by the first device, wherein the third information is used to indicate one or more of the following: the first data packet in the RLC layer has been deleted; and there is no need to retransmit the first data packet.

[0140] In some implementations, the communication device further includes: a determining unit configured to, after receiving the third information, determine whether the first data packet has been successfully received, or not indicate in an RLC status report whether the first data packet has been successfully received.

[0141] In some implementations, the number of retransmissions of the data packet in the RLC layer reaching a maximum value is not used to trigger the RRC re-establishment process.

[0142] In some implementations, the number of retransmissions of the data packet in the RLC layer is determined based on an RLC status report.

[0143] In some implementations, the communication device further includes: a sending unit configured to send fourth information to the first device before the second device receives the first type of data packet sent by the first device, wherein the fourth information is used to indicate whether the first type of data packet is allowed to be transmitted through the transmission block before confirming that the transmission is successful.

[0144] In some implementations, the fourth information satisfies one or more of the following: the fourth information is configuration information for uplink transmission; the fourth information is configuration information for downlink transmission; the fourth information is configuration information for part or all of the data packets in the downlink transmission and / or the uplink transmission.

[0145] In some implementations, the fourth information is configuration information for some data packets in the downlink transmission and / or the uplink transmission, and the some data packets are indicated based on packet headers of the data packets.

[0146] In some implementations, the communication device further includes: a third receiving unit, configured to receive fifth information sent by the first device before the second device receives the first type of data packet sent by the first device, wherein the fifth information is used to indicate whether the first device supports transmission of the first type of data packet through a transmission block.

[0147] FIG10 is a schematic diagram of the structure of an apparatus according to an embodiment of the present application. The dotted lines in FIG10 indicate that the unit or module is optional. Apparatus 1000 may be used to implement the method described in the above method embodiment. Apparatus 1000 may be a chip or a communication device.

[0148] The device 1000 may include one or more processors 1010. The processor 1010 may support the device 1000 to implement the method described in the method embodiment above. The processor 1010 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor may be another 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, discrete hardware component, etc. The general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0149] The apparatus 1000 may further include one or more memories 1020. The memories 1020 store programs that can be executed by the processor 1010, causing the processor 1010 to perform the methods described in the above method embodiments. The memories 1020 may be independent of the processor 1010 or integrated into the processor 1010.

[0150] The apparatus 1000 may further include a transceiver 1030. The processor 1010 may communicate with other devices or chips via the transceiver 1030. For example, the processor 1010 may transmit and receive data with other devices or chips via the transceiver 1030.

[0151] The present invention also provides a computer-readable storage medium for storing a program. The computer-readable storage medium can be applied to a terminal device provided in the present invention, and the program enables a computer to execute the method performed by the terminal device in each embodiment of the present invention.

[0152] The present application also provides a computer program product. The computer program product includes a program. The computer program product can be applied to the terminal device provided in the present application, and the program causes a computer to execute the method performed by the terminal device in each embodiment of the present application.

[0153] The embodiments of the present application also provide a computer program. The computer program can be applied to the terminal device provided in the embodiments of the present application, and the computer program enables a computer to execute the method executed by the terminal device in each embodiment of the present application.

[0154] It should be understood that the terms "system" and "network" in this application can be used interchangeably. In addition, the terms used in this application are only used to explain the specific embodiments of this application and are not intended to limit this application. The terms "first", "second", "third", and "fourth" in the specification and claims of this application and the accompanying drawings are used to distinguish different objects rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions.

[0155] In the embodiments of this application, the term "indication" may refer to a direct indication, an indirect indication, or an indication of an association. For example, "A indicates B" may refer to a direct indication of B, e.g., B can obtain information through A; it may refer to an indirect indication of B, e.g., A indicates C, e.g., B can obtain information through C; or it may refer to an association between A and B.

[0156] In the embodiment of the present application, "B corresponding to A" means that B is associated with A and B can be determined based on A. However, it should be understood that determining B based on A does not mean determining B based solely on A, but B can also be determined based on A and / or other information.

[0157] In the embodiments of the present application, the term "corresponding" may indicate a direct or indirect correspondence between the two, or an association relationship between the two, or a relationship between indication and indication, configuration and configuration, etc.

[0158] In the embodiments of the present application, "pre-definition" or "pre-configuration" may be implemented by pre-storing corresponding codes, tables, or other methods that can be used to indicate relevant information in a device (e.g., a terminal device and a network device). The present application does not limit the specific implementation method. For example, pre-definition may refer to information defined in a protocol.

[0159] In the embodiments of the present application, the “protocol” may refer to a standard protocol in the communications field, for example, it may include an LTE protocol, an NR protocol, and related protocols used in future communication systems, and the present application does not limit this.

[0160] In the embodiments of this application, the term "and / or" is simply a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

[0161] In various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0162] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0164] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0165] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be read by a computer or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital versatile disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0166] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for transmitting data, characterized in that include: Before receiving confirmation from the second device, the first device sends a first type of data packet to the second device, where the first type of data packet includes: a data packet that has been transmitted but for which it is not determined whether the transmission is successful.

2. The method according to claim 1, characterized in that Before sending the first type of data packet to the second device, the method further includes: The first device determines a second type of data packet, where the second type of data packet includes one or more of the following: Data packets that have not been transmitted; Acknowledges packets that have failed transmission and are awaiting retransmission.

3. The method according to claim 2, characterized in that The method further comprises: If the first device receives the first information, the first device sends the second type of data packet to the second device; The first information is used to indicate that the second device has received part or all of the first category of data packets, and the second category of data packets includes part of the first category of data packets.

4. The method according to claim 3, characterized in that The method further comprises: If the first device does not receive the first information, the first device sends the first type of data packet to the second device.

5. The method according to any one of claims 1 to 4, characterized in that The method further comprises: The first device deletes a third type of data packet, wherein a discard timer corresponding to the third type of data packet has timed out.

6. The method according to claim 5, characterized in that The third type of data packet is determined based on second information sent by a Packet Data Convergence Protocol (PDCP) layer, where the second information is used to indicate in advance a timeout period of a data packet of a Radio Link Control (RLC) layer.

7. The method according to claim 6, characterized in that The time difference between the sending time of the second information and the timeout time of the third type of data packet is determined based on protocol predefined information or configuration information of the network device.

8. The method according to any one of claims 1 to 7, characterized in that Whether the data packet in the RLC layer is successfully transmitted is determined based on one or more of the following: RLC status report; Hybrid Automatic Repeat Request HARQ feedback information.

9. The method according to any one of claims 1 to 8, characterized in that The first type of data packet includes multiple data packets, and the order in which the multiple data packets are placed into the transmission block is determined based on one or more of the following: types of the plurality of data packets; RLC sequence numbers SN of the multiple data packets; The remaining delay budget of the plurality of data packets.

10. The method according to any one of claims 1 to 9, characterized in that The method further comprises: The first device sends third information to the second device, where the third information is used to indicate one or more of the following: The first data packet in the RLC layer has been deleted; There is no need to retransmit the first data packet.

11. The method according to any one of claims 1 to 10, characterized in that The number of retransmissions of the data packet in the RLC layer reaching the maximum value is not used to trigger the radio resource control RRC re-establishment process.

12. The method according to any one of claims 1 to 10, characterized in that The number of retransmissions of the data packet in the RLC layer is determined based on the RLC status report.

13. The method according to any one of claims 1 to 12, characterized in that Before sending the first type of data packet to the second device, the method further includes: The first device obtains fourth information, where the fourth information is used to indicate whether transmission of the first type of data packet through a transmission block is allowed before confirming that the transmission is successful.

14. The method according to claim 13, characterized in that The fourth information satisfies one or more of the following: The fourth information is configuration information for uplink transmission; The fourth information is configuration information for downlink transmission; The fourth information is configuration information for part or all of the data packets in the downlink transmission and / or the uplink transmission.

15. The method according to claim 14, characterized in that The fourth information is configuration information for part of the data packets in the downlink transmission and / or the uplink transmission, and the part of the data packets is indicated based on a packet header of the data packet.

16. The method according to any one of claims 1 to 15, characterized in that Before sending the first type of data packet to the second device, the method further includes: The first device sends fifth information, where the fifth information is used to indicate whether the first device supports the first type of data packet.

17. A method for transmitting data, characterized in that include: The second device receives a first type of data packet sent by the first device, where the first type of data packet includes: a data packet that has been transmitted but it is not determined whether the transmission is successful.

18. The method according to claim 17, characterized in that The first device further includes a second type of data packet in a radio link control (RLC) layer, where the second type of data packet includes one or more of the following: Data packets that have not been transmitted; Acknowledges packets that have failed transmission and are awaiting retransmission.

19. The method according to claim 17 or 18, characterized in that The first device also includes a third type of data packet in the RLC layer, and a discard timer corresponding to the third type of data packet has timed out.

20. The method according to claim 19, characterized in that The third type of data packet is determined based on second information sent by a Packet Data Convergence Protocol (PDCP) layer, where the second information is used to indicate in advance a timeout period of the data packet at the RLC layer.

21. The method according to claim 20, characterized in that The time difference between the sending time of the second information and the timeout time of the third type of data packet is determined based on protocol predefined information or configuration information of the network device.

22. The method according to any one of claims 17 to 21, characterized in that Whether the data packet in the RLC layer is successfully transmitted is determined based on one or more of the following: RLC status report; Hybrid Automatic Repeat Request HARQ feedback information.

23. The method according to any one of claims 17 to 22, characterized in that The first type of data packet includes multiple data packets, and the order in which the multiple data packets are placed into the transmission block is determined based on one or more of the following: types of the plurality of data packets; RLC sequence numbers SN of the multiple data packets; The remaining delay budget of the plurality of data packets.

24. The method according to any one of claims 17 to 23, characterized in that The method further comprises: The second device receives third information sent by the first device, where the third information is used to indicate one or more of the following: The first data packet in the RLC layer has been deleted; There is no need to retransmit the first data packet.

25. The method according to claim 24, characterized in that After receiving the third information, the method further includes: The second device determines that the first data packet has been successfully received, or does not indicate in an RLC status report whether the first data packet has been successfully received.

26. The method according to any one of claims 17 to 25, characterized in that The number of retransmissions of the data packet in the RLC layer reaching the maximum value is not used to trigger the radio resource control RRC re-establishment process.

27. The method according to any one of claims 17 to 25, characterized in that The number of retransmissions of the data packet in the RLC layer is determined based on the RLC status report.

28. The method according to any one of claims 17 to 27, characterized in that Before the second device receives the first type of data packet sent by the first device, the method further includes: The second device sends fourth information to the first device, where the fourth information is used to indicate whether to allow transmission of the first type of data packet through a transmission block before confirming that the transmission is successful.

29. The method according to claim 28, characterized in that The fourth information satisfies one or more of the following: The fourth information is configuration information for uplink transmission; The fourth information is configuration information for downlink transmission; The fourth information is configuration information for part or all of the data packets in the downlink transmission and / or the uplink transmission.

30. The method according to claim 29, wherein The fourth information is configuration information for part of the data packets in the downlink transmission and / or the uplink transmission, and the part of the data packets is indicated based on a packet header of the data packet.

31. The method according to any one of claims 17 to 30, characterized in that Before the second device receives the first type of data packet sent by the first device, the method further includes: The second device receives fifth information sent by the first device, where the fifth information is used to indicate whether the first device supports transmission of the first type of data packet through a transmission block.

32. A communication device, characterized in that: The communication device is a first device, and the communication device includes: The first sending unit is configured to send a first type of data packet to the second device before receiving a radio link control RLC status report, where the first type of data packet includes: a data packet that has been transmitted but for which it is not determined whether the transmission is successful.

33. The communication device according to claim 32, wherein: Before sending the first type of data packet to the second device, the method further includes: A determining unit is configured to determine a second category of data packets, where the second category of data packets includes one or more of the following: Data packets that have not been transmitted; Acknowledges packets that have failed transmission and are awaiting retransmission.

34. The communication device according to claim 32 or 33, characterized in that The communication device further includes: a second sending unit, configured to send the second type of data packet to the second device if the first device receives the first information; The first information is used to indicate that the second device has received part or all of the first category of data packets, and the second category of data packets includes part of the first category of data packets.

35. The communication device according to claim 34, characterized in that The communication device further includes: The third sending unit is configured to send the first type of data packet to the second device if the first device does not receive the first information.

36. The communication device according to any one of claims 32 to 35, characterized in that The method further comprises: The deleting unit is used to delete a third type of data packet, wherein a discard timer corresponding to the third type of data packet has timed out.

37. The communication device according to claim 36, wherein: The third type of data packet is determined based on second information sent by a Packet Data Convergence Protocol (PDCP) layer, where the second information is used to indicate in advance a timeout period of the data packet at the RLC layer.

38. The communication device according to claim 37, wherein: The time difference between the sending time of the second information and the timeout time of the third type of data packet is determined based on protocol predefined information or configuration information of the network device.

39. The communication device according to any one of claims 32 to 38, characterized in that Whether the data packet in the RLC layer is successfully transmitted is determined based on one or more of the following: RLC status report; Hybrid Automatic Repeat Request HARQ feedback information.

40. The communication device according to any one of claims 32 to 39, characterized in that The first type of data packet includes multiple data packets, and the order in which the multiple data packets are placed into the transmission block is determined based on one or more of the following: types of the plurality of data packets; RLC sequence numbers SN of the multiple data packets; The remaining delay budget of the plurality of data packets.

41. The communication device according to any one of claims 32 to 40, characterized in that The communication device further includes: A third sending unit is configured to send third information to the second device, where the third information is used to indicate one or more of the following: The first data packet in the RLC layer has been deleted; There is no need to retransmit the first data packet.

42. The communication device according to any one of claims 32 to 41, characterized in that The number of retransmissions of the data packet in the RLC layer reaching the maximum value is not used to trigger the radio resource control RRC re-establishment process.

43. The communication device according to any one of claims 32 to 41, characterized in that The number of retransmissions of the data packet in the RLC layer is determined based on the RLC status report.

44. The communication device according to any one of claims 32 to 43, characterized in that The communication device further includes: The receiving unit is configured to obtain fourth information before sending the first type of data packet to the second device, where the fourth information is used to indicate whether the first type of data packet is allowed to be transmitted through the transmission block before confirming that the transmission is successful.

45. The communication device according to claim 44, characterized in that The fourth information satisfies one or more of the following: The fourth information is configuration information for uplink transmission; The fourth information is configuration information for downlink transmission; The fourth information is configuration information for part or all of the data packets in the downlink transmission and / or the uplink transmission.

46. The communication device according to claim 45, characterized in that The fourth information is configuration information for part of the data packets in the downlink transmission and / or the uplink transmission, and the part of the data packets is indicated based on a packet header of the data packet.

47. The communication device according to any one of claims 32 to 46, characterized in that The communication device further includes: The fourth sending unit is configured to send fifth information before sending the first type of data packet to the second device, where the fifth information is used to indicate whether the first device supports transmission of the first type of data packet through a transmission block.

48. A communication device for transmitting data, characterized in that include: The first receiving unit is configured to receive a first type of data packet sent by a first device, where the first type of data packet includes a data packet that has been transmitted but for which it is not determined whether the transmission is successful.

49. The communication device according to claim 48, characterized in that The first device further includes a second type of data packet in a radio link control (RLC) layer, where the second type of data packet includes one or more of the following: Data packets that have not been transmitted; Acknowledges packets that have failed transmission and are awaiting retransmission.

50. The communication device according to claim 48 or 49, characterized in that The first device also includes a third type of data packet in the RLC layer, and a discard timer corresponding to the third type of data packet has timed out.

51. The communication device according to claim 50, characterized in that The third type of data packet is determined based on second information sent by a Packet Data Convergence Protocol (PDCP) layer, where the second information is used to indicate in advance a timeout period of the data packet at the RLC layer.

52. The communication device according to claim 51, characterized in that The time difference between the sending time of the second information and the timeout time of the third type of data packet is determined based on protocol predefined information or configuration information of the network device.

53. The communication device according to any one of claims 48 to 52, characterized in that Whether the data packet in the RLC layer is successfully transmitted is determined based on one or more of the following: RLC status report; Hybrid Automatic Repeat Request HARQ feedback information.

54. The communication device according to any one of claims 48 to 53, characterized in that The first type of data packet includes multiple data packets, and the order in which the multiple data packets are placed into the transmission block is determined based on one or more of the following: types of the plurality of data packets; RLC sequence numbers SN of the multiple data packets; The remaining delay budget of the plurality of data packets.

55. The communication device according to any one of claims 48 to 54, characterized in that The communication device further includes: The second receiving unit is configured to receive third information sent by the first device, where the third information is used to indicate one or more of the following: The first data packet in the RLC layer has been deleted; There is no need to retransmit the first data packet.

56. The communication device according to claim 55, characterized in that The communication device further includes: A determining unit is configured to, after receiving the third information, determine whether the first data packet has been successfully received, or not indicate in an RLC status report whether the first data packet has been successfully received.

57. The communication device according to any one of claims 48 to 56, characterized in that The number of retransmissions of the data packet in the RLC layer reaching the maximum value is not used to trigger the radio resource control RRC re-establishment process.

58. The communication device according to any one of claims 48 to 56, characterized in that The number of retransmissions of the data packet in the RLC layer is determined based on the RLC status report.

59. The communication device according to any one of claims 48 to 58, characterized in that The communication device further includes: A sending unit is used to send fourth information to the first device before the second device receives the first type of data packet sent by the first device, where the fourth information is used to indicate whether the first type of data packet is allowed to be transmitted through the transmission block before confirming that the transmission is successful.

60. The communication device according to claim 59, wherein The fourth information satisfies one or more of the following: The fourth information is configuration information for uplink transmission; The fourth information is configuration information for downlink transmission; The fourth information is configuration information for part or all of the data packets in the downlink transmission and / or the uplink transmission.

61. The communication device according to claim 60, characterized in that The fourth information is configuration information for part of the data packets in the downlink transmission and / or the uplink transmission, and the part of the data packets is indicated based on a packet header of the data packet.

62. The communication device according to any one of claims 48 to 61, characterized in that The communication device further includes: The third receiving unit is used to receive fifth information sent by the first device before the second device receives the first type of data packet sent by the first device, where the fifth information is used to indicate whether the first device supports transmission of the first type of data packet through a transmission block.

63. A communication device, characterized in that The terminal comprises a transceiver, a memory and a processor, wherein the memory is used to store a program, and the processor is used to call the program in the memory and control the transceiver to receive or send a signal so that the terminal executes the method as described in any one of claims 1-16 or 17-31.

64. A device, characterized in that The device comprises a processor configured to call a program from a memory so as to cause the device to execute the method according to any one of claims 1 to 16 or 17 to 31.

65. A chip, characterized in that The device comprises a processor configured to call a program from a memory so that a device equipped with the chip executes the method according to any one of claims 1 to 16 or 17 to 31.

66. A computer-readable storage medium, characterized in that A program is stored thereon, the program causing a computer to execute the method according to any one of claims 1-16 or 17-31.

67. A computer program product, characterized in that The method comprises a program for causing a computer to execute the method according to any one of claims 1 to 16 or 17 to 31.

68. A computer program, characterized in that The computer program causes a computer to execute the method according to any one of claims 1 to 16 or 17 to 31.

Images