Wireless communication method and communication device

Abstract

A wireless communication method and a communication device are provided. The wireless communication method comprises: a first device sending a first type of data packet to a second device before receiving a confirmation from the second device, the first type of data packet containing a data packet that has been transmitted but whether the transmission is successful is not determined.

Description

Wireless communication methods and communication devices Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a wireless communication method and communication device. Background Technology

[0002] The radio link control (RLC) layer is primarily responsible for data forwarding, segmentation, retransmission, dropping, and RLC reconstruction. The RLC layer includes three operating modes: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM).

[0003] In AM mode, if a communication device receives a non-acknowledgment (NACK) message from the peer device after sending a data packet, it will retransmit the data packet, ensuring the reliability of data packet transmission. However, the current retransmission mechanism has a relatively large data packet transmission delay. Especially for certain data services with high reliability and low latency requirements, the existing AM mode may not be able to meet their quality of service (QoS) requirements. Summary of the Invention

[0004] This application provides a wireless communication method and a communication device. The various aspects covered by this application are described below.

[0005] In a first aspect, a wireless communication method is provided, comprising: a first device sending a first type of data packet to the second device before receiving confirmation from the second device, the first type of data packet including: data packets that have been transmitted but whose transmission success is uncertain.

[0006] 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, the first type of data packet including: data packets that have been transmitted but whose transmission success is uncertain.

[0007] Thirdly, a communication device is provided, the communication device being a first device, the communication device comprising: a first transmitting unit, configured to transmit 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 including: data packets that have been transmitted but whose transmission success is uncertain.

[0008] Fourthly, a communication device is provided, the communication device being a second device, the communication device comprising: a first receiving unit, configured to receive a first type of data packet sent by a first device, the first type of data packet including: data packets that have been transmitted but whose transmission success is uncertain.

[0009] Fifthly, a communication device is provided, including a transceiver, a memory, and a processor, wherein the memory is used to store a program, the processor is used to invoke the program in the memory, and to control the transceiver to receive or send signals so that the terminal performs the method as described in the first or second aspect.

[0010] A sixth aspect provides an apparatus including a processor for calling a program from a memory to cause the apparatus to perform the method as described in the first or second aspect.

[0011] A seventh aspect provides a chip including a processor for calling a program from memory, causing a device on which the chip is mounted to perform the method as described in the first or second aspect.

[0012] Eighthly, a computer-readable storage medium is provided having a program stored thereon that causes a computer to perform the method as described in the first or second aspect.

[0013] Ninth aspect, a computer program product is provided, including a program that causes a computer to perform the method as described in the first or second aspect.

[0014] In a tenth aspect, a computer program is provided that causes a computer to perform the method as described in the first or second aspect.

[0015] This application provides a wireless communication method in which a first device (transmitter) sends a first type of data packet to a second device (receiver). The first type of data packet includes one or more of the following: data packets that have been transmitted but whose transmission success is uncertain. In other words, in this application embodiment, the first device retransmits "data packets that have been initially transmitted but whose transmission success is uncertain and / or data packets that have been retransmitted and are awaiting confirmation from the second device." Compared to the traditional scheme that relies on RLC status reports for retransmission, this scheme helps reduce data packet transmission latency in AM mode; compared to the traditional scheme that blindly retransmits all data packets, this scheme helps reduce wireless data packet transmission, thereby saving wireless resources. Attached Figure Description

[0016] Figure 1 is a system architecture example diagram of a wireless communication system applicable to embodiments of this application.

[0017] Figure 2 is a schematic diagram of the protocol stack provided in one embodiment of this application.

[0018] Figure 3 is a flowchart illustrating a data packet transmission method in AM mode according to an embodiment of this application.

[0019] Figure 4 is a flowchart illustrating a wireless communication method provided in an embodiment of this application.

[0020] Figure 5 is a flowchart illustrating a wireless communication method provided in another embodiment of this application.

[0021] Figure 6 is a flowchart illustrating a wireless communication method provided in another embodiment of this application.

[0022] Figure 7 is a flowchart illustrating a wireless communication method provided in another embodiment of this application.

[0023] Figure 8 is a schematic diagram of the structure of a communication device provided in one embodiment of this application.

[0024] Figure 9 is a schematic diagram of the structure of a communication device provided in another embodiment of this application.

[0025] Figure 10 is a schematic diagram of the structure of the device provided in the embodiment of this application. Detailed Implementation

[0026] Communication system architecture

[0027] Figure 1 is a system architecture example diagram of a wireless communication system 100 to which embodiments of this application can 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 geographical area and may communicate with the terminal device 120 located within that coverage area.

[0028] Figure 1 exemplarily illustrates 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 area of ​​the network device 110, or all may be located outside the network coverage area of ​​the network device 110, or some may be located within the coverage area of ​​the network device 110 and others outside the network coverage area. This embodiment of the application does not limit this.

[0029] Optionally, the wireless communication system 100 may also include other network entities such as a network controller and a mobility management entity, which is not limited in this embodiment.

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

[0031] The terminal device in this application embodiment can 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 this application embodiment can 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 handheld devices with wireless connectivity, in-vehicle devices, etc. The terminal device in this application embodiment can be a mobile phone, tablet computer, laptop computer, PDA, mobile internet device (MID), wearable device, vehicle, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, etc. For example, the terminal device can act as a dispatching entity, providing sidelink signaling between terminal devices in vehicle-to-everything (V2X) or device-to-device (D2D) communications. For instance, cellular phones and cars communicate with each other using sidelink signals. Cellular phones and smart home devices communicate without relaying communication signals through base stations. Optionally, the terminal device can be used to act as a base station.

