A communication method and related device

Abstract

The application provides a communication method and related equipment, and belongs to the field of data processing. In the method, the sending end and / or the receiving end can discard the to-be-discarded data packet when the to-be-discarded data packet has been submitted to a lower layer. Moreover, the sending end and / or the receiving end can update the transmission state parameters, such as the state parameters of the sending window, the state parameters of the receiving window, the state parameters of the PDCP layer and the like, in a timely manner after discarding the to-be-discarded data packet. In this way, the transmission or retransmission of the to-be-discarded data packet can be avoided, and the receiving end can avoid receiving data failure, which is beneficial to saving window resources and improving communication quality.

Description

[0001] This application claims priority to Chinese Patent Application No. 202410178018.4, filed on February 8, 2024, entitled "A Communication Method and Related Device", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and in particular to a communication method and related equipment. Background Technology

[0003] New Radio (NR) Layer 2 (L2) includes the Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Media Access Control (MAC), and Physical Layer (PHY). Data generated by the application layer at the transmitting end is sequentially appended with header information from each layer to facilitate the implementation of each layer's functions. Specifically, the RLC layer adds its header information to the PDCP protocol data units (SDUs) from the PDCP layer, encapsulates them into RLC SDUs, enters the RLC layer's transmission window queue, and delivers them to the MAC layer. The MAC layer encapsulates the RLC SDUs into MAC SDUs and then sends them to the receiving end via the PHY layer.

[0004] In some scenarios, partial data packets can be discarded. After confirming the need to discard a portion of data packets, the PDCP layer can transmit a request to the RLC layer to discard that portion. According to protocol specifications, in acknowledged mode (AM), sequence number (SN) gaps cannot be introduced in the SDU. That is, after receiving a request to discard a portion of data packets, if the corresponding SDU has not yet been transmitted to lower layers (e.g., MAC and physical layers), the RLC layer will directly discard the corresponding SDU. If the corresponding SDU has already been transmitted to lower layers, according to the relevant protocol, the sender cannot discard the corresponding SDU. This can lead to transmission window failure between the sender and receiver, such as the sender frequently retransmitting the corresponding SDU, or the receiver window becoming stuck due to some status parameters failing to update. Summary of the Invention

[0005] This application provides a communication method and related equipment that can update the transmission status parameters of the device based on discarded data packets. This method can avoid transmitting or retransmitting discarded data packets and avoid receiving window freezing, which is beneficial to improving communication efficiency and saving air interface resources.

[0006] In a first aspect, a communication method is provided, applied to a sending end, the method comprising: determining dropped data packets; and updating the transmission status parameters of the sending end based on the dropped data packets.

[0007] In this implementation, the sender can update its transmission status parameters, such as the sending window status parameters, based on the dropped data packets. Thus, even if the dropped data packets have already been transmitted to lower layers, the sender can avoid transmitting or retransmitting them, which improves communication efficiency and saves air interface resources.

[0008] Optionally, the dropped data packet can be an SDU or Protocol Data Unit of the RLC layer.

[0009] In one possible implementation of the first aspect described above, the transmission status parameters of the sending end include a first status parameter, which is used to indicate the sequence number of the next data packet to be acknowledged by the sending end.

[0010] Optionally, the first state parameter can be the TX_Next_Ack parameter mentioned below.

[0011] In one possible implementation of the first aspect above, the dropped data packet satisfies a first condition; the first condition includes: the dropped data packet is within the sending window; or the sequence number of the dropped data packet is between the sequence number indicated by the first status parameter and the sequence number of the next data packet to be sent by the sender; or the sequence number of the dropped data packet is greater than or equal to the sequence number indicated by the first status parameter; or the sequence number of the dropped data packet is less than or equal to the sequence number of the next data packet to be sent by the sender.

[0012] In this implementation, the sequence number of the discarded data packet can be between the sequence number indicated by the first status parameter and the sequence number of the next data packet sent by the sender, or between the sequence number indicated by the first status parameter and the sequence number of the next data packet sent by the sender, or between the sequence number indicated by the first status parameter and the sequence number of the discarded data packet and the sequence number of the next data packet sent by the sender, or between the sequence number indicated by the first status parameter and the sequence number of the discarded data packet and the sequence number of the next data packet sent by the sender, or between the sequence number indicated by the first status parameter and the sequence number of the discarded data packet and the sequence number of the next data packet sent by the sender.

[0013] Optionally, the first condition could be, for example, the discard condition corresponding to the RLC layer of the sender, as described below.

[0014] In one possible implementation of the first aspect above, updating the transmission status parameters of the sending end based on the dropped data packets includes: updating the transmission status parameters of the sending end based on the dropped data packets when the dropped data packets satisfy a second condition; wherein the second condition includes: the dropped data packets are within the transmission window; or the sequence number of the dropped data packets is between the sequence number indicated by the first status parameter and the sequence number of the next data packet to be transmitted by the sending end; or the sequence number of the dropped data packets is greater than or equal to the sequence number indicated by the first status parameter; or the sequence number of the dropped data packets is less than or equal to the sequence number of the next data packet to be transmitted by the sending end.

[0015] In this implementation, the sequence number of the discarded data packet can be between the sequence number indicated by the first status parameter and the sequence number of the next data packet sent by the sender, or between the sequence number indicated by the first status parameter and the sequence number of the next data packet sent by the sender, or between the sequence number indicated by the first status parameter and the sequence number of the discarded data packet and the sequence number of the next data packet sent by the sender, or between the sequence number indicated by the first status parameter and the sequence number of the discarded data packet and the sequence number of the next data packet sent by the sender, or between the sequence number indicated by the first status parameter and the sequence number of the discarded data packet and the sequence number of the next data packet sent by the sender.

[0016] Optionally, the second condition may be, for example, the update condition corresponding to the RLC layer of the sending end, as described below.

[0017] In one possible implementation of the first aspect above, updating the transmission status parameters of the sending end based on the dropped data packets includes: if there is a first data packet in the dropped data packets with the same sequence number as the sequence number indicated by the first status parameter, updating the first status parameter to a second sequence number after the first sequence number of the first data packet; or, corresponding to the absence of a data packet in the dropped data packets with the same sequence number as the sequence number indicated by the first status parameter, updating the first status parameter to a second sequence number if the first status parameter is updated to the first sequence number.

[0018] In this implementation, if neither the second nor the first condition exists, the sender can update the transmission status parameters of the sending window if the sequence number indicated by the first status parameter is the same as the first sequence number of the first data packet in the discarded data packets. If no data packet with the same sequence number as the sequence number indicated by the first status parameter exists among the discarded data packets, the sender can wait until the first status parameter is updated to the first sequence number before updating the transmission status parameters of the sending window. In this implementation, the first data packet can be any data packet among the discarded data packets.

[0019] In one possible implementation of the first aspect above, updating the transmission state parameters of the sender based on dropped data packets includes:

[0020] If the sequence number indicated by the first status parameter is the same as the first sequence number of the first data packet in the discarded data packets, the first status parameter is updated to the second sequence number after the first sequence number, wherein the first data packet is the data packet with the smallest sequence number among the discarded data packets; or, if the sequence number indicated by the first status parameter is different from the first sequence number, and the first status parameter is updated to the first sequence number, the first status parameter is updated to the second sequence number.

[0021] This implementation method avoids retransmitting dropped data packets, which is beneficial to communication quality and saves air interface resources.

[0022] In one possible implementation of the first aspect described above, the second sequence number is not among the sequence numbers corresponding to the dropped data packets. That is, the data packet corresponding to the second sequence number is not among the dropped data packets, or in other words, the data packet corresponding to the second sequence number was not dropped.

[0023] In one possible implementation of the first aspect above, the dropped data packets include a first consecutive data packet, the first consecutive data packet includes a first data packet, and the second sequence number is the sequence number of the second data packet following the first consecutive data packet.

[0024] Optionally, the first consecutive data packet may include N (N is an integer greater than or equal to 1) data packets. The first data packet may be the first data packet of the first consecutive data packet or a data packet in the middle of the first consecutive data packet.

[0025] Optionally, consecutive data packets can be data packets with consecutive sequence numbers.

[0026] In one possible implementation of the first aspect described above, the second data packet is the next data packet after the first consecutive data packet, or the first data packet after the first consecutive data packet that has not received an acknowledgment, or the first data packet after the first consecutive data packet that has not received an acknowledgment and is not among the dropped data packets.

[0027] In one possible implementation of the first aspect described above, the first sequence number and the third sequence number corresponding to the last data packet in the first consecutive data packets are maintained based on the first discard state parameter and the second discard state parameter, respectively.

[0028] Optionally, the first discard status parameter can be TX_discard_low as described below, and the discard status parameter can be TX_Discard_High as described below.

[0029] In one possible implementation of the first aspect described above, the method further includes:

[0030] Identify at least one consecutive data packet that has been dropped, and update the first drop status parameter and the second drop status parameter based on the at least one consecutive data packet that has been dropped.

[0031] In one possible implementation of the first aspect above, the maximum value of the sequence numbers corresponding to at least one consecutive data packet is the fourth sequence number, the minimum value is the fifth sequence number, and the fourth sequence number is greater than or equal to the fifth sequence number; and updating the first discard state parameter and the second discard state parameter based on the discarded at least one consecutive data packet includes:

[0032] If the fourth sequence number is less than the first discard status parameter, update the first discard status parameter to the fifth sequence number and update the second discard status parameter to the fourth sequence number.

[0033] Alternatively, if the fourth sequence number is greater than the second discard state parameter, and the fifth sequence number is greater than or equal to the first discard state parameter and less than or equal to the second discard state parameter, then update the second discard state parameter to the fourth sequence number.

[0034] Alternatively, if the fourth sequence number is less than or equal to the second discard state parameter and greater than or equal to the first state parameter, and the fifth sequence number is less than the first discard state parameter, then update the first discard state parameter to the fifth sequence number.

[0035] Alternatively, if the fourth sequence number is less than or equal to the second discard state parameter and greater than or equal to the first state parameter, and the fifth sequence number is less than the first discard state parameter, then update the first discard state parameter to the fifth sequence number.

[0036] Alternatively, if the fourth and fifth serial numbers are between the first and second discard state parameters, or if the fifth serial number is greater than the second discard state parameter, the first and second discard state parameters are not updated.

[0037] In one possible implementation of the first aspect above, the method further includes:

[0038] Send a discard message to the receiving end; the discard message indicates which data packets have been discarded.

[0039] In this implementation, after receiving the discard information, the receiving end can discard the discarded data packet based on the discarded data packet indicated by the discard information, the receiving end's transmission status parameters, and / or the discarded data packet.

[0040] In one possible implementation of the first aspect above, the method further includes: receiving first instruction information;

[0041] In response to the first indication message, the dropped data packet is discarded.

[0042] In this implementation, before or during the process of determining the discarded data packet, the sending end may discard the discarded data packet upon receiving the first indication information. That is, if the sending end does not receive the first indication information, it will not discard the discarded data packet.

[0043] In one possible implementation of the first aspect described above, the method further includes: determining at least one consecutive data packet to be discarded, wherein the maximum value of the sequence number in the at least one consecutive data packet is a fourth sequence number and the minimum value is a fifth sequence number, and the fourth sequence number is greater than or equal to the fifth sequence number; corresponding to the fourth sequence number being less than a first discard status parameter, updating the first discard status parameter to the fifth sequence number and updating the second discard status parameter to the fourth sequence number; or corresponding to the fourth sequence number being greater than the second discard status parameter, and the fifth sequence number being greater than or equal to the first discard status parameter and less than or equal to the discard status parameter, updating the second discard status parameter to the fourth sequence number; or corresponding to the fourth sequence number being less than or equal to the second discard status parameter and greater than or equal to the first status parameter, and the fifth sequence number being less than the first discard status parameter, updating the first discard status parameter to the fifth sequence number; or corresponding to the fourth sequence number and the fifth sequence number being between the first discard status parameter and the second discard status parameter, or the fifth sequence number being greater than the second discard status parameter, not updating the first discard status parameter and the second discard status parameter.

[0044] In one possible implementation of the first aspect described above, the method further includes sending discard information to the receiving end, the discard information being used to indicate a discarded data packet.

[0045] In one possible implementation of the first aspect above, determining the data packet to be discarded includes: receiving first indication information and determining the data packet to be discarded in response to the first indication information.

[0046] In this implementation, the first indication information can be used to enable or disable the function of the sender to determine dropped data packets and update the receiver's transmission status parameters based on the dropped data packets. The sender can determine dropped data packets and update the receiver's transmission status parameters based on the dropped data packets only after receiving the first indication information and enabling this function.

[0047] Secondly, a communication method is provided for use at a receiving end, the method comprising: determining dropped data packets; and updating the transmission status parameters of the receiving end based on the dropped data packets.

[0048] In this implementation, the receiver can update its transmission status parameters based on the dropped data packets, such as the status parameters of the receive window and the status parameters of the PDCP layer. Thus, even if the dropped data packets have already been transmitted to lower layers, the sender can avoid transmitting or retransmitting the dropped data packets, and the receive window can be prevented from freezing, which helps improve communication efficiency and save air interface resources.

[0049] In one possible implementation of the second aspect above, the transmission status parameters of the receiving end include at least one of the following parameters: a second status parameter, which indicates the sequence number of the next data packet after the latest data packet received completely in sequence by the receiving end; a third status parameter, which indicates the sequence number of the next data packet after the latest data packet received completely by the receiving end; and a fourth status parameter, which indicates the next sequence number of the data packet corresponding to the sequence number that triggered the reassembly timer.

[0050] Optionally, the second status parameter can be RX_Next (hereinafter referred to as RX_Next), the third status parameter can be RX_Highest_Status (hereinafter referred to as RX_Highest_Status), and the fourth status parameter can be RX_Next_Status_Trigger (hereinafter referred to as RX_Next_Status_Trigger).

[0051] In one possible implementation of the second aspect described above, updating the transmission status parameters of the receiving end based on the dropped data packets includes: updating the transmission status parameters of the receiving end based on the dropped data packets when the dropped data packets satisfy a third condition; wherein the third condition includes: the dropped data packets are within the receiving window; or the sequence number of the dropped data packets is between the sequence number indicated by the second status parameter and the largest sequence number among the sequence numbers of the data packets that the receiving end has completely received; or the sequence number of the dropped data packets is between the sequence number indicated by the second status parameter and the sequence number indicated by the third status parameter; or the sequence number of the dropped data packets is between the sequence number indicated by the second status parameter and the sequence number indicated by the fourth status parameter; or the sequence number of the dropped data packets is greater than or equal to the sequence number indicated by the second status parameter; or the sequence number of the dropped data packets is less than or equal to the largest sequence number among the sequence numbers of the data packets that the receiving end has completely received; or the sequence number of the dropped data packets is less than or equal to the sequence number indicated by the third status parameter; or the sequence number of the dropped data packets is less than or equal to the sequence number indicated by the fourth status parameter.

[0052] In this implementation, the receiver only updates its transmission status parameters if the dropped data packet meets the third condition, and does not need to update the receiver's transmission status parameters if the dropped data packet does not meet the third condition. This reduces the overhead of maintaining the receiver's transmission status parameters.

[0053] In one possible implementation of the second aspect above, updating the transmission status parameters of the receiving end based on the discarded data packets includes: if there is a third data packet in the discarded data packets with the same sequence number as the sequence number indicated by the second status parameter, updating the second status parameter to a seventh sequence number after the sixth sequence number of the third data packet; or, corresponding to the absence of a data packet in the discarded data packets with the same sequence number as the sequence number indicated by the second status parameter, updating the second status parameter to a seventh sequence number if the second status parameter is updated to a sixth sequence number.

[0054] In this implementation, if the aforementioned third condition does not exist, the receiving end can update the transmission status parameters of the receiving window if the sequence number indicated by the second status parameter is the same as the sixth sequence number of the third data packet in the discarded data packets. If there is no data packet in the discarded data packets with the same sequence number as the sequence number indicated by the second status parameter, the receiving end can wait until the second status parameter is updated to the sixth sequence number before updating the transmission status parameters of the receiving window. In this implementation, the third data packet can be any data packet in the discarded data packets.

[0055] In one possible implementation of the second aspect above, updating the transmission state parameters of the receiving end based on dropped data packets includes:

[0056] If the sequence number indicated by the second status parameter is the same as the sixth sequence number of the third data packet among the discarded data packets, the second status parameter is updated to the seventh sequence number after the sixth sequence number, where the third data packet is the data packet with the smallest sequence number among the discarded data packets;

[0057] Alternatively, if the sequence number indicated by the second state parameter is different from the sixth sequence number, and the second state parameter is updated to the sixth sequence number, then the second state parameter is updated to the seventh sequence number.

[0058] In one possible implementation of the second aspect above, the dropped data packets include a second consecutive data packet, the second consecutive data packet includes a third data packet, and the seventh sequence number is the sequence number of the fourth data packet following the second consecutive data packet.

[0059] Optionally, the second consecutive data packet may include N (N is an integer greater than or equal to 1) data packets, and the third data packet may be the first data packet of the second consecutive data packet or a data packet in the middle of the second consecutive data packet.

[0060] In one possible implementation of the second aspect described above, the seventh sequence number is not among the sequence numbers corresponding to the dropped data packets. That is, the data packet corresponding to the seventh sequence number is not among the dropped data packets, or in other words, the data packet corresponding to the seventh sequence number was not dropped.

[0061] In one possible implementation of the second aspect above, the fourth data packet is the next data packet after the second consecutive data packet, or the first data packet that was not fully received after the second consecutive data packet, or the first data packet that was not fully received after the second consecutive data packet and is not among the dropped data packets.

[0062] In one possible implementation of the second aspect above, the discarded data packets include a second consecutive data packet, the second consecutive data packet includes a third data packet; and updating the transmission status parameters of the receiving end based on the discarded data packets further includes:

[0063] If the sequence number of the last data in the second consecutive data packet is greater than or equal to the sequence number indicated by the third status parameter, the third status parameter is updated to the eighth sequence number;

[0064] And / or if the sequence number of the last data in the second consecutive data packet is greater than or equal to the sequence number corresponding to the fourth state parameter, the fourth state parameter is updated to the next sequence number of the largest sequence number among the sequence numbers of the data packets that the receiver has completely received;

[0065] The eighth sequence number is the sequence number of the fifth data packet following the second consecutive data packet. The fifth data packet is either the next data packet after the second consecutive data packet or the first data packet that was not fully received after the second consecutive data packet.

[0066] In one possible implementation of the second aspect above, the method further includes:

[0067] A status report is sent to the sending end, indicating that all data packets in the second consecutive data packet have been completely received by the receiving end.

[0068] In one possible implementation of the second aspect above, sending the report to the sender includes:

[0069] If the acknowledgment (ACK) feedback for one or more packets in the second consecutive data packet is not sent to the sender, a status report is sent to the sender, which includes the ACKs for one or more packets.

[0070] In one possible implementation of the second aspect above, the ninth sequence number corresponding to the sixth sequence number and the last data packet in the second consecutive data packet is maintained based on the third discard state parameter and the fourth discard state parameter, respectively.

[0071] Optionally, the third discard status parameter can be RX_discard_low as described below, and the fourth discard status parameter can be RX_Discard_High as described below.

[0072] In one possible implementation of the second aspect above, the method further includes:

[0073] Identify at least one consecutive data packet that has been dropped, and update the third and fourth drop status parameters based on the dropped data packet.

