Wireless communication method and communication equipment

Abstract

The invention provides a wireless communication method and communication equipment. The wireless communication method comprises: before receiving confirmation of a second device, a first device sends a first type of data packets to the second device, the first type of data packets including data packets that have been transmitted but are not determined to be transmitted successfully.

Description

[0001] This divisional application is based on the parent patent application with application number CN202480000398.0, application date February 8, 2024, and title "Wireless Communication Method and Communication Device". The entire contents of the parent patent application are incorporated herein by reference. Technical Field

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

[0003] 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).

[0004] In AM mode, if a communication device receives a non-acknowledgement (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

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

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

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

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

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

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

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

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

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

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

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

[0016] 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

[0017] Figure 1 This is a system architecture example diagram of a wireless communication system to which embodiments of this application can be applied.

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

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

[0020] Figure 4 This is a flowchart illustrating a wireless communication method provided in one embodiment of this application.

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

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

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

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

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

[0026] Figure 10 This is a schematic diagram of the device provided in an embodiment of this application. Detailed Implementation

[0027] Communication system architecture Figure 1This is a system architecture example diagram of a wireless communication system 100 applicable to embodiments of this application. 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 An exemplary network device and a terminal device are shown. 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 application embodiment 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, and so on.

[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] like Figure 2 As shown, 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. 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 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).

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

[0040] 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 transmitted RLC PDUs equals the total size indicated by the MAC layer. In UM mode, the sender is only responsible for sending the 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).

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

[0042] In some embodiments, the wireless communication method provided in this application mainly relates to a data packet transmission method in RLC AM mode, which is described below in conjunction with... Figure 3 The data packet transmission method under the AM mode described above will be introduced in detail.

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

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

[0045] 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 indicate to the receiving end that it needs to send an RLC status report. For example, when Poll is 1, the receiving end sends an RLC status report; when Poll is 0, the receiving end does not send an RLC status report.

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

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

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

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

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

[0051] Based on the above description, it can be seen that in AM mode, after the sending end sends a data packet, if it receives a status report (including NACK information for the data packet) from the receiving end, it will retransmit the data packet, ensuring the reliability of data packet transmission. However, the sending end must wait for the receiving end 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.

[0052] To reduce data packet transmission latency in AM mode, a blind retransmission mechanism has been proposed in related technologies. This mechanism involves the sender retransmitting all data packets even when unsure whether the receiver has correctly received them. For example, in the above... Figure 3 Before step S340, the sending end can resend data packets 1-20 to the receiving end. It can be seen that this method improves the success rate of data packet transmission at the expense of wireless resource utilization. This method 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.

[0053] 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).

[0054] 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). 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. The following is in conjunction with... Figure 4 The above wireless communication methods will be described in more detail.

[0055] Figure 4 This is a schematic flowchart of the wireless communication method proposed in the embodiments of this application. Figure 4 The communication-free method shown is presented from the perspective of communication between the first and second devices. Figure 4 The first and second devices in the communication link can be two communication devices at opposite ends of the link. The first device can be the transmitting end of the communication link, and the second device can be the receiving end. For example, the first device could be... Figure 1 The network device 110 mentioned in the text. The second device could be, for example, the network device 110. Figure 1 The terminal device 120 mentioned in the text. Of course, the first device could also be... Figure 1 The terminal device 120 mentioned in the text. The second device can be... Figure 1 The network device mentioned in the text is 110.

[0056] See 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.

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

[0058] 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).

[0059] 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).

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

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

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

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

[0064] In some implementations, such as Figure 5As shown, 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 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. 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 first device sends the second type of data packet 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.

[0065] In some implementations, such as Figure 6 As shown, in step 610, if the first device does not receive 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 does not receive 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.

[0066] To deepen the understanding of the wireless communication method in the embodiments of this application, the following will be combined with... Figure 7 This section provides a more detailed description of the wireless communication method.

[0067] like Figure 7 As shown, in step S710, the first device can send multiple data packets to the second device, such as data packets 1-5.

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

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

[0070] It should be understood that after steps S710-S730, if authorized radio resources exist, multiple data packets can be grouped to generate first-type and second-type data packets. The first-type data packets may include, for example, data packets 2, 3, and 5, and the second-type data packets 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 data packets to fully utilize radio resources.