[0032] The network device in this application embodiment can be a device for communicating with a terminal device. This network device can also be called an access network device or a wireless access network device, such as a base station. In this application embodiment, the network device can refer to a radio access network (RAN) node (or device) that connects the terminal device to the wireless network. A base station can broadly encompass, or be replaced by, various names including: NodeB, evolved NodeB (eNB), next-generation NodeB (gNB), relay station, access point, transmitting and receiving point (TRP), transmitting point (TP), master MeNB, auxiliary SeNB, multi-mode 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 can be a macro base station, micro base station, relay node, donor node, or similar entities, or combinations thereof. A base station can also refer to a communication module, modem, or chip installed within the aforementioned equipment or apparatus. A base station can also be a mobile switching center, a device that performs base station functions in device-to-device (D2D), V2X, and 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. Base stations can support networks using the same or different access technologies. The embodiments of this application do not limit the specific technologies or device forms used in the network equipment.

[0033] 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 depending on the location of the mobile base station. In other examples, a helicopter or drone can be configured as a device to communicate with another base station.

[0034] In some deployments, the network device in this application embodiment may refer to a CU or a DU, or the network device may include both a CU and a DU. The gNB may also include an AAU.

[0035] Network devices and terminal devices can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can also be deployed in the air on airplanes, balloons, and satellites. This application does not limit the scenario in which the network devices and terminal devices are located.

[0036] Currently, to achieve air interface data transmission, wireless cellular networks employ protocol stack structures on both the network device (such as a base station) and the terminal device side. Communication between the network device and the terminal device can then be achieved based on these protocol stacks.

[0037] As shown in Figure 2, the above 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 packet segmentation and retransmission; the MAC layer is responsible for allocating transmission opportunities to each data radio bearer (DRB) and organizing transport blocks for transmission; and the PHY layer is responsible for transmitting data at the radio interface. In some embodiments, this application mainly relates to the RLC layer, which will be described in more detail below with examples.

[0038] RLC layer

[0039] The RLC layer sits between the PDCP and MAC layers. It communicates with the PDCP layer via the RLC channel and with the MAC layer via a logical channel. The RLC layer is primarily responsible for data forwarding, segmentation, retransmission, discarding, and RLC reconstruction. These functions are implemented by RLC entities, which are created when an RLC bearer is established and deleted when it is released. Each RLC entity can be configured by the radio resource control (RRC) layer and operates in three modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM).

[0040] TM mode, also known as transparent transmission mode, is where data is transparent to the RLC entity using TM mode. The RLC entity does not modify the data in any way (e.g., it does not segment the RLC service data unit (SDU) or add any header information). The TM entity consists only of a transmission buffer that stores the RLC SDU, 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 one RLC SDU from the transmission buffer to the MAC layer without any modification.

[0041] UM mode provides an unreliable service. When a UM entity receives a data packet from a higher layer, it generates an unacknowledged mode data (UMD) protocol data unit (PDU) (containing header information) for each RLC SDU and buffers the generated UMD PDU in the transmission buffer. When the MAC layer instructs it to send an RLC PDU, it segments some RLC SDUs if necessary, regenerating the RLC header and RLC PDU so that the total size of the final sent RLC PDUs equals the total size indicated by the MAC layer. In UM mode, the sender is only responsible for sending data and does not care whether the receiver successfully receives it; the receiver does not send an acknowledgment to the sender after receiving the data. Therefore, UM mode can deliver data packets to the peer entity in order with minimal delay. UM mode is mainly suitable for services that are sensitive to delay but allow for a certain packet loss rate, such as Voice over New Radio (VoNR).

[0042] AM mode provides a reliable service. Compared to UM mode, the main difference is that AM mode adds Automatic Repeat Request (ARQ) error correction functionality on top of the UM functionality. That is, after sending a data packet, the sender needs to wait for an acknowledgment from the receiver confirming whether the packet was received correctly. If the sender receives a negative acknowledgment, it needs to retransmit the failed data packet. Therefore, AM mode can provide reliable data transmission to upper layers, ensuring that data is correctly delivered to the other end. AM mode is mainly suitable for services that are not sensitive to latency but are sensitive to errors, such as File Transfer Protocol (FTP) services.

[0043] In some embodiments, the wireless communication method provided in this application mainly relates to a data packet transmission method in RLC AM mode. The data packet transmission method in AM mode described above will be described in detail below with reference to FIG3.

[0044] As shown in Figure 3, the data packet transmission method in this RLC AM mode may include steps S310 to S350.

[0045] In step S310, the sending end can send multiple data packets to the receiving end, for example, data packets 1-20. It should be understood that if there are many data packets and transmission resources are limited, the multiple data packets can be transmitted in multiple transmissions.

[0046] In step S320, when the amount of data or data packets sent exceeds a preset threshold or other conditions are met (such as sending the last data packet in the buffer), the sending end can send poll information to the receiving end. This poll information can be used to instruct the receiving end to provide an RLC status report. For example, when Poll is 1, the receiving end provides an RLC status report; when Poll is 0, the receiving end does not provide an RLC status report.

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

[0048] In some implementations, the triggering conditions mentioned above can include two aspects. One aspect is triggering by the sender: as shown in step S320 of Figure 3, the sender notifies the receiver to send an RLC status report via the poll command. The triggering conditions for sending poll can include one or more of the following: all data in the sender's buffer has been transmitted; the sender's RLC transmission window is in a blocked state, meaning the sender has sent the maximum number of data packets in transit.