[0074] In one possible implementation of the second aspect above, the maximum value of the sequence numbers corresponding to the at least one consecutive data packet is the tenth sequence number, the minimum value is the eleventh sequence number, and the tenth sequence number is greater than or equal to the eleventh sequence number; and updating the third and fourth discard status parameters based on the at least one discarded consecutive data packet includes:

[0075] If the tenth sequence number is less than the third discard status parameter, update the third discard status parameter to the eleventh sequence number and update the fourth discard status parameter to the tenth sequence number.

[0076] Alternatively, if the tenth sequence number is greater than the fourth discard state parameter, and the eleventh sequence number is greater than or equal to the third discard state parameter and less than or equal to the discard state parameter, then update the fourth discard state parameter to the tenth sequence number.

[0077] Alternatively, if the tenth sequence number is less than or equal to the fourth discard state parameter and greater than or equal to the third state parameter, and the eleventh sequence number is less than the third discard state parameter, then update the third discard state parameter to the eleventh sequence number.

[0078] Alternatively, if the tenth sequence number is less than or equal to the fourth discard state parameter and greater than or equal to the third state parameter, and the eleventh sequence number is less than the third discard state parameter, then update the third discard state parameter to the eleventh sequence number.

[0079] Alternatively, if the tenth and eleventh serial numbers are between the third and fourth discard state parameters, or if the eleventh serial number is greater than the fourth discard state parameter, then the third and fourth discard state parameters are not updated.

[0080] In one possible implementation of the second aspect above, the receiving end includes a radio link control layer, and the radio link control layer: determines the dropped data packets; and updates the transmission state parameters of the receiving end based on the dropped data packets.

[0081] In one possible implementation of the second aspect above, the transmission status parameters of the receiving end include at least one of the following parameters:

[0082] The fifth state parameter is used to indicate the COUNT value corresponding to the first data packet that the PDCP layer at the receiving end has not submitted to the upper layer of the PDCP layer.

[0083] The sixth state parameter is used to indicate the COUNT value corresponding to the data packet that triggered the reassembly timer of the PDCP layer.

[0084] In one possible implementation of the second aspect above, the discarded data packets update the transmission status parameters of the receiving end, including:

[0085] If the dropped data packet satisfies the fourth condition, the transmission status parameters of the receiving end are updated based on the dropped data packet. The fourth condition includes: the COUNT value corresponding to the dropped data packet is between the COUNT value indicated by the fifth status parameter and the COUNT value corresponding to the next data packet received at the PDCP layer; or the COUNT value corresponding to the dropped data packet is greater than or equal to the COUNT value indicated by the fifth status parameter; or the COUNT value corresponding to the dropped data packet is less than or equal to the COUNT value corresponding to the next data packet received at the PDCP layer.

[0086] In one possible implementation of the second aspect above, updating the transmission status parameters of the receiving end based on the discarded data packets includes: if there is a sixth data packet in the discarded data packets with the same COUNT value as the COUNT value indicated by the fifth status parameter, updating the fifth status parameter to the second COUNT value after the first COUNT value of the sixth data packet; or, corresponding to the absence of a data packet in the discarded data packets with the same COUNT value as the COUNT value indicated by the fifth status parameter, updating the fifth status parameter to the second COUNT value if the fifth status parameter is updated to the first COUNT value.

[0087] In this implementation, if the fourth condition does not exist, the receiver can update the transmission status parameters of the receiving window if the COUNT value indicated by the fifth status parameter is the same as the first COUNT value of the sixth data packet in the discarded data packets. If there is no data packet in the discarded data packets with a COUNT value that matches the COUNT value indicated by the first status parameter, the receiver can wait until the fifth status parameter is updated to the first COUNT value before updating the transmission status parameters of the receiving window. In this implementation, the sixth data packet can be any data packet in the discarded data packets.

[0088] In one possible implementation of the second aspect above, updating the transmission state parameters of the receiving end based on dropped data packets includes:

[0089] If the COUNT value indicated by the fifth status parameter is the same as the first COUNT value of the sixth data packet among the discarded data packets, the fifth status parameter is updated to the second COUNT value after the first COUNT value, wherein the sixth data packet is the data packet with the smallest COUNT value among the discarded data packets; or, if the COUNT value indicated by the fifth status parameter is different from the first COUNT value, the fifth status parameter is updated to the second COUNT value if the fifth status parameter is updated to the first COUNT value.

[0090] In one possible implementation of the second aspect above, the dropped data packets include a third consecutive data packet, the third consecutive data packet includes a sixth data packet, and the second COUNT value is the COUNT value of the seventh data packet following the sixth data packet.

[0091] Optionally, the third consecutive data packet may include Q data packets, where Q is an integer greater than or equal to 1. The sixth data packet may be the first data packet of the third consecutive data packet, or it may be a data packet in the middle of the third consecutive data packet.

[0092] In one possible implementation of the second aspect described above, the second COUNT value is not included in the COUNT value corresponding to the dropped data packet.

[0093] In one possible implementation of the second aspect above, the seventh data packet is the next data packet after the third consecutive data packet, or the first data packet after the third consecutive data packet that has not been submitted to the upper layer of the PDCP layer, or the first data packet after the third consecutive data packet that has not been submitted to the upper layer of the PDCP layer and is not among the dropped data packets.

[0094] In one possible implementation of the second aspect above, the update of the receiver's transmission state parameters based on dropped data packets further includes:

[0095] If the second COUNT value is greater than the COUNT value indicated by the sixth status parameter, the sixth status parameter will be updated to the COUNT value corresponding to the next data packet received at the PDCP layer.

[0096] And / or start the PDCP layer recombination timer.

[0097] In one possible implementation of the second aspect above, the first COUNT value and the third COUNT value corresponding to the last data packet in the third consecutive data packet are maintained based on the fifth discard state parameter and the sixth discard state parameter, respectively.

[0098] Optionally, the fifth discard status parameter can be PDCPRX_discard_low as described below, and the sixth discard status parameter can be PDCPRX_Discard_High as described below.

[0099] In one possible implementation of the second aspect above, the method further includes:

[0100] Identify at least one consecutive data packet to be dropped, wherein the maximum value of the COUNT values ​​corresponding to at least one consecutive data packet is the fourth COUNT value and the minimum value is the fifth COUNT value, and the fourth COUNT value is greater than or equal to the fifth COUNT value;

[0101] If the fourth COUNT value is less than the fifth discard status parameter, update the fifth discard status parameter to the fifth COUNT value and update the sixth discard status parameter to the fourth COUNT value.

[0102] Alternatively, if the fourth COUNT value is greater than the fifth discard state parameter, and the fifth COUNT value is greater than or equal to the fifth discard state parameter and less than or equal to the sixth discard state parameter, then update the sixth discard state parameter to the fourth COUNT value.

[0103] Alternatively, if the fourth COUNT value is less than or equal to the sixth discard state parameter and greater than or equal to the fifth state parameter, and the fifth COUNT value is less than the fifth discard state parameter, then update the fifth discard state parameter to the fifth COUNT value.

[0104] Alternatively, if the fourth COUNT value is less than or equal to the sixth discard state parameter and greater than or equal to the fifth state parameter, and the fifth COUNT value is less than the fifth discard state parameter, then update the fifth discard state parameter to the fifth COUNT value.

[0105] Alternatively, if the fourth and fifth COUNT values ​​are between the fifth and sixth discard state parameters, or if the fifth COUNT value is greater than the sixth discard state parameter, then the fifth and sixth discard state parameters are not updated.

[0106] In one possible implementation of the second aspect above, determining the data packet to be dropped includes receiving drop information indicating that the data packet should be dropped.

[0107] In this implementation, the receiving end can determine the dropped data packet indicated by the drop information as the dropped data packet.

[0108] In one possible implementation of the second aspect above, the PDCP layer: determines the dropped data packets; and updates the transmission status parameters of the receiving end based on the dropped data packets.

[0109] Thirdly, a transmitting device is provided, comprising: one or more processors; one or more memories; the one or more memories storing one or more computer programs, the one or more computer programs including instructions that, when executed by the one or more processors, cause the terminal device to perform the method as described in any of the implementations of the first to third aspects above.

[0110] Fourthly, a communication system is provided, including a transmitting device and a receiving device, wherein the transmitting device is configured to perform the method as described in any implementation of the first aspect above, and the receiving device is configured to perform the method as described in any implementation of the second aspect above.

[0111] Fifthly, a computer-readable storage medium is provided, the computer-readable storage medium storing computer-executable program instructions, which, when executed on a computer, cause the computer to perform the method as described in any of the implementations of the first to second aspects above.

[0112] In a sixth aspect, a computer program product is provided, the computer program product including computer program code, which, when run on a computer, causes the computer to perform the method as described in any of the implementations of the first to second aspects above.

[0113] It should be understood that the beneficial effects of the third to sixth aspects mentioned above can be referred to the descriptions of the first and second aspects, and will not be repeated here. Attached Figure Description

[0114] Figure 1A According to some embodiments of this application, a schematic diagram of a user plane protocol architecture is shown.

[0115] Figure 1B According to some embodiments of this application, a schematic diagram of a process for transmitting a set of protocol data units from a sending end to a receiving end is shown.

[0116] Figure 2 According to some embodiments of this application, a schematic diagram of a control plane protocol architecture is shown.

[0117] Figure 3 A schematic diagram of a sending window is shown according to some embodiments of this application.

[0118] Figure 4 A schematic diagram of a receiving window is shown according to some embodiments of this application.

[0119] Figure 5 According to some embodiments of this application, a schematic diagram of the state parameters of a PDCP layer is shown.

[0120] Figure 6A According to some embodiments of this application, a schematic diagram of a process of a sender transmitting data packets is shown.

[0121] Figure 6B According to some embodiments of this application, a schematic diagram of a receiving end receiving data packets is shown.

[0122] Figure 7A According to some embodiments of this application, a schematic diagram of the relationship between data packet A and the sending window is shown.

[0123] Figure 7B According to some embodiments of this application, a schematic diagram of the relationship between data packet A and the receiving window is shown.

[0124] Figures 8A to 8D According to some embodiments of this application, a schematic diagram showing the relationship between some dropped data packets and the sending window is shown.

[0125] Figures 9A to 9E According to some embodiments of this application, schematic diagrams are shown of some scenarios where the sending end discards the window for updating.

[0126] Figure 10A According to some embodiments of this application, a schematic diagram of updating receiver transmission parameters is shown.

[0127] Figure 10B According to some embodiments of this application, another schematic diagram of updating receiver transmission parameters is shown.

[0128] Figures 11A to 11G According to some embodiments of this application, schematic diagrams are shown of some scenarios where the receiving end discards a window.

[0129] Figures 12A to 12C According to some embodiments of this application, schematic diagrams are shown of some updated state parameters of the receiving window.

[0130] Figures 13A to 13B According to some embodiments of this application, schematic diagrams of updating state parameters of the PDCP layer are shown.

[0131] Figures 14A to 14E According to some embodiments of this application, schematic diagrams are shown of some scenarios for updating the PDCP discard window.

[0132] Figure 15A According to some embodiments of this application, a schematic diagram is shown of a network-side device sending first instruction information to a user equipment.

[0133] Figure 15B According to some embodiments of this application, a schematic diagram is shown of a PDCP layer sending first indication information to an RLC layer.

[0134] Figure 15C According to some embodiments of this application, a schematic diagram is shown of a MAC layer sending first indication information to an RLC layer.

[0135] Figure 16 According to some embodiments of this application, a schematic diagram of the interaction flow of a communication method is shown.

[0136] Figure 17 According to some embodiments of this application, a schematic diagram of the interaction flow of another communication method is shown.

[0137] Figure 18 According to some embodiments of this application, a flowchart of a communication method is shown.

[0138] Figure 19 According to some embodiments of this application, a flowchart of another communication method is shown.

[0139] Figure 20 According to some embodiments of this application, a flowchart of yet another communication method is shown.

[0140] Figure 21 A schematic diagram of a system architecture is shown according to some embodiments of this application.

[0141] Figure 22 According to some embodiments of this application, a schematic diagram of the structure of a transmitting device 00 is shown. Detailed Implementation

[0142] It should be noted that the terminology used in the implementation section of the embodiments of this application is only used to explain the specific embodiments of this application and is not intended to limit this application. In the description of the embodiments of this application, unless otherwise stated, " / " means "or", for example, A / B can mean A or B; "and / or" in this document is merely a description of the association relationship of related obstacles, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. In addition, in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, "at least one" or "one or more" means one, two or more.

[0143] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0144] References to "one embodiment" or "some embodiments" as used in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0145] To facilitate understanding of the communication method provided in this application, the concepts or categories that may be involved in the following embodiments will be introduced first.

[0146] 1. Protocol Data Unit Set

[0147] According to the definition of SA, a Protocol Data Unit (PDU) set can serve as a data unit in the data transmission process. A PDU set consists of one or more data packets, each of which can carry a payload that constitutes an information unit. The application layer at the receiving end can obtain a complete information unit, such as the information corresponding to a video frame or image frame, based on the payloads carried by all PDUs in a PDU set. In the embodiments of this application, the data unit may include frames and video slices. A frame can be understood as a carrier of transmitted data, and a video slice can be understood as a specific type of data unit in a video service. From the perspective of the carrier of transmitted data, in some cases, a PDU set can correspond to a frame; from the perspective of the type of transmitted data, in some cases, in video services, the data carried by a PDU set can correspond to a video slice.

[0148] Generally, the receiving application layer needs to receive all data packets within the protocol data unit set to obtain a complete information unit. Discarding one or more data packets may prevent the receiving end from obtaining the entire information unit. However, in some cases, the receiving application layer can also use certain algorithms to calculate the discarded data based on the data of the acquired PDUs. In this way, even if some PDUs (such as a small number or less important ones) are discarded, the receiving application layer can still recover all or part of the information unit.

[0149] SA introduced the concept of a PDU set, defined as follows:

[0150] PDU Set: A PDU Set is composed of one or more PDUs carrying the payload of one unit of information generated at the application level (e.g., a frame or video slice for XRM Services, as used in TR 26.926

[27] ). In some implementations, all PDUs in a PDU Set are needed by the application layer to use the corresponding unit of information. In other implementations, the application layer can still recover parts all or of the information unit when some PDUs are missing. That is, a PDU set consists of one or more PDUs that carry the payload of one unit of information generated by the application layer, such as a frame or video slice. The above definition indicates that in some implementations, the application layer needs to receive all PDUs in the PDU set to obtain the information unit; in other implementations, the application layer can still recover all or part of the information unit even if some PDUs are lost.

[0151] A protocol data unit (PDU) set can be considered a single data unit, specifically corresponding to a frame or a video slice. A PDU set comprises multiple data packets, each with a unique sequence number (such as a PDU SN). The payloads carried by these data packets can form information units (such as a video frame or an image). Different PDU sets can be assigned different importance levels. High-importance PDU sets can be used to transmit high-importance frames, while low-importance PDU sets can be used to transmit lower-importance frames, thus separating frames of different importance for differentiated processing in subsequent transmissions.

[0152] For the same payload, the data packets divided at different layers can be different, and the number and sequence number of data packets at different layers are also different. For ease of description, in the following embodiments, the sequence number of data packets at the RLC layer (e.g., RLC SDU or RLC PDU) is referred to as RLC SN, and the sequence number of data packets at the PDCP layer (e.g., PDCP SDU or PDCPPDU) is referred to as PDCP SN.

[0153] 2. User plane protocol architecture

[0154] refer to Figure 1A The user plane protocol architecture can include the SDAP layer, PDCP layer, RLC layer, MAC layer, and physical layer.

[0155] refer to Figure 1B ,based on Figure 1A In the user plane protocol architecture, the process of transmitting a set of protocol data units (PDUs) from the sending end to the receiving end can include: the SDAP layer acquires the IP data packets transmitted from its upper layer (application layer or transport layer), performs radio bearer (RB) processing on the IP data packets, and generates a data packet including a header and an entity portion SDAP SDU (i.e., payload), which can be labeled as an SDAP PDU data packet. Then, the SDAP layer transmits the SDAP PDU data packet to the PDCP layer. After acquiring the SDAP PDU data packet, the PDCP layer processes the data packet according to the PDCP protocol, generating a data packet including a header H and an entity portion PDCP SDU (including the SDAP SDU and the SDAP layer header), which can be labeled as a PDCP PDU data packet. Then, the PDCP layer further transmits the PDCP PDU data packet to the RLC layer. After the RLC layer acquires the PDCP PDU data packet, it processes it according to the RLC protocol to generate a data packet including a header (H) and an entity portion (RLC SDU, including the PDCP SDU and the PDCP layer header). This data packet can be labeled as an RLC PDU data packet. Then, the RLC layer further transmits the RLC PDU data packet to the MAC layer. After the MAC layer acquires the RLC PDU data packet, it processes it according to the MAC protocol to generate a data packet including a header (H) and an entity portion (MAC SDU, including the RLC SDU and the RLC layer header). This data packet can be labeled as a MACPDU data packet.

[0156] Following the above process, the MAC layer can obtain multiple MAC PDU data packets corresponding to a data unit. Based on these MAC PDU data packets, the MAC layer can eventually obtain a MAC PDU transport block containing multiple data packets. Afterward, the MAC layer can transmit the generated MAC PDU transport block to the receiving end through air interface resources.

[0157] After receiving a protocol data unit, the receiving end can parse it by reversing the process of generating the protocol data unit. This allows the application layer at the receiving end to obtain the data carried by all PDUs in the protocol data unit set based on the parsed result, and then obtain the information unit based on the payload carried by all PDUs. The specific method and process by which the receiving end parses the data in the protocol data unit set can be configured according to relevant protocols or actual requirements.

[0158] 3. Control Plane Protocol Architecture

[0159] refer to Figure 2 In the control plane protocol framework, the user equipment (UE) side may include the non-access stratum (NAS) layer, radio resource control (RRC) layer, PDCP layer, RLC layer, MAC layer, and PHY layer; the gNB side may include the RRC layer, PDCP layer, RLC layer, MAC layer, and PHY layer; and the access and mobility management function (AMF) side may include the NAS layer.

[0160] The NAS layer can be used for UE mobility and session management procedures, establishing and maintaining IP connections between the UE and the PDN GW.

[0161] The main services and functions of the RRC layer include broadcasting non-access stratum (NAS) system information related to system information, paging, establishing, maintaining, and releasing RRC connections between the access stratum (AS) and the E-UTRAN, security functions including key management, establishing, configuring, maintaining, and releasing radio bearers point-to-point, broadcasting system messages from the NAS and AS layers, paging functions, establishing, maintaining, and releasing RRC connections, establishing, modifying, and releasing end-to-end radio bearers, and mobility management including UE measurement reports, cell handover, UE cell selection and reselection, etc. The RRC layer protocol terminates at the eNode B.

[0162] The PDCP layer can be used to send or receive packet data from peer PDCP entities. For example, the PDCP layer can perform IP header compression and decompression, data and signaling encryption, and signaling integrity protection.

[0163] The RLC layer is used for segmentation and connection, error correction, retransmission processing, and sequential transmission of data to higher layers. The RLC layer includes three modes: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). AM mode can be used for TCP services such as file transfer; UM mode is used for sequential data transmission provided by higher layers; and TM mode can be used for special purposes such as random access.