[0071] In step S740, if the second device is a network device, the second device can allocate uplink grant (UL grant) radio resources to the first device.

[0072] 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, then step S760 is executed, and the first device sends a second type of data packet to 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 packet (such as data packets 2 and 5 mentioned above).

[0073] 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 step S760 is executed, and the first device can send the first type of data packet to the second device.

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

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

[0076] See again Figure 7 If the timer for discarding data packet 2 expires at time T1 before packet reassembly is complete, then data packet 2 can be skipped during the reassembly process, thus saving radio resources. This is mainly because retransmitting a timed-out data packet is pointless.

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

[0078] 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. For example, the transmission time of the second information can be before the first device receives the uplink grant for radio resource allocation, as described above. Figure 7 As shown.

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

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

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

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

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

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

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

[0086] 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 assume that the data packet with RLC SN=XXX has been successfully received and update the RLC parameters of the second device.

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

[0088] 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 "data packets whose transmission success is uncertain" (which can be called type 2A) to "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 "data packets confirming successful transmission" (which can be called type 3).

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

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

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

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

[0093] 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".

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

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

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

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

[0098] 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 placement of multiple data packets into a transport block within the logical channel prioritization (LCP) process.

[0099] It is understood 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.

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

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

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

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

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

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

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

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

[0108] 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).

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

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

[0111] 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 process further includes: the first device sending fifth information, which may carry the first device's capability information. This fifth information 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.

[0112] The above text combined Figures 1 to 7 The method embodiments of this application are described in detail below, in conjunction with... Figures 8 to 10 The present application provides a detailed description of the apparatus embodiments. 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 found in the foregoing method embodiments.

[0113] Figure 8 This is a schematic diagram of the structure of a communication device according to an embodiment of this application. Figure 8 The communication device shown is a first device, which 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 uncertain.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0129] Figure 9 This is a schematic diagram of the structure of a communication device according to an embodiment of this application. Figure 9 The communication device shown 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 including: data packets that have been transmitted, but whose transmission success is uncertain.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0162] 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)).

[0163] 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: In response to the second information, the first device retransmits the first type of data packet to the second device; The first type of data packet includes: data packets that have been transmitted but whose transmission success is uncertain. The second information is used to indicate that the first type of data packet timed out at time T1. The retransmission time of the first type of data packet occurs before time T1 arrives. The time difference between the acquisition time of the second information and time T1 is determined according to the configuration information of the network device.

2. The method according to claim 1, characterized in that, The first device acquires the second information, including: The RLC layer of the first device obtains the second information from the PDCP layer of the first device.

3. The method according to claim 1 or 2, characterized in that, Before the first device retransmits the first type of data packet to the second device, it also includes: The first device determines that it has not received the first information, which is used to instruct the second device to receive the first type of data packet.

4. The method according to claim 1 or 2, characterized in that, Also includes: The first device identifies a second type of data packet, which includes one or more of the following: data packets that have not been transmitted; A data packet that has been confirmed as having failed to transmit and is awaiting retransmission; When 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 the first type of data packet.

5. A method for transmitting data, characterized in that, include: The second device receives a first type of data packet retransmitted from the first device. The first type of data packet includes: data packets that have been transmitted, but whose transmission success is uncertain. The first type of data packet is retransmitted by the first device in response to the second information. The second information is used to indicate that the first type of data packet timed out at time T1. The retransmission time of the first type of data packet occurs before time T1 arrives. The advance time of the acquisition time of the second information from time T1 is determined according to the configuration information of the network device.

6. The method according to claim 5, characterized in that, include: The second device sends first configuration information to the first device, the first configuration information being used to instruct the first device's PDCP layer on the lead time for sending the second information to the first device's RLC layer.

7. The method according to claim 5, characterized in that, include: The second device did not send the first information to the first device, the first information being used to indicate that the second device had received the first type of data packet.

8. A communication device, characterized in that, Includes units or modules for performing the method as described in any one of claims 1-4 or 5-7.

9. 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-4 or 5-7.

10. A communication device, characterized in that, Includes a processor for calling a program from memory to cause the device to perform the method as described in any one of claims 1-4 or 5-7.

Images