[0049] On the other hand, it can be triggered by the receiving end. For example, the receiving end might set a timer to periodically send RLC status reports; or, if the receiving end determines that a data packet has been sent for a certain period of time, exceeding a threshold, but the receiving end has not yet received the data packet, it will also send an RLC status report. For instance, the receiving end receives data packet number 5 but not data packet number 4. Since it received data packet number 5, the receiving end assumes that the sending end must have sent data packet number 4. After a period of time, if the receiving end still hasn't received data packet number 4, it will send an RLC status report.

[0050] In step S340, in response to the fulfillment of the triggering condition for sending a status report, the receiving end sends an RLC status report to the sending end. This RLC status report may, for example, indicate that data packets 1-15 and 17-20 are acknowledgment (ACK) received data packets, and data packet 16 is a negative acknowledgment (NACK) received data packet.

[0051] In step S350, after receiving the status report from step S340, the sending end determines that data 16 was not transmitted correctly. Based on the NACK information in the status report, the sending end retransmits the failed data packet 16 to the receiving end. The sending end can record the number of retransmissions, for example, data packet 16 is retransmitted twice.

[0052] Based on the above description, it can be seen that in AM mode, after the sender transmits a data packet, if it receives a status report (including NACK information for the data packet) from the receiver, it will retransmit the data packet, ensuring the reliability of data packet transmission. However, the sender must wait for the receiver to send a status report before retransmitting the data packet, resulting in a relatively large data packet transmission delay. Especially for certain data services with high reliability and low latency requirements, the existing AM mode may not be able to meet their Quality of Service (QoS) requirements.

[0053] To reduce packet transmission latency in AM mode, a blind retransmission mechanism has been proposed. This mechanism involves the sender retransmitting all data packets even when unsure if the receiver has received them correctly. For example, before step S340 in Figure 3, the sender can retransmit data packets 1-20 to the receiver. It can be seen that this method sacrifices radio resource utilization to increase the probability of successful packet transmission. This is suitable for ultra-reliable low-latency communications (URLLC) services with small data volumes. However, for URLLC services with large data volumes (such as XR services), the blind retransmission method is not appropriate due to the inherently large data volume of XR services.

[0054] In other words, for URLLC services, the urgent technical problem to be solved is how to balance reducing data packet transmission latency in AM mode with saving radio resources (i.e., improving the utilization rate of radio resources).

[0055] To address the aforementioned problems, this application provides a wireless communication method in which a first device (transmitter) sends a first type of data packet to a second device (receiver). This first type of data packet includes one or more of the following: data packets that have been transmitted but whose transmission success is uncertain. In other words, in this application embodiment, the first device retransmits "data packets that have been initially transmitted but whose transmission success is uncertain and / or data packets that have been retransmitted and are awaiting confirmation from the second device." Compared to the traditional scheme that relies on RLC status reports for retransmission, this scheme helps reduce data packet transmission latency in AM mode; compared to the traditional scheme that blindly retransmits all data packets, this scheme helps reduce wireless data packet transmission, thereby saving wireless resources. The wireless communication method described above will be further described in detail below with reference to Figure 4.

[0056] Figure 4 is a schematic flowchart of the wireless communication method proposed in an embodiment of this application. The wireless communication method shown in Figure 4 is described 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 opposite 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, and the second device can be the network device 110 mentioned in Figure 1.

[0057] Referring to Figure 4, in step S410, before receiving confirmation from the second device, the first device sends a first type of data packet to the second device. This first type of data packet includes data packets that have been transmitted, but whose transmission success is uncertain.

[0058] In some embodiments, a “transmitted but not yet confirmed as successfully transmitted data packet” may include one or more of the following: a data packet that has been initially transmitted but not yet confirmed as successfully transmitted; or a data packet that has been retransmitted and is awaiting confirmation from a second device.

[0059] In some implementations, "data packets that have been initially transmitted but whose transmission success is uncertain" can refer to data packets that the first device receives an RLC status report after the initial transmission, but the RLC status report does not indicate, or the first device does not receive an RLC status report at all (neither an ACK nor a NACK indication is received).

[0060] In some embodiments, "a data packet that has been retransmitted and is awaiting confirmation from a second device" may refer to a data packet that has been retransmitted but has not received an RLC status report indication (neither an ACK indication nor a NACK indication).

[0061] In some implementations, before sending the first type of data packet to the second device, the process further includes: the first device determining a second type of data packet, which includes one or more of the following: untransmitted data packets (new data packets); data packets that failed to transmit (e.g., received a NACK indication) and are awaiting retransmission. It should be understood that data packets awaiting retransmission can refer to data packets placed in a retransmission buffer.

[0062] In some implementations, the second type of data packet may also contain a portion of the first type of data packet.

[0063] This application takes into account that during the packet assembly process, the first device may receive another indication message (such as an RLC status report) from the second device, indicating that some or all of the packets in the first type of data packet have been acknowledged as received. In this case, retransmitting the first type of data packet would inevitably waste radio resources. Therefore, before transmission, the first device can generate N transport blocks, each of which can include different first type of data packets. Then, based on the received first information, the first device sends the corresponding transport block to the second device (this transport block does not include the data packets that have already been acknowledged as received), thereby helping to improve the utilization rate of radio resources.

[0064] For example, the N transport blocks may include a first transport block, a second transport block, and a third transport block. The first transport block contains first-type data packets 1A and second-type data packets 1B; the second transport block contains first-type data packets 2A and second-type data packets 2B; and the third transport block contains first-type data packets 3A and second-type data packets 3B. The first-type data packets contained in first-type data packets 1A, 2A, and 3A are not entirely identical; they may overlap or not. When it's time to send a transport block, if the first device has already received the first information sent by the second device, indicating that first-type data packet 1A has been received, then the first device selects one transport block from the second and third transport blocks to send. If, when it's time to send a transport block, the first device has already received the aforementioned first information sent by the second device, indicating that first-type data packet 2A has been received, then the first device selects one transport block from the first and third transport blocks to send. In this way, the first device can avoid sending data packets for which acknowledgment has already been received, thereby helping to improve resource utilization.