[0164] The MAC layer is used for mapping between logical channels and transport channels. It schedules and assigns priorities to logical channels according to QoS, and handles HARQ retransmission and uplink / downlink scheduling.

[0165] The PHY layer is used to handle encoding / decoding, modulation / demodulation, multi-antenna mapping, and other telecommunications physical layer functions.

[0166] 4. Send Window:

[0167] refer to Figure 3 The status parameters of the sending window may include, but are not limited to, TX_Next_Ack, TX_Next, and AM_Window_Size.

[0168] TX_Next_Ack: This state variable holds the value of the SN of the nextRLC SDU for which a positive acknowledgment is to be received in-sequence, and it serves as the lower edge of the transmitting window. It is initially set to 0, and is updated whenever the AM RLC entity receives a positive acknowledgment for an RLC SDU with SN=TX_Next_Ack.

[0169] The TX_Next_Ack status variable is the serial number (SN) of the next data packet in the sequence of received acknowledgment packets, and it represents the lower boundary of the sending window. Once the SN of a received data packet is TX_Next_Ack, TX_Next_Ack needs to be updated.

[0170] Alternatively, TX_Next_Ack can be understood as the RLC SN of the RLC SDU awaiting acknowledgment. RLC SDUs with RLC SNs smaller than this value have already been acknowledged by the receiver. Its initial value is 0, representing the lower boundary of the sending window. Furthermore, the upper boundary of the sending window is TX_Next_Ack + AM_Window_Size.

[0171] TX_Next: This newly state variable holds the value of the SN to be assigned for the next generated AMD PDU. It is initially set to 0, and is updated whenever the AM RLC entity constructs an AMD PDU with SN=TX_Next andcontains an RLC SDU or the last segment of aRLC SDU.

[0172] The TX_Next state variable is the serial number (SN) of the next most recently generated AMD PDU. It is updated once an AM RLC entity assembles an AMD PDU with the SN TX_Next, which includes an RLC SDU or a segment of an RLC SDU.

[0173] This can also be understood as the TX_Next state variable being the RLC SN of the RLC SDU to be sent, or the maximum value of the RLC SN of the already sent RLC SDU plus 1, or the RLC SN of the most recently generated RLC SDU. If the SN of the RLC SDU assembled by the AM RLC entity is equal to TX_Next, then TX_Next can be updated. The initial value of TX_Next is 0.

[0174] AM_Window_Size: The size of the AM window. When using a 12-bit SN, its size is 2048; when using an 18-bit SN, its size is 131072.

[0175] It should be understood that the status parameters of the sending window may also include PDU_WITHOUT_POLL, BYTE_WITHOUT_POLL, RETX_COUNT, t_PollRetransmit, etc. For details, please refer to the relevant protocols, which will not be elaborated here.

[0176] 5. Receive Window

[0177] refer to Figure 4 The status parameters of the receiving window may include, but are not limited to: RX_Next, RX_Next_Highest, AM_Window_Size, RX_Highest_Status, and RX_Next_Status_Trigger.

[0178] RX_Next: This state variable holds the value of the SN following the last in-sequence completely received RLC SDU, and it serves as the lower edge of the receiving window. It is initially set to 0, and is updated whenever theAM RLC entity receives an RLC SDU with SN=RX_Next.

[0179] The RX_Next state variable is the next SN after the SN of the most recently received, fully ordered RLC SDU, and represents the lower boundary of the receive window. It is updated once the AM RLC entity receives a packet with the SN RX_Next.

[0180] Alternatively, RX_Next can be understood as the RLC SN of the next RLC SDU to be received. RLC SDUs with RLC SNs smaller than this value have all been fully received, forming the lower boundary of the receive window. If the RLC SN of the RLC SDU received by the AM RLC entity is the same as RX_Next, then RX_Next can be updated. The upper boundary of the receive window is RX_Next + AM_Window_Size.

[0181] RX_Next_Highest: This state variable holds the value of the SN following the SN of the RLC SDU with the highest SN among received RLCSDUs.It is initially set to 0.

[0182] The RX_Next_Highest state variable is the next highest SN number in the received RLC SDU. It is the maximum value of the RLC SNs of the currently fully received RLC SDUs plus 1, and the initial value of RX_Next_Highest is 0.

[0183] AM_Window_Size: The size of the AM window. When using a 12-bit SN, its size is 2048; when using an 18-bit SN, its size is 131072.

[0184] RX_Highest_Status: This state variable holds the highest possible value of the SN which can be indicated by "ACK_SN" when a STATUS PDU needs to be constructed. It is initially set to 0.

[0185] The RX_Highest_Status status variable is the highest possible serial number (SN) when the status PDU needs to be constructed. This SN can be indicated as "ACK_SN (acknowledgment feedback)".

[0186] Alternatively, RX_Highest_Status can be understood as the maximum value among the RLC SNs of the RLC SDUs that have been fully received when the status report is sent, and it is updated when the timer t-Reassembly times out or when the received RLC SN equals its value. Or, RX_Highest_Status can be the sequence number of the next data packet after the most recently fully received data packet at the receiving end.

[0187] RX_Next_Status_Trigger: This state variable holds the value of the SN following the SN of the RLC SDU which triggered t-Reassembly.

[0188] RX_Next_Status_Trigger is the next SN of the RLC SDU that triggers the recombination timer.

[0189] It can also be understood as the value of RX_Next_Highest when the timer t-Reassembly times out.

[0190] t-Reassembly: Reassembles the timer, sending a status report upon timeout. The actual timeout duration can depend on the specific implementation, and it continuously loops.

[0191] t-StatusProhibit: Disables the status report sending timer. It starts after a status report is sent and can only send a status report after the timeout period.

[0192] It should be understood that the status parameters of the receive window may also include t-Reassembly, t-StatusProhibit, etc. For details, please refer to the relevant protocols, which will not be elaborated here.

[0193] 6. PDCP layer state parameters

[0194] refer to Figure 5 The status parameters of the PDCP receiver can include RX_NEXT, RX_DELIV, and RX_REORD, etc.

[0195] RX_NEXT, This state variable indicates the COUNT value of the nextPDCP SDU expected to be received.The initial value is 0.

[0196] RX_NEXT indicates the COUNT value of the next PDCP SDU expected to be received. Alternatively, RX_NEXT can be understood as indicating the COUNT value of the next PDCP SDU that needs to be received.

[0197] RX_DELIV, This state variable indicates the COUNT value of the firstPDCP SDU not delivered to the upper layers, but still waited for.The initialvalue is 0.

[0198] RX_DELIV indicates the COUNT value of the first PDCP SDU that has not yet been submitted to an upper layer (such as the SDAP layer). Its initial value is 0.

[0199] RX_REORD, This state variable indicates the COUNT value following the COUNT value associated with the PDCP Data PDU which triggered t-Reordering. For target SRB configured with state variables continuation, the initial value is the value stored in PDCP entity for the corresponding sourceSRB.

[0200] RX_REORD indicates the COUNT value of the PDCP DATA PDU that triggered the reassembly timer.

[0201] What is needed is that, at the PDCP layer, data packets are identified based on the COUNT value. The existing SA protocol defines the COUNT value as follows: The COUNT value is composed of an HFN and the PDCP SN. The size of the HFN part in bits is equal to 32 minus the length of the PDCP SN. For MRBs, the HFN with a reference SN can be provided by upper layers. If provided, the initial value of the HFN is set according to the HFN and the reference SN. Otherwise, the initial value of the HFN is set by the UE implementation.

[0202] The COUNT value can be understood as including the hyperframe number (HFN) and the PDCP SN. The size of the HFN portion (e.g., in bits) can be equal to 32 minus the length of the PDCP SN. The COUNT value can be used in the PDCP layer to maintain data integrity and for encryption / decryption operations.

[0203] The technical solution of this application will now be described in conjunction with the accompanying drawings.

[0204] The current protocol description of the RLC response to the upper layer (e.g., PDCP) instructing the discard of the RLC SDU may include:

[0205] Description 1: When indicated from upper layer (egPDCP) to discard particular RLC SDU, the transmitting side of an AM RLC entity or the transmitting UM RLC entity shall discard the indicated RLC SDU, if neither the RLC SDU nor a segment thereof has been submitted to the lower layers. The transmitting side of an AM RLC entity shall not introduce an RLC SN gap when discarding an RLC SDU.

[0206] Description 2: RLC-AM is useful to limit data loss, however RLC-AM feedback or retransmission triggering mechanisms are not well adapted for short packetdelay budgets applicable to XR traffic. Also, for RLC AM, considered amounts of data may be in-flight, iein the window, and there is no current way to avoid retransmitting this data, even if the data is old.

[0207] As described above, in the current protocol, after the RLC receives an instruction from the upper layer to discard a data packet (hereinafter referred to as the packet to be discarded), if the segment of the RLC SDU or RLCSDU corresponding to the packet to be discarded has not been transmitted to the lower layer (e.g., the MAC layer and PHY layer), the RLC can discard the SDU or RLC SDU segment. If the packet to be discarded has already been delivered to the lower layer, the RLC will not discard it. This leads to the sender retransmitting the packet to be discarded, wasting transmission resources.

[0208] For example, refer to Figure 6AAssuming the sender first transmits RLC SDUs corresponding to SN0 through SN7, then TX_Next_Ack = SN0, and TX_Next = SN8. If the state report (SR) received by the sender indicates that the receiver has fully received the RLC SDUs corresponding to SN0, SN1, and SN7, and has not fully received (or not fully received) the RLC SDUs corresponding to SN2 through SN6, the sender can initially transmit the RLC SDU corresponding to SN8 and retransmit the RLC SDUs corresponding to SN2 through SN6, updating TX_Next_Ack to SN2 and TX_Next to SN9. If the sender confirms that the RLC SNs of the RLC SDUs corresponding to the data packets to be discarded are SN2 through SN6, since the RLC SDUs corresponding to SN2 through SN6 are within the transmission window and have been delivered to the lower layer, according to the protocol, the sender cannot perform discard processing on the RLC SDUs corresponding to SN2 through SN6. Since the RLCSDU1 corresponding to SN2 through SN6 has not yet been fully transmitted to the receiver, the sender still needs to continue retransmitting the RLC SDUs corresponding to SN2 through SN6. Accordingly, refer to Figure 6B After receiving the SDUs corresponding to SN0 and SN1, the receiving end can update RX_Next from SN0 to SN2. At this time, RX_Next_Highest is SN8. After receiving the RLC SDU corresponding to SN7, the receiving end can send an SR to the sending end indicating that it has completely received the RLC SDUs corresponding to SN0, SN1, and SN7, but has not completely received the RLC SDUs corresponding to SN2-SN6, and wait for the retransmission of the RLC SDU corresponding to SN2. This affects the data transmission efficiency between the sending and receiving ends.