[0065] In some implementations, as shown in Figure 5, in step 510, if the first device receives the first information before sending the first type of data packet to the second device, then the first device sends the second type of data packet; wherein, the first information is used to indicate that the second device has received some or all of the data packets in the first type of data packet. That is, if an acknowledgment indication of some or all of the first type of data packets is received before the packet assembly is completed, then the second type of data packet is sent to the second device, and the second type of data packet only includes a portion of the data packets in the first type of data packet.

[0066] In some implementations, as shown in Figure 6, in step 610, if the first device has not received the first information before sending the first type of data packet to the second device, then the first device sends the first type of data packet to the second device. That is, if the first device has not received confirmation of some or all of the first type of data packets before completing the packet assembly, it continues to send the first type of data packets to the second device.

[0067] To deepen the understanding of the wireless communication method in the embodiments of this application, the wireless communication method will be described in more detail below with reference to Figure 7.

[0068] As shown in Figure 7, in step S710, the first device can send multiple data packets to the second device. For example, the multiple data packets can be data packets 1-5.

[0069] 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, while data packets 2 and 3 were not successfully received. 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 anything for data packet 5.

[0070] In step S730, after receiving the first status report, the first device retransmits data packet 2. In some implementations, due to limited radio resources, data packet 3 is not retransmitted temporarily.

[0071] It should be understood that after steps S710 to S730, if authorized radio resources exist, multiple data packets can be grouped together to generate a first type of data packet and a second type of data packet. The first type of data packet may include, for example, data packets 2, 3, and 5, and the second type of data packet may include data packets 3, 6, and 7. It should be understood that data packet 3 is an RLC status report indicating a negative acknowledgment (NACK), and therefore is the preferred data packet for transmission. Considering that acknowledgments for data packets 2 and 5 may be received subsequently, new data packets 6 and 7 are incorporated into the second type of data packet to fully utilize radio resources.

[0072] In step S740, if the second device is a network device, the second device can configure uplink grant (ULgrant) radio resources for the first device.

[0073] 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 can be used to indicate that the second device has acknowledged receiving a portion of the data packets in the first type of data packets (such as data packets 2 and 5 mentioned above).

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

[0075] It should be understood that in step S750, if the first device has not received 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.

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

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

[0078] Referring again to Figure 7, if the discard timer for data packet 2 expires at time T1 before packet assembly is completed, then data packet 2 can be skipped during the assembly process, thus saving radio resources. This is mainly because retransmitting a timed-out data packet is pointless.

[0079] In some implementations, the third type of data packet can be determined based on second information sent by the PDCP layer, which is used to indicate the timeout period of the data packet at the RLC layer in advance. For example, the second information can be used to indicate that data packet 2 timed out at time T1 mentioned above.

[0080] In some implementations, the lead 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 transmission time of the second information and the timeout time of the third type of data packet is determined based on protocol predefined information or network device configuration information. The transmission time of the second information can be, for example, before the first device receives the allocation time of the uplink authorized radio resources, as shown in Figure 7 above.

[0081] It should be noted that if RLC-enhanced DRB is not used, the above time difference is not used. If the time difference is configured by network equipment (such as base stations), it does not need to be configured.

[0082] In some implementations, the timeliness of data packet transmission is taken into consideration. If the PDCP layer notifies the RLC that the discard timer of the first data packet (such as data packet 2 whose discard timer has expired as mentioned above) has expired, or instructs the RLC to discard a data packet for other reasons, then for the RLC layer, regardless of the type of the first data packet, it will no longer be transmitted.

[0083] In some implementations, the first device can delete the third packet after the discard timer expires, thereby helping to save wireless resources.

[0084] Understandably, after deleting the first data packet, the first device no longer expects to receive an RLC status report about the first data packet from the second device. Therefore, the first device can send a third message to the second device, indicating one or more of the following: the first data packet in the RLC layer has been deleted; or there is no need to retransmit the first data packet.

[0085] 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 be retransmitted.

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

[0087] In some implementations, the third information can indicate the deletion of one data packet at a time, or it can indicate the deletion of multiple data packets at once. For example, in XR service data, the third information can indicate that all data packets in a PDU set have been deleted.

[0088] In some embodiments, after receiving 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 was successfully received in the RLC status report, in order to save wireless transmission resources. For example, after receiving the third information, the second device may consider that the data packet with RLC SN=XXX has been successfully received and update the RLC parameters of the second device.

[0089] In some implementations, whether a data packet in the RLC layer has been successfully transmitted can be determined based on one or more of the following: RLC status reports; hybrid automatic repeat request (HARQ) feedback information.

[0090] In other words, the RLC layer of the first device can determine whether the data packets it sent have 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 packets were successfully transmitted through HARQ feedback or other HARQ behaviors. For example, the first device transmits data packets 1-5 through HARQ process 3. After transmission, it receives uplink resources allocated by the second device (such as a network device), requesting the first device to retransmit the data from HARQ process 3. At this point, the first device can infer that data packets 1-5 were not successfully transmitted. Internally, the first device can update the status of data packets 1-5 from the type "data packets whose transmission success is uncertain" (which can be called type 2A) to the type "data packets confirming transmission failure and waiting for retransmission" (which can be called type 2B). It should be understood that if an ACK indication for data packets 1-5 is subsequently received, the status of data packets 1-5 can be updated again from type 2B to the type "data packets confirming successful transmission" (which can be called type 3).

[0091] By using HARQ feedback, or other feedback that can determine whether a data packet has been successfully transmitted, the first device can perform RLC retransmission on data that has not yet been successfully transmitted before receiving the RLC status report, thus achieving effective RLC AM enhancement. This can reduce data packet transmission latency and save wireless resources.

[0092] It should be noted that the HARQ feedback in this embodiment does not necessarily mean that a feedback signal is actually transmitted. Any feedback information from the second device is sufficient to notify the first device whether the data packet was successfully transmitted, and this feedback information can be used by RLC to infer the transmission status of the data packet.

[0093] It should be noted that in the embodiments of this application, data packets in different states can be divided into multiple types. For example, the "data packet that has not been transmitted" type can be called type 1, the "data packet that has not been successfully transmitted" type can be called type 2A, the "data packet that has been confirmed to have failed transmission and is waiting to be retransmitted" type can be called type 2B, the "data packet that has failed transmission and has been retransmitted" type can be called type 2C, and the "data packet that has been confirmed to have successfully transmitted" type can be called type 3.

[0094] In some implementations, the first type of data packet includes multiple data packets, and the order in which the multiple data packets are placed into the transport 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.

[0095] For example, the first device can put data packets into the transport block in the order of "Type 2B, Type 2C, Type 2A, Type 1".

[0096] For example, the first device can also put the data packet into the transport block according to the RLC SN of the data packet.

[0097] For example, the first device may also place data packets into the transport block in the order of their remaining transmission delay budget, without distinguishing the type of data packets.

[0098] For example, the first device can also place data packets into the transport block in other orders (such as various combinations of the sorting conditions mentioned above). For instance, data packets can be placed into the transport block in the order of the remaining transmission delay budget and the RLC SN of each 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 packets.

[0099] It should be noted that the order in which multiple data packets are placed into the transport block can be determined based on protocol predefined information or network device configuration information.

[0100] It should be noted that the order in which multiple data packets are placed into a transport block does not refer to the order in which the multiple data packets are arranged within the transport block, but rather to the order in which the "determine" action is performed when determining the order in which multiple data packets are placed into a transport block during the logical channel prioritization (LCP) process.

[0101] It is understandable that while the wireless communication method described in this application can accelerate the transmission of RLC data packets, it also increases the number of RLC retransmissions. If the number of RLC retransmissions reaches its maximum value, the first device will consider a radio link failure (RLF) to have occurred, thereby triggering an RRC re-establishment process. To prevent the RRC re-establishment process, in this embodiment, the maximum number of retransmissions of data packets in the RLC layer is not used to trigger the RRC re-establishment process.

[0102] In some implementations, the number of retransmissions of data packets in the RLC layer is determined based on RLC status reports. That is, the first device can increment the RLC retransmission counter only for retransmissions in certain situations. For example, the first device may only increment the RLC retransmission counter when it receives an RLC status report indicating a negative acknowledgment (NACK) and triggers an RLC retransmission. For other RLC retransmissions, the first device may not increment the RLC retransmission counter.

[0103] In some implementations, before sending the first type of data packet to the second device, the process further includes: the first device acquiring fourth information, which indicates whether it is permissible to transmit the first type of data packet via a transport block before confirming successful transmission. In other words, the fourth information can be used to indicate whether RLC enhancement should be performed to reduce the latency of data packet retransmission.

[0104] 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 restrictions 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.

[0105] In some implementations, the fourth information can be explicit or implicit configuration information. For example, for explicit configuration, the fourth information can include a Boolean parameter "whether to perform RLC AM enhancement," where a value of 1 indicates RLC AM enhancement is performed, and a value of 0 indicates it is not performed. The fourth information can also include an enumerated parameter; if it exists, it indicates that RLC AM enhancement should be performed; if it does not exist, it indicates that RLC AM enhancement is not performed. For implicit configuration, the fourth information can include the service type; "whether it is an enhanced XR service" can be determined based on protocol predefined information or network device configuration information. If the service type included in the fourth information is an enhanced service, the protocol defaults to requiring RLC AM enhancement for this type of service.

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

[0107] 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 some or all data packets in downlink transmission and / or uplink transmission.

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

[0109] In some implementations, the aforementioned packet header indication can refer to the packet header indication from the user plane.

[0110] In some implementations, the upper-layer protocol stack of the first device can provide this instruction, such as the header of the Real-Time Transport Protocol (RTP).

[0111] In some implementations, the first device can determine which data packets require RLC AM enhancement based on other information in the packet header. For example, the first device can determine which data packets require RLC AM enhancement based on the priority parameter in the RTP packet header. Thus, RLC AM enhancement can be performed on high-priority data packets, while RLC AM enhancement can be omitted for low-priority data packets.

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

[0113] In some implementations, before the first device sends the first type of data packet to the second device (i.e., before the service data transmission begins), the first device also sends fifth information. This fifth information may carry the first device's capability information and can be used to indicate whether the first device supports transmitting the first type of data packet via transport blocks. In other words, the first device can report its own capability information.

[0114] The method embodiments of this application have been described in detail above with reference to Figures 1 to 7. The apparatus embodiments of this application will be described in detail below with reference to Figures 8 to 10. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments. Therefore, any parts not described in detail can be referred to the foregoing method embodiments.

[0115] Figure 8 is a schematic diagram of the structure of a communication device according to an embodiment of this application. The communication device shown in Figure 8 is a first device, and the communication device 800 includes a first transmitting unit 810. The first transmitting unit 810 is used 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: data packets that have been transmitted, but whose transmission success is not yet determined.

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