[0209] In view of this, this application provides a communication method in which a device (e.g., a sender or a receiver) can discard a data packet after determining that the data packet is to be discarded, and update the transmission status parameters (e.g., the status parameters of the sender's sending window, the status parameters of the receiver's receiving window, the status parameters of the receiver's PDCP layer, etc.) after the data packet is discarded, so as to improve the communication quality between devices.

[0210] In some embodiments, the data packet to be discarded may be an SDU or a PDU, and there is no limitation on this.

[0211] In some embodiments, the data packets to be discarded may be data packets of the RLC layer, data packets of the PDCP layer, or data packets of other layers, without limitation.

[0212] To make it easier to understand, let's start with:

[0213] Conditions for packet dropping

[0214] In some embodiments, the device (e.g., the sender) discards data packet A (the data packet to be discarded) according to a first condition. The discarding condition may be whether data packet A is within the transmission window range, or more specifically, whether the serial number (SN) corresponding to data packet A is within the transmission window range. The transmission window may be a window corresponding to or reported by the sending window, or a window corresponding to or included in the receiving window.

[0215] For example, taking the RLC protocol layer as an example, data packet A is a data packet that the RLC protocol layer has already delivered to a lower layer (e.g., the MAC protocol layer). Data packet A is a data packet that the PDCP layer sent to the RLC layer that needs to be discarded. Therefore, the sending RLC layer will discard the data packet that has already been delivered to the lower layer to avoid retransmission of the data packet and waste of resources.

[0216] For example, if data packet A is within the transmission window, the device can discard data packet A; if data packet A is outside the transmission window, the device does not need to discard data packet A, i.e., it does not need to perform any action. This is because data packets outside the transmission window do not require maintenance, and therefore do not need to be processed.

[0217] In some embodiments, corresponding to the RLC layer of the sending end, data packet A can be an RLC SDU or an RLC PDU. The discard condition may include the first RLC SN corresponding to data packet A satisfying: TX_Next_Ack ≤ first RLC SN ≤ TX_Next. The sending end may discard data packet A if the first RLC SN satisfies TX_Next_Ack ≤ first RLC SN ≤ TX_Next; otherwise, no action is taken.

[0218] For example, refer to Figure 7A Assuming the lower boundary of the sending window is SN2, the upper boundary of the sending window is SN2049, and TX_Next = SN7. If the first RLC SN is less than SN2 (e.g., SN0) or greater than SN7 (e.g., SN8), it is determined that the discarding condition is not met, and no action is taken. If the first RLC SN is greater than or equal to SN2 and less than or equal to SN7, or greater than SN7 (e.g., SN8), the sender can determine that the discarding condition is met and discards data packet A.

[0219] In other embodiments, the dropping condition corresponding to the RLC layer of the sending end may also include other conditions, such as the first RLC SN corresponding to data packet A satisfying: TX_Next_Ack≤first RLC SN, or first RLC SN≤TX_Next.

[0220] In some embodiments, corresponding to the RLC layer of the receiving end, the dropping condition may include the first RLC SN corresponding to data packet A satisfying: RX_Next ≤ First RLC SN ≤ RX_Next_Highest. The receiving end may drop data packet A if the first RLC SN satisfies RX_Next ≤ First RLC SN ≤ RX_Next_Highest; otherwise, it will not perform any processing.

[0221] For example, refer to Figure 7B Assume that RX_Next is SN2 and RX_Next_Highest is SN7 in the receive window. If the first RLC SN is less than SN2 (e.g., SN0) or greater than SN7 (e.g., SN8), the discard condition is determined not to be met, and no action is taken. If the first RLC SN is greater than or equal to SN2 and less than or equal to SN7 (e.g., SN5), the receiver can determine that the discard condition is met and discards data packet A.

[0222] In some embodiments, corresponding to the RLC layer of the receiving end, the dropping condition may include the first RLC SN corresponding to data packet A satisfying: RX_Next ≤ First RLC SN ≤ RX_Highest_status. The receiving end may drop data packet A if RX_Next ≤ First RLC SN ≤ RX_Highest_status; otherwise, it will not perform any processing.

[0223] In some embodiments, corresponding to the RLC layer of the receiving end, the dropping condition may include the first RLC SN corresponding to data packet A satisfying: RX_Next ≤ First RLC SN ≤ RX_Next_status_trigger. The receiving end may drop data packet A if RX_Next ≤ First RLC SN ≤ RX_Next_status_trigger; otherwise, it will not perform any processing.

[0224] In other embodiments, corresponding to the RLC layer at the receiving end, the dropping condition may also include other conditions, such as the first RLC SN corresponding to data packet A satisfying: RX_Next ≤ first RLC SN, or first RLC SN ≤ RX_Next_Highest, or first RLC SN ≤ RX_Highest_status, or first RLC SN ≤ RX_Next_status_trigger. When the first RLC SN is greater than RX_Highest_status, RX_NEXT_Highest can be updated, for example, RX_NEXT_Highest can be updated to the largest SN number in the dropped data packet.

[0225] In some embodiments, corresponding to the PDCP layer of the receiving end, the discarding condition may include the first COUNT value corresponding to data packet A satisfying: RX_DELIV ≤ first COUNT value ≤ RX_NEXT. The receiving end may discard data packet A if RX_DELIV ≤ first COUNT value ≤ RX_NEXT; otherwise, it will not perform any processing.

[0226] In other embodiments, corresponding to the PDCP layer at the receiving end, the discarding condition may also include other conditions, such as the first COUNT value corresponding to data packet A satisfying: RX_DELIV ≤ first COUNT value, or the first COUNT value ≤ RX_NEXT. When the first COUNT value is greater than RX_NEXT, RX_NEXT can be updated, for example, RX_NEXT can be updated to the largest SN number in the discarded data packet.

[0227] After discarding data packet A (for example, discarding data packet A if it meets the aforementioned discarding conditions, or directly discarding data packet A based on existing protocol logic), the device can also update the transmission status parameters. This is described below:

[0228] Conditions for updating transmission status parameters

[0229] In some embodiments, the device (e.g., the sender or receiver) updates the transmission status parameters according to update conditions. The update conditions may be whether the discarded data packet is within the transmission window range, or more specifically, whether the SN number corresponding to the discarded data packet is within the transmission window range.

[0230] In some embodiments, the transmission status parameters may include the status parameters of the sending window (e.g., TX_Next_Ack), the status parameters of the receiving window (e.g., RX_Next, RX_Highest_Status, RX_Next_Status_Trigger), and the status parameters of the PDCP layer (e.g., RX_DELIV and RX_REORD).

[0231] It should be understood that in other embodiments, the transmission status parameters may also be other parameters that have the same or similar functions as the aforementioned TX_Next_Ack, RX_Next, RX_Highest_Status, RX_Next_Status_Trigger, RX_DELIV and RX_REORD, and these parameters may have different names than the aforementioned parameters.

[0232] For example, taking the RLC protocol layer as an example, the update condition corresponding to the RLC layer of the sending end can include the first RLC SN corresponding to data packet A (the dropped data packet) satisfying: TX_Next_Ack ≤ first RLC SN ≤ TX_Next. The sending end can update the state parameters of the sending window (e.g., TX_Next_Ack, etc.) when the first RLC SN satisfies TX_Next_Ack ≤ first RLC SN ≤ TX_Next; otherwise, no processing is performed. The specific process of the sending end updating the state parameters of the sending window will be described below and will not be elaborated here.

[0233] For example, refer to the above Figure 7A Assuming the lower boundary of the sending window is SN2, the upper boundary of the sending window is SN2049, and TX_Next = SN7. If the first RLC SN is less than SN2 (e.g., SN0) or greater than SN7 (e.g., SN8), it is determined that the discard condition is not met, and no action is taken. If the first RLC SN is greater than or equal to SN2 and less than or equal to SN7, or greater than SN7 (e.g., SN8), the sender can determine that the discard condition is met and updates the status parameters of the sending window.

[0234] In other embodiments, the update conditions corresponding to the RLC layer of the sending end may also include other conditions, such as the first RLC SN corresponding to data packet A satisfying: TX_Next_Ack≤first RLC SN, or first RLC SN≤TX_Next.

[0235] Corresponding to the RLC layer at the receiving end, the update condition may include the second RLC SN corresponding to data packet B (a discarded data packet, such as a data packet that the sender has discarded and / or is to discard; data packet B can be an RLC SDU or RLC PDU) satisfying: RX_Next ≤ Second RLC SN ≤ RX_Next_Highest. The receiving end can update the status parameters (e.g., RX_Next, RX_Highest_Status, RX_Next_Status_Trigger) of the receiving window if the first RLC SN satisfies RX_Next ≤ Second RLC SN ≤ RX_Next_Highest; otherwise, no processing is performed. The specific process of the receiving end updating the status parameters of the receiving window will be described below and will not be elaborated here.

[0236] For example, refer to the above Figure 7BAssume that RX_Next is SN2 and RX_Next_Highest is SN7 in the receiving window. If the second RLC SN is less than SN2 (e.g., SN0) or greater than SN7 (e.g., SN8), the second condition is determined not to be met, and no action is taken. If the second RLC SN is greater than or equal to SN2 and less than or equal to SN7 (e.g., SN5), the receiver can determine that the second condition is met and update the status parameters of the receiving window.

[0237] In some embodiments, corresponding to the RLC layer of the receiver, the update condition may include the second RLC SN corresponding to data packet B satisfying: RX_Next ≤ second RLC SN ≤ RX_Highest_status. The receiver may update the status parameters of the receive window if RX_Next ≤ second RLC SN ≤ RX_Highest_status; otherwise, no action is taken.

[0238] In some embodiments, corresponding to the RLC layer of the receiving end, the update condition may include the second RLC SN corresponding to data packet B satisfying: RX_Next ≤ second RLC SN ≤ RX_Next_status_trigger. The receiving end may update the status parameters of the receiving window if RX_Next ≤ second RLC SN ≤ RX_Next_status_trigger; otherwise, no action is taken.

[0239] In other embodiments, corresponding to the RLC layer of the receiving end, the update condition may also include other conditions, such as the first RLC SN corresponding to data packet A satisfying: RX_Next≤first RLC SN, or first RLC SN≤RX_Next_Highest, or first RLC SN≤RX_Highest_status, or first RLC SN≤RX_Next_status_trigger.

[0240] In some embodiments, corresponding to the PDCP layer at the receiving end, the update condition may include the first COUNT value corresponding to data packet C (a discarded data packet, such as a data packet that has been discarded and / or is to be discarded by the sender, which may be a PDCP SDU or PDCP PDU) satisfying: RX_DELIV ≤ first COUNT value ≤ RX_NEXT. The receiving end may update the state parameters of the PDCP layer if RX_DELIV ≤ first COUNT value ≤ RX_NEXT; otherwise, no action is taken.

[0241] For example, corresponding to the PDCP layer at the receiving end, the update condition may include: the first COUNT value corresponding to data packet C satisfies: RX_DELIV ≤ first COUNT value ≤ RX_NEXT. The receiving end may update the state parameters of the PDCP layer if RX_DELIV ≤ first COUNT value ≤ RX_NEXT; otherwise, no processing is performed.

[0242] In other embodiments, corresponding to the PDCP layer of the receiving end, the update condition may also include other conditions, such as the first COUNT value corresponding to data packet A satisfying: RX_DELIV≤first COUNT value, or first COUNT value≤RX_NEXT.

[0243] In some embodiments, the receiver can update the PDCP layer state parameters (e.g., RX_NEXT, RX_DELIV, and RX_REORD) if RX_DELIV is equal to the first COUNT value corresponding to data packet C. The specific process of the receiver updating the PDCP layer state parameters will be described below and will not be repeated here.

[0244] The device can update the transmission status parameters when it determines that the data packet meets the update conditions or when it determines that the data packet has been discarded.

[0245] The following is an introduction:

[0246] Status parameter update process at the sending end

[0247] In some embodiments, the sending end updates its transmission status parameters based on the dropped data packets (data packets that the sending end has dropped and / or are to be dropped), and further updates the sending end's status parameters based on the SN number of the dropped data packets.

[0248] For example, corresponding to the sending end, the transmission status parameters include the TX_Next_Ack parameter of the sending window.

[0249] In some embodiments, the dropped data packets may include data packet A, or multiple consecutive data packets (sequence numbers (e.g., RLC SN, PDCP SN, etc.) with data packet A as the first data packet). Accordingly, the relationship between the dropped data packets and the sending window can correspond to the following scenarios:

[0250] Case 1: The discarded data packets may include a plurality of consecutive data packets starting with data packet A as the first data packet, and the RLC SN corresponding to data packet A is the same as the RLC SN corresponding to TX_Next_Ack which is the lower boundary of the transmission window. In this case, the RLC SNs corresponding to the plurality of consecutive data packets starting with data packet A may be {TX_Next_Ack, ..., SN_high}, where TX_Next_Ack<SN_high≤TX_Next. For example, refer to Figure 8A , assuming TX_Next_Ack=SN2, TX_Next=SN12, the first RLC SN corresponding to data packet A is SN2, and the plurality of consecutive data packets starting with data packet A may be the data packets corresponding to SN2, SN3, and SN4.

[0251] Case 2: The discarded data packets may include data packet A, and the RLC SN of data packet A is the same as the RLC SN corresponding to TX_Next_Ack which is the lower boundary of the transmission window. For example, refer to Figure 8B , assuming TX_Next_Ack=SN2, TX_Next=SN12, the RLC SN of data packet A is SN2.

[0252] Case 3: The discarded data packets may include a plurality of consecutive data packets starting with data packet A as the first data packet, and the RLC SN corresponding to data packet A is different from the RLC SN corresponding to TX_Next_Ack which is the lower boundary of the transmission window. In this case, the RLC SNs corresponding to the plurality of consecutive data packets starting with data packet A may be {the first RLC SN, ..., SN_high}, where TX_Next_Ack+2<SN_high≤TX_Next, and TX_Next_Ack+1<the first RLC SN≤TX_Next-1. For example, refer to Figure 8C , assuming TX_Next_Ack=SN2, TX_Next=SN12, and the first RLC SN is SN6, the plurality of consecutive data packets starting with data packet A may be the data packets corresponding to SN6, SN7, and SN8.

[0253] Case 4: The discarded data packets may include data packet A, and the RLC SN of data packet A is different from the RLC SN corresponding to TX_Next_Ack which is the lower boundary of the transmission window. In this case, the RLC SN of data packet A may be any RLC SN that is greater than TX_Next_Ack and less than or equal to TX_Next. For example, refer to Figure 8D , assuming TX_Next_Ack=SN2, TX_Next=SN12, the first RLC SN may be SN10.

[0254] In some embodiments, situations 1 to 4 described above may coexist. For example, Figures 8A to 8D Of the four scenarios shown, multiple scenarios can coexist.

[0255] Corresponding to scenarios 1 and 2, the sending end can directly update the lower boundary of the sending window to the RLC SN of the first unacknowledged received data packet after the data packet corresponding to the upper boundary of the RLC SN of the dropped data packet (the RLC SN with the largest value among the RLC SNs corresponding to the dropped data packet), or the next RLC SN after the upper boundary of the RLC SN of the dropped data packet.

[0256] For example, the sender can update the lower boundary of the sending window if the first RLC SN corresponding to packet A is equal to the lower boundary (TX_Next_Ack) of the sending window (or, packet A can be a packet with the SN number corresponding to TX_Next_Ack. The sender can update the lower boundary of the sending window if one or more packets in the dropped packets have RLC SNs equal to the lower boundary (TX_Next_Ack) of the sending window, or if one or more packets in the dropped packets have RLC SNs including the lower boundary (TX_Next_Ack) of the sending window). For example, the sender can update the lower boundary of the sending window to: the fourth RLC SN after the third RLC SN of the last packet in a series of dropped packets starting with packet A; or the fourth RLC SN after the third RLC SN of the last packet in a series of dropped packets starting with the SN number corresponding to TX_Next_Ack; or the fourth RLC SN after the third RLC SN of the last packet in a series of dropped packets including packet A. The third RLC SN can be the largest RLC SN among the consecutive dropped packets starting with packet A, or the largest RLC SN among the consecutive dropped packets starting with packet TX_Next_Ack, or the largest RLC SN among the consecutive dropped packets including packet TX_Next_Ack. For example, if the dropped packets only include packet A, then the third RLC SN is the same as the first RLC SN; if the dropped packets include multiple consecutive packets starting with packet A, then the SNs corresponding to these multiple consecutive packets starting with packet A are {first RLC SN, ..., third RLC SN}, where the packet corresponding to the fourth RLC SN was not dropped, meaning the packet corresponding to the fourth RLC SN is not among the dropped packets.

[0257] In some embodiments, the fourth RLC SN can be the next RLC SN after the third RLC SN. In this case, if the sender has already received an acknowledgment (ACK) for the data packet corresponding to the fourth RLC SN, the sender can update the lower boundary of the sending window to the next RLC SN after the fourth RLC SN based on the existing protocol.

[0258] It should be understood that an acknowledgment feedback is a message sent by the receiver to the sender via a status report, indicating that the data packet (e.g., RLCSDU or RLC PDU) has been successfully received by the receiver. Conversely, if the status report indicates that a data packet's reception status is NACK, it means the data packet was not successfully received by the receiver. The existing protocol, after receiving a status report, updates TX_Next_Ack to the smallest RLC SN corresponding to the data packet for which no acknowledgment feedback was received, as recorded in the status report (the receiver's feedback to the sender on received data packets, acknowledging reception or reception failure).

[0259] In some embodiments, the fourth RLC SN can be the smallest RLC SN among the RLC SNs corresponding to data packets following the third RLC SN that have not received an ACK. Based on this approach, if the sender has already received ACKs for one or more consecutive data packets following the third RLC SN, it can directly update the lower boundary of the sending window to the fourth RLC SN, eliminating the need for the sender to update it again according to existing protocols. This embodiment differs from existing technologies in that it requires combining the information from the joint state report of the RLC SNs corresponding to dropped data packets to update the transmission state parameters.

[0260] In some embodiments, the data packet corresponding to the fourth RLC SN is not dropped, or in other words, the data packet corresponding to the fourth RLC SN is not among the dropped data packets. That is, if the data packet corresponding to the smallest RLC SN among the RLC SNs of the data packets following the data packet corresponding to the third RLC SN and for which no ACK has been received is a data packet among the dropped data packets, then the fourth RLC SN can be the RLC SN of the first data packet that is not among the dropped data packets and for which no ACK has been received, following the consecutive data packets including the smallest RLC SN in the dropped data packets (where the data packet corresponding to the smallest RLC SN can be the first data packet of the consecutive data packets or a data packet in the middle of the consecutive data packets). For example, suppose the RLC SNs of the dropped data packets are SN1, SN2, and SN3, and SN6, SN7, and SN8. The sender has received data packets with RLC SNs of SN4 and SN5, but has not received data packets with RLC SNs of SN6, SN7, SN8, and SN9 (or may have received them). After the consecutively dropped data packets SN1-SN3, the smallest data packet SN that has not received an ACK is SN6. However, SN6 is within the consecutively dropped data packets SN6-SN8. Therefore, the sender can update the lower boundary of the sending window to SN9. In one scenario, the sender can first update the lower boundary of the sending window to SN4, and then, after determining that the data packets with RLC SNs of SN4 and SN5 have been completely received by the receiver and that the data packets corresponding to SN6, SN7, and SN8 are dropped data packets, update the lower boundary of the sending window to SN9. In another scenario, after updating TX_Next_Ack to SN1, the sender can determine that the RLC SNs of the dropped packets are SN1, SN2, and SN3, as well as SN6, SN7, and SN8, and that packets with RLC SNs of SN4 and SN5 have been fully received by the receiver. In this case, the sender can directly update the lower boundary of the sending window to SN9.

[0261] In some embodiments, the third RLC SN is greater than or equal to TX_Next_Ack and less than or equal to TX_Next.

[0262] In some embodiments, if the third RLC SN is greater than or equal to TX_Next_Ack, TX_Next_Ack has already been updated to the next RLC SN of the second RLC SN.

[0263] In some embodiments, the third RLC SN is greater than or equal to (the second RLC SN+1) and less than or equal to TX_Next.

[0264] For example, corresponding Figure 8AIn the scenario shown, TX_Next_Ack = SN2, TX_Next = SN12, and the RLC SN corresponding to the dropped data packet is SN2 (serving as the first and third RLC SNs). If the sender does not fully receive the ACK for the data packet corresponding to SN3, the sender can update TX_Next_Ack to SN3 (serving as the fourth RLC SN). If the sender has fully received the ACK for the data packet corresponding to SN3, but has not fully received the ACK for the data packet corresponding to SN4, the sender can directly update TX_Next_Ack to SN4, or first update TX_Next_Ack to SN3 and then update it to SN4 (serving as the fourth RLC SN) based on the existing protocol.

[0265] For example, corresponding Figure 8B In the scenario shown, TX_Next_Ack = SN2, TX_Next = SN12, and the RLC SNs corresponding to the dropped data packets are SN2-SN4, with the third RLC SN being SN4. If the sender does not fully receive the ACK for the data packet corresponding to SN5, the sender can update TX_Next_Ack to SN5 (as the fourth RLC SN). If the sender has fully received the ACK for the data packet corresponding to SN5 but has not fully received the ACK for the data packet corresponding to SN6, the sender can directly update TX_Next_Ack to SN6 (as the fourth RLC SN), or first update TX_Next_Ack to SN5 and then update it to SN6 based on the existing protocol.

[0266] Corresponding to scenario 3 or 4, the sender can wait until TX_Next_Ack is updated to match the first RLC SN corresponding to data packet A before updating the lower boundary of the sending window. For example, the sender can update the lower boundary of the sending window to the fourth RLC SN after the third RLC SN of the last data packet in a series of consecutively dropped data packets starting with data packet A.

[0267] In some embodiments, waiting for TX_Next_Ack to be updated to the same as the first RLC SN corresponding to data packet A includes: after receiving a status report, updating TX_Next_Ack to the RLC SN corresponding to the smallest data packet in the status report that did not receive an acknowledgment. When the updated TX_Next_Ack is the same as the first RLC SN, the sender can update the status parameters of the sending window. For details, refer to the methods for updating the status parameters of the sending window in Scenarios 1 and 2 described above, which will not be elaborated here.

[0268] In some embodiments, the fourth RLC SN can be the next RLC SN after the third RLC SN, or the smallest RLC SN among the RLC SNs corresponding to the data packet U that has not received an ACK after the data packet corresponding to the third RLC SN.

[0269] For example, corresponding Figure 8C In the scenario shown, TX_Next_Ack = SN2, TX_Next = SN12, and the RLC SNs corresponding to the dropped packets are SN6-SN8 (the first RLC SN is SN6 and the third RLC SN is SN8). The sender can update TX_Next_Ack to SN9 (as the fourth RLC SN) if TX_Next_Ack is updated to SN6 and the sender has not fully received the ACK for the packet corresponding to SN9. Alternatively, the sender can update TX_Next_Ack to SN10 (as the fourth RLC SN) if TX_Next_Ack is updated to SN6, the sender has fully received the ACK for the packet corresponding to SN9, but has not fully received the ACK for the packet corresponding to SN10. In some embodiments, if the sender updates TX_Next_Ack to an RLC SN after SN9 (e.g., SN10) based on a status report, it is not necessary to update the status parameters of the sending window according to the dropped packets.

[0270] For example, corresponding Figure 8D In the scenario shown, TX_Next_Ack = SN2, TX_Next = SN12, and the RLC SN corresponding to the dropped data packet is SN10 (as the first RLC SN and the third RLC CN). If the sender updates TX_Next_Ack to SN10 but has not fully received the ACK for the data packet corresponding to SN11, the sender can update TX_Next_Ack to SN11. Similarly, if the sender updates TX_Next_Ack to SN10, has fully received the ACK for the data packet corresponding to SN11, but has not fully received the ACK for the data packet corresponding to SN12, the sender can update TX_Next_Ack to SN12. In some embodiments, if the sender updates TX_Next_Ack to an RLC SN after SN10 (e.g., SN11) based on a status report, it is not necessary to update the status parameters of the sending window according to the dropped data packets.

[0271] As mentioned above Figures 8A to 8D As shown, the data packets corresponding to the updated TX_Next_Ack were not dropped.

[0272] If the aforementioned Figures 8A to 8DThe scenario shown involves multiple scenarios, and the sending end can update its status parameters based on these scenarios.

[0273] For example, suppose Figure 8B and Figure 8C The situation shown exists simultaneously. If the data packet corresponding to SN5 has not been fully received by the receiving end (for example, the sending end has not received the acknowledgment feedback of the data packet corresponding to SN5), the sending end can first update the lower boundary of the sending window to SN5, and then update the lower boundary of the sending window to SN9 after TX_Next_Ack is updated to SN6.

[0274] For example, suppose Figure 8B and Figure 8C The scenarios shown both exist simultaneously. If the data packet corresponding to SN5 has been completely received by the receiver (e.g., the sender has received an acknowledgment of the data packet corresponding to SN5), the sender can first update the lower boundary of the sending window to SN6. After TX_Next_Ack is updated to SN6, the lower boundary of the sending window is updated to SN9 based on the continuously dropped data packets (data packets corresponding to SN6-SN8). Alternatively, if the sender determines that the data packet corresponding to SN5 has been completely received by the receiver and the data packet corresponding to SN6 is a dropped data packet, it can directly update the lower boundary of the sending window to SN9.

[0275] In some embodiments, the sender can update the status parameters of the sending window by maintaining a sender-end discard window. The sender-end discard window may include a first discard status parameter (e.g., TX_Discard_Low) and a second discard status parameter (e.g., TX_Discard_High). The first discard status parameter indicates the lower boundary of consecutively discarded data packets U (e.g., the RLC SN with the smallest value among the consecutively discarded data packets), and the second discard status parameter indicates the upper boundary of consecutively discarded data packets (e.g., the RLC SN with the largest value among the consecutively discarded data packets). Then, the sender can update the status parameters of the sending window based on the relationship between the lower boundary of the sending window and the first and second discard status parameters.

[0276] Maintenance process of the sender's discard window

[0277] In some embodiments, the sender's discard window is used to indicate the packet with the smallest RLC SN value among the discarded packets, or a list of consecutive discarded packets containing the packet with the smallest RLC SN value. For example, assuming the RLC SNs of the discarded packets are SN2, SN5, SN8, and SN9, then TX_Discard_High = TX_discard_low = SN2. As another example, assuming the RLC SNs of the discarded packets are SN2, SN3, SN4, SN8, and SN9, then TX_Discard_High = SN4, and TX_discard_low = SN2.

[0278] In some embodiments, if the sender has determined that there are TX_Discard_High and TX_discard_low, and the RLC SN (one or more consecutive RLC SNs) corresponding to the data packets requested to be discarded by the PDCP layer are all less than the current TX_discard_low, the sender can update TX_Discard_High to the upper boundary of the RLC SN corresponding to the data packets requested to be discarded by the PDCP layer, and update TX_discard_low to the lower boundary of the RLC SN corresponding to the data packets requested to be discarded.

[0279] In some embodiments, if the sender has determined that TX_Discard_High, TX_discard_low, and the RLC SN (one or more consecutive RLC SNs) corresponding to the data packet requested to be discarded by the PDCP layer are all greater than the current TX_discard_high, the sender may not update TX_Discard_High and TX_discard_low.

[0280] In some embodiments, if the sender has determined that there are TX_Discard_High and TX_discard_low, and the RLC SN corresponding to the data packet requested to be discarded by the PDCP layer overlaps with [TX_discard_low, TX_Discard_High] and can be superimposed into a continuous RLC SN interval, the sender can update TX_Discard_High to the upper boundary of the continuous RLC SN interval (the maximum value of the continuous RLC SN interval) and update TX_discard_low to the lower boundary of the continuous RLC SN interval (the minimum value of the continuous RLC SN interval).

[0281] For example, Figures 9A to 9E According to some embodiments of this application, a schematic diagram of the sender updating the sender discard window is shown.