[0117] In some implementations, the communication device further includes: a second sending unit, configured to send the second type of data packets 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 some or all of the data packets in the first type of data packets, and the second type of data packets includes some of the data packets in the first type of data packets.

[0118] 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.

[0119] In some implementations, the method further includes a deletion unit for deleting a third type of data packet, wherein the discard timer corresponding to the third type of data packet has expired.

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

[0121] 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 network device configuration information.

[0122] In some implementations, whether a 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.

[0123] In some implementations, the first type of data packet includes multiple data packets, and the order in which the multiple data packets are placed into the transport block is determined based on one or more of the following: the type of the multiple data packets; the RLCSN of the multiple data packets; and the remaining delay budget of the multiple data packets.

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

[0125] In some implementations, the maximum number of retransmissions of data packets in the RLC layer is not used to trigger the RRC re-establishment process.

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

[0127] In some implementations, the communication device further includes a receiving unit, configured to acquire fourth information before sending the first type of data packet to the second device, the fourth information being used to indicate whether the first type of data packet is allowed to be transmitted via a transport block before successful transmission is confirmed.

[0128] 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 some or all data packets in the downlink transmission and / or the uplink transmission.

[0129] In some implementations, the fourth information is configuration information for a portion of the data packets in the downlink transmission and / or the uplink transmission, and the portion of the data packets is based on the packet header indication.

[0130] 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, the fifth information being used to indicate whether the first device supports transmitting the first type of data packet via a transport block.

[0131] Figure 9 is a schematic diagram of the structure of a communication device according to an embodiment of this application. The communication device shown in Figure 9 is a second device, and the communication device 900 includes a first receiving unit 910. The first receiving unit 910 is used to receive a first type of data packet sent by the first device. The first type of data packet includes: data packets that have been transmitted, but whose transmission success is not yet determined.

[0132] In some implementations, the first device further includes a second type of data packet in the RLC layer, the second type of data packet including one or more of the following: data packets that have not been transmitted; data packets that confirm transmission failure and are waiting for retransmission.

[0133] In some implementations, the first device also includes a third type of data packet in the RLC layer, the discard timer corresponding to which the third type of data packet has expired.

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

[0135] 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 network device configuration information.

[0136] In some implementations, whether a 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.

[0137] In some implementations, the first type of data packet includes multiple data packets, and the order in which the multiple data packets are placed into the transport block is determined based on one or more of the following: the type of the multiple data packets; the RLCSN of the multiple data packets; and the remaining delay budget of the multiple data packets.

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

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

[0140] In some implementations, the maximum number of retransmissions of data packets in the RLC layer is not used to trigger the RRC re-establishment process.

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

[0142] 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, the fourth information being used to indicate whether the first type of data packet is allowed to be transmitted via a transport block before successful transmission is confirmed.

[0143] 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 some or all data packets in the downlink transmission and / or the uplink transmission.

[0144] In some implementations, the fourth information is configuration information for a portion of the data packets in the downlink transmission and / or the uplink transmission, and the portion of the data packets is based on the packet header indication.

[0145] 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, the fifth information being used to indicate whether the first device supports transmitting the first type of data packet via a transport block.

[0146] Figure 10 is a schematic structural diagram of the apparatus according to an embodiment of this application. The dashed lines in Figure 10 indicate that the unit or module is optional. The apparatus 1000 can be used to implement the methods described in the above method embodiments. The apparatus 1000 can be a chip or a communication device.

[0147] Apparatus 1000 may include one or more processors 1010. The processor 1010 may support apparatus 1000 in implementing the methods described in the preceding method embodiments. 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 other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0148] The apparatus 1000 may further include one or more memories 1020. The memories 1020 store a program that can be executed by the processor 1010, causing the processor 1010 to perform the methods described in the preceding method embodiments. The memories 1020 may be independent of the processor 1010 or integrated within the processor 1010.

[0149] The device 1000 may also include a transceiver 1030. The processor 1010 can communicate with other devices or chips via the transceiver 1030. For example, the processor 1010 can send and receive data with other devices or chips via the transceiver 1030.

[0150] This application also provides a computer-readable storage medium for storing a program. This computer-readable storage medium can be applied to the terminal device provided in this application, and the program causes a computer to execute the methods performed by the terminal device in various embodiments of this application.

[0151] This application also provides a computer program product. The computer program product includes a program. The computer program product can be applied to a terminal device provided in this application embodiment, and the program causes a computer to execute the methods executed by the terminal device in various embodiments of this application.

[0152] This application also provides a computer program. This computer program can be applied to the terminal device provided in this application, and the computer program causes the computer to execute the methods performed by the terminal device in various embodiments of this application.

[0153] It should be understood that the terms "system" and "network" in this application can be used interchangeably. Furthermore, the terminology used in this application is only for explaining specific embodiments of the application and is not intended to limit the application. The terms "first," "second," "third," and "fourth," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. In addition, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0154] In the embodiments of this application, the term "instruction" can be a direct instruction, an indirect instruction, or an indication of a relationship. For example, A instructing B can mean that A directly instructs B, such as B being able to obtain information through A; it can also mean that A indirectly instructs B, such as A instructing C, so B can obtain information through C; or it can mean that there is a relationship between A and B.

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

[0156] In the embodiments of this application, the term "correspondence" can indicate a direct or indirect correspondence between two things, or an association between two things, or a relationship such as instruction and being instructed, configuration and being configured.

[0157] In this application embodiment, "predefined" or "preconfigured" can be implemented by pre-storing corresponding codes, tables, or other means that can be used to indicate relevant information in the device (e.g., including terminal devices and network devices). This application does not limit the specific implementation method. For example, predefined can refer to what is defined in the protocol.

[0158] In this application embodiment, the "protocol" may refer to a standard protocol in the field of communication, such as the LTE protocol, the NR protocol, and related protocols applied to future communication systems. This application does not limit this.

[0159] In the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0160] In the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

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

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

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

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

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

Claims

1. A method for transmitting data, characterized in that, include: The PDCP layer of the first device sends second information to the RLC layer of the first device. The second information is used to indicate the timeout time of the data packets of the RLC layer in advance. The advance time for the PDCP layer to send the second information to the RLC layer is determined by protocol predefined information or network device configuration information. The advance time is the time difference between the sending time of the second information and the timeout time of the third type of data packets. The third type of data packets is determined based on the second information. Before receiving the confirmation from the second device, the RLC layer of the first device sends a first type of data packets to the second device. The first type of data packets includes: data packets that have been transmitted, but whose transmission success is not yet determined. The PDCP entity of the first device corresponds to a unique RLC entity.

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 determining a second type of data packet, the second type of data packet including one or more of the following: data packets that have not been transmitted; data packets that have been confirmed to have failed to transmit and are waiting for retransmission.

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

4. The method according to claim 3, characterized in that, The method further includes: 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, Whether a 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.

6. The method according to any one of claims 1 to 4, 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 transport block is determined based on one or more of the following: the type of the multiple data packets; the RLC sequence number (SN) of the multiple data packets; and the remaining delay budget of the multiple data packets.

7. The method according to any one of claims 1 to 4, characterized in that, The method further includes: the first device sending third information to the second device, the third information indicating 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.

8. The method according to any one of claims 1 to 4, characterized in that, The maximum number of retransmissions of data packets in the RLC layer is not used to trigger the Radio Resource Control (RRC) re-establishment process.

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

10. The method according to any one of claims 1 to 4, characterized in that, Before sending the first type of data packet to the second device, the method further includes: the first device obtaining fourth information, the fourth information being used to indicate whether the first type of data packet is allowed to be transmitted via transport block before the transmission is confirmed to be successful.

11. The method according to claim 10, 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 some or all data packets in the downlink transmission and / or the uplink transmission.

12. The method according to claim 11, characterized in that, The fourth information is configuration information for a portion of the data packets in the downlink transmission and / or the uplink transmission, and the portion of the data packets is based on the packet header indication.

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

14. A method for transmitting data, characterized in that, include: The second device sends first configuration information to the first device. The first configuration information is used to indicate the advance time for the PDCP layer of the first device to send second information to the RLC layer of the first device. The second information is used to indicate the timeout time of the data packets of the RLC layer in advance. The advance time is the time difference between the sending time of the second information and the timeout time of the third type of data packets. The third type of data packets is determined based on the second information. The second device receives the first type of data packets sent by the first device. The first type of data packets includes: data packets that have been transmitted but whose transmission success is not yet determined. The PDCP entity of the first device corresponds to a unique RLC entity.

15. The method according to claim 14, characterized in that, The first device also includes a second type of data packet in the Radio Link Control (RLC) layer, which includes one or more of the following: untransmitted data packets; data packets confirming transmission failure and awaiting retransmission.

16. The method according to claim 14, 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 network device configuration information.

17. The method according to claim 14 or 15, characterized in that, Whether a 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.

18. The method according to claim 14 or 15, 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 transport block is determined based on one or more of the following: the type of the multiple data packets; the RLC sequence number (SN) of the multiple data packets; and the remaining delay budget of the multiple data packets.

19. The method according to claim 14 or 15, characterized in that, The method further includes: the second device receiving third information sent by the first device, the third information indicating 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.

20. The method according to claim 19, characterized in that, After receiving the third information, the method further includes: the second device determining that the first data packet has been successfully received, or not indicating in the RLC status report whether the first data packet has been successfully received.

21. The method according to claim 14 or 15, characterized in that, The maximum number of retransmissions of data packets in the RLC layer is not used to trigger the Radio Resource Control (RRC) re-establishment process.

22. The method according to claim 14 or 15, characterized in that, The number of retransmissions of data packets in the RLC layer is determined based on the RLC status report.

23. The method according to claim 14 or 15, 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 sending fourth information to the first device, the fourth information being used to indicate whether the first type of data packet is allowed to be transmitted via transport block before the transmission is confirmed to be successful.

24. The method according to claim 23, 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 some or all data packets in the downlink transmission and / or the uplink transmission.

25. The method according to claim 24, characterized in that, The fourth information is configuration information for a portion of the data packets in the downlink transmission and / or the uplink transmission, and the portion of the data packets is based on the packet header indication.

26. The method according to claim 14 or 15, 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 receiving fifth information sent by the first device, the fifth information being used to indicate whether the first device supports transmitting the first type of data packet via transport block.

27. A communication device, characterized in that, The communication device is a first device, comprising: a communication unit, configured to send second information to the RLC layer of the first device using the PDCP layer of the first device, the second information being used to indicate the timeout period of data packets in advance of the RLC layer, the advance time of the PDCP layer sending the second information to the RLC layer being determined by protocol predefined information or network device configuration information, the advance time being the time difference between the sending time of the second information and the timeout period of a third type of data packet, the third type of data packet being determined based on the second information; and a first sending unit, configured to send a first type of data packet to the second device before receiving a Radio Link Control (RLC) status report, the first type of data packet including: data packets that have been transmitted but whose transmission success is uncertain; wherein, the PDCP entity of the first device corresponds to a unique RLC entity.