[0282] Assuming the sender has already determined TX_Discard_High and TX_discard_low (hereinafter, the sender's discard window corresponding to the determined TX_Discard_High and TX_discard_low will be referred to as the current sender's discard window), the upper boundary of the RLC SN of the data packets requested to be discarded by the PDCP layer is SN_high, and the lower boundary is SN_low ≤ SN_high. The sender can update the status parameters of the sender's discard window based on the relationship between SN_high, SN_low and the current sender's discard window.

[0283] refer to Figure 9A If SN_high is less than TX_discard_low, it means that all RLC SNs corresponding to the requested packet are less than TX_discard_low, and the requested packet does not overlap with the current discard window. The sender can update TX_discard_low to SN_low and TX_discard_high to SN_high.

[0284] refer to Figure 9B If SN_low is greater than TX_discard_high, it means that all RLC SNs corresponding to the requested data packet are greater than TX_discard_high, and the sender does not need to update the sender's discard window.

[0285] refer to Figure 9C If SN_high is greater than or equal to TX_discard_high and SN_low is less than or equal to TX_discard_low, it means that the data packets requested to be discarded include the current sender's discard window. The sender can update TX_discard_low to SN_low and TX_discard_high to SN_high.

[0286] refer to Figure 9D If SN_high is greater than or equal to TX_discard_low and less than or equal to TX_discard_high, and SN_low is less than TX_discard_low, it means that the packet to be dropped and the current sender's drop window constitute a new consecutive packet, and the sender can update TX_discard_low to SN_low.

[0287] refer to Figure 9EIf SN_low is greater than TX_discard_low and less than or equal to TX_discard_high, and SN_high is greater than TX_discard_high, it means that the packet to be dropped and the current sender's drop window constitute a new consecutive packet, and the sender can update TX_discard_high to SN_high.

[0288] In some embodiments, if the updated TX_discard_high is greater than Tx_Next, the sender can update TX_discard_high to Tx_Next. Alternatively, when it is necessary to update TX_discard_high to SN_high, if SN_high is greater than Tx_Next, the sender can update TX_discard_high to Tx_Next.

[0289] The process by which the sending end updates the state parameters of the sending window based on the state parameters of the sending end's discard window.

[0290] When the sender determines that the lower boundary of the sending window (Tx_Next_Ack) is the same as the lower boundary of the sender's discard window (TX_discard_low), it can update the lower boundary of the sending window to the RLC SN after the upper boundary of the sender's discard window (TX_discard_high), or the RLC SN of the first data packet that receives an ACK after the upper boundary of the sender's discard window (TX_discard_high).

[0291] In some embodiments, after updating the lower boundary (TX_Next_Ack) of the sending window, if there are still discarded packets within the sending window, the sender can update or maintain TX_discard_low and TX_discard_high based on the discarded packets present in the sending window. Specific update methods can be found in the aforementioned section on maintaining the sender's discard window, and will not be elaborated upon here.

[0292] In some embodiments, if the updated lower boundary of the sending window is greater than Tx_Next, the sender can update the lower boundary of the sending window to Tx_Next.

[0293] In some embodiments, after the state parameters of the sending window have been updated based on the current sending window (e.g., the lower boundary of the sending window has been updated to the RLCSN after the upper boundary (TX_discard_high) of the sending window, or the RLC SN of the first packet that did not receive an ACK after the upper boundary (TX_discard_high) of the sending window), if there are still dropped packets, the sending end can, based on... Figures 9A to 9E The illustrated embodiment updates or establishes a sender drop window, and updates the status parameters of the send window based on the updated or established sender drop window.

[0294] In some embodiments, the sender may update the status parameters of the sending window not based on the RLC SN corresponding to the dropped data packet, but based on an existing protocol (e.g., the TS28.322 protocol). Specifically, in this embodiment, after or during the dropping of a data packet to be dropped, the sender may send drop information indicating the dropped data packet (data packets dropped and / or to be dropped) to the receiver. After receiving the drop information, the receiver may send a status report to the sender, which includes the reception status (e.g., ACK) of the data packets corresponding to the data packets dropped or to be dropped by the sender. After receiving the status report, the sender may update the lower boundary Tx_Next_Ack of the sending window to the smallest RLC SN among the data packets that have not yet received an ACK. Thus, there is no need to modify the process of the sender updating the sending window.

[0295] The following is an introduction:

[0296] The process of updating the status parameters at the receiving end

[0297] In some embodiments, the receiver can update its status parameters based on the data packets that the sender has dropped and / or is about to drop, and further update the sender's status parameters based on the SN number of the data packets that the sender has dropped or is about to drop, or further update the sender's status parameters based on the COUNT value of the data packets that have dropped and / or are about to drop.

[0298] In some embodiments, the receiver can update the state parameters of the RLC layer, such as RX_Next, RX_Highest_Status, and RX_Next_Status_Trigger. The receiver can also update the state parameters of the PDCP layer, such as RX_DELIV and RX_REORD.

[0299] The process of updating the state parameters of the RLC layer at the receiving end

[0300] For example, using the RLC layer, when the second RLC SN corresponding to data packet B is equal to the lower boundary (RX_Next) of the receive window (or, data packet B can be a data packet with the SN number corresponding to RX_Next; or, if one or more discarded data packets have RLC SNs equal to the lower boundary (RX_Next) of the receive window, or if one or more discarded data packets have RLC SNs that include the lower boundary (RX_Next) of the receive window), the receiver can update the lower boundary of the receive window. Data packet B is a data packet that the sender has discarded or is about to discard (i.e., the aforementioned discarded data packet) as determined by the receiver, and can be indicated to the receiver by the sender.

[0301] For example, the receiving end can update the lower boundary of the receiving window to: the sixth RLC SN (in some embodiments, the data packet corresponding to the sixth RLC SN is not dropped) after the fifth RLC SN of the last dropped data packet in a series of dropped data packets starting with data packet B (in some embodiments, the data packet corresponding to the sixth RLC SN is not dropped), or the RLC SN (in some embodiments, the data packet corresponding to the SN of the last dropped data packet including the SN of the RX_Next data packet (in some embodiments, the data packet corresponding to this RLC SN is not dropped). The fifth RLC SN can be the largest RLC SN among the RLC SNs corresponding to the dropped data packets starting with data packet B, or the fifth RLC SN can be the largest RLC SN among the RLC SNs corresponding to the dropped data packets including data packet B. For example, if the dropped data packets only include data packet B, then the fifth RLC SN is the same as the second RLC SN; if the dropped data packets include multiple consecutive data packets starting with data packet B, then the SNs corresponding to the multiple consecutive data packets starting with data packet B are {second RLC SN, ..., fifth RLC SN}.

[0302] In some embodiments, the data packet corresponding to the sixth RLC SN is not dropped, or in other words, the data packet corresponding to the sixth RLC SN is not among the dropped data packets. That is, if the data packet corresponding to the smallest RLC SN among the RLC SNs of the data packets following the data packet corresponding to the fifth RLC SN and not yet fully received is a data packet among the dropped data packets, then the sixth RLC SN can be the RLC SN of the first data packet that is not among the dropped data packets and is not yet fully received, following the consecutive data packets including the smallest RLC SN (where the data packet corresponding to the smallest RLC SN can be the first data packet of the consecutive data packets or a data packet in the middle of the consecutive data packets).

[0303] For example, suppose the RLC SNs of the dropped data packets are SN1, SN2, and SN3, and SN6, SN7, and SN8, and the receiver has received data packets with RLC SNs of SN4 and SN5, but has not completely received data packets with RLC SNs of SN6, SN7, SN8, and SN9 (or may have received them completely). In this case, the receiver can update the lower boundary of the receive window to SN9. In one scenario, the receiver can first update the lower boundary of the receive window to SN4, and then, after determining that the data packets with RLC SNs of SN4 and SN5 have been completely received and that the data packets corresponding to SN6, SN7, and SN8 are dropped data packets, update the lower boundary of the receive window to SN9. In another scenario, the receiver can update the lower boundary of the receive window to SN1, and then, after determining that the RLC SNs of the dropped data packets are SN1, SN2, and SN3, and SN6, SN7, and SN8, and that the data packets with RLC SNs of SN4 and SN5 have been completely received, directly update the lower boundary of the receive window to SN9.

[0304] In some embodiments, the sixth RLC SN can be the next RLC SN after the fifth RLC SN.

[0305] In one scenario, if the receiver has already received the data packet corresponding to the sixth RLC SN in its entirety, or if the receiver has sent an acknowledgment (ACK) to the sender for the data packet corresponding to the sixth RLC SN, the receiver can update the lower boundary of the receive window to the next RLC SN after the sixth RLC SN or the RLC SN after the sixth RLC SN based on the existing protocol.

[0306] In one scenario, if the receiver has completely received the data packet corresponding to the sixth RLC SN and all data packets following the sixth RLC SN, the receiver can update the lower boundary of the receive window to the SN number of the first data packet after the sixth RLC SN that has not been completely received, based on existing protocols. Existing protocols include updating RX_Next to the RLC SN number corresponding to the first data packet after RX_Next that has not been completely received when a data packet is completely received (i.e., all bytes of the data packet have been received) and the RLC SN number of that data packet is equal to RX_Next. In this embodiment, RX_Next is first updated to the next RLC SN after the fifth RLC SN, and optionally, then updated according to existing protocols.

[0307] In some embodiments, the sixth RLC SN can be the RLC SN corresponding to the first incompletely received data packet after the fifth RLC SN, and the data packet corresponding to the sixth RLC SN has not been dropped. Based on this approach, if the receiver determines that data packets corresponding to one or more consecutive RLC SNs after the fifth RLC SN have been received completely, or if the receiver has already sent an ACK to the sender for data packets corresponding to one or more consecutive RLC SNs after the fifth RLC SN, the receiver can directly update the lower boundary of the receive window to the sixth RLC SN, so that the receiver does not need to update it again according to the existing protocol.

[0308] In some embodiments, the sixth RLC SN is greater than or equal to RX_Next and less than or equal to RX_Next_Highest.

[0309] In some embodiments, the sixth RLC SN is greater than or equal to the fifth RLC SN and less than or equal to RX_Next_Highest.

[0310] In some embodiments, reference Figure 10A If the updated RX_Next is greater than RX_Highest_Status, the receiver can also update RX_Highest_Status to the updated RX_Next. For example, if the receiver updates RX_Next to the sixth RLC SN, and the sixth RLC SN is greater than RX_Highest_Status, the receiver can also update RX_Highest_Status to the sixth RLC SN.

[0311] In some embodiments, reference Figure 10B If the updated RX_Next is greater than or equal to RX_Next_Status_trigger, stop the reassembly timer. Figure 4 As shown, where RX_Next is less than RX_Next_Highest, the receiver can also update RX_Next_Status_trigger to the RLC SN corresponding to RX_Next_Highest and start (e.g., if the rebuild timer is not running or has stopped) or restart (e.g., if the rebuild timer is running). For example, if the receiver updates RX_Next to the sixth RLC SN, and the sixth RLC SN is greater than RX_Next_Status_Trigger, the receiver can also update RX_Next_Status_Trigger to the RLC SN corresponding to RX_Next_Highest and start or restart the rebuild timer.

[0312] In some embodiments, if the fifth RLC SN is greater than or equal to RX_Highest_Status (or if one or more packets in the dropped packets have an RLC SN greater than or equal to RX_Highest_Status), the receiver can update RX_Highest_Status to the sixth RLC SN corresponding to the packet following the fifth RLC SN. As in the aforementioned embodiments, the sixth RLC SN can be the next RLC SN after the fifth RLC SN, or the sixth RLC SN can be the RLC SN corresponding to the first packet that was not fully received after the fifth RLC SN. For example, if the first N packets in the dropped packets are consecutive packets, and the RLC SN corresponding to the last packet in the first N packets is greater than or equal to RX_Highest_Status, the receiver can update RX_Highest_Status to the RLC SN corresponding to the packet following the last packet in the first N packets (e.g., the RLC SN corresponding to the next packet after the last packet in the first N packets, or the RLC SN with the smallest value among the RLC SNs corresponding to the packets that were not fully received after the last packet in the first N packets).

[0313] In some embodiments, if the fifth RLC SN is greater than or equal to RX_Next_Status_Trigger (or if one or more dropped packets have an RLC SN greater than or equal to RX_Next_Status_Trigger), and / or the second RLC SN is less than or equal to RX_Highest_Status (or if one or more dropped packets have an RLC SN greater than or equal to RX_Next_Status_Trigger), the receiver can update RX_Next_Status_Trigger to the RLC SN corresponding to RX_Next_Highest, and start or restart the reassembly timer. For example, if the first N dropped packets are consecutive packets, and the RLC SN corresponding to the last packet in those first N packets is greater than or equal to RX_Next_Status_Trigger, the receiver can update RX_Next_Status_Trigger to the RLC SN corresponding to RX_Next_Highest, and start or restart the reassembly timer.

[0314] In some embodiments, if the RLC SN corresponding to any of the discarded packets is different from RX_Next, the receiver does not update RX_Next.

[0315] In some embodiments, when the receiver receives a complete data packet and the RLC SN of the data packet is RX_Next, the receiver can update RX_Next to the smallest SN number among the RLC SNs corresponding to the data packets that were not fully received.

[0316] In some embodiments, if RX_Next is updated to the smallest RLC SN among the RLC SNs corresponding to the dropped data packet, the receiver may update RX_Next to the RLC SN of the data following the next data packet in the dropped data packet, where the smallest RLC SN is located.

[0317] In some embodiments, the receiver can update the status parameters of the receiver window by maintaining a receiver discard window. These status parameters may include a third discard status parameter (e.g., RX_Discard_Low) and a fourth discard status parameter (e.g., RX_Discard_High). The third discard status parameter indicates the lower boundary of the consecutive data packets to be discarded (e.g., the smallest RLC SN among the RLC SNs corresponding to the consecutive discarded data packets). The fourth discard status parameter indicates the upper boundary of the consecutive discarded data packets (e.g., the largest RLC SN among the RLC SNs corresponding to the consecutive discarded data packets; further, the third discard status parameter may correspond to the RLC SN of the last data packet in the consecutive discarded data packets of the first data packet). The receiver can then update the PCDP layer status parameters based on the relationship between the receiver window status parameters and the third and fourth discard status parameters, and the relationship between RX_DELIV.

[0318] Maintenance process of the receiver's discard window

[0319] In some embodiments, the receiver's discard window is used to indicate the SN of the packet with the smallest RLC SN value corresponding to the discarded packet, or the SNs of multiple consecutively discarded packets containing the packet with the smallest RLC SN value. Multiple consecutively discarded packets refer to packets whose RLC SN numbers are consecutive. For example, assuming the RLC SNs of the discarded packets are SN2, SN5, SN8, and SN9, then RX_Discard_High = RX_discard_low = SN2. As another example, assuming the RLC SNs of the discarded packets are SN2, SN3, SN4, SN8, and SN9, then RX_Discard_High = SN4, and RX_discard_low = SN2.

[0320] In some embodiments, if the receiver has determined that RX_Discard_High and RX_discard_low exist, and the receiver determines that the RLC SN (one or more consecutive RLC SNs) corresponding to the data packet to be discarded by the sender is less than the current RX_discard_low, the receiver can update RX_Discard_High to the upper boundary of the RLC SN corresponding to the data packet to be discarded, and update RX_discard_low to the lower boundary of the RLC SN corresponding to the data packet to be discarded.

[0321] In some embodiments, if the receiver has already determined that RX_Discard_High and RX_discard_low exist, and the receiver determines that the RLC SN (one RLC SN or multiple consecutive RLC SNs) corresponding to the data packets discarded by the sender are all greater than the current RX_discard_high, the receiver may not update RX_Discard_High and RX_discard_low.

[0322] In some embodiments, if the receiver has determined that RX_Discard_High and RX_discard_low exist, and the receiver determines that the RLC SN corresponding to the data packet discarded by the sender overlaps with [RX_discard_low, RX_Discard_High] and can be superimposed into a continuous RLC SN interval, the receiver can update RX_Discard_High to the upper boundary of the continuous RLC SN interval (the maximum value of the continuous RLC SN interval) and update RX_discard_low to the lower boundary of the continuous RLC SN interval (the minimum value of the continuous RLC SN interval).

[0323] For example, Figures 11A to 11EAccording to some embodiments of this application, a schematic diagram of the receiver updating the receiver discard window is shown.

[0324] Assume the receiver has already determined RX_Discard_High and RX_discard_low (hereinafter, the receiver's discard window corresponding to the determined RX_Discard_High and RX_discard_low will be referred to as the current receiver discard window). The receiver determines the upper boundary of the RLC SN of the data packets discarded by the sender as SN_high and the lower boundary as SN_low ≤ SN_high. The sender can update the state parameters of the receiver discard window based on the relationship between SN_high, SN_low and the current receiver discard window.

[0325] refer to Figure 11A If SN_high is less than RX_discard_low, it means that all RLC SNs corresponding to the requested packet are less than RX_discard_low, and the requested packet does not overlap with the current discard window. The receiver can update RX_discard_low to SN_low and RX_discard_high to SN_high.

[0326] refer to Figure 11B If SN_low is greater than RX_discard_high, it means that all RLC SNs corresponding to the requested data packet are greater than RX_discard_high, and the receiver does not need to update the receiver's discard window.

[0327] refer to Figure 11C If SN_high is greater than or equal to RX_discard_high and SN_low is less than or equal to RX_discard_low, it means that the data packets requested to be discarded include the current discard window of the receiver. The receiver can update RX_discard_low to SN_low and RX_discard_high to SN_high.

[0328] refer to Figure 11D If SN_high is greater than or equal to RX_discard_low and less than or equal to RX_discard_high, and SN_low is less than RX_discard_low, it means that the packet to be discarded and the current discard window of the receiver constitute a new continuous packet, and the receiver can update RX_discard_low to SN_low.

[0329] refer to Figure 11EIf SN_low is greater than RX_discard_low and less than or equal to RX_discard_high, and SN_high is greater than RX_discard_high, it means that the packet to be discarded and the current discard window of the receiver constitute a new continuous packet, and the receiver can update RX_discard_high to SN_high.

[0330] In some embodiments, reference Figure 11F The receiver's discard window includes RX_Highest_Status, and optionally excludes RX_Next_Status_Trigger (equivalent to RX_discard_low≤RX_Highest_Status≤RX_discard_high). The receiver can update RX_Highest_Status to the RLC SN corresponding to the first packet whose RLC SN is greater than RX_discard_high that was not fully received. For example, if the packet corresponding to RX_discard_high+1 was not fully received, the receiver can update RX_Highest_Status to RX_discard_high+1. If the packet corresponding to RX_discard_high+1 has been fully received, but the packet corresponding to RX_discard_high+2 was not fully received, the receiver can update RX_Highest_Status to RX_discard_high+2, and so on.

[0331] It should be understood that in other embodiments, the receiver may also update RX_Highest_Status when updating the status parameters of the receive window based on the continuously dropped data packets indicated by the receiver's discard window. This application does not limit the timing of updating RX_Highest_Status.

[0332] In some embodiments, reference Figure 11GIf the updated receiver discard window includes RX_Highest_Status and RX_Next_Status_Trigger (equivalent to RX_discard_low≤RX_Highest_Status≤RX_Next_Status_Trigger≤RX_discard_high), the receiver can update RX_Highest_Status to the RLC SN corresponding to the first incompletely received data packet that is greater than RX_discard_high, and update RX_Next_Status_Trigger to RX_Next_highest, and start or restart the timer. For example, if the data packet corresponding to RX_discard_high+1 is not completely received, the receiver can update RX_Highest_Status to RX_discard_high+1 and update RX_Next_Status_Trigger to RX_Next_highest. If the data packet corresponding to RX_discard_high+1 has been completely received, but the data packet corresponding to RX_discard_high+2 has not been completely received, the receiving end can update RX_Highest_Status to RX_discard_high+2 and RX_Next_Status_Trigger to RX_Next_highest, and so on.

[0333] It should be understood that in other embodiments, the receiving end may also update RX_Highest_Status and RX_Next_Status_trigger when updating the status parameters of the receiving window based on the receiving end's discard window. This application does not limit the timing of updating RX_Highest_Status and RX_Next_Status_trigger.

[0334] The following is an introduction:

[0335] The process by which the receiving end updates the state parameters of the receiving window based on the state parameters of the receiving end's discard window.

[0336] When the receiver determines that the lower boundary of the receive window (RX_Next) is the same as the lower boundary of the receiver's discard window (RX_discard_low), it can update the lower boundary of the receive window to the next RLC SN after the upper boundary of the receiver's discard window (RX_discard_high), or the RLC SN of the first incompletely received data packet after the data packet corresponding to the upper boundary of the receiver's discard window (RX_discard_high).

[0337] In some embodiments, corresponding to the RLC layer, the data packet can be an RLC PDU and / or an RLC SDU.

[0338] In some embodiments, after updating the lower boundary (RX_Next) of the receive window, if there are still discarded data packets within the receive window, the receiver can update or maintain RX_discard_low and RX_discard_high based on these discarded data packets. Specific update methods can be found in the aforementioned section on maintaining the receiver's discard window, and will not be elaborated upon here.

[0339] In some embodiments, if RX_discard_low≤RX_Highest_Status≤RX_discard_high, the receiver can update RX_Highest_Status to the RLC SN of the first data packet that was not fully received and whose RLC SN is greater than RX_discard_high.

[0340] In some embodiments, if RX_discard_low≤RX_Next_Status_Trigger≤RX_discard_high), the receiver can update RX_Next_Status_Trigger to RX_Next_highest and start or restart the timer.

[0341] In some embodiments, after the lower boundary of the receive window has been updated to the RLC SN following the upper boundary (RX_discard_high) of the receive window, or after the RLC SN of the first incompletely received packet following the upper boundary (RX_discard_high) of the receive window, if there are still dropped packets, the receiver can, based on... Figures 11A to 11G The illustrated embodiment updates or establishes the receiver's discard window, and updates the state parameters of the sending window based on the updated or established receiver's discard window. As can be seen from the above embodiment, the lower boundary of the receiver window will not be updated to the SN number corresponding to the discarded data packet.

[0342] In some embodiments, after updating the status parameters of the receive window, the receiving end can also send a status report to the sending end, indicating that all data packets corresponding to the dropped data packets have been received. For example, the status report may include ACKs for all data packets corresponding to the dropped data packets.

[0343] In some embodiments, the reception status of the data packet corresponding to the dropped data packet in the status report is ACK, where ACK indicates that the data packet has been fully received. Thus, the sender can update the status parameters of the sending window based on an existing protocol (e.g., the TS28.322 protocol), for example, updating the lower boundary Tx_Next_Ack of the sending window to the smallest RLC SN among the RLC SNs corresponding to data packets that have not yet received an ACK.

[0344] The process of the receiving end sending a status report to the sending end

[0345] In some embodiments, the receiving end can trigger the sending of a status report to the sending end based on the relationship between the RLC SN corresponding to the dropped data packet and RX_Highest_Status and RX_Next_Status_Trigger.

[0346] In some embodiments, the RCL SN corresponding to the dropped data packet, taking the relationship between the drop window and RX_Highest_Status and RX_Next_Status_Trigger as an example, can correspond to the following cases 5 to 7.

[0347] Case 5: RX_discard_low≤RX_Highest_Status≤RX_discard_high <RX_Next_Status_Trigger

[0348] refer to Figure 12A This could be a situation where the receiver updates RX_Highest_Status during the maintenance of the discard window (e.g.) Figure 11F (as shown in the example), or in cases where RX_Highest_Status has been updated during the process of updating the status parameters of the receive window based on the receiver's discard window.

[0349] Case 6: RX_discard_low≤RX_Highest_Status≤RX_Next_Status_Trigger≤RX_discard_high

[0350] refer to Figure 12B This situation could occur when the receiver updates RX_Highest_Status and RX_Next_Status_Trigger during the process of maintaining the receiver's discard window (e.g., Figure 11G(as shown in the example), or in cases where RX_Highest_Status and RX_Next_Status_Trigger have been updated based on the receiver's process of updating the status parameters of the receiver window by discarding the window.

[0351] Case 7: RX_discard_low ≤ RX_discard_high <RX_Highest_Status

[0352] refer to Figure 12C This situation can occur when all RLC SNs corresponding to the receiver's discard window are less than RX_Highest_Status, and the receiver does not update RX_Highest_Status and RX_Next_Status_Trigger during the process of maintaining the receiver's discard window and updating the status parameters of the receiver window based on the receiver's discard window.

[0353] In some embodiments, corresponding to scenarios 5 and 6, the receiver can trigger the sending of a status report to the sender by updating RX_Highest_Status (or RX_Highest_Status and RX_Next_Status_Trigger) based on the status parameters of maintaining the receiver's discard window and updating the receiver window based on the receiver's discard window.

[0354] In some embodiments, corresponding to scenario 7, the receiving end can determine whether it has already sent ACKs for all data packets indicated by the receiving end's discard window to the sending end. If the receiving end has already sent ACKs for all data packets indicated by the receiving end's discard window to the sending end, it indicates that the sending end will no longer transmit or retransmit the data packets indicated by the receiving end's discard window, and there is no need to trigger a status report. If at least one data packet indicated by the receiving end's discard window has not yet sent ACKs to the sending end (e.g., no receive status corresponding to the at least one data packet has been sent, or a NACK receive status has been sent for the at least one data packet), it indicates that the sending end will continue to transmit or retransmit the at least one data packet, and a status report needs to be triggered to be sent to the sending end. Thus, if the receiving end has already sent ACKs for all data packets indicated by the receiving end's discard window to the sending end, there is no need to trigger a status report based on the current receiving end's discard window, which can reduce the frequency and content of the status reports sent by the receiving end.

[0355] In some embodiments, corresponding to any one of Scenarios 5-7, the receiving end can directly send a status report to the sending end based on the existing transmission opportunity, without waiting for the t-StatusProhibit timeout. In this way, the receiving end can promptly send an ACK to the sending end instructing it to discard the data packets corresponding to the window, allowing the sending end to promptly stop transmitting or retransmit the data packets corresponding to the discarded window, thus improving the communication efficiency between the sending and receiving ends.

[0356] In some embodiments, regardless of whether the receiving end receives the data packet corresponding to the receiving end's discard window, the receiving status of the data packet corresponding to the receiving end's discard window in the status report sent by the receiving end to the sending end is ACK. That is, even if the data packet corresponding to the receiving end's discard window is not received, the receiving status of the corresponding data packet will be set to ACK, and the receiving status of the data packet will not be set to NACK.

[0357] The process of the receiver updating the state parameters of the PDCP layer

[0358] In some embodiments, the receiver can update the status parameters of the receiver's PDCP layer based on the dropped data packets (data packets dropped and / or to be dropped by the sender), and further update the status parameters of the receiver's PDCP layer based on the SN number of the dropped data packets.

[0359] For example, for the PDCP layer of the receiving end, the state parameters may include RX_DELIV, RX_REORD, etc.

[0360] In some embodiments, corresponding to the PDCP layer, the data packet can be a PDCP PDU and / or a PDCP SDU.

[0361] In some embodiments, the dropped data packets may include data packet C, or multiple consecutively dropped data packets (COUNT consecutive data packets) with data packet C as the first data packet, wherein data packet C is the data packet with the smallest COUNT value among the dropped data packets.

[0362] If the COUNT value corresponding to data packet C is equal to RX_DELIV (optionally, data packet C can be a data packet with the COUNT value corresponding to RX_DELIV; this can occur if one or more dropped data packets have a COUNT value equal to RX_DELIV, or if one or more dropped data packets have a COUNT value including RX_DELIV), the receiving end can update RX_DELIV to the third COUNT value following the second COUNT value of the last dropped data packet in a series of consecutively dropped data packets starting with data packet C. For example, if the dropped data packets only include data packet C, then the second COUNT value is the same as the first COUNT value; if the dropped data packets include multiple consecutive data packets starting with data packet C, the COUNT values ​​are {first COUNT value, ..., second COUNT value}.

[0363] In some embodiments, the third COUNT value can be the next COUNT value after the second COUNT value.

[0364] In some embodiments, the third COUNT value can be the COUNT value corresponding to the first PDCP layer packet that was not delivered to the higher layer, following the second COUNT value. For example, if the COUNT values ​​of consecutive packets corresponding to the dropped packets are C2, C3, and C4 (C2, C3, and C4 are consecutive COUNT values) and the packet corresponding to COUNT value C5 was not delivered to the higher layer, the receiver can update RX_DELIV to C5. As another example, if the COUNT values ​​of consecutive packets corresponding to the dropped packets are C2, C3, and C4, and the packets corresponding to COUNT values ​​C5 and C6 have been delivered to the higher layer, while the packet corresponding to COUNT value C7 has not been delivered to the higher layer, the receiver can update RX_DELIV to C7.

[0365] In some embodiments, the data packet corresponding to the third COUNT value is not dropped, meaning that the data packet corresponding to the third COUNT value is not among the dropped data packets. In other words, if the data packet following the data packet corresponding to the second COUNT value does not have a COUNT value corresponding to any data packet not delivered to a higher layer, and the data packet corresponding to the smallest COUNT value is among the dropped data packets, then the third COUNT value can be the first (e.g., the smallest COUNT value) data packet not among the dropped data packets and not delivered to a higher layer, following the consecutive data packets containing the smallest COUNT value (where the data packet corresponding to the smallest COUNT value can be the first data packet in the consecutive data packets or a data packet in the middle of the consecutive data packets).

[0366] For example, assuming the dropped packets have COUNT values ​​of C1, C2, and C3, as well as C6, C7, and C8, and packets with COUNT values ​​of C4 and C5 have been delivered to the higher layer, while packets with COUNT values ​​of C6, C7, C8, and C9 have not been delivered to the higher layer (or may have already been delivered), the receiving end can update RX_DELIV to C9. In one scenario, the receiving end can first update RX_DELIV to C4, and then, if it is determined that packets with COUNT values ​​of C4 and C5 have been delivered to the higher layer and the packets corresponding to C6, C7, and C8 are dropped packets, update RX_DELIV to C9. In another scenario, the receiving end can update RX_DELIV to C1, and if it is determined that the dropped packets have COUNT values ​​of C1, C2, and C3, as well as C6, C7, and C8, and the packets with COUNT values ​​of C4 and C5 have been delivered to the higher layer, directly update RX_DELIV to C9.

[0367] In some embodiments, if the COUNT value corresponding to the last packet of consecutively dropped packets is greater than or equal to RX_REORD (for example, if one or more packets in the dropped packets have a COUNT value greater than or equal to RX_REORD), the receiver can update RX_REORD to RX_NEXT and start the reordering timer.

[0368] In some embodiments, if the COUNT value of a continuously dropped data packet is greater than or equal to RX_REORD, the receiver can update RX_REORD to RX_NEXT and start a reordering timer.

[0369] In some embodiments, reference Figure 13A If the updated RX_DELIV is less than or equal to RX_REORD, the receiving end may not update RX_REORD. It should be understood that in some embodiments, the updated RX_DELIV is less than RX_NEXT.

[0370] In some embodiments, reference Figure 13B If the updated RX_DELIV is greater than RX_REORD, the reordering timer stops. If the updated RX_DELIV is less than RX_NEXT, the receiver can also update RX_REORD to RX_NEXT, making RX_DELIV less than the updated RX_REORD (i.e., RX_NEXT), and then start the reordering timer. For example, if the updated RX_DELIV is greater than RX_REORD, the receiver can start the reordering timer even if it is not running or has stopped.

[0371] In some embodiments, the receiver can maintain a PDCP discard window at the PDCP layer to update the PDCP layer's status parameters. The discard status parameters of the PDCP discard window may include a fifth discard status parameter (e.g., PDCPRX_Discard_Low) and a sixth discard status parameter (e.g., PDCPRX_Discard_High). The fifth discard status parameter indicates the lower boundary of the COUNT values ​​corresponding to consecutively discarded packets (e.g., the smallest COUNT value among the consecutively discarded packets), and the sixth discard status parameter indicates the upper boundary of the COUNT values ​​corresponding to consecutively discarded packets (e.g., the largest COUNT value among the consecutively discarded packets). The receiver can then update the status parameters of the receive window based on the relationship between the fifth and sixth discard status parameters and the relationship with RX_DELIV.

[0372] PDCP Discard Window Maintenance

[0373] In some embodiments, the PDCP drop window is used to indicate the packet with the smallest COUNT value among the dropped packets, or a group of consecutively dropped packets containing the packet with the smallest COUNT value. For example, assuming the dropped packets have COUNT values ​​of C2, C5, C8, and C9, then PDCPRX_Discard_High = PDCPRX_discard_low = C2. As another example, assuming the dropped packets have COUNT values ​​of C2, C3, C4, C8, and C9 (C2, C3, and C4 are consecutive COUNT values), then PDCPRX_Discard_High = C4, and PDCPRX_discard_low = C2.

[0374] In some embodiments, if the receiver has determined that there are PDCPRX_Discard_High and PDCPRX_discard_low, and the COUNT value (one COUNT value or multiple consecutive COUNT values) corresponding to the data packet requested to be discarded by the sender is less than the current PDCPRX_discard_low, the receiver can update PDCPRX_Discard_High to the upper boundary of the COUNT value corresponding to the data packet requested to be discarded, and update PDCPRX_discard_low to the lower boundary of the COUNT value corresponding to the data packet requested to be discarded.

[0375] In some embodiments, if the receiver has already determined that PDCPRX_Discard_High and PDCPRX_discard_low exist, and the COUNT value (one COUNT value or multiple consecutive COUNT values) corresponding to the data packet requested to be discarded by the sender is greater than the current PDCPRX_discard_low, the receiver may not update PDCPRX_Discard_High and PDCPRX_discard_low.

[0376] In some embodiments, if the receiver has determined that there are PDCPRX_Discard_High and PDCPRX_discard_low, and the COUNT value corresponding to the data packet requested to be discarded by the sender overlaps with [PDCPRX_discard_low, PDCPRX_Discard_High] and can be superimposed into a continuous range of COUNT values, the receiver can update PDCPRX_Discard_High to the upper boundary of the continuous range of COUNT values ​​(the maximum value of the continuous range of COUNT values) and update PDCPRX_discard_low to the lower boundary of the continuous range of COUNT values ​​(the minimum value of the continuous range of COUNT values).

[0377] For example, Figures 14A to 14E According to some embodiments of this application, a schematic diagram of the receiver updating the PDCP discard window is shown.

[0378] Assuming the receiver has already determined PDCPRX_Discard_High and PDCPRX_discard_low (hereinafter, the PDCP discard window corresponding to the determined PDCPRX_Discard_High and PDCPRX_discard_low is referred to as the current PDCP discard window), the upper boundary of the COUNT value corresponding to the data packet requested to be discarded by the PDCP layer is C_high, and the lower boundary is C_low, where C_low ≤ C_high. The receiver can update the state parameters of the PDCP discard window based on the relationship between C_high, C_low and the current PDCP discard window.

[0379] refer to Figure 14A If C_high is less than PDCPRX_discard_low, it means that all COUNT values ​​corresponding to the requested packet are less than PDCPRX_discard_low, and the requested packet does not overlap with the current discard window. The receiving end can update PDCPRX_discard_low to C_low and PDCPRX_discard_high to C_high.

[0380] refer to Figure 14B If C_low is greater than PDCPRX_discard_high, it means that all COUNT values ​​corresponding to the requested data packets are greater than PDCPRX_discard_high, and the receiver does not need to update the PDCP discard window.

[0381] refer to Figure 14C If C_high is greater than or equal to PDCPRX_discard_high and C_low is less than or equal to PDCPRX_discard_low, it means that the data packets requested to be discarded include the current PDCP discard window. The receiving end can update PDCPRX_discard_low to C_low and PDCPRX_discard_high to C_high.

[0382] refer to Figure 14D If C_high is greater than or equal to PDCPRX_discard_low and less than or equal to PDCPRX_discard_high, and C_low is less than PDCPRX_discard_low, it means that the packet requested to be discarded constitutes a new consecutive packet with the current PDCP discard window, and the receiver can update PDCPRX_discard_low to C_low.

[0383] refer to Figure 14E If C_low is greater than PDCPRX_discard_low and less than or equal to PDCPRX_discard_high, and C_high is greater than PDCPRX_discard_high, it means that the packet requested to be discarded constitutes a new consecutive packet with the current PDCP discard window, and the receiver can update PDCPRX_discard_high to C_high.

[0384] In some embodiments, if the updated PDCPRX_discard_high is greater than RX_REORD, the receiver can update RX_REORD to RX_NEXT.

[0385] The following is an introduction:

[0386] The process by which the receiver updates the state parameters of the PDCP layer according to the PDCP drop window

[0387] When the receiver determines that the lower boundary of the PDCP discard window (PDCPRX_discard_low) is the same as RX_DELIV of the PDCP layer, it can update RX_DELIV to the COUNT value following PDCPRX_discard_high. For example, it can update RX_DELIV to the COUNT value following PDCPRX_discard_high, or the COUNT value corresponding to the first PDCP layer packet that has not been delivered to the higher layer, following the COUNT value of PDCPRX_discard_high.

[0388] In some embodiments, after updating RX_DELIV, if there are still dropped data packets with corresponding COUNT values ​​between RX_DELIV and RX_NEXT, the receiving end can update or maintain PDCPRX_discard_low and PDCPRX_discard_high based on the existence of dropped data packets. Specific update methods can be found in the aforementioned section on maintaining the PDCP discard window, and will not be elaborated upon here.

[0389] In some embodiments, if the updated RX_DELIV is less than or equal to RX_REORD, the receiver may not update RX_REORD.

[0390] For example, refer to Figure 13A If PDCPRX_discard_high is less than RX_REORD, and the updated RX_DELIV is less than or equal to RX_REORD, the receiver may not update RX_REORD.

[0391] In some embodiments, if the updated RX_DELIV is greater than RX_REORD, the receiver can also update RX_REORD to RX_NEXT and start the reordering timer.

[0392] For example, refer to Figure 13B If PDCPRX_discard_high is greater than or equal to RX_REORD, then the updated RX_DELIV is greater than RX_REORD. The receiver can also update RX_REORD to RX_NEXT and start the reordering timer.

[0393] For example, if PDCPRX_discard_high is less than RX_REORD, but the updated RX_DELIV is greater than RX_REORD, the receiver can also update RX_REORD to RX_NEXT and start the reordering timer.

[0394] In some embodiments, if there are still dropped packets after RX_DELIV has been updated to COUNT after PDCPRX_discard_high, the receiver can, based on... Figures 14A to 14E The illustrated embodiment updates or establishes a PDCP drop window and updates the PDCP layer state parameters based on the updated or established PDCP drop window. As can be seen from the above embodiment, the lower boundary of the receive window will not be updated to the COUNT value corresponding to the dropped data packet.

[0395] Configuration process of communication method

[0396] In some embodiments, the sending end and the receiving end may transmit information on enabling or disabling the functions corresponding to the communication method provided in this application based on the aforementioned control plane protocol framework. For example, information may be used to indicate whether to enable or disable the function of discarding data packets that have been delivered to the lower layer, or to update the transmission status parameters (e.g., the status parameters of the sending window, the status parameters of the receiving window, the status parameters of the PDCP layer, etc.) based on the discarded data packets.

[0397] For example, a user equipment (UE) may obtain first indication information, which indicates whether to perform a transmission state parameter update based on a dropped data packet. If the first indication information indicates that a transmission state parameter update should be performed based on a dropped data packet, the UE performs the dropping of data packets that have already been delivered to lower layers. For example, the UE's RLC layer may drop the data packets and update the transmission state parameters based on the methods provided in the foregoing embodiments.

[0398] In some embodiments, reference Figure 15A Network-side equipment (e.g., base station (BS)) can configure first indication information to the user equipment. This first indication information can be configured in conjunction with RLC entity configuration, for example, it can be included in the RLC entity configuration parameters. The first indication information can be configured via MAC CE, PDCP layer signaling, RLC layer signaling, or RRC signaling. Further, the first indication information can indicate which RLC entity can perform a transmission state parameter update based on the dropped data packet. For example, the first indication information includes an RLC entity identifier and an indication of whether to perform a transmission state parameter update based on the dropped data packet.

[0399] In some embodiments, the first indication information may be an implicit indication, the content of which is obtained through other configuration information (e.g., a drop indication based on PDU set, or an indication to execute the drop of submitted packets, or a drop indication based on the importance of PDU set).

[0400] In some embodiments, the network-side device may also configure the duration for which the first indication information is applied (e.g., a timer), or the duration for which packets that have been delivered to lower layers are discarded.

[0401] In some embodiments, reference Figure 15B In user equipment or network-side equipment, the PDCP layer can indicate first indication information to the RLC layer. The PDCP layer indicates the first indication information when it notifies the packet to be dropped. The conditions for the PDCP layer to indicate the first indication information to the RLC layer may include: the PDCP layer configuring a drop indication based on a PDU set, and / or executing the dropping of a PDU set; and / or, the PDCP layer configuring (e.g., activating) a drop indication based on the importance of a PDU set. The drop indication based on a PDU set is used to indicate that the dropping of a PDU set has been executed (e.g., if packets in a PDU set are dropped, all packets in the PDU set are dropped); the drop indication based on the importance of a PDU set is used to indicate the use of different drop timers according to the importance of different PDU sets. For example, when the PDU set corresponding to the packet is a PDU set of first importance, the first drop timer is started; when the PDU set corresponding to the packet is a PDU set of second importance, the second drop timer is started.

[0402] In some embodiments, reference Figure 15B In user equipment or network-side equipment, the MAC layer can indicate the first indication information to the RLC layer. The conditions for the MAC layer to indicate the first indication information to the RLC layer may include: the RLC entity is configured (e.g., activated) with a drop indication based on the importance of PDU set.

[0403] The technical solution of this application will now be described in conjunction with the accompanying drawings.

[0404] As mentioned above, in some embodiments, after determining that a data packet to be discarded should be dropped, the sending end can update the status parameters of the sending window and send drop information indicating the data packet to be dropped to the receiving end. Accordingly, after receiving the drop information, the receiving end can update the status parameters of the receiving window based on the data packet to be dropped indicated by the drop information.

[0405] For example, Figure 16 According to some embodiments of this application, a schematic diagram of the interaction flow of a communication method is shown.

[0406] like Figure 16 As shown, the interaction process includes the following steps:

[0407] S1601, the sender discards the data packet to be discarded.

[0408] For example, when the sending end determines that the data packet to be discarded meets the aforementioned discarding conditions, it may discard the data packet to be discarded.

[0409] In some embodiments, corresponding to the RLC layer of the sending end, the dropping condition may include the first RLC SN corresponding to data packet A (as the data packet to be dropped) satisfying: TX_Next_Ack ≤ first RLC SN ≤ TX_Next. The sending end may drop data packet A if the first RLC SN satisfies TX_Next_Ack ≤ first RLC SN ≤ TX_Next; otherwise, no processing is performed.

[0410] It should be understood that in other embodiments, the discard conditions may include other conditions, which are not limited here.

[0411] In some embodiments, the sender may discard the data packet to be discarded upon receiving the aforementioned first indication information, and the first indication information indicating that the data packet to be discarded should be discarded.

[0412] S1602, the sending end updates the status parameters of the sending window.

[0413] For example, after discarding a data packet to be discarded, the sender can update the status parameters of the sending window based on the discarded data packet. The specific method by which the sender updates the sending window can refer to the aforementioned processes of updating the sender's status parameters, maintaining the sender's discard window, and updating the sender's status parameters based on the status parameters of the sender's discard window, which will not be elaborated here.

[0414] In some embodiments, the sender can update the state parameters of the sending window based on the dropped data packets if the dropped data packets meet the aforementioned update conditions.

[0415] In some embodiments, corresponding to the RLC layer of the sender, the update condition may include the first RLC SN corresponding to packet A (as a discarded packet) satisfying: TX_Next_Ack ≤ first RLC SN ≤ TX_Next. The sender may update the state parameters (e.g., TX_Next_Ack, etc.) of the sending window if the first RLC SN satisfies TX_Next_Ack ≤ first RLC SN ≤ TX_Next; otherwise, no action is taken.

[0416] In some embodiments, the sending end may update the state parameters of the sending window upon receiving the aforementioned first indication information, which indicates that the state parameters of the sending window should be updated based on the dropped data packets.

[0417] S1603, the sending end sends a discard message to the receiving end.

[0418] The sender can send a discard message to the receiver indicating that a data packet has been discarded (e.g., a data packet that the sender has discarded and / or is to be discarded).

[0419] In some embodiments, the discard information can be used to indicate data packets that the sender has discarded and / or is about to discard. For example, the discard information may include the identifier of the RLC SDU or RLC PDU or PDCP SDU or PDCP PDU corresponding to the data packets that the sender has discarded and / or is about to discard, such as RLC SN, PDCP SN, PDCP layer COUNT value, etc.

[0420] It should be understood that in other embodiments, the discard information may also be other forms of information that enable the receiving end to determine the discarded data packet, and this is not limited here.

[0421] S1604, the receiving end updates the transmission status parameters based on the discard information.

[0422] After receiving the discard information, the receiving end can update the transmission status parameters, such as the status parameters of the receive window and the status parameters of the PDCP layer, based on the discarded data packet indicated by the discard information.

[0423] In some embodiments, the receiver may update the state parameters of the receiving window and the state parameters of the PDCP layer if the discarded data packets meet the aforementioned update conditions.

[0424] In some embodiments, corresponding to the RLC layer of the receiving end, the update condition may include the second RLC SN corresponding to data packet B (a discarded data packet, such as a data packet that has been discarded and / or is to be discarded by the sending end, and data packet B may be an RLC SDU or an RLC PDU) satisfying: RX_Next≤Second RLC SN≤RX_Next_Highest.

[0425] In some embodiments, corresponding to the RLC layer of the receiving end, the update condition may include the second RLC SN corresponding to data packet B satisfying: RX_Next≤Second RLC SN≤RX_Highest_status.

[0426] In some embodiments, corresponding to the RLC layer of the receiving end, the update condition may include the second RLC SN corresponding to data packet B satisfying: RX_Next≤Second RLC SN≤RX_Next_status_trigger.

[0427] In some embodiments, corresponding to updating the state parameters of the PDCP layer, the update condition may include the first COUNT value of the PDCP SDU corresponding to packet A (as a packet to be discarded) satisfying: RX_DELIV≤first COUNT value≤RX_NEXT.

[0428] In some embodiments, the specific process of the receiver updating the state parameters of the receiving window can refer to the aforementioned process of the receiver updating the state parameters, the process of the receiver updating the state parameters of the RLC layer, the process of the receiver maintaining the discarded window, and the process of the receiver updating the state parameters of the receiving window based on the state parameters of the discarded window. It will not be repeated here.

[0429] In some embodiments, the specific process of the receiver updating the state parameters of the PDCP layer can refer to the aforementioned process of the receiver updating the state parameters, the process of the receiver updating the state parameters of the PDCP layer, the maintenance of the PDCP discard window, and the process of the receiver updating the state parameters of the PDCP layer according to the PDCP discard window, and will not be repeated here.

[0430] In some embodiments, the receiving end may update the state parameters of the receiving window upon receiving the aforementioned first indication information, which indicates that the state parameters of the receiving window should be updated based on the dropped data packets.

[0431] In some embodiments, the receiving end may update the state parameters of the PDCP layer upon receiving the aforementioned first indication information, which indicates that the state parameters of the PDCP layer should be updated based on the dropped data packets.

[0432] In some embodiments, the specific form of the first indication information and the method by which the receiving end receives the first indication information can be referred to the configuration section of the aforementioned communication method, and will not be repeated here.

[0433] It should be understood that the execution order of steps S1601 to S1604 described above is only an example. In other embodiments, the execution order of some steps can be adjusted, or some steps can be merged or split, which is not limited here. For example, in some embodiments, steps S1602 and S1603 can be performed synchronously, or their execution order can be adjusted. As another example, step S1604 can be executed before step S1603, or it can be executed in parallel with step S1604, which is not limited here. Furthermore, steps S1601 and S1603 can be executed together, and steps S1602 and S1604 can be executed in parallel.

[0434] In some embodiments, the aforementioned steps S1601 to S1604 can be implemented by the RLC layers of the transmitting and receiving ends.

[0435] Based on the above method, the sending and receiving ends can adjust the status parameters of the sending and receiving windows in a timely manner when the discarded data packets have been delivered to the lower layer, avoiding the retransmission of discarded data packets and the freezing of the receiving window, which is conducive to improving the communication quality between the sending and receiving ends.

[0436] In some embodiments, after determining which data packets to be discarded, the sending end may send discard information indicating the discarded data packets to the receiving end. Upon receiving the discard information, the receiving end may update the status parameters of its receiving window based on the discarded data packets indicated in the discard information and send an ACK indicating that all discarded data packets have been completely received to the sending end. Correspondingly, upon receiving the ACK indicating that all discarded data packets have been completely received, the sending end may update the status parameters of its sending window based on the existing protocol framework.

[0437] For example, Figure 17 According to some embodiments of this application, a schematic diagram of the interaction flow of a communication method is shown.

[0438] like Figure 17 As shown, the interaction process includes the following steps:

[0439] S1701, the sender discards the data packet to be discarded.

[0440] For details, please refer to the aforementioned step S1601, which will not be repeated here.

[0441] S1702, the sending end sends a discard message to the receiving end.

[0442] After discarding a data packet to be discarded, the sender can send a discard message to the receiver indicating the data packets to be discarded (e.g., data packets that the sender has discarded and / or is to discard).

[0443] In some embodiments, the discard information can be used to indicate the data packets that have been discarded. For example, the discard information may include the identifier of the RLC SDU, RLC PDU, PDCP SDU, or PDCP PDU corresponding to the data packets that the sender has discarded and / or is about to discard, such as the RLC SN, PDCP SN, PDCP layer COUNT value, etc.

[0444] It should be understood that in other embodiments, the discarded information may also be other forms of information, which are not limited here.

[0445] S1703, the receiving end updates the transmission status parameters based on the discard information.

[0446] After receiving the discard information, the receiving end can update the transmission status parameters (such as the status parameters of the receiving window, the status parameters of the PDCP layer, etc.) based on the discard information (such as the discarded data packet indicated by the discard information). For details, please refer to the content of the aforementioned step S1604, which will not be repeated here.

[0447] S1704, the receiving end sends a status report to the sending end.

[0448] The receiving end can also send a status report to the sending end, indicating that all data packets corresponding to the dropped data packets have been received. When updating the transmission status parameters based on the dropped information, the receiving end can trigger a status report. The process and method of the receiving end triggering a status report can be found in the section on the process of the receiving end sending a status report to the sending end, and will not be repeated here.

[0449] In some embodiments, if ACKs for all packets corresponding to a dropped packet have been sent to the sender, the receiver may not need to send a status report. In some embodiments, if ACKs for some packets corresponding to a dropped packet have been sent to the sender, the status report may not include the ACKs for those packets.

[0450] In some embodiments, if a portion of the packets corresponding to a dropped packet has been sent to the sender with a NACK, the status report can indicate that the reception status of that portion of the packets is ACK.

[0451] S1705, the sending end updates the status parameters of the sending window based on the status report.

[0452] After receiving the status report, the sending end can update the status parameters of the sending window based on the relevant protocol (such as the TS28.322 protocol). For details, please refer to the description of the relevant protocol; it will not be elaborated upon here.

[0453] In some embodiments, the order of steps S1704 and S1705 can be interchanged or executed in parallel, and no limitation is made here.

[0454] This application also provides a communication method applied at a sending end, see reference. Figure 18 The method includes the following steps:

[0455] S1801, Discard the data packet to be discarded.

[0456] For example, after receiving a drop request from an upper layer (e.g., the RLC layer of the sender), the sender can drop the data packet to be dropped. For details, please refer to the aforementioned step S1601, which will not be repeated here.

[0457] S1802, Update the status parameters of the sending window.

[0458] For example, after discarding a data packet to be discarded, the sending end (e.g., the sending end's RLC layer) can update the state parameters of the sending window based on the discarded data packet. For details, please refer to the aforementioned step S1602, which will not be repeated here.

[0459] S1803, send discard information to the receiving end.

[0460] The sender sends discard information to the receiver, which indicates the data packets that have been discarded (e.g., data packets that the sender has discarded and / or are to be discarded), and instructs the receiver to update the transmission status parameters based on the discard information.

[0461] In some embodiments, the discard information can be used to indicate the data packets that have been discarded. For example, the discard information may include the identifier of the RLC SDU, RLC PDU, PDCP SDU, or PDCP PDU corresponding to the data packets that the sender has discarded and / or is about to discard, such as the RLC SN, PDCP SN, PDCP layer COUNT value, etc.

[0462] It should be understood that the discard information can be any information that can indicate the discarded data packet, and the specific form of the discard information is not limited in the embodiments of this application.

[0463] In some embodiments, the discard information can be used to instruct the RLC layer of the receiver to update the state parameters of the receive window, and / or to instruct the PDCP layer of the receiver to update the state parameters of the PDCP layer.

[0464] Based on the above embodiments, the sending end can update the status parameters of the sending window in a timely manner based on the dropped data packets, avoiding the sending end from transmitting or retransmitting the dropped data packets. Furthermore, the sending end may instruct the receiving end to update the status parameters of the receiving window and / or the status parameters of the PDCP layer in a timely manner through dropout information, preventing the receiving window from becoming stuck or PDCP layer data reception failure due to untimely parameter updates, thus improving communication quality.

[0465] This application also provides a communication method applied at a receiving end, see reference. Figure 19 The method includes the following steps:

[0466] S1901, Receive the discard information sent by the sender.

[0467] For example, the receiving end can receive discard information sent by the sending end (e.g., the sending end's RLC layer, PDCP layer, MAC layer, PHY layer, etc.).

[0468] In some embodiments, the discard information can be used to indicate discarded data packets (e.g., data packets that the sender has discarded and / or is about to discard). For example, the discard information may include the identifier of the RLC SDU or RLC PDU or PDCP SDU or PDCP PDU corresponding to the data packets that the sender has discarded and / or is about to discard, such as RLC SN, PDCP SN, PDCP layer COUNT value, etc.

[0469] It should be understood that the discard information can be any information that can indicate the discarded data packet, and the specific form of the discard information is not limited in the embodiments of this application.

[0470] S1902, update the transmission status parameters based on the discarded information.

[0471] After receiving the discard information, the receiving end can determine the discarded data packet indicated by the discard information and update the transmission status parameters based on the discarded data packet.

[0472] For example, the receiving end can determine the RLC SDU or RLCPDU corresponding to the dropped data packet indicated by the drop information, and update the status parameters of the receiving window based on the RLC SDU or RLC PDU corresponding to the dropped data packet. For details, please refer to the aforementioned processes of updating status parameters by the receiving end, updating RLC layer status parameters by the receiving end, maintaining the receiving end's drop window, and updating the receiving window's status parameters based on the status parameters of the receiving end's drop window; these will not be elaborated upon here.

[0473] For example, the receiving end can determine the PDCP SDU or PDCPPDU corresponding to the dropped data packet indicated by the drop information, and update the PDCP layer status parameters based on the PDCP SDU or PDCP PDU corresponding to the dropped data packet. For details, please refer to the aforementioned processes of the receiving end updating status parameters, updating PDCP layer status parameters, maintaining the PDCP drop window, and updating PDCP layer status parameters based on the PDCP drop window; these will not be elaborated upon here.

[0474] Based on the above embodiments, the receiving end can update the status parameters of the receiving window and / or the status parameters of the PDCP layer in a timely manner based on the dropped data packets, so as to avoid the receiving window becoming stuck or the PDCP layer data receiving failure due to the failure to update the parameters in a timely manner, which is conducive to improving the communication quality.

[0475] This application also provides a communication method applied at a receiving end, see reference. Figure 20 The method includes the following steps:

[0476] S2001, Receive the discard information sent by the sender.

[0477] For example, the receiving end can receive discard information sent by the sending end (e.g., the sending end's RLC layer, PDCP layer, MAC layer, PHY layer, etc.).

[0478] In some embodiments, the discard information can be used to indicate discarded data packets (e.g., data packets that the sender has discarded and / or is about to discard). For example, the discard information may include the identifier of the RLC SDU or RLC PDU or PDCP SDU or PDCP PDU corresponding to the data packets that the sender has discarded and / or is about to discard, such as RLC SN, PDCP SN, PDCP layer COUNT value, etc.

[0479] It should be understood that the discard information can be any information that can indicate the discarded data packet, and the specific form of the discard information is not limited in the embodiments of this application.

[0480] S2002, update transmission status parameters based on discarded information.

[0481] After receiving the discard information, the receiving end can determine the discarded data packet indicated by the discard information and update the transmission status parameters based on the discarded data packet.

[0482] For example, the receiving end can determine the RLC SDU or RLCPDU corresponding to the dropped data packet indicated by the drop information, and update the status parameters of the receiving window based on the RLC SDU or RLC PDU corresponding to the dropped data packet. For details, please refer to the aforementioned processes of the receiving end updating status parameters, updating the RLC layer status parameters, maintaining the receiving end's drop window, and updating the receiving window's status parameters based on the status parameters of the receiving end's drop window; these will not be elaborated upon here.

[0483] For example, the receiving end can determine the PDCP SDU or PDCPPDU corresponding to the dropped data packet indicated by the drop information, and update the PDCP layer status parameters based on the PDCP SDU or PDCP PDU corresponding to the dropped data packet. For details, please refer to the aforementioned processes of the receiving end updating status parameters, the process of the receiving end updating the PDCP layer status parameters, the maintenance of the PDCP drop window, and the process of the receiving end updating the PDCP layer status parameters according to the PDCP drop window; these will not be elaborated upon here.

[0484] S2003, send a status report to the sending end.

[0485] For example, after updating the status parameters of the receiving window, the receiving end can send a status report to the sending end, which indicates that the data packet indicated by the discard information has been received by the receiving end.

[0486] The process and method of triggering a status report by the receiving end can be referred to in the above-mentioned process of the receiving end sending a status report to the sending end, and will not be repeated here.

[0487] In some embodiments, if ACKs for all packets corresponding to a dropped packet have been sent to the sender, the receiver may not need to send a status report. In some embodiments, if ACKs for some packets corresponding to a dropped packet have been sent to the sender, the status report may not include the ACKs for those packets.

[0488] In some embodiments, if a portion of the packets corresponding to a dropped packet has been sent to the sender with a NACK, the status report can indicate that the reception status of that portion of the packets is ACK.

[0489] It should be understood that after receiving a status report, the sending end can update its status parameters based on the status report, such as updating the status parameters of the sending window. Since all the dropped data packets indicated by the drop information have been acknowledged by the receiving end (in reality, the receiving end may not have received the data packets but only sent an ACK), the sending end will not retransmit these data packets, which helps improve communication quality.

[0490] The communication method provided in this application can be applied to scenarios such as audio stream data, video stream data, or image data transmission between a sending end and a receiving end under audio, video, and image services, such as XR scenarios. The data packet discarding method provided in this application can be applied to various types of communication systems, such as fifth-generation (5G) communication systems. th Generation 5G mobile communication systems, such as New Radio (NR) systems. In addition, it can also be applied to Universal Mobile Telecommunications System (UMTS), Wireless Local Area Network (WLAN), Wireless Fidelity (Wi-Fi) systems, wired systems, vehicle-to-everything (V2X) communication systems, device-to-deveice (D2D) communication systems, and fourth-generation (4G) mobile communication systems. th Generation 4G mobile communication systems, satellite communication systems, and future communication systems, such as sixth generation (6G) mobile communication systems, satellite communication systems, and future communication systems. th Generation 6G mobile communication systems, etc. This application does not limit this to the embodiments described herein.

[0491] For example, such as Figure 21 The diagram shown is a structural schematic of a system architecture 10 applicable to a communication method provided in this application embodiment. This system architecture includes a transmitting device 100 and a receiving device 200 (or a transmitting end and a receiving end).

[0492] In some embodiments, the sending device 100 can act as the sender of data packets, and the receiving device 200 can act as the receiver of data packets.

[0493] In some embodiments, the transmitting device 100 can be various types of user devices, such as mobile phones, tablets, wearable devices, in-vehicle devices, augmented reality (AR) / virtual reality (VR) devices, cloud gaming (CG) devices, mixed reality (MR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), and other devices with audio / video and communication functions. This application embodiment does not limit the type of transmitting device.

[0494] In some embodiments, the receiving device 200 may be a network device / core network device, such as an access device that allows the transmitting device 100 to wirelessly access the wireless communication system. The receiving device 200 may be a network-side entity used for transmitting or receiving signals, such as a base station. The term "base station" can broadly encompass or be replaced by various names such as: NodeB, evolved NodeB (eNB), next-generation NodeB (gNB), relay station, access point, transmitting and receiving point (TRP), transmitting point (TP), master station, auxiliary station, multi-mode wireless node, home base station, network controller, access node, access point, transmission node, transceiver node, baseband unit, remote radio unit, active antenna unit, radio head, central unit, distribution unit, positioning node, etc. A base station may be a macro base station, micro base station, relay node, donor node, or the like. A base station may also be used for communication modules, modems, or chips disposed within the aforementioned devices or apparatus. Base stations can also be mobile switching centers, as well as devices that perform base station functions in device-to-device, vehicle-to-vehicle, and machine-to-machine communications. This application does not limit the specific technologies or device forms used in the network equipment.

[0495] In some embodiments, the transmitting device 100 may be a network device / core device, and correspondingly, the receiving device 200 may be a user device.

[0496] For example, such as Figure 22 The diagram shown is a structural schematic of a transmitting device 100 provided in an embodiment of this application.

[0497] The transmitting device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0498] It is understood that the structure illustrated in the embodiments of this application does not constitute a specific limitation on the transmitting device 100. In other embodiments of this application, the transmitting device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware. In addition, the interface connection relationships between the modules illustrated in the embodiments of this application are illustrative and do not constitute a limitation on the structure of the transmitting device 100. In other embodiments of this application, the transmitting device 100 may also adopt different interface connection methods than those described in the above embodiments, or a combination of multiple interface connection methods.

[0499] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0500] The controller can serve as the central nervous system and command center of the transmitting device 100. The controller can generate operation control signals based on the instruction opcode and timing signals to control the fetching and execution of instructions.

[0501] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0502] The charging management module 140 receives charging input from the charger. The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, and supplies power to the processor 110, internal memory 121, external memory, display 194, camera 193, and wireless communication module 160, etc. The power management module 141 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 141 may also be located within the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be located in the same device.

[0503] The wireless communication function of the transmitting device 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor.

[0504] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the transmitting device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0505] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the transmitting device 100.