28. The communication device according to claim 27, characterized in that, Before sending the first type of data packet to the second device, the communication device further includes: a determining unit, configured to determine a second type of data packet, the second type of data packet including one or more of the following: a data packet that has not been transmitted; a data packet that has been confirmed to have failed to transmit and is waiting for retransmission.

29. The communication device according to claim 28, characterized in that, The communication device further includes: a second sending unit, configured to send the second type of data packets 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 some or all of the data packets in the first type of data packets, and the second type of data packets includes some of the data packets in the first type of data packets.

30. The communication device according to claim 29, characterized in that, 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.

31. The communication device according to any one of claims 27 to 30, characterized in that, Whether a 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.

32. The communication device according to any one of claims 27 to 30, 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 transport block is determined based on one or more of the following: the type of the multiple data packets; the RLC sequence number (SN) of the multiple data packets; and the remaining delay budget of the multiple data packets.

33. The communication device according to any one of claims 27 to 30, characterized in that, The communication device further includes: a third sending unit, configured to send third information to the second device, the third information being 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.

34. The communication device according to any one of claims 27 to 30, characterized in that, The maximum number of retransmissions of data packets in the RLC layer is not used to trigger the Radio Resource Control (RRC) re-establishment process.

35. The communication device according to any one of claims 27 to 30, characterized in that, The number of retransmissions of data packets in the RLC layer is determined based on the RLC status report.

36. The communication device according to any one of claims 27 to 30, characterized in that, 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, the fourth information being used to indicate whether the first type of data packet is allowed to be transmitted via a transport block before successful transmission is confirmed.

37. The communication device according to claim 36, 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 some or all data packets in the downlink transmission and / or the uplink transmission.

38. The communication device according to claim 37, characterized in that, The fourth information is configuration information for a portion of the data packets in the downlink transmission and / or the uplink transmission, and the portion of the data packets is based on the packet header indication.

39. The communication device according to any one of claims 27 to 30, characterized in that, 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, the fifth information being used to indicate whether the first device supports transmitting the first type of data packet via a transport block.

40. A communication device for transmitting data, characterized in that, include: A communication unit is configured to send first configuration information to a first device. The first configuration information is used to indicate the advance time for the PDCP layer of the first device to send second information to the RLC layer of the first device. The second information is used to indicate the timeout time of the data packets of the RLC layer in advance. The advance time is the time difference between the sending time of the second information and the timeout time of the third type of data packets. The third type of data packets is determined based on the second information. A first receiving unit is configured to receive a first type of data packets sent by the first device. The first type of data packets includes: data packets that have been transmitted but whose transmission success is uncertain. The PDCP entity of the first device corresponds to a unique RLC entity.

41. The communication device according to claim 40, characterized in that, The first device also includes a second type of data packet in the Radio Link Control (RLC) layer, which includes one or more of the following: untransmitted data packets; data packets confirming transmission failure and awaiting retransmission.

42. The communication device according to claim 40, 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 network device configuration information.

43. The communication device according to claim 40 or 41, characterized in that, Whether a 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.

44. The communication device according to claim 40 or 41, 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 transport block is determined based on one or more of the following: the type of the multiple data packets; the RLC sequence number (SN) of the multiple data packets; and the remaining delay budget of the multiple data packets.

45. The communication device according to claim 40 or 41, characterized in that, The communication device further includes: a second receiving unit, configured to receive third information sent by the first device, the third information indicating one or more of the following: the first data packet in the RLC layer has been deleted; or there is no need to retransmit the first data packet.

46. ​​The communication device according to claim 45, characterized in that, The communication device further includes a determining unit, configured to determine, after receiving the third information, whether the first data packet has been successfully received or not indicate in the RLC status report whether the first data packet has been successfully received.

47. The communication device according to claim 40 or 41, characterized in that, The maximum number of retransmissions of data packets in the RLC layer is not used to trigger the Radio Resource Control (RRC) re-establishment process.

48. The communication device according to claim 40 or 41, characterized in that, The number of retransmissions of data packets in the RLC layer is determined based on the RLC status report.

49. The communication device according to claim 40 or 41, characterized in that, 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, the fourth information being used to indicate whether the first type of data packet is allowed to be transmitted via a transport block before the transmission is confirmed to be successful.

50. The communication device according to claim 49, 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 some or all data packets in the downlink transmission and / or the uplink transmission.

51. The communication device according to claim 50, characterized in that, The fourth information is configuration information for a portion of the data packets in the downlink transmission and / or the uplink transmission, and the portion of the data packets is based on the packet header indication.

52. The communication device according to claim 40 or 41, characterized in that, 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, the fifth information being used to indicate whether the first device supports transmitting the first type of data packet via a transport block.

53. A communication device, characterized in that, The device includes a transceiver, a memory, and a processor. The memory stores a program, and the processor invokes the program in the memory and controls the transceiver to receive or transmit signals so that the communication device performs the method as described in any one of claims 1-13 or 14-26.

54. An apparatus, characterized in that, Includes a processor for calling a program from memory to cause the apparatus to perform the method as described in any one of claims 1-13 or 14-26.

55. A chip, characterized in that, Includes a processor for calling a program from memory, causing a device on which the chip is mounted to perform the method as described in any one of claims 1-13 or 14-26.

56. A computer-readable storage medium, characterized in that, It contains a program that causes a computer to perform the method as described in any one of claims 1-13 or 14-26.

57. A computer program product, characterized in that, Includes a program that causes a computer to perform the method as described in any one of claims 1-13 or 14-26.

Images