[0506] The wireless communication module 160 can provide solutions for wireless communication applications on the transmitting device 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0507] In some embodiments, antenna 1 of transmitting device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling transmitting device 100 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0508] The transmitting device 100 implements display functions through a GPU, a display screen 194, and an application processor. The display screen 194 is used to display images, videos, etc.

[0509] The external storage interface 120 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the transmitting device 100. The external storage card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external storage card.

[0510] Internal memory 121 can be used to store computer executable program code, including instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of the transmitting device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory, universal flash storage (UFS), etc. The processor 110 executes various functional applications and data processing of the transmitting device 100 by running instructions stored in internal memory 121 and / or instructions stored in memory located within the processor.

[0511] The transmitting device 100 can implement audio functions, such as music playback and recording, through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, and an application processor.

[0512] In some embodiments, the receiving device 200 may adopt a structure similar to or the same as that of the transmitting device 100, or it may have a different structure; no limitation is made here.

[0513] Based on the same technical concept, embodiments of this application also provide a transmitting device, including one or more processors; one or more memories; the one or more memories storing one or more computer programs, the one or more computer programs including instructions, which, when executed by the one or more processors, cause the transmitting device to perform one or more steps of any of the above methods.

[0514] Based on the same technical concept, embodiments of this application also provide a communication system, including a transmitting end device and a receiving end device. The transmitting end device is used to perform one or more steps in any of the above methods, and the receiving end is used to receive the data packets in the protocol data unit set transmitted by the transmitting end.

[0515] Based on the same technical concept, embodiments of this application also provide a computer-readable storage medium storing computer-executable program instructions, which, when executed on a computer, cause the computer or processor to perform one or more steps of any of the above methods.

[0516] Based on the same technical concept, the embodiments of the present application further provide a computer program product comprising instructions, the computer program product includes computer program code, which when run on a computer, causes the computer or a processor to execute one or more steps of any one of the above-mentioned methods.

[0517] It should be noted that, in the embodiments of the present application, the description of a numerical range, for example, A being between B and C, may include the endpoints (e.g., B, C) or exclude the endpoints. That is, "A is between B and C" may be B<A<C, B≤A<C, B≤A≤C, or B<A≤C.

[0518] In the above embodiments, the functions may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented by software, the functions may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in accordance with the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions may be transmitted from one website site, computer, server or data center to another website site, computer, server or data center by wired means (such as coaxial cable, optical fiber, digital subscriber line) or wireless means (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that can be accessed by a computer, or a data storage device such as a server or a data center integrated with one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)), etc.

[0519] A person of ordinary skill in the art may understand that all or part of the processes of the methods in the above embodiments may be implemented by a computer program instructing relevant hardware. The program may be stored in a computer-readable storage medium, and when executed, the program includes the processes of the above-mentioned method embodiments. The aforementioned storage medium includes various media capable of storing program codes, such as ROM or random access memory RAM, magnetic disk, or optical disc, etc.

[0520] The above description is merely a specific implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application. Therefore, the protection scope of the embodiments of this application should be determined by the protection scope of the claims.

Claims

1. A communication method applied to a receiving end, characterized in that, include: The dropped data packets are identified, including the second consecutive data packets; The transmission status parameters of the receiving end are updated based on the dropped data packets; A status report is sent to the sending end, the status report indicating that all data packets in the second consecutive data packets have been completely received by the receiving end.

2. The method of claim 1, wherein, The transmission status parameters of the receiving end include at least one of the following parameters: The second state parameter is the lower boundary of the receiving window, and the data packet corresponding to the sequence number indicated by the second state parameter has not been completely received and has not been discarded. The third state parameter is the highest possible sequence number that the ACK_SN field can indicate when the state report is constructed; The fourth state parameter is used to indicate the next sequence number of the sequence number corresponding to the data packet that triggered the reassembly timer.

3. The method according to claim 2, characterized in that, The dropped data packets are within the receiving window.

4. The method according to claim 2, characterized in that, The step of updating the transmission status parameters of the receiving end based on the dropped data packets includes: The second status parameter is updated to the seventh sequence number after the sixth sequence number of the third data packet, wherein the third data packet is any one of the dropped data packets, and the sequence number of the third data packet is the same as the sequence number of the second status parameter.

5. The method according to claim 3, characterized in that, The step of updating the transmission status parameters of the receiving end based on the dropped data packets includes: If the sequence number indicated by the second status parameter is the same as the sixth sequence number of the third data packet in the discarded data packets, the second status parameter is updated to the seventh sequence number after the sixth sequence number, wherein the third data packet is the data packet with the smallest sequence number in the discarded data packets; Alternatively, if the sequence number indicated by the second status parameter is different from the sixth sequence number, and the second status parameter is updated to the sixth sequence number, the second status parameter is updated to the seventh sequence number.

6. The method according to claim 4 or 5, characterized in that, The second consecutive data packet includes the third data packet, and the seventh sequence number is the sequence number of the fourth data packet following the second consecutive data packet.

7. The method according to claim 6, characterized in that, The fourth data packet is the next data packet after the second consecutive data packet, or the first data packet that was not fully received after the second consecutive data packet, or the first data packet that was not fully received after the second consecutive data packet and is not among the dropped data packets.

8. The method according to claim 4 or 5, characterized in that, The second consecutive data packet includes the third data packet; and the step of updating the transmission status parameters of the receiving end based on the dropped data packets further includes: If the sequence number of the last data in the second consecutive data packet is greater than or equal to the sequence number indicated by the third status parameter, the third status parameter is updated to the eighth sequence number; And / or if the sequence number of the last data in the second consecutive data packet is greater than or equal to the sequence number corresponding to the fourth state parameter, the fourth state parameter is updated to the next sequence number of the largest sequence number among the sequence numbers of the data packets that the receiving end has completely received; The eighth sequence number is the sequence number of the fifth data packet following the second consecutive data packet, and the fifth data packet is either the next data packet after the second consecutive data packet or the first data packet that was not completely received after the second consecutive data packet.

9. The method according to claim 6, characterized in that, Sending a status report to the sending end includes: If the acknowledgment (ACK) feedback for one or more data packets in the second consecutive data packets is not sent to the sending end, the status report, which includes the ACKs for the one or more data packets, is sent to the sending end.

10. The method according to claim 6, characterized in that, The sixth sequence number and the ninth sequence number corresponding to the last data packet in the second consecutive data packet are maintained based on the third discard state parameter and the fourth discard state parameter, respectively.

11. The method according to claim 10, characterized in that, The method further includes: Identify at least one consecutive data packet that has been dropped, and update the third and fourth drop status parameters based on the at least one consecutive data packet that has been dropped.

12. The method according to claim 11, characterized in that, The maximum value of the sequence numbers corresponding to the at least one consecutive data packet is the tenth sequence number, and the minimum value is the eleventh sequence number, wherein the tenth sequence number is greater than or equal to the eleventh sequence number; and, updating the third and fourth discard status parameters based on the at least one discarded consecutive data packets includes: If the tenth serial number is less than the third discard status parameter, update the third discard status parameter to the eleventh serial number and update the fourth discard status parameter to the tenth serial number. Alternatively, if the tenth sequence number is greater than the fourth discard status parameter, and the eleventh sequence number is greater than or equal to the third discard status parameter and less than or equal to the fourth discard status parameter, then the fourth discard status parameter is updated to the tenth sequence number. Alternatively, if the tenth sequence number is less than or equal to the fourth discard state parameter and greater than or equal to the third state parameter, and the eleventh sequence number is less than the third discard state parameter, then the third discard state parameter is updated to the eleventh sequence number. Alternatively, if the tenth sequence number is less than or equal to the fourth discard state parameter and greater than or equal to the third state parameter, and the eleventh sequence number is less than the third discard state parameter, then the third discard state parameter is updated to the eleventh sequence number. Alternatively, if the tenth serial number and the eleventh serial number are between the third discard state parameter and the fourth discard state parameter, or if the eleventh serial number is greater than the fourth discard state parameter, then the third discard state parameter and the fourth discard state parameter are not updated.

13. The method according to claim 1, characterized in that, The second consecutive data packets are maintained based on the seventh discard status parameter, and data packets with sequence numbers less than or equal to the sequence number indicated by the seventh discard status parameter need to be discarded.

14. The method according to claim 2, characterized in that, The step of updating the transmission status parameters of the receiving end based on the dropped data packets further includes: The second state parameter is updated to the tenth sequence number, where the tenth sequence number is greater than the third state parameter; Update the third state parameter to the tenth sequence number.

15. The method according to any one of claims 2 to 14, characterized in that, The receiving end includes a radio link control layer, and is comprised of the radio link control layer: Identify dropped data packets; The receiving end's transmission status parameters are updated based on the dropped data packets.

16. The method according to claim 1, characterized in that, The transmission status parameters of the receiving end include at least one of the following parameters: The fifth state parameter is used to indicate the COUNT value corresponding to the first data packet that the Packet Data Convergence Protocol (PDCP) layer of the receiving end has not submitted to the upper layer of the PDCP layer. The sixth state parameter is used to indicate the COUNT value corresponding to the data packet that triggers the reassembly timer of the PDCP layer.

17. The method according to claim 16, characterized in that, The discarded data packets update the transmission status parameters of the receiving end, including: If the dropped data packet satisfies a fourth condition, the transmission status parameters of the receiving end are updated based on the dropped data packet; wherein the fourth condition includes: The COUNT value corresponding to the dropped data packet is between the COUNT value indicated by the fifth state parameter and the COUNT value corresponding to the next data packet received by the PDCP layer. Or the COUNT value corresponding to the dropped data packet is greater than or equal to the COUNT value indicated by the fifth status parameter; Alternatively, the COUNT value corresponding to the discarded data packet is less than or equal to the COUNT value corresponding to the next received data packet at the PDCP layer.

18. The method according to claim 16, characterized in that, The step of updating the transmission status parameters of the receiving end based on the dropped data packets includes: If a sixth data packet exists among the discarded data packets with the same COUNT value as indicated by the fifth status parameter, the fifth status parameter is updated to the second COUNT value after the first COUNT value of the sixth data packet. Alternatively, if there is no packet in the dropped packets whose COUNT value is the same as the COUNT value indicated by the fifth status parameter, the fifth status parameter is updated to the second COUNT value if the fifth status parameter is updated to the first COUNT value.

19. The method according to claim 17, characterized in that, The step of updating the transmission status parameters of the receiving end based on the dropped data packets includes: If the COUNT value indicated by the fifth status parameter is the same as the first COUNT value of the sixth data packet among the discarded data packets, the fifth status parameter is updated to the second COUNT value after the first COUNT value, wherein the sixth data packet is the data packet with the smallest COUNT value among the discarded data packets; Alternatively, if the COUNT value indicated by the fifth state parameter is different from the first COUNT value, the fifth state parameter will be updated to the second COUNT value if the fifth state parameter is updated to the first COUNT value.

20. The method according to claim 18 or 19, characterized in that, The discarded data packets include a third consecutive data packet, which includes the sixth data packet, and the second COUNT value is the COUNT value of the seventh data packet following the third consecutive data packet.

21. The method according to claim 20, characterized in that, The seventh data packet is the next data packet after the third consecutive data packet, or the first data packet after the third consecutive data packet that is not submitted to the upper layer of the PDCP layer, or the first data packet after the third consecutive data packet that is not submitted to the upper layer of the PDCP layer and is not among the discarded data packets.

22. The method according to claim 18 or 19, characterized in that, The step of updating the transmission status parameters of the receiving end based on the dropped data packets further includes: If the second COUNT value is greater than the COUNT value indicated by the sixth status parameter, the sixth status parameter will be updated to the COUNT value corresponding to the next data packet received at the PDCP layer. And / or start the recombination timer of the PDCP layer.

23. The method according to claim 20, characterized in that, The first COUNT value and the third COUNT value corresponding to the last data packet in the third consecutive data packet are maintained based on the fifth discard state parameter and the sixth discard state parameter, respectively.

24. The method according to claim 23, characterized in that, The method further includes: Determine at least one consecutive data packet to be discarded, wherein the maximum value of the COUNT values ​​corresponding to the at least one consecutive data packet is the fourth COUNT value and the minimum value is the fifth COUNT value, wherein the fourth COUNT value is greater than or equal to the fifth COUNT value; If the fourth COUNT value is less than the fifth discard status parameter, update the fifth discard status parameter to the fifth COUNT value and update the sixth discard status parameter to the fourth COUNT value. Alternatively, if the fourth COUNT value is greater than the fifth discard state parameter, and the fifth COUNT value is greater than or equal to the fifth discard state parameter and less than or equal to the sixth discard state parameter, then the sixth discard state parameter is updated to the fourth COUNT value. Alternatively, if the fourth COUNT value is less than or equal to the sixth discard state parameter and greater than or equal to the fifth state parameter, and the fifth COUNT value is less than the fifth discard state parameter, then the fifth discard state parameter is updated to the fifth COUNT value. Alternatively, if the fourth COUNT value is less than or equal to the sixth discard state parameter and greater than or equal to the fifth state parameter, and the fifth COUNT value is less than the fifth discard state parameter, then the fifth discard state parameter is updated to the fifth COUNT value. Alternatively, if the fourth COUNT value and the fifth COUNT value are between the fifth discard state parameter and the sixth discard state parameter, or if the fifth COUNT value is greater than the sixth discard state parameter, then the fifth discard state parameter and the sixth discard state parameter are not updated.

25. The method according to claim 16, characterized in that, From the PDCP layer: Identify dropped data packets; The receiving end's transmission status parameters are updated based on the dropped data packets.

26. The method according to claim 1, characterized in that, The determined discarded data packets include: Received discard information indicating that the data packet to be discarded.

27. A receiving device, characterized in that, include: One or more processors; One or more memory units; The one or more memories store one or more computer programs, the one or more computer programs including instructions that, when executed by the one or more processors, cause the receiving device to implement the method of any one of claims 1 to 26.

28. A communication system, characterized in that, The communication system includes: The receiving device as described in claim 27.

29. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable program instructions that, when executed on a computer, cause the computer to perform the method of any one of claims 1 to 26.

30. A computer program product, characterized in that, The computer program product includes computer program code that, when run on a computer, causes the computer to implement the method of any one of claims 1 to 26.

Images