Data packet notification method and related device

Abstract

The invention provides a data packet notification method and a related device, and relates to the technical field of communication. The method comprises the following steps: receiving a first report which can be used for indicating the state of a data packet sent by a sending end to a receiving end; determining a first data packet based on the first report, wherein the first data packet is a data packet determined to stop transmission by the sending end and is a data packet to be received by the receiving end; and then, based on the first data packet, first information is sent, and the first information is used for informing the receiving end of the data packet which stops transmission. Therefore, the data packets waiting for receiving by the receiving end can be fed back in the first report, and the sending end can determine the data packets which are still waiting for receiving by the receiving end but cannot be transmitted to the receiving end based on the first report and then notify the receiving end, so that the receiving end does not need to wait continuously; the problem that the receiving window stops due to the fact that the receiving window waits for the data packet which the sending end stops transmitting can be avoided, and therefore normal sliding of the receiving window is pushed.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method and related apparatus for notifying data packets. Background Technology

[0002] Wireless communication systems consist of a Radio Link Control (RLC) layer and a Packet Data Convergence Protocol (PDCP) layer. The RLC protocol has a retransmission mechanism. After the sender transmits a data packet to the receiver, if the receiver determines that the data packet was not completely received (e.g., not received or only received fragments), the receiver can send a first report to the sender indicating the status of the data packet. The sender can then retransmit the data packet with the status of "incompletely received" based on the retransmission mechanism.

[0003] Currently, on the sending end side, there may be some data packets that have stopped transmitting. The sending end's PDCP layer can notify the sending end's RLC layer of the stopped data packets or data packets that have been discarded. The RLC can then stop transmitting these data packets. If the sending end has already transmitted them to the receiving end, the sending end will not retransmit them if the receiving end has not fully received the data packet. However, the receiving end will still wait for the retransmission of the data packet, which may cause the receiving window to stagnate, thus affecting the data communication efficiency between the sending and receiving ends. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a data packet notification method and related apparatus. The purpose is to promptly notify the receiving end when a data packet that has stopped transmitting exists at the sending end, thereby promoting the normal sliding of the receiving window at the receiving end and avoiding impacting the data communication efficiency between the sending and receiving ends.

[0005] Firstly, this application provides a data packet notification method applied to a sending end. Exemplarily, the sending end can be a network device, and the receiving end can be a terminal device; alternatively, the sending end can be a terminal device, and the receiving end can be a network device. In this method, the sending end receives a first report, which can be used to indicate the status of a data packet sent by the sending end to the receiving end, including at least one of the following: a NACK status for a data packet that was not fully received, an ACK status for a data packet that was fully received, and a discard status or ACK status for a data packet that the receiving end has discarded. Based on the first report, the sending end can determine a first data packet, which is both a data packet that the sending end determines to stop transmitting and a data packet that the receiving end is waiting to receive; subsequently, based on the first data packet, the sending end can send first information, which is used to notify the receiving end to stop transmitting the data packet.

[0006] In this way, the first report can provide feedback on the data packets that the receiving end is waiting to receive. Based on the first report, the sending end can determine the data packets that the receiving end is still waiting to receive but will no longer transmit to the receiving end, and then notify the receiving end so that the receiving end does not have to continue waiting. This avoids the problem of the receiving window stagnation caused by waiting for data packets that the sending end has stopped transmitting, and promotes the sliding of the receiving window, thereby improving the data communication efficiency between the sending end and the receiving end.

[0007] In one possible implementation, the data packets that the sender determines to stop transmitting can include data packets that the sender determines have been dropped. For example, the sender's PDCP layer notifies the sender's RLC layer of dropped data packets, and the sender's RLC layer can then determine that dropped data packets have stopped transmitting. In this way, notifying the receiver of dropped data packets that the sender has stopped transmitting avoids the problem of the receiver window becoming stagnant due to continuous waiting.

[0008] In one possible implementation, the data packets the receiver is waiting to receive include data packets that the receiver has not fully received; for example, this could include data packets in a NACK state. This allows the sender to clearly identify the data packets the receiver is waiting to receive based on the first report, facilitating the sender to transmit more accurate first information.

[0009] In one possible implementation, the data packets the receiver is waiting to receive include those excluding packets that the receiver has determined have been discarded and those that the receiver has determined have been received completely. For example, packets in a discarded state and packets in an ACK state are excluded. The excluded packets may include packets in a NACK state and packets that the sender has sent to the receiver but were not indicated in the first report. Alternatively, the data packets the receiver is waiting to receive may include those excluding packets that the receiver has determined have been received completely. For example, if a packet that the receiver has discarded is also in an ACK state, excluding ACK packets will exclude both discarded and completely received packets. This allows the sender to not only clearly identify the packets the receiver is waiting to receive as indicated in the first report, but also the packets the receiver is waiting to receive that were not indicated in the first report. This allows for sending more comprehensive first information and notifying the receiver all at once, reducing signaling overhead.

[0010] In one possible implementation, the first information may include a first bit, where a first value of the first bit indicates that the corresponding data packet has stopped transmitting (e.g., the first value could be 1), and a second value of the first bit indicates that the corresponding data packet has not stopped transmitting (e.g., the second value could be 0). This allows the receiving end to more accurately determine whether its corresponding data packet has stopped transmitting based on the value of the first bit in the first information, thereby avoiding interference with the sliding of the receiving window.

[0011] In one possible implementation, the first bit corresponds one-to-one with a data packet that was not completely received by the receiver; for example, one bit corresponds one-to-one with a data packet in the NACK state. This reduces the number of bits required for the initial information, thus lowering signaling overhead.

[0012] In one possible implementation, the first bit corresponds one-to-one with the consecutive data packets indicated by the first report. This reduces information loss in the initial data transmission, allowing the receiving end to more accurately identify the data packets from which the sending end has stopped transmitting.

[0013] In one possible implementation, the first information further includes a first sequence number, which indicates the smallest sequence number among the sequence numbers corresponding to the first data packet. That is, the first sequence number indicates the data packet with the smallest sequence number that the sender has stopped transmitting from and the receiver is waiting to receive. The first bit corresponds one-to-one with consecutive data packets whose sequence number is greater than or equal to the first sequence number. In this way, by reducing the number of bits in the first information, it further ensures that the receiver accurately reads the first information.

[0014] In one possible implementation, the first information includes a second sequence number, which corresponds one-to-one with the first data packet. This directly indicates the sequence number of the first data packet, making it easier for the receiving end to understand and more accurately guide the sliding of the receiving window. It avoids situations where misunderstandings of the first information lead to the misinterpretation of a data packet that the sender has stopped transmitting as one that is still being transmitted.

[0015] In one possible implementation, the first information is sent via the initial data packet sent from the sender to the receiver. For example, the sender sends an SN10 data packet to the receiver for the first time, which may carry the first information. Alternatively, the first information can be sent via a retransmitted data packet from the sender to the receiver. For example, if the sender has already sent an SN8 data packet to the receiver, retransmitting the SN8 data packet may also carry the first information. This reduces the signaling overhead of sending the first information separately.

[0016] In one possible implementation, the first information may include a third sequence number and a field. The third sequence number indicates the sequence number of the data packet initially sent by the sender to the receiver, or the sequence number of the data packet retransmitted by the sender to the receiver. In other words, the third sequence number indicates the sequence number of the sent data packet itself; for example, if the sender first sends a data packet with sequence number SN10 to the receiver, the third sequence number is SN10. The field indicates that one or more data packets with sequence numbers less than the third sequence number should stop transmission. Thus, by combining the existing third sequence number of the sent data packet with the field to indicate the data packet to be stopped, the number of bits in the first information can be reduced, further reducing signaling overhead.

[0017] In one possible implementation, the field may include a first field, which includes a first quantity. This first field indicates that a first number of consecutive data packets with sequence numbers less than the third sequence number and adjacent to the third sequence number should cease transmission. For example, if the first field is a range field, and the third sequence number is SN10 with a range of 5, it could indicate that the five data packets preceding the third sequence number (SN5-SN9) should cease transmission. Thus, by adding a first field to the data packets with the third sequence number to indicate the first information, there is no need to send the first information separately, reducing signaling overhead.

[0018] In one possible implementation, the field may include a second field, which may include a second quantity. The second field indicates that the difference between the sequence number of the data packet whose transmission is to be stopped and the third sequence number is either less than 1 or greater than or equal to the second quantity. For example, the second field may be a gap field, and if the third sequence number is SN10 and the gap field is 5, it can indicate that data packets with a third sequence number 5 data packets apart should stop transmission, i.e., data packets with SN4 should stop transmission. The difference between SN10 and SN4 minus 1 is the second quantity 5. Alternatively, if the third sequence number is SN10 and the gap field is 5, it can indicate that data packets with a third sequence number 5 packets apart should stop transmission, i.e., data packets with SN5 should stop transmission. The difference between SN10 and SN5 is the second quantity 5. Thus, by adding a second field to the data packet with the third sequence number to indicate the first information, the first information does not need to be sent separately, reducing signaling overhead.

[0019] In one possible implementation, the fields may include a first field and a second field. The first field includes a third quantity, and the second field includes a fourth quantity. The difference between the sequence number of the data packet indicating that transmission should be stopped and the third sequence number, minus 1, or the difference is greater than or equal to the fourth quantity, is the number of data packets indicating that transmission should be stopped, as indicated by the second field. For example, if the first field is a range field, the second field is a gap field, the third sequence number is SN10, the range field is 3, and the gap field is 5, it can indicate that two consecutive data packets that are not adjacent to each other and separated by 5 data packets before the third sequence number should stop transmission, i.e., the data packets SN3-SN4 should stop transmission. The difference between SN10 and SN4 minus 1 equals the fourth quantity 5, and the difference between SN10 and SN3 minus 1 is greater than the fourth quantity 5. Alternatively, it can indicate that two consecutive data packets that are not adjacent to each other and separated by 5 data packets before the third sequence number should stop transmission, i.e., the data packets SN4-SN5 should stop transmission. The difference between SN10 and SN5 equals the fourth quantity 5, and the difference between SN10 and SN4 is greater than the fourth quantity 5. Thus, by adding the first and second fields to the data packet with the third sequence number to indicate the first information, the first information does not need to be sent separately, which can reduce signaling overhead.

[0020] In one possible implementation, the data packet notification method may further include: the sending end obtaining second information, which instructs the sending end to stop transmitting data packets that have been discarded; and the sending end determining the data packets to be stopped from transmission based on the second information. In this way, the sending end can be triggered to determine the data packets to be stopped from transmission based on the second information, improving flexibility and making the operation of the sending end to determine the data packets to be stopped from transmission more accurate and effective.

[0021] In one possible implementation, the data packet notification method, after determining the data packet to be stopped based on the second information, may further include: the sending end obtaining third information; based on the third information, the sending end may not perform the action of determining the data packet to be stopped. For example, after obtaining the second information, the sending end's RLC layer receives a notification from the PDCP layer that the data packet has been discarded or that transmission of the data packet has been stopped, and the RLC layer can determine the data packet to be stopped; after obtaining the third information, for data packets already submitted by the RLC layer to the MAC layer, even if the RLC layer receives a notification from the PDCP layer that these data packets have been discarded or that transmission of these data packets has been stopped, the RLC layer does not need to determine the data packet to be stopped, but can still retransmit these data packets already submitted to the MAC layer. Thus, the sending end can be triggered to no longer determine the data packet to be stopped based on the third information, further improving flexibility and making the sending end's operation of determining the data packet to be stopped more accurate and effective.

[0022] In one possible implementation, the sending end obtaining the second information may include: the sending end receiving the second information sent by the receiving end to the sending end. For example, the sending end is a terminal device, and the receiving end is a network device. The network device may configure the second information, and then send the second information to the terminal device. Thus, the sending end can determine whether to stop transmitting data packets based on the indication of the second information sent by the receiving end.

[0023] In one possible implementation, the sending end obtaining the third information may include: the sending end receiving third information sent by the receiving end to the sending end. For example, the sending end is a terminal device, and the receiving end is a network device. The network device may configure the third information, and then send the third information to the terminal device. Thus, the sending end can determine whether to stop transmitting data packets based on the indication of the second information sent by the receiving end.

[0024] In one possible implementation, the sending end sends first information based on the first data packet, which may include:

[0025] If it is determined that the timer is not running, such as when the timer expires or is not started, the sending end can send the first message based on the first data packet. This avoids frequently sending the first message and reduces signaling overhead.

[0026] In one possible implementation, the sending end sends first information based on the first data packet, which may include:

[0027] The sending end sends the first information based on the first data packet and the fourth information. The fourth information is used to instruct the sending end to send the first information. In other words, the fourth information enables the sending end to send the first information. The sending end can be triggered to send the first information based on the fourth information, which can improve flexibility and make the sending end's operation of sending the first information more accurate and effective.

[0028] Secondly, this application provides a data packet notification method applied to a receiving end. Exemplarily, the sending end can be a network device, and the receiving end can be a terminal device; alternatively, the sending end can be a terminal device, and the receiving end can be a network device. In this method, the receiving end can determine the status of the data packet sent by the sending end to the receiving end based on a discard timer, and / or, based on a reordering timer, or based on both a discard timer and a reordering timer. Subsequently, the receiving end can send a first report based on the data packets with determined statuses among the data packets sent by the sending end to itself. For example, the first report can be sent to the sending end, and the first report can be used to indicate the status of the data packets sent by the sending end to the receiving end, including at least one of the following: a NACK status for data packets that were not fully received, an ACK status for data packets that were fully received, and a discard status or ACK status for data packets that the receiving end has discarded. Exemplarily, the discard timer can be maintained by the receiving end's RLC layer, which can be used to determine discarded data packets (e.g., an ACK status or a discard status), and the reordering timer can be maintained by the receiving end's PDCP layer, which can also be used to determine discarded data packets (e.g., an ACK status or a discard status).

[0029] In this way, the receiving end can determine the status of the data packet based on the discard timer and / or the reordering timer, and then provide feedback to it. This allows the receiving end to be notified of the status of the data packet in a timely manner, and can promptly push the sliding of the sending window of the sending end, avoiding the problem of the sending window of the sending end stagnating, which is conducive to improving the efficiency of data communication.

[0030] In one possible implementation, the notification method for the data packet may further include: the receiving end receiving first information; the first information is used to notify the receiving end to stop transmitting the data packet. For example, the sending end can determine the first data packet based on the first report. The first data packet is both the data packet that the sending end determines to stop transmitting and the data packet that the receiving end is waiting to receive. Then, the sending end can send the first information based on the first data packet, so that the receiving end receives the first information.

[0031] In this way, the receiving end can report the data packets it is waiting to receive through the first report, and then receive the first information indicating that it is still waiting to receive data packets but will no longer be transmitted. The receiving end does not need to continue waiting, avoiding the problem of the receiving window stagnation caused by waiting for data packets that have stopped being transmitted. It can promote the sliding of the receiving window, thereby helping to improve the efficiency of data communication.

[0032] In one possible implementation, the data packet notification method may further include: if the receiving end determines that the fourth sequence number of the received data packet is greater than a first state variable, it can start a discard timer. The first state variable indicates the lower limit of the receiving end's receiving window, which is the value of the lower boundary of the receiving window. For example, the first state variable could be RX_Next, used to store the next sequence number after the highest sequence number of the most recently and completely received data packet in sequence. The fourth sequence number being greater than the first state variable indicates that the receiving end has not received the data packet in order, thus allowing the discard timer to be started. In this way, the receiving end's failure to receive the data packet in order indicates the possible presence of a data packet that has stopped transmitting. To avoid affecting the sliding of the receiving window, starting the discard timer can prevent the receiving window from stalling.

[0033] In one possible implementation, the second state variable is used to indicate the fourth sequence number of the received data packet or a sequence number following the fourth sequence number. For example, the second state variable could be RX_Deliv. For example, the fourth sequence number could be the sequence number of the data packet that triggered the drop timer, or the next sequence number after the sequence number of the data packet that triggered the drop timer, or the last sequence number of consecutively received data packets starting with the sequence number of the data packet that triggered the drop timer, or the next sequence number after that last sequence number. Thus, associating the second state variable with the drop timer facilitates subsequent determination of whether any data packets have been dropped.

[0034] In one possible implementation, the data packet notification method may further include: the receiving end determining that a discard timer is running and that a first state variable is greater than a second state variable, stopping the discard timer, indicating that data packets with sequence numbers less than or equal to the second state variable have been completely received and there is no need to continue running the discard timer. Thus, the change in the first state variable allows the receiving end to more accurately determine whether any data packets have been discarded.

[0035] In one possible implementation, the notification method for the data packet may further include: the receiving end determining, based on the timeout of the discard timer, that data packets with sequence numbers less than or equal to the second state variable have been discarded. For example, the receiving end determines, based on the timeout of the discard timer, that all data packets with sequence numbers greater than or equal to the first state variable and less than or equal to the second state variable have been discarded. Thus, based on the discard timer, the receiving end can more accurately determine whether any data packets have been discarded.

[0036] In one possible implementation, the data packet notification method may further include: the receiving end updating the first state variable to the sequence number of the first incompletely received data packet whose sequence number is greater than or equal to the second state variable based on the timeout of the discard timer; and / or updating the second state variable to the fifth sequence number of the received data packet whose sequence number is greater than the latest first state variable, or a sequence number after the fifth sequence number, wherein the sequence number after the fifth sequence number can be the next sequence number after the fifth sequence number, or it can be the last sequence number of a consecutively received data packet starting with the fifth sequence number, or it can be the next sequence number after the last sequence number of a consecutively received data packet starting with the fifth sequence number. Thus, timely updating of the first and second state variables to accurately determine whether the discard timer needs to be restarted is beneficial for maintaining the sending window of the sending end and the receiving window of the receiving end.

[0037] In one possible implementation, the notification method for the data packet may further include: the receiving end determining that the updated second state variable is greater than the latest first state variable, and then starting a discard timer, i.e., restarting the discard timer. Thus, by maintaining the discard timer, discarded data packets can be identified in a timely manner, facilitating the maintenance of the sending window of the sending end and the receiving window of the receiving end.

[0038] In one possible implementation, the data packet notification method may further include: determining a first state variable and starting a discard timer; the first state variable is used to indicate the lower limit of the receiver's receiving window. For example, the first state variable is initially set to 0. If the first state variable is assigned a value, it indicates that there are data packets not received in order within the receiver's receiving window, and the discard timer can be started. Thus, if the receiver does not receive data packets in order, it indicates that there may be data packets that have stopped transmitting. To avoid affecting the sliding of the receiving window, the discard timer can be started, preventing the receiving window from stalling; and maintaining the first state variable saves more resources.

[0039] In one possible implementation, the data packet notification method may further include: if the discard timer is running, determining that the first state variable has been updated allows the discard timer to be stopped, indicating that the data packet with the sequence number equal to the first state variable has been completely received and has not been discarded, thus allowing the discard timer to be stopped. In this way, determining whether to stop the discard timer based on whether the first state variable has been updated facilitates a more accurate determination by the receiving end of whether any data packets have been discarded.

[0040] In one possible implementation, the notification method for the data packet may further include: starting a discard timer based on updating a first state variable. An updated first state variable indicates that the packet has not yet been fully received, and the discard timer can be restarted or resumed accordingly. Thus, the discard timer maintained based on the first state variable allows the receiving end to more accurately determine whether any data packets have been discarded.

[0041] In one possible implementation, the data packet notification method may further include: determining, based on a discard timer timeout, that a data packet with a sequence number equal to the latest first state variable has been discarded. In this way, when the discard timer times out, discarded data packets can be identified promptly, avoiding interference with the sliding of the receive window.

[0042] In one possible implementation, the data packet notification method may further include: updating a first state variable to the sequence number of the first incompletely received data packet with a sequence number greater than the first state variable, based on the timeout of the discard timer. This timely updating of the first state variable allows for accurate determination of whether the discard timer needs to be restarted, which is beneficial for maintaining the receiver's receive window.

[0043] In one possible implementation, the receiving end includes a Radio Link Control (RLC) layer and a Packet Data Convergence Protocol (PDCP) layer. The RLC layer maintains a drop timer, and the PDCP layer maintains a reordering timer. The notification method for the data packet may further include: the PDCP layer updating a third state variable to the sequence number of the first incompletely received data packet whose sequence number is greater than or equal to the fourth state variable based on the reordering timer timeout; and / or, the PDCP layer updating the fourth state variable to the sequence number of the first incompletely received data packet whose sequence number is greater than the latest third state variable; the PDCP layer sending fifth information to the RLC layer, for example, the updated third state variable; and the RLC layer updating a first state variable based on the fifth information. The third state variable indicates the next sequence number after the largest sequence number of the data packets received completely in sequence by the receiving end, the fourth state variable indicates the sequence number of the first incompletely received data packet greater than the third state variable, and the first state variable indicates the lower limit of the receiving window of the receiving end. Thus, by maintaining the reordering timer through the PDCP layer, the receiving window can be updated in a timely manner by notifying the RLC layer, avoiding receiving window stagnation.

[0044] In one possible implementation, the receiving end includes a Radio Link Control (RLC) layer and a Packet Data Convergence Protocol (PDCP) layer. The RLC layer maintains a drop timer, and the PDCP layer maintains a reordering timer. The notification method for the data packet may further include: based on the timeout of the drop timer, the RLC layer determines that a data packet with a sequence number less than or equal to a second state variable has been dropped; the RLC layer sends a sixth message to the PDCP layer; for example, the sixth message indicates a data packet that has been dropped by the PDCP layer, or the sixth message may instruct the PDCP layer to update a third state variable and / or a fourth state variable. The third state variable indicates the next sequence number after the largest sequence number of the data packets received completely in sequence by the receiving end, and the fourth state variable indicates the sequence number of the first incompletely received data packet with a sequence number greater than the third state variable. This avoids repeatedly determining dropped data packets, and through the interaction between the RLC and PDCP layers, timely notification to the PDCP layer avoids waiting for the reordering timer to run, thus saving resources.

[0045] Thirdly, this application provides a communication device, which includes a processing unit and a transceiver unit. The communication device is used to execute the data packet notification method described in the first or second aspect above, including programs or instructions.

[0046] Fourthly, this application provides a communication device, which includes a processor coupled to a memory, the memory storing a program or instructions for executing the data packet notification method described in the first or second aspect above.

[0047] Fifthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the data packet notification method described in the first or second aspect.

[0048] Sixthly, this application provides a computer program product, which includes computer program code that, when executed by an electronic device, implements the data packet notification method described in the first or second aspect. Attached Figure Description

[0049] Figure 1 This application provides a schematic diagram of the structure of a communication system according to an embodiment of the present application.

[0050] Figure 2 A schematic diagram of a sending window of a sending end provided in an embodiment of this application;

[0051] Figure 3 A schematic diagram of a receiving window of a receiving end provided in an embodiment of this application;

[0052] Figure 4A signaling interaction diagram of a data packet notification method provided in an embodiment of this application;

[0053] Figure 5 Signaling interaction diagram of another data packet notification method provided in an embodiment of this application;

[0054] Figure 6a A schematic diagram illustrating the start and timeout of a discard timer provided in this application embodiment;

[0055] Figure 6b A schematic diagram illustrating another discard timer start-up and timeout provided in this application embodiment.

[0056] Figure 7 A schematic diagram illustrating the reordering of timer startup and timeout provided in this application embodiment;

[0057] Figure 8 A schematic diagram of a first type of information provided in an embodiment of this application;

[0058] Figure 9 A schematic diagram illustrating another type of first information provided in an embodiment of this application;

[0059] Figure 10 A schematic diagram illustrating yet another type of first information provided in an embodiment of this application;

[0060] Figure 11a A schematic diagram of an encapsulated data packet provided in an embodiment of this application;

[0061] Figure 11b A schematic diagram of another encapsulated data packet provided in an embodiment of this application;

[0062] Figure 11c A schematic diagram illustrating yet another type of encapsulated data packet provided in an embodiment of this application;

[0063] Figure 11d A schematic diagram of another encapsulated data packet provided in an embodiment of this application;

[0064] Figure 12 This is a schematic diagram illustrating a discarded timer that times out and a rearranged timer that does not time out, provided as an embodiment of this application.

[0065] Figure 13 A schematic diagram of a status report provided in an embodiment of this application;

[0066] Figure 14 This is a schematic diagram of another status report provided in an embodiment of this application. Detailed Implementation

[0067] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0068] The embodiments of this application are applied to communication systems, which can be second-generation (2G) communication systems, third-generation (3G) communication systems, long-term evolution (LTE) systems, fifth-generation (5G) communication systems, LTE and 5G hybrid architectures, 5G New Radio (5G NR) systems, and new communication systems that will emerge in the future development of communication.

[0069] A communication system may include network devices and terminal devices. Network devices are used to provide network communication functions; they are sometimes also called network elements. Network devices are typically terrestrial network devices such as base stations or functional units of base stations. In the embodiments of this application, one example of a communication system may be as follows: Figure 1 As shown, Figure 1 It includes base station 101 and terminal equipment 102.

[0070] In the embodiments provided in this application, the base station can be any device with wireless transceiver capabilities, including but not limited to: evolved Node B (NodeB or eNB or e-NodeB) in LTE systems, base stations (gNodeB or gNB) or transmission receiving points (TRPs) in new radio (NR), base stations evolved by 3GPP, access nodes, wireless relay nodes, and wireless backhaul nodes in Wi-Fi systems. The base station can be: macro base station, micro base station, pico base station, small cell, relay station, or balloon station, etc. The base station can include one or more co-located or non-co-located transmission receiving points (TRPs). The base station can also be a radio controller, centralized unit (CU), and / or distributed unit (DU) in a cloud radio access network (CRAN) scenario. The base station can communicate with the terminal, or it can communicate with the terminal through a relay station. The terminal can communicate with multiple base stations using different technologies. For example, the terminal can communicate with base stations that support LTE networks, base stations that support 5G networks, and can also establish dual connections with both LTE and 5G base stations.

[0071] In the embodiments provided in this application, the terminal device can take various forms, such as a mobile phone, tablet computer, computer with wireless transceiver capabilities, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in industrial control, vehicle-mounted terminal device, wireless terminal in self-driving, wireless terminal in remote medical care, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, wearable terminal device, etc. The terminal device may also be referred to as a terminal, user equipment (UE), access terminal device, vehicle-mounted terminal, industrial control terminal, UE unit, UE station, mobile station, mobile station, remote station, remote terminal device, mobile device, UE terminal device, terminal device, wireless communication device, UE agent, or UE device, etc. The terminal device can also be a fixed terminal or a mobile terminal.

[0072] It should be noted that the above Figure 1 The communication system shown is merely an example; in practical applications, the communication system may include more numbers or types of devices. This application does not limit the architecture of the communication system.

[0073] In related technologies, the sending end includes a PDCP layer, an RLC layer, and a Media Access Control (MAC) layer. The PDCP layer can deliver data packets to the RLC layer, which then encapsulates the data packets and assigns a serial number (SN). The RLC layer then delivers the encapsulated and serialized data packets to the MAC layer, which then sends the data packets to the receiving end.

[0074] In some extended reality (XR) scenarios, the transmission of certain data packets may be interrupted. The PDCP layer can notify the RLC layer of the interrupted data packets or data packets that have been discarded. Upon receiving this notification, the RLC layer can stop transmitting the corresponding data packets. If the interrupted data packet has already been submitted to the MAC layer for transmission before the RLC layer, but the data packet is not fully received by the receiving end, the RLC layer will not retransmit the data packet. However, this may result in the receiving end continuing to wait to receive the data packet, which can easily lead to a stagnation of the receiving window at the receiving end, thereby affecting the data communication efficiency between the sending and receiving ends.

[0075] For example, if the lower boundary of the receiver's receive window is SN10, it means that the lower boundary of the receive window will only be updated to SN11 after the receiver has completely received the data packet with SN10. If the sender has already sent the data packet with SN10 to the receiver, but the receiver has not received it completely, the sender will not retransmit the SN10 data packet to the receiver after confirming that it has stopped transmitting the data packet. However, the receiver will continue to wait, causing the lower boundary of the receive window to remain at SN10. The receive window is stalled and cannot receive data packets with a sequence number greater than or equal to the upper boundary of the receive window. For example, if the upper boundary of the receive window is 15, the receiver cannot receive data packets with SN greater than or equal to SN15.

[0076] Therefore, in order to solve the above problems, this application provides a data packet notification method. In this method, the receiving end sends a first report to the sending end. The first report can indicate data packets that were not fully received, which will be represented as a negative acknowledgment (NACK) in the first report. The first report can also indicate data packets that were fully received, which will be represented as a negative acknowledgment (ACK) in the first report. The first report can also indicate data packets that the receiving end has acknowledged as discarded, which will be represented as an ACK or discarded status in the first report. Based on the first report, the sending end can determine the data packets that the sending end has stopped transmitting and the receiving end is waiting to transmit, and notify the receiving end of them through first information.

[0077] In this way, the receiving end no longer needs to wait for the sending end to stop transmitting data packets, and can promptly push the receiving window to slide, thereby reducing the impact on the data communication efficiency between the sending and receiving ends.

[0078] Next, we will introduce the multiple state variables when transmitting data packets between the sending and receiving ends, and how these multiple state variables are updated.

[0079] The RLC layer supports multiple transmission modes in data transmission. In Acknowledged Mode (AM), the RLC layer requires data packets to receive status acknowledgments during transmission, which can trigger a first report. This causes the receiver to send a first report to the sender. The sender waits for the receiver's first report to confirm the status of the transmitted data packets. The status of the data packets indicated by the first report can include the reception status of the data packets, such as the data packet being fully received by the receiver (ACK status) or the data packet not being fully received by the receiver (NACK status). The status of the data packets indicated by the first report can also include the data packet being discarded, indicating that the data packet has been determined by the receiver to have been discarded.

[0080] It should be noted that the status of the data packet may also include the status of the data packet being dropped. This is just an example. The status of a data packet that has been dropped as determined by the receiving end may also be represented as an ACK status. This application does not limit this.

[0081] In the embodiments of this application, the data packets processed by the transmitting end and the receiving end are called Radio Link Control Service Data Units (RLC SDUs). An RLC SDU can be a complete RLC SDU, or an RLC SDU can be composed of multiple segments to form a complete RLC SDU.

[0082] The data packets transmitted between the sender and receiver are called Adaptive Mode Data Protocol Data Units (AMD PDUs). The sender can encapsulate an RLC SDU or segments of an RLC SDU into an AMD PDU and send it to the receiver. In other words, if an RLC SDU consists of multiple segments, the sender can encapsulate each segment of the RLC SDU into an AMD PDU and send it to the receiver.

[0083] In this embodiment, the transmitting end assigns serial numbers (SNs) to the RLC SDUs in ascending order. After assignment, the transmitting end sends multiple AMD PDUs to the receiving end in ascending order of SN. For example, the transmitting end assigns SNs 1-3 to three RLC SDUs, and sends the three AMD PDUs packaged from these three RLC SDUs in ascending order of SN.

[0084] It should be noted that when an RLC SDU comprises multiple segments, the transmitter will assign a single serial number (SN) to the RLC SDU. The SNs of all segments within the RLC SDU are identical, indicating that the AMD PDUs encapsulated from each segment of the RLC SDU also share the same SN. For example, if an RLC SDU comprises three segments, and the transmitter has already sent AMD PDUs with SNs 1 and 2, then the transmitter will assign SN 3 to this RLC SDU. The three AMD PDUs formed by the three segments of this RLC SDU will each be assigned SN 3, and the transmitter will send the segments sequentially from beginning to end within the RLC SDU.

[0085] like Figure 2 As shown, the sending end has several status variables, including the acknowledgment status variable TX_Next_Ack, the transmission status variable TX_Next, and the window size AM_Window_Size. TX_Next_Ack stores the next SN of the RLCSDU's latest acknowledgment status, serving as the lower boundary of the sending end's transmission window. TX_Next_Ack is updated as the sending end acknowledges the status of a new RLCSDU. TX_Next stores the SN allocated for the next newly generated AMD PDU. An AMD PDU consists of an RLC SDU or a segment of an RLC SDU. AM_Window_Size refers to the window size pre-set under AM. TX_Next_Ack + AM_Window_Size serves as the upper boundary of the transmission window, determining the number of RLC SDUs the sending end can continuously transmit without receiving the first report from the receiving end. The SN of the RLC SDUs the sending end can transmit is greater than or equal to TX_Next_Ack and less than TX_Next_Ack + AM_Window_Size.

[0086] like Figure 3As shown, the receiver has the following status variables: RX_Next, RX_Highest_Status (maximum state transmission), RX_Next_Status_Trigger (t-reassembly status), RX_Next_Highest (highest reception status), and AM_Window_Size. RX_Next stores the next SN of the most recently received complete RLCSDU in sequence, serving as the lower boundary of the receiver's reception window. RX_Next + AM_Window_Size serves as the upper boundary of the reception window, indicating the upper limit of the receiver's reception window. RX_Highest_Status stores the next SN of the highest possible SN indicated by the first report when the first report is constructed, i.e., the next SN of the highest SN of the RLC SDU whose status can be confirmed by the receiver. RX_Next_Status_Trigger stores the next SN of the SN of the RLC SDU that triggered the reassembly timer. RX_Next_Highest stores the next SN of the highest SN of the RLC SDU received by the receiver.

[0087] It should be noted that in the embodiments of this application, RLC SDU is referred to as a data packet, and the segmentation of RLC SDU is referred to as a data packet segment.

[0088] Next, combined Figures 4-14 This application describes a method for notifying data packets provided in its embodiments.

[0089] Example 1:

[0090] like Figure 4 As shown, the notification method for this data packet may include the following steps:

[0091] S401: The receiving end sends the first report to the sending end.

[0092] In this embodiment of the application, the first report is used to indicate the status of the data packet sent by the sender to the receiver, and the first report may include a status report.

[0093] For example, the first report may include packets in the NACK state and / or packets in the ACK state.

[0094] Alternatively, the first report may also include packets in the NACK state, packets in the ACK state, and / or packets in the discarded state. A detailed description of the packets in each state is provided in Embodiment 2 below, and will not be elaborated upon here.

[0095] S402: The sending end determines the first data packet based on the first report.

[0096] In this embodiment of the application, the first data packet is a data packet in which the sending end determines to stop transmission and the receiving end waits to receive it.

[0097] In one possible implementation, the data packets the receiving end is waiting to receive may include data packets in the NACK state or data packet segments. That is, even if a portion of a data packet is received, if the sending end determines that the data packet has stopped transmitting, it will still be identified as the first data packet.

[0098] In another possible implementation, in the example where the receiver represents the state of a discarded data packet as a discarded state, the data packets that the receiver is waiting to receive may also include data packets excluding those in the ACK state indicated by the first report and data packets in the discarded state. For data packet segments, if a portion of a data packet is confirmed as ACK and another portion is confirmed as NACK, then the NACK state should prevail. Therefore, data packets excluding those in the ACK state indicated by the status report are the complete received data packets, not data packet segments in the ACK state. That is, the data packets that the receiver is waiting to receive include complete data packets excluding those in the ACK state indicated by the status report and data packets in the discarded state.

[0099] In the example where the receiver represents the status of a discarded data packet as an ACK status, the data packets the receiver is waiting to receive may include data packets excluding those in the ACK status indicated by the first report. That is, the data packets the receiver is waiting to receive may also include complete data packets excluding those in the ACK status indicated by the status report and data packets in the discarded status. In other words, the data packets the receiver is waiting to receive may also include data packets not indicated in the first report.

[0100] For example, the sender sends data packets SN1-SN15 to the receiver, and the first report indicates the status of data packets SN1-SN13, wherein data packets SN1-SN8 are in the ACK state, data packets SN9-SN10 are in the discard state, and data packets SN11-SN13 are in the NACK state.

[0101] In this example, the data packets that the receiving end is waiting to receive may include data packets from SN11 to SN13.

[0102] In this example, the data packets that the receiving end is waiting to receive may also include data packets of SN11-SN15.

[0103] For example, the sender sends data packets SN1-SN15 to the receiver, and the status report indicates the status of data packets SN1-SN13, where data packets SN1-SN6 are in ACK status, data packets SN7-SN8 are partially in ACK status and partially in NACK status, data packets SN9-SN10 are in discard status, and data packets SN11-SN13 are in NACK status.

[0104] In this example, the data packets that the receiving end is waiting to receive may include data packets of SN7-SN8 and SN11-SN13.

[0105] In this example, the data packets that the receiving end is waiting to receive may also include data packets of SN7-SN8 and SN11-SN15.

[0106] In some embodiments, the PDCP layer of the transmitting end notifies the RLC layer of the transmitting end of data packets to stop transmission or notifies the RLC layer of data packets that have been discarded. If these data packets have already been delivered to the MAC layer, the RLC layer will continue to transmit data packets without needing to determine whether to stop transmitting data packets. If the transmitting end obtains the second information, the PDCP layer of the transmitting end notifies the RLC layer of the transmitting end of data packets to stop transmission or notifies the RLC layer of data packets that have been discarded. If these data packets have already been delivered to the MAC layer, the transmitting end can determine whether to stop transmitting data packets. The second information can also be called enable indication information, and a related description can be found in S501 of Embodiment 2 below.

[0107] The sending end can determine the data packet that has stopped transmission, and based on the first report, it can determine the data packet that the receiving end is waiting to receive. Subsequently, the sending end can determine the data packet that has stopped transmission and the data packet that the receiving end is waiting to receive.

[0108] For example, the data packets that the sending end determines to stop transmitting include data packets SN8, SN11, and SN15, and the data packets that the receiving end is waiting to receive include data packets SN11-SN15, with the first data packet being the data packets SN11 and SN15.

[0109] Furthermore, in some embodiments, after the sending end obtains the third information, and the sending end's RLC layer receives a notification from the PDCP layer that a data packet has been stopped from transmission or has been discarded, the sending end's RLC layer may no longer need to determine the data packets that have been stopped from transmission; that is, it can continue to transmit these data packets without executing the data packet notification method provided in this application embodiment. The third information can also be called a disable indication information, and a related description can be found in S501 of Embodiment 2 below.

[0110] The data packet whose transmission has been stopped can be a data packet that has already been discarded. For example, it could be a data packet that the sending end's PDCP layer notifies the sending end's RLC layer of a discarded data packet (e.g., indicated by the PDCP layer to the RLC layer via a discard indication), or a data packet that the sending end's PDCP layer determines has been discarded and notifies the sending end's RLC layer of a data packet to be stopped from transmission (e.g., indicated by the PDCP layer to the RLC layer via a stop transmission indication). The data packet whose transmission has been stopped indicated by the stop transmission indication can include data packets that the sending end's PDCP layer has determined have been discarded.

[0111] S403: The sending end sends the first information to the receiving end based on the first data packet.

[0112] The first message is a data packet used to notify the receiving end to stop transmission.

[0113] In one possible implementation, the first information can notify the receiving end that there is a first data packet to stop transmission.

[0114] In another possible implementation, the first information can notify the receiver that a data packet has stopped transmission, and it can also notify the receiver of other data packets that have stopped transmission. For example, it can notify the receiver that a data packet in the ACK state has stopped transmission. For instance, based on the previous example, if the data packet SN8 is in the ACK state, and the sender has determined that the data packet to be stopped also includes the data packet SN8, the first information can also notify the receiver that the data packet SN8 has stopped transmission.

[0115] It should be noted that a detailed description of Embodiment 1 can be found in [link to documentation]. Figure 5 The corresponding second embodiment will not be elaborated here.

[0116] In one possible implementation, after the sending end sends the first information, the sending window of the sending end can be updated according to the data packet indicating that transmission has stopped, or the sending window of the sending end can be updated according to the data packet indicating that transmission has stopped in the first information.

[0117] For example, the lower boundary of the sending window is updated to the first data packet that has not stopped transmitting or has not received an acknowledgment of receipt (i.e., the receiver has not reported that the data packet is in an ACK state and / or has been discarded).

[0118] For example, if the lower boundary of the sending window TX_Next_Ack is SN5, the data packets that confirm the ACK status from the sender are SN5, SN6 and SN7, the data packets that do not receive acknowledgment feedback are SN8, SN9 and SN10, and the data packet that the sender stops transmitting is SN8, then the lower boundary of the sending window TX_Next_Ack can be updated to SN9.

[0119] In this way, if the receiving end has stopped transmitting a data packet among the data packets it is waiting to receive, the sending end can notify the receiving end in a timely manner, avoiding the problem of the receiving window stagnation caused by the receiving end waiting continuously. This helps to push the receiving window of the receiving end, thereby improving the data communication efficiency between the sending and receiving ends.

[0120] S404: The receiving end receives the first information and sends the first indication information to the sending end.

[0121] In this embodiment of the application, the first indication information is used to enable the sending end to determine that the receiving end has received the first information.

[0122] In some embodiments, the first indication information may be 1 bit of indication information.

[0123] Furthermore, the first indication information, in addition to enabling the sending end to determine that the receiving end has received the first information, may also carry a data packet that has been acknowledged as received (i.e., a data packet in the ACK state), and / or a data packet that has been discarded by the receiving end (i.e., a data packet in the discarded state). The discarded data packet can be determined by the reassembly timer timeout, or the discard timer in Embodiment 3 below, or the reordering timer in Embodiment 3.

[0124] S405: The sending end updates the sending window based on the first instruction information.

[0125] After receiving the first indication information, the sending end can update its sending window according to the data packet indicating that transmission has stopped, or update its sending window according to the data packet indicating that transmission has stopped in the first information. Please refer to the introduction of the relevant content of S403 above, which will not be repeated here.

[0126] Example 2:

[0127] Next, we will continue to describe in detail the process by which the terminal device determines the data packet to be stopped from transmission, which may include the following steps (not shown in the figure):

[0128] S501: The base station sends an activation instruction to the terminal device.

[0129] In some embodiments, the base station can send an activation indication message to the terminal device via signaling.

[0130] The enable instruction information is used to instruct the sender's RLC layer to determine which data packets to stop transmitting. In other words, if the sender's PDCP layer notifies the sender's RLC layer to stop transmitting a data packet or a data packet that has been discarded, and the sender receives the enable instruction information, its RLC layer can determine which data packets to stop transmitting based on the notification from the PDCP layer.

[0131] In some embodiments, the packet to be stopped can be indicated by the PDCP layer to the RLC layer via a drop indication. When the PDCP layer determines that a packet has been dropped based on its drop timer, and the packet has already been delivered to the RLC layer, it will notify the RLC layer that the packet has been dropped.

[0132] In some embodiments, the base station may configure the enable indication information.

[0133] It should be noted that in the example where the base station is the sender and the terminal device is the receiver, the base station can also configure the enable indication information. However, the base station does not need to send the enable indication information to the terminal device. Instead, the base station configures the enable indication information and can determine the data packets to stop transmitting based on the enable indication information.

[0134] S502: The terminal device determines which data packets to stop transmitting based on the enable instruction information.

[0135] Based on the above description, a terminal device may include a PDCP layer, an RLC layer, and a MAC layer. After the PDCP layer determines that a data packet has been dropped based on its drop timer (i.e., when the drop timer expires), the PDCP layer can notify the RLC layer that the data packet has been dropped or that transmission of the data packet has stopped. If the terminal device receives an enable indication, the RLC layer can determine that the data packet notified by the PDCP layer is a data packet that has stopped transmission, and thus the RLC layer stops transmitting the data packet.

[0136] Furthermore, if the terminal device does not receive an enable instruction or receives a disable instruction, the PDCP layer can notify the RLC layer that the data packet has been dropped or that the data packet has stopped transmitting. However, the RLC layer does not need to determine the data packet that has stopped transmitting, indicating that the RLC layer can continue to transmit the data packet notified by the PDCP layer, without having to execute the data packet notification method provided in the embodiments of this application.

[0137] The disable indication information is used to instruct the RLC layer at the sending end not to determine which data packets to stop transmitting. In other words, when the sending end receives this enable indication information, the RLC layer can determine which data packets to stop transmitting without relying on notifications from the PDCP layer.

[0138] For example, the PDCP layer notifies the RLC layer that data packet 1 has been dropped, and the RLC layer has already delivered data packet 1 to the MAC layer. If the terminal device does not receive an enable indication or receives a disable indication, the RLC layer does not need to stop transmitting data packets, indicating that the RLC layer can transmit data packet 1. In other words, even if the base station does not fully receive data packet 1, the RLC layer will retransmit data packet 1.

[0139] Example 3:

[0140] like Figure 5 As shown, the data packet notification method provided in the embodiments of this application is described in detail.

[0141] The notification method for this data packet may include the following steps:

[0142] S601: The receiver determines that a data packet has been discarded.

[0143] It should be understood that, based on the above description, the sending end can identify data packets that have stopped transmitting. In order to maintain consistency between the sending and receiving ends and avoid affecting the sliding of the receiving window at the receiving end, the receiving end can also identify data packets that have been discarded.

[0144] In some embodiments, the receiving end also includes a PDCP layer, an RLC layer, and a MAC layer. The MAC layer of the receiving end can receive data packets sent by the MAC layer of the sending end. The MAC layer of the receiving end then delivers the received data packets to the RLC layer of the receiving end. Subsequently, the RLC layer of the receiving end can deliver the received data packets to the PDCP layer of the receiving end.

[0145] It should be noted that the MAC layer can forward a complete data packet or a fragment of a data packet to the RLC layer after receiving it, indicating that the RLC layer will receive complete data packets or fragments of data packets. However, the RLC layer will only forward a data packet after receiving a complete data packet, indicating that the RLC layer will not forward a fragment of a data packet after receiving a fragment, but will wait until it receives a complete data packet before forwarding it to the PDCP layer, indicating that the PDCP layer will only receive complete data packets.

[0146] It needs to be further explained that, Figure 3 The various state variables introduced can be state variables maintained by the RLC layer.

[0147] In this embodiment, the RLC layer of the receiving end can maintain a drop timer, and the PDCP layer of the receiving end can maintain a reordering timer, which will be described separately below. The receiving end determines the data packets that have been dropped through the drop timer and / or the reordering timer.

[0148] In one possible implementation, the RLC layer at the receiving end can determine the dropped data packets using a drop timer.

[0149] Combination Figure 3 The description states that the receiving end has a status variable RX_Next, which can be used to store the next SN of the SN of the most recently and completely received data packet in sequence.

[0150] exist Figure 3In addition to the state variables introduced, the receiver RLC layer can also have a state variable called RX_Deliv, which can be used to store the SN that triggered the discard timer.

[0151] First, let's introduce how the discard timer is started: When the RLC layer of the receiving end fully receives a data packet whose SN (which can be called the fourth sequence number) is greater than RX_Next (which can be called the first state variable), or receives a segment of a data packet whose SN (which can be called the fourth sequence number) is greater than RX_Next, the discard timer can be triggered. Then, RX_Deliv (which can be called the second state variable) can be used to store the SN of the data packet that started the discard timer, or RX_Deliv can also be used to store the SN after the SN of the data packet that started the discard timer.

[0152] The subsequent SN can be the SN after the SN of the packet that started the discard timer.

[0153] For example, if the SN of the packet that starts the discard timer is SN6, then RX_Deliv can be SN7.

[0154] Alternatively, the subsequent SN can be the last SN of a series of consecutively received packets, starting with the SN of the packet that started the discard timer, or the SN following the last SN.

[0155] For example, if the SN that starts the discard timer is SN6, and the data packets from SN7 to SN9 are also received by the receiver, then RX_Deliv can be SN9 or SN10.

[0156] It should be noted that in some cases, it is not necessary to determine whether the data packet is a complete data packet or a segment of a data packet. When the receiving end receives a data packet whose SN is greater than RX_Next, the discard timer can be started.

[0157] It should be noted that the above-described start conditions for the discard timer are merely examples, and the discard timer may include other start conditions, which are not limited in this application.

[0158] In some examples, the receiver's RLC layer can exclude fully received data packets, meaning it only considers segments of the received data packets. If, after receiving a segmented data packet, the segment's serial number (SN) is greater than RX_Next, a discard timer can be started. If a complete data packet is received and its SN is greater than RX_Next, then a discard timer does not need to be started.

[0159] For example, if the RLC layer's RX_Next is SN1 and RX_Next_Highest is SN16, it indicates that the RLC layer has not yet received SN1 in full order. In this case, if the RLC layer receives the SN6 packet in full among packets with SNs greater than SN1, the drop timer will not be activated. However, if the RLC layer receives a fragment of the SN4 packet, the drop timer can be triggered. Furthermore, the SN of the packet that triggers the drop timer can be either SN4 or SN5. Because complete packets may not need to be dropped, there is no need to maintain a drop timer.

[0160] For example, such as Figure 6a As shown, the RLC layer at the receiving end has RX_Next as SN1 and RX_Next_Highest as SN16, indicating that the RLC layer has not yet received SN1 in complete order. In this case, among data packets with SN greater than SN1, the RLC layer receives the data packet SN6 first, which can trigger the start of the discard timer. Therefore, RX_Deliv can be SN6 (or RX_Deliv can also be SN7, not shown in the figure). Once the RLC layer has received SN6 completely, it can deliver it to the PDCP layer.

[0161] The following describes how to stop the discard timer: During the operation of the discard timer, the RLC layer updates RX_Next to a SN greater than or equal to RX_Deliv. This indicates that during the operation of the discard timer, the RLC layer has continuously and completely received data packets with a SN greater than or equal to the previous RX_Next and less than or equal to RX_Deliv. The SN gap that occurred has returned to normal, and the discard timer can be stopped.

[0162] When RX_Deliv is the SN of the received packet that started the discard timer, the RLC layer's RX_Next can be updated to be equal to the SN of RX_Deliv without stopping the discard timer. At this time, the packet corresponding to RX_Deliv has not been completely received.

[0163] When RX_Deliv is the SN after the received packet that started the drop timer, the RLC layer's RX_Next can be updated to be equal to the SN of RX_Deliv, and the drop timer can be stopped.

[0164] Among them, the SN gap can be caused by the RLC layer of the receiving end not receiving data packets in order. In some cases, the SN gap can refer to the interruption of the SN of the data packets delivered by the RLC layer to the PDCP layer, which makes the SN of the data packets received by the PDCP layer discontinuous.

[0165] In some embodiments, if the receiving end has received a data packet with a sequence number greater than the updated RX_Next, then RX_Deliv is updated to the SN of the first received data packet with a sequence number greater than RX_Next, or the SN following that SN, or updated to the last SN of a consecutive data packet starting with the first received data packet, or the SN following that last SN. The received data packet can be a complete received data packet, or a segment of a received data packet.

[0166] Additionally, if the updated RX_Deliv is greater than RX_Next after the discard timer has been stopped, the discard timer can be restarted.

[0167] Combination Figure 6a As shown, assuming that during the operation of the discard timer, RX_Next is updated to SN7, it indicates that the RLC layer of the receiving end has completely received the data packets from SN1 to SN6, and the RLC layer has delivered the data packets from SN1 to SN6 to the PDCP layer. There is no SN gap between SN1 and SN6, so the discard timer can be stopped (not shown in the figure).

[0168] The method for restarting the drop timer is then described: During the operation of the drop timer, the RLC layer's RX_Next is updated to a SN greater than or equal to RX_Deliv. This indicates that during the drop timer's operation, the RLC layer has continuously and completely received data packets with SNs greater than or equal to the previous RX_Next and less than or equal to RX_Deliv, and any SN gaps have been resolved. If a data packet greater than the updated RX_Next has been received, then RX_Deliv is updated to the SN of the first received data packet greater than RX_Next, or the next SN, or updated to the last SN of a consecutive data packet starting with the first received data packet, or the next SN of the last SN. The received data packets can be received completely or in segments. If the updated RX_Deliv is greater than RX_Next, the drop timer is restarted.

[0169] The following section describes how to update state variables when the discard timer times out:

[0170] In one scenario, where RX_Deliv is used to store the SN of the packet that started the drop timer, if the drop timer times out and the RLC layer's RX_Next is still not updated to be greater than or equal to RX_Deliv (i.e., RX_Next is less than or equal to RX_Deliv), the RLC layer can first update RX_Next to the SN of the first incompletely received packet that is greater than or equal to RX_Deliv.

[0171] When the receiving end receives a data packet with a sequence number (SN) greater than the updated RX_Next, it can update RX_Deliv to the SN (which can be called the fifth sequence number) of the first complete received data packet (or a segment of a received data packet) after the updated RX_Next, or to the SN after that SN. That is, update RX_Deliv to the SN of the first received data packet greater than RX_Next, or the SN following that SN, or update it to the last SN of a consecutive data packet starting with the first received data packet, or the SN following the last SN. The received data packet can be a complete received data packet or a received data packet segment.

[0172] Combination Figure 6b In the RLC layer, RX_Next is SN1, RX_Next_Highest is SN16, and RX_Deliv can be SN6 (or RX_Deliv can be SN7, etc., not shown in the diagram). When the discard timer expires, the SN7 data packet is received completely, while the data packets corresponding to SN8 and SN12-SN14 are only received in segments. If the SN5 data packet is received completely during the discard timer's operation, then RX_Next is updated to SN8, and the data packets of SN1-SN4 and SN6 are discarded. RX_Deliv can be updated to SN12, where the SN12 data packet is the SN of the first data packet received after the updated RX_Next.

[0173] In addition, RX_Deliv can be updated to SN13, which is the SN following the SN of the first received packet; RX_Deliv can be updated to SN14, which is the last SN of a consecutive packet starting with the first received packet; RX_Deliv can be updated to SN15, which is the SN following the last SN of a consecutive packet starting with the first received packet (not shown in the figure).

[0174] In the above situation, if RX_Deliv is greater than RX_Next, the discard timer can be enabled.

[0175] The above process can then be repeated. That is, after stopping the drop timer or after the drop timer expires, if a data packet with SN greater than RX_Next is received at the RLC layer (or a segment of a data packet with SN greater than RX_Next is received), the drop timer can be started. In some cases, this can be called restarting the drop timer.

[0176] In the example where RX_Deliv is used to store the SN of the packet that started the drop timer, or in the example where RX_Deliv is used to store the SN of the packet that started the drop timer as the last SN of the continuously received packets, the receiver will determine that a packet with an SN greater than or equal to RX_Next and less than or equal to RX_Deliv has been dropped.

[0177] It should be noted that the receiving end may no longer maintain data packets with sequence numbers less than RX_Deliv. Therefore, the receiving end can also determine that data packets with sequence numbers less than or equal to RX_Deliv have been discarded.

[0178] In another scenario, where RX_Deliv is used to store the next SN of the packet that triggered the drop timer, if the drop timer times out and the RLC layer's RX_Next is not yet updated to a value greater than or equal to RX_Deliv, the RLC layer can first update RX_Next to the SN of the first incompletely received packet after RX_Deliv, and then update RX_Deliv to the next SN of the first completely received packet (or a segment of a received packet) after the latest RX_Next. The drop timer can then be triggered again.

[0179] It should be noted that the initial value of RX_Deliv can be obtained based on the first complete reception of a data packet with SN greater than RX_Next by the RLC layer (or the reception of a segment of a data packet with SN greater than RX_Next). Subsequently, RX_Deliv can be updated based on the above steps, that is, updated according to the running status of the discard timer (stopped or timed out).

[0180] In the example where RX_Deliv is used to store the next SN of the packet that started the drop timer, or in the example where RX_Deliv is used to store the SN of the packet that started the drop timer as the SN of the packet that started the drop timer, the receiver will determine that a packet with a SN greater than or equal to RX_Next and less than RX_Deliv has been dropped.

[0181] See also Figure 6aTaking RX_Deliv, which stores the SN of the data packet that triggered the discard timer, as an example, if the discard timer expires and the RLC layer's RX_Next is not updated to a SN greater than SN6, the receiver will determine that all data packets from SN1 to SN6 have been discarded. If the RLC layer has completely received data packets from SN7 to SN10 and delivered them to the PDCP layer, the receiver can update RX_Next to SN11. Among the data packets with SNs greater than SN11, the first data packet received by the receiver is SN14. The receiver can update RX_Deliv to SN14, and since the SN14 data packet has been completely received, the RLC layer can deliver it to the PDCP layer. The highest SN data packet received by the RLC layer remains SN15, and RX_Next_Highest remains unchanged at SN16. At this point, the discard timer can be restarted.

[0182] It should be further explained that the above example of maintaining the discard timer and associating it with the first state variable RX_Next and the second state variable RX_Deliv is only an example. The first state variable RX_Next can also be associated with the maintained discard timer. That is to say, the discard timer is a timer set for RX_Next.

[0183] The conditions for starting the discard timer are as follows: Setting RX_Next enables the discard timer. It should be understood that the initial value of RX_Next is 0. While the receiving end continuously receives data packets in sequence, the initial value of RX_Next remains uninitialized. However, when RX_Next is set, it indicates that the receiving end has received data packets out of sequence, thus enabling the discard timer to start. Setting RX_Next allows you to receive a complete data packet with the sequence number (SN) corresponding to RX_Next (all bytes of the data packet have been received). In some cases, if the sequence number of the received data packet is greater than RX_Next, the discard timer can also be started. In short, the conditions for starting the discard timer follow the previous example; subsequent operations related to the discard timer are described below.

[0184] If the SN of a data packet received by the receiver is the same as RX_Next during the operation of the discard timer, then RX_NEXT can be updated to the SN of the first incompletely received data packet that is greater than RX_NEXT.

[0185] The stopping condition for the discard timer can be: during the operation of the discard timer, the discard timer can be stopped by updating RX_NEXT.

[0186] Subsequently, based on the update RX_Next, the discard timer will be restarted or started.

[0187] If the drop timer times out, it will be confirmed that packets with SN equal to RX_NEXT have been dropped.

[0188] In the event of a timer expiration, RX_NEXT can be updated to the SN of the first incompletely received packet that is greater than RX_NEXT.

[0189] Subsequently, based on the updated RX_Next, the discard timer can be restarted again or the restart timer can be started.

[0190] For example, initially RX_Next is set to 0. The receiver receives SN1-SN4 in sequence, and RX_Next can remain 0. Subsequently, the receiver receives a segment of the SN6 data packet in sequence, and RX_Next can be SN5. A drop timer can be started. During the drop timer's execution, RX_Next is updated to SN6, and the drop timer can be stopped. In this case, based on the update of RX_Next, the drop timer can be restarted or started. During the drop timer's execution, the receiver receives the complete SN7 data packet in sequence and a segment of the SN8 data packet. If the drop timer times out, the SN6 data packet can be considered discarded, and RX_Next is updated to the SN of the first incompletely received data packet greater than RX_NEXT, i.e., SN8.

[0191] In some embodiments, the receiver's RX_Next is SN1, but a segment of the SN1 data packet has been received. RX_Next_Highest can then be assigned the value SN2, indicating that the RLC layer has not yet received SN1 in complete order. In this case, if the discard timer is not running, it can be started. Furthermore, the SN of the data packet associated with starting the discard timer can be RX_Next_Highest, and the SN of subsequent data packets associated with the discard timer can be updated through the discard timer timeout.

[0192] In some embodiments, if the receiver is a network device, the receiver may be configured with a discard timer.

[0193] For example, the receiving end can obtain the discard timer configuration information and then configure the discard timer based on the discard timer configuration information.

[0194] For example, the configuration information for a discard timer can include the duration of the discard timer, the start and stop methods of the discard timer, and the subsequent operations that the receiver needs to perform under specific circumstances. For instance, the subsequent operations that the receiver needs to perform under specific circumstances can include: the method for updating state variables when the discard timer times out, as described above.

[0195] The discard timer configuration information may also include the discard timer's duration, that is, the discard timer will time out after the specified duration. For example, the receiving end can determine the discard timer's duration based on the network environment, but this application does not limit this.

[0196] In one possible implementation, the PDCP layer at the receiving end can reorder packets that have been discarded by the reordering timer.

[0197] It should be understood that a data packet has a serial number (SN) at the RLC layer, and a count (COUNT) value at both the RLC and PDCP layers. The RLC and PDCP layers can determine the correspondence based on the COUNT values ​​of the data packets. For example, the PDCP layer can indicate the COUNT value of data packet 1 to the RLC layer, and the RLC layer can determine that the PDCP layer is indicating data packet 1 based on the COUNT value of data packet 1.

[0198] In some embodiments, the PDCP layer at the receiving end may have two state variables, RX_DELIV and RX_REORD. RX_DELIV is used to store the next COUNT value of the latest COUNT value of the data packet received by the PDCP layer in sequence. For example, if the PDCP layer receives data packets from COUNT1 to COUNT5, then RX_DELIV is COUNT6.

[0199] RX_REORD is used to store the COUNT value of the first incompletely received data packet after RX_DELIV.

[0200] In one scenario, RX_REORD is used to store the COUNT value of the first complete received data packet after RX_DELIV. For example, when the PDCP layer receives data packets COUNT1-COUNT5 and COUNT8, RX_DELIV is COUNT6 and RX_REORD is COUNT9.

[0201] First, let's introduce how the reordering timer is started: When the PDCP layer of the receiving end receives a data packet with a COUNT value greater than RX_DELIV for the first time, it can trigger the start of the reordering timer.

[0202] For example, such as Figure 7 As shown, the RX_DELIV of the PDCP layer at the receiving end is COUNT1. In data packets with a COUNT value greater than COUNT1, the receiving end receives the data packet with COUNT5 first, which can start the reordering timer, and RX_REORD is the next COUNT6 of the data packet with COUNT5.

[0203] For example, if the RX_DELIV of the PDCP layer at the receiving end is COUNT1, and the receiving end receives COUNT5-COUNT7 packets among packets with a COUNT value greater than COUNT1, a reordering timer can be started, and RX_REORD can be the next COUNT8 after the COUNT7 packet. The method for stopping the reordering timer is then described: During the operation of the reordering timer, if the RX_DELIV of the PDCP layer is updated to be greater than or equal to RX_REORD, it indicates that during the operation of the reordering timer, the PDCP layer has received consecutive packets with a COUNT value greater than or equal to the previous RX_DELIV and less than RX_REORD, and the COUNT gap returns to normal, the reordering timer can be stopped.

[0204] Based on the above example, assuming that during the reordering timer operation, RX_DELIV is updated to COUNT7, it indicates that the PDCP layer of the receiving end has received the data packets COUNT1-COUNT6 submitted by the RLC layer (not shown in the figure).

[0205] The following section describes how to update state variables when the reordering timer times out:

[0206] In the event of a reordering timer timeout, the PDCP layer can update RX_DELIV (which can be called the third state variable) to the COUNT value of the first unreceived data packet after RX_REORD (which can be called the fourth state variable). For example, if RX_DELIV is COUNT1 and RX_REORD is COUNT6, and the receiver receives COUNT6-COUNT8 and COUNT10 in the data packets that are greater than or equal to COUNT6, RX_DELIV can be updated to COUNT9 after the reordering timer times out.

[0207] Then update RX_REORD to the COUNT value of the first unreceived data packet after the latest RX_DELIV. For example, if RX_DELIV is COUNT1 and RX_REORD is COUNT6, and the receiver receives COUNT6-COUNT8 and COUNT10 in data packets greater than or equal to COUNT6, after the reordering timer expires, RX_DELIV can be updated to COUNT9 first, and then RX_REORD can be updated to COUNT11.

[0208] For example, if RX_DELIV is COUNT1 and RX_REORD is COUNT6, and the receiving end receives COUNT6-COUNT8 and COUNT10-COUNT12 in packets greater than or equal to COUNT6, after the reordering timer expires, RX_DELIV can be updated to COUNT9 first, and then RX_REORD can be updated to COUNT13.

[0209] Then, the above process can be repeated. At the PDCP layer, the updated RX_REORD is greater than the latest RX_DELIV. At this time, the reordering timer can be triggered again, which can also be called restarting the reordering timer.

[0210] In some embodiments, the PDCP layer sends a fifth piece of information to the RLC layer, such as an updated RX_DELIV (i.e., the COUNT value of the corresponding data packet). The PDCP layer can then notify the RLC layer of the updated RX_DELIV. The RLC layer can update RX_Next based on the fifth piece of information, i.e., the updated RX_DELIV.

[0211] For example, the RLC layer can update RX_Next to the SN of the first incompletely received packet after (including RX_DELIV) following the updated RX_DELIV.

[0212] See also Figure 7 If the reordering timer times out, and the PDCP layer has already received data packets COUNT1-COUNT3, COUNT5-COUNT6, and COUNT8, among the data packets with a COUNT value greater than or equal to COUNT6, the first data packet that the PDCP layer has not fully received is COUNT7. The receiving end can update RX_DELIV to COUNT7 and RX_REORD to COUNT9. At this time, the reordering timer can be restarted.

[0213] The PDCP layer can notify the RLC layer that the updated RX_DELIV is COUNT7, and the RLC layer can update RX_Next to SN7.

[0214] It should be noted that if the reordering timer times out, the receiving end can determine that packets with a COUNT value greater than or equal to the previous RX_DELIV and less than RX_REORD have been discarded. For example, such as... Figure 7 As shown, it can be determined that the packets from COUNT1 to COUNT6 have been dropped.

[0215] Furthermore, in some embodiments, if the updated RX_Next is greater than RX_Highest_Status after the RLC layer updates RX_Next based on the notification from the PDCP layer, then RX_Highest_Status can be updated to the SN of the first data packet that has not yet been fully received after RX_Next (including RX_Next).

[0216] For example, if the updated RX_Next is SN7 and RX_Highest_Status is SN4, then RX_Highest_Status can be updated to SN7.

[0217] In addition, in this embodiment, if the lower boundary of the receiving window has exceeded the updated RX_Next, then RX_Next needs to be updated again to the lower boundary of the receiving window. For example, if the updated RX_DELIV is COUNT5, but the lower boundary of the receiving window is SN8, RX_Next can be updated to SN5, and then updated to SN8.

[0218] Additionally, in this embodiment, if the updated RX_Next is greater than RX_Next_Status_Trigger, RX_Next_Status_Trigger can be updated to the updated RX_Next. If the updated RX_Next is SN7 and RX_Next_Status_Trigger is SN4, then RX_Next_Status_Trigger can be updated to SN7.

[0219] In this embodiment, the RLC layer of the receiving end can also maintain a reassembly timer. If the RLC layer of the receiving end detects that the serial numbers (SNs) of multiple received data packets are not consecutive, the receiving end may start one or more reassembly timers. If the reassembly timer expires, the receiving end can determine the status of the data packets that have not been fully received before RX_Next_Status_Trigger as NACK status.

[0220] Based on the above example, if the reassembly timer is running and the latest RX_Next (i.e., the updated RX_Next, or the lower boundary of the latest receive window) is greater than RX_Next_Status_Trigger, the RLC layer can stop the reassembly timer.

[0221] In some embodiments, the receiving end is a network device, and the receiving end can be configured with a reordering timer. The configuration method for the reordering timer can be found in the configuration method for the discard timer described above, and will not be repeated here.

[0222] It should be noted that in the example where the network device is the sender and the terminal device is the receiver, the sender can also configure a drop timer and a reordering timer, and then send the drop timer and reordering timer to the receiver so that the receiver can determine the dropped data packets based on the drop timer or the reordering timer.

[0223] S602: The receiving end sends the first report to the sending end.

[0224] After the first report is triggered, the receiving end can send the first report to the sending end.

[0225] In some embodiments, the receiving end may trigger the first report after determining that a data packet has been dropped based on a drop timer or a reordering timer. This application does not limit the triggering mechanism of the first report.

[0226] The first report can be used to indicate the status of packets whose SN is less than the highest SN in the first report, indicating that the receiver can determine the status of packets whose SN is less than RX_Highest_Status.

[0227] In some embodiments, the first report may indicate the NACK status of a data packet that the sender sent to the receiver but the receiver did not fully receive. That is, after the reassembly timer expires, the receiver can acknowledge the incompletely received data packet and report its status as NACK in the first report, indicating that the receiver expects the sender to retransmit the data packet in the NACK status.

[0228] In some embodiments, the first report may also indicate the ACK status of a data packet that the sender sent to the receiver and that the receiver fully received. That is, the receiver can report the fully received data packet as an ACK status in the first report, indicating that the receiver does not need the sender to retransmit the data packet with the ACK status.

[0229] In some embodiments, the first report may also indicate to the sender the status of data packets that the receiver has determined to have been dropped. This indicates that the receiver does not need the sender to retransmit these data packets, regardless of whether the data packets were received completely (or even if they were just one data packet).

[0230] For example, the receiving end can report a dropped data packet as an ACK status in the first report, or the receiving end can report a dropped data packet as a dropped status in the first report.

[0231] For example, the sender sends data packets with SNs SN1-SN15 to the receiver. After the receiver confirms the status of the data packets SN1-SN13, the receiver has completely received the data packets SN1-SN8, but has not completely received the data packets SN9 and SN10, and the data packets SN11-SN13 have been discarded. At this time, the first report is triggered. The first report can indicate that the status of the data packets SN1-SN8 is ACK, the status of the data packets SN9 and SN10 is NACK, and the status of the data packets SN11 and SN13 is ACK or discarded.

[0232] S603: The sending end determines the first data packet based on the first report.

[0233] After receiving the first report, the sending end can determine the data packet that has stopped transmission and the receiving end is waiting to transmit (also called the first data packet) based on the data packet that it has already determined to stop transmitting (see the description of S502).

[0234] For details, please refer to S402 for the two possible implementations of the sender determining the first data packet based on the first report, which will not be elaborated here.

[0235] Furthermore, in some embodiments, there may be situations where the first report does not include data packets with a NACK status, or the first data packet only includes data packets not indicated in the first report.

[0236] For example, the sender sends data packets SN1-SN15 to the receiver, and the first report indicates the status of data packets SN1-SN13, wherein data packets SN1-SN8 are in the ACK state and data packets SN9-SN13 are in the discard state. In an example where the sender determines that the data packets to be stopped from transmission include data packets SN8, SN11 and SN15, the first data packet may include SN15.

[0237] S604: The sending end sends the first information to the receiving end based on the determined first data packet.

[0238] The first message is used to notify the receiving end that the sending end has stopped transmitting the data packet.

[0239] In some embodiments, the sending end may obtain fourth information, which is used to instruct the sending end to send the first information to the receiving end after obtaining the first information. That is, the fourth information is used to trigger the sending end to send the first information to the receiving end.

[0240] In this case, if the receiving end is a network device, the fourth information can be configured by the receiving end and sent to the sending end. It should be noted that in the example where the network device is the sending end and the terminal device is the receiving end, the network device can also configure the fourth information, but the network device does not need to send the fourth information to the terminal device. Instead, the network device configures the fourth information and can then send the first information to the terminal device based on that fourth information.

[0241] In some embodiments, the first information may be used to notify the sending end on the receiving end to stop transmitting the first data packet.

[0242] Next, we will introduce the different forms of information, such as the first report or the first data packet.

[0243] First, let's introduce the format of the first information as the first report. It should be noted that "first information" is the first report; the term "first report" is merely an example, and the first information should include the content described below.

[0244] In one possible implementation, the first report may include a bit (also referred to as the first bit, or simply a bit). One value of the bit (also referred to as the first value) (e.g., 1) can indicate that the data packet corresponding to the bit has stopped transmitting, and another value of the bit (also referred to as the second value) (e.g., 0) can indicate that the data packet corresponding to the bit has not stopped transmitting. It should be noted that there is no limitation on the one value and the other value of the bit, as long as they are different.

[0245] In one example, bits can correspond to all consecutive SNs indicated by the first report, with one bit corresponding to one data packet. In some cases, the number of bits is the same as the number of all data packets indicated by the first report.

[0246] For example, the first bit of the multiple bits can correspond to the first NACK packet in the first report, and the subsequent bits correspond to the packets that follow the first NACK packet SN.

[0247] For example, such as Figure 8As shown, the first report indicates that the data packets for SN1-SN8 are in the ACK state, the data packets for SN9 and SN10 are in the NACK state, and the data packets for SN11-SN13 are in the ACK state (the receiver has determined that they have been discarded). The first report indicates data packets for a total of 13 consecutive SNs. The first information may include 13 bits, corresponding one-to-one with SN1-SN13. Specifically, the bit values ​​corresponding to the data packets for SN1-SN9 and SN11-SN13 can be 0, indicating that SN1-SN9 and SN11-SN13 have not stopped transmitting, and the bit value corresponding to the data packet for SN10 can be 1, indicating that SN10 transmission has stopped.

[0248] The bitmap is byte-aligned and is always a multiple of 8 bytes. We will use an example where a bitmap corresponds to 8 bits. Figure 8 As shown, the first piece of information includes a bitmap, indicating that it can correspond to 16 bits. 13 bits in the bitmap correspond one-to-one with SN1-SN13, and the remaining bits can be reserved or set to a value such as 0.

[0249] In some cases, the bit can correspond to the first NACK packet in the first report (i.e., the NACK packet with the smallest sequence number). In this case, the bitmap can indicate that SN9-SN13, SN9, and SN11-SN13 have not stopped transmitting, and the corresponding bit value can be 0. The bit value corresponding to SN10 can be 1, indicating that it has stopped transmitting. The remaining bits in this bitmap can be reserved bits and can be set to values ​​such as 0.

[0250] In another example, one bit can correspond to one NACK state data packet. For example, the first report indicates M NACK state data packets, that is, M bits, and the M bits correspond one-to-one with the M NACK state data packets, where M is an integer greater than or equal to 1.

[0251] For example, based on the previous example, the status of the data packets SN9 and SN10 is NACK. The first information may include two bits, corresponding one-to-one with SN9 and SN10. Specifically, the value of the bit corresponding to the data packet SN9 can be 0, indicating that SN9 has not stopped transmitting, and the value of the bit corresponding to the data packet SN10 can be 1, indicating that SN10 has stopped transmitting.

[0252] In yet another example, the bit can correspond to all consecutive SNs indicated by the first report, or it can correspond to all consecutive SNs greater than or equal to the highest SN of the first report that the sender has sent to the receiver.

[0253] For example, the sending end sends data packets SN1-SN15 to the receiving end, the first report indicates data packets SN1-SN13, and the first information may include 15 bits, corresponding one-to-one with SN1-SN15.

[0254] In one possible implementation, the first report may include a serial number (SN, which can be referred to as a second sequence number). One SN may correspond to one first data packet. For example, if the first data packet has SN5, SN8, and SN10, the first report may include three SNs, namely SN5, SN8, and SN10, as follows. Figure 9 As shown. The data packet corresponding to the SN number carried in the first message has stopped transmitting at the sending end.

[0255] In one example, the SN included in the first report could be the SN of the first data packet indicated by the status report. For example, the SN of a data packet in a NACK state indicated by the status report (in the case of its stopped transmission).

[0256] In another example, the SN could also include the first data packet for which no report was indicated. For example, the SN of a data packet that the sender has sent to the receiver, but the receiver has not responded with a status update (in the case of the receiver ceasing transmission).

[0257] In one possible implementation, the first report may include the SN and the bit.

[0258] In one example, the SN (which can be called the first sequence number) can be the first discard SN, which is the SN of the first data packet that the sender determines to stop transmitting and the receiver expects to transmit. That is, the smallest SN among the SNs corresponding to the first data packet. The bits can correspond to all data packets that are greater than or equal to the first discard SN indicated by the first report.

[0259] For example, such as Figure 10 As shown, the first report indicates the status of data packets SN5-SN17. Data packets SN10-SN17 are in the NACK state. The sender determines that the data packets to be stopped are SN13, SN16, and SN17. The first discard SN is SN13, which has a total of 5 bits. It can include a bitmap with 8 bits. 5 bits correspond one-to-one with the data packets SN13-SN17, and the remaining bits are reserved.

[0260] In another example, the SN can be the first discard SN, which is the SN of the first data packet that the sender determines to stop transmission and the receiver expects to transmit. That is, the smallest SN among the SNs corresponding to the first data packet. In addition to the bits corresponding to all data packets that are greater than or equal to the first discard SN indicated by the first report, the bits can also correspond to all data packets with consecutive SNs that are greater than or equal to the highest SN in the first report and that the sender has sent to the receiver. That is, excluding the data packets that the receiver determines have been discarded and the data packets that the receiver determines have been completely received. Alternatively, the data packets that the receiver is waiting to receive include the data packets that exclude the data packets that the receiver determines have been completely received and the data packets that the sender determines have stopped transmission.

[0261] For example, such as Figure 10 As shown, the sending end has sent data packets SN1-SN20 to the receiving end. The first report indicates the status of data packets SN5-SN17. Data packets SN10-SN17 are in the NACK state. The sending end determines that the data packets to be stopped are data packets SN13, SN16, and SN17. The first discard SN is SN13, which has a total of 8 bits, corresponding one-to-one with data packets SN13-SN20.

[0262] The first piece of information describes the form of the data packet sent from the sender to the receiver. For example, this data packet can be an initial data packet sent by the sender, or it can be a retransmitted data packet; this application does not limit this.

[0263] In one possible implementation, the RLC layer can add a range field (also known as adding a new sub-header) during the packet encapsulation process. This range field (which can be called the first field) can indicate that one or more consecutive packets preceding this packet should stop transmitting. The value of the range field can be called the first number included in the first field.

[0264] For example, the SN (which can be called the third sequence number) of the data packet that the sender is about to transmit is SN15, the range field is 1, indicating that the data packet of SN14 has stopped transmitting, and the range field is 5, indicating that the data packets of SN10-SN14 have stopped transmitting.

[0265] In one possible implementation, the RLC layer can add a gap field (also known as adding a new sub-header) during the packet encapsulation process. This gap field (which can be called the second field) can indicate that the previous packet has stopped transmitting. The difference between the SN of the stopped packet and the current SN minus 1, or the difference itself, is the gap field value. The value of the gap field can be referred to as the second quantity included in the second field.

[0266] For example, in the example where the difference between the SN of the stopped data packet and the SN of the data packet to be sent minus 1 is the value of the gap field, the SN of the data packet to be transmitted by the sender is SN15, the gap field is 5, indicating that the data packet of SN9 has stopped transmission, and the difference between the SNs of the data packet of SN9 and the data packet of SN15 minus 1 is 5, which is the value of the gap field.

[0267] For example, in the case where the difference between the SN of the stopped data packet and the SN of the data packet to be sent is the value of the gap field, the SN of the data packet to be transmitted by the sender is SN15, and the gap field is 5, indicating that the data packet of SN10 has stopped transmitting. The difference between the SNs of the data packet of SN9 and the data packet of SN15 is 5, which is the value of the gap field.

[0268] In one possible implementation, the RLC layer can add gap and range fields during packet encapsulation. These gap and range fields indicate that one or more consecutive, non-adjacent packets preceding the encapsulated packet should cease transmission. The gap field is the difference between the maximum serial number (SN) of the stopped packets and the current SN plus 1. Alternatively, the gap field can be the difference between the maximum SN of the stopped packets and the current SN.

[0269] In this example, the value of the range field can be referred to as the third quantity included in the first field, and the value of the gap field can be referred to as the fourth quantity included in the second field.

[0270] For example, in the example where the difference between the SN of the stopped data packet and the SN of the data packet to be sent minus 1 is the value of the gap field, the SN of the data packet to be transmitted by the sender is SN15, the gap field is 5, and the range field is 2, indicating that the data packets of SN8 and SN9 have stopped transmitting. The difference between the SNs of the data packets of SN9 and SN15 minus 1 is 5, which is the value of the gap field.

[0271] For example, in the case where the difference between the SN of the stopped data packet and the SN of the data packet to be sent is the value of the gap field, the SN of the data packet to be transmitted by the sender is SN15, the gap field is 5, and the range field is 2, indicating that the data packets of SN10 and SN9 have stopped transmitting, and the difference between the SNs of the data packets of SN10 and SN15 is 5.

[0272] like Figures 11a-11d The diagram shows different schematics of the encapsulated data packets. Figure 11a As shown, Oct indicates the fields of the data packet, Oct1-OctN represent the first to Nth fields of the data packet, D / C indicates whether the AMD PDU transmitted between the sender and receiver is a data PDU (i.e., D) or a control PDU (i.e., C), P represents the poll field, SI represents the data packet segmentation, SN represents the SN of the data packet, and Data represents the data carried by the data packet. Figure 11b As shown, SO is used to represent the length of a data packet segment. For example... Figure 11c As shown, R represents reserved bits. It should be noted that each... Figures 11a-11d The meanings of the initials not introduced in the text can be found in other texts, and will not be repeated here.

[0273] Furthermore, in some embodiments, such as Figure 11d As shown, the R field can be replaced with the gap field. In other words, the gap field occupies the position of the previous R field. In this way, reusing R can reduce the number of bits and lower signaling overhead.

[0274] It should be noted that the R field can also be replaced with the range field, and this application does not restrict this.

[0275] In the example where the first information includes the gap field and the range field, R can be replaced by either or both of them.

[0276] See Figure 11a As shown, a range field can be added; see [link / reference]. Figure 11b As shown, a gap field can be added; see [link / reference]. Figure 11c As shown, a range and gap field can be added. For related information, please refer to the implementation method above.

[0277] Furthermore, in some embodiments, the receiving end, based on the first information, can stop waiting for the sending end to stop transmitting data packets and can update the state variable of the receiving window to avoid the receiving window from stalling. For example, if the lower boundary of the receiving window is SN8, and the first information indicates that the sending end should stop transmitting SN8, the sending end can update the lower boundary of the receiving window to SN9.

[0278] If the data packet indicating the first information to stop transmission is equal to the receiver's RX_NEXT, then RX_NEXT needs to be updated to the SN of the first data packet that was not fully received and was not yet stopped transmitting.

[0279] To avoid problems such as wasted signaling overhead due to short time intervals between two transmissions of the first information, in some embodiments, after the sender last sends the first information to the receiver, the sender may start a disable timer. During the execution of the disable timer, the sender and receiver execute steps S601-603 as described above. Even if the sender generates the first information based on the first data packet and has the resources to transmit the first information, the sender will not send the first information to the receiver. Instead, it will send the first information to the receiver only after the disable timer expires.

[0280] In addition, if the timer is not started, and the sending end generates the first information based on the first data packet and has the resources to transmit the first information, the sending end can also send the first information to the receiving end.

[0281] In some embodiments, the receiving end is a network device, and the receiving end can be configured to disable the timer. The configuration method for disabling the timer can be found in the configuration method for discarding the timer described above, and will not be repeated here.

[0282] It should be noted that in the example where the network device is the sender and the terminal device is the receiver, the sender can also configure a timer to disable the sender, and then the sender determines when to send the first information to the receiver based on the timer to disable the sender.

[0283] In addition, in one possible implementation, the PDCP layer and the RLC layer at the receiving end can simultaneously start a reordering timer and a discard timer, respectively. The reordering timer and the discard timer have the same duration, and the PDCP layer and the RLC layer determine the same data packets that have been discarded.

[0284] In another possible implementation, the reordering timer and the discard timer may have different durations, or the reordering timer and the discard timer may be configured separately for the network device and may not start at the same time, resulting in different timeout times for the reordering timer and the discard timer.

[0285] In some embodiments, when the RLC layer's discard timer times out, it can determine the data packets that have been discarded and send a sixth message to the PDCP layer.

[0286] For example, this sixth piece of information can indicate packets that have been dropped. Accordingly, based on the sixth piece of information, PDCP can stop the reordering timer and update RX_DELIV and / or RX_REORD if it determines that the reordering timer is still running.

[0287] For example, the sixth information can instruct the PDCP layer to update RX_DELIV and / or RX_REORD. Accordingly, based on the sixth information, if the PDCP determines that the reordering timer is still running, it can stop the reordering timer and update RX_DELIV and / or RX_REORD.

[0288] like Figure 12 As shown, taking the sixth message as an example of indicating that a data packet has been dropped, if the drop timer expires first, the RLC layer can send the sixth message to notify the PDCP layer that the data packets SN1-SN6 have been dropped. Based on the sixth message, the PDCP layer can stop the reordering timer and update the two status variables RX_DELIV and / or RX_REORD.

[0289] For example, if RX_DELIV of the PDCP layer is SN1 and RX_REORD is SN6, after the PDCP layer receives the sixth message, it has already received SN1-SN3, SN5-SN6 and SN8. RX_DELIV can be updated to SN7 and RX_REORD can be updated to SN9.

[0290] Finally, combining Figure 13 and Figure 14 The first report described above can be a status report.

[0291] In some embodiments, the status report can be 12 bits, such as Figure 13 As shown. In some embodiments, the status report can also be 18 bits, such as... Figure 14 As shown.

[0292] Combination Figure 13 and Figure 14 As shown, the status report includes a control PDU header (also known as an RLC control PDU header) and a payload. The RLC control PDU header includes a D / C field and a CPT field. The D / C field indicates whether the AMD PDU transmitted between the sender and receiver is a data PDU (D) or a control PDU (C). The CPT field indicates the type of RLC control PDU, as shown in Table 1 below:

[0293] Table 1

[0294] value describe 000 Status Report PDU 001 Reserved (For this protocol version, the receiving end will discard PDUs with a value of 001).

[0295] As shown in Table 1, the value of the CPT field in the status report is 000. The status report is a type of RLC control PDU.

[0296] The ACK_SN field (12-bit or 18-bit in length) is used to indicate the SN of the next unacknowledged data packet at the receiving end. In other words, this status report can indicate the status of data packets whose SN precedes ACK_SN, where RX_Highest_Status = ACK_SN.

[0297] The E1 field is used to indicate whether there will be a NACK_SN field later. The E1, E2, and E3 fields are used to indicate the status of data packets that were not completely received by the receiving end. The E1 field can be seen in Table 2 below:

[0298] Table 2

[0299] value describe 0 The NACK_SN, E1, E2, and E3 fields are missing. 1 It has NACK_SN field, E1 field, E2 field and E3 field

[0300] NACK_SN is used to indicate that a data packet (or a segment of a data packet) with that SN was detected and discarded at the receiving end. In other words, the receiving end did not receive a data packet (or a segment of a data packet) with that SN, and its status is "not received".

[0301] The E2 field is used to indicate whether there are subsequent SOstart and SOend fields. In other words, it can indicate whether a data packet with the SN indicated by NACK_SN is fragmented, as shown in Table 3 below:

[0302] Table 3

[0303] value describe 0 There are no SOstart and SOend fields. 1 It has SOstart and SOend fields.

[0304] The E3 field is used to indicate whether there are consecutive packets that have not been received, as shown in Table 4 below:

[0305] Table 4

[0306] value describe 0 No NACK range field 1 There is a NACK range field

[0307] The SOstart field (together with the SOend field) is used to indicate that a segment of a packet with SN NACK_SN has been detected and dropped. The SOstart field indicates the position of the first byte of the segment in the packet.

[0308] When E3 is 0, the SOend field (together with the SOstart field) indicates that a segment of a packet with SN NACK_SN (SOend associated with SOend) was detected and dropped. The SOend field indicates the position of the last byte of the segment in the packet.

[0309] When E3 is 1, the SOend field indicates that a segment of a packet with SN of NACK_SN+NACK range–1 was detected as not received.

[0310] The NACK range is used to indicate the number of consecutive RLC SDUs that have not been received, starting from a packet with SN NACK_SN.

[0311] R is used to indicate reserved fields and is usually set to 0, which can be ignored.

[0312] Oct is used to indicate fields in a status report. For example... Figure 13 As shown, Oct1-Oct14 represent the first to fourteenth fields of the status report. Figure 14 As shown, Oct1-Oct18 represent the first to the eighteenth fields of the status report.

[0313] After receiving the status report, the sending end can retransmit the data packet based on the SN of the data packet that the receiving end did not receive completely, as indicated in the status report.

[0314] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a computer, can implement one or more steps of the above-described data packet notification method.

[0315] Computer-readable storage media can be non-transitory computer-readable storage media, such as ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage devices.

[0316] Another embodiment of this application provides a computer program product containing instructions. When executed by a computer, this computer program product can implement one or more steps of any of the above-described data packet notification methods.

[0317] The electronic device, computer-readable storage medium, and computer program product provided in this embodiment are all used to execute the corresponding data packet notification method provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding data packet notification method provided above, and will not be repeated here.

[0318] The terms "first," "second," and "third," etc., used in this application specification, claims, and drawings are used to distinguish different objects, not to limit a specific order.

[0319] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0320] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for notifying data packets, characterized in that, Applied to the sending end, including: Receive a first report; the first report is used to indicate the status of the data packet sent by the sending end to the receiving end; The first data packet is determined based on the first report; the first data packet is the data packet that the sending end has determined to stop transmitting and the data packet that the receiving end is waiting to receive; Based on the first data packet, first information is sent; the first information is used to notify the receiving end to stop transmitting the data packet.

2. The method according to claim 1, wherein the data packet that the sending end determines to stop transmission includes data packets that the sending end determines have been discarded.

3. The method according to claim 1, characterized in that, The data packets that the receiving end is waiting to receive include data packets that the receiving end has not completely received.

4. The method according to claim 1, characterized in that, The data packets that the receiving end is waiting to receive include data packets that exclude data packets that the receiving end determines have been discarded and data packets that the receiving end determines have been received completely, or the data packets that the receiving end is waiting to receive include data packets that exclude data packets that the receiving end determines have been received completely.

5. The method according to claim 3, characterized in that, The first information includes a first bit, where a first value of the first bit indicates that the corresponding data packet has stopped transmitting, and a second value of the first bit indicates that the corresponding data packet has not stopped transmitting.

6. The method according to claim 5, characterized in that, The first bit corresponds one-to-one with the data packets that the receiving end did not fully receive.

7. The method according to claim 5, characterized in that, The first bit corresponds one-to-one with the consecutive data packets indicated by the first report.

8. The method according to claim 5, characterized in that, The first information also includes a first sequence number, which is used to indicate the smallest sequence number among the sequence numbers corresponding to the first data packet, and the first bit corresponds one-to-one with consecutive data packets whose sequence number is greater than or equal to the first sequence number.

9. The method according to claim 3 or 4, characterized in that, The first information includes a second sequence number, which corresponds one-to-one with the first data packet.

10. The method according to claim 1, characterized in that, The first information is sent via a data packet initially sent from the sending end to the receiving end, or the first information is sent via a data packet retransmitted from the sending end to the receiving end.

11. The method according to claim 10, characterized in that, The first information includes a third sequence number and a field. The third sequence number is used to indicate the sequence number of the data packet initially sent by the sending end to the receiving end, or to indicate the sequence number of the data packet retransmitted by the sending end to the receiving end. The field is used to indicate that one or more data packets with a sequence number less than the third sequence number stop transmission.

12. The method according to claim 11, characterized in that, The field includes a first field, which includes a first quantity. The first field is used to indicate that a first number of consecutive data packets with a sequence number less than the third sequence number and adjacent to the third sequence number will stop transmission.

13. The method according to claim 11, characterized in that, The field includes a second field, which includes a second quantity, and the second field indicates that the difference between the sequence number of the data packet whose transmission has been stopped and the third sequence number is either less than 1 or the difference is greater than or equal to the second quantity.

14. The method according to claim 11, characterized in that, The field includes a first field and a second field. The first field includes a third quantity, and the second field includes a fourth quantity. The difference between the sequence number of the data packet whose transmission has stopped, indicated by the second field, and the third sequence number, is 1 or greater than or equal to the fourth quantity. The third quantity is the number of data packets whose transmission has stopped, indicated by the second field.

15. The method according to any one of claims 1-14, characterized in that, Also includes: Obtain second information; the second information is used to instruct the sending end to stop transmitting data packets that have been discarded; Based on the second information, the data packets that should be stopped from transmission are determined.

16. The method according to claim 15, characterized in that, After determining the data packet to be stopped based on the second information, the method further includes: Obtain third information; the third information is used to instruct the sending end to transmit data packets that have been discarded; Based on the third information, the sending end does not execute the action of determining to stop transmitting the data packet.

17. The method according to any one of claims 1-16, characterized in that, The step of sending first information based on the first data packet includes: If it is determined that the timer is not running, the first information is sent based on the first data packet.

18. The method according to any one of claims 1-17, characterized in that, The step of sending first information based on the first data packet includes: Based on the first data packet and the fourth information, the first information is sent; the fourth information is used to instruct the sending end to send the first information.

19. A method for notifying data packets, characterized in that, Applied to the receiving end, including: The state of data packets sent from the sender to the receiver is determined based on a drop timer and / or a reordering timer. Send a first report; the first report is used to indicate the status of the data packets sent by the sending end to the receiving end.

20. The method according to claim 19, characterized in that, Also includes: Receive the first message; The first information is used to notify the receiving end to stop transmitting data packets.

21. The method according to claim 19, characterized in that, Also includes: If the fourth sequence number of the received data packet is determined to be greater than the first state variable, the discard timer is started; the first state variable is used to indicate the lower limit of the receiving window of the receiving end.

22. The method according to claim 21, characterized in that, The second state variable is used to indicate the fourth sequence number of the received data packet or the sequence number after the fourth sequence number.

23. The method according to claim 22, characterized in that, Also includes: If the discard timer is determined to be running, and the first state variable is determined to be greater than the second state variable, then the discard timer is stopped.

24. The method according to claim 22, characterized in that, The method further includes: Based on the timeout of the discard timer, it is determined that data packets with sequence numbers less than or equal to the second state variable have been discarded.

25. The method according to claim 22, characterized in that, Also includes: Based on the timeout of the discard timer, update the first state variable to the sequence number of the first incompletely received data packet whose sequence number is greater than or equal to the second state variable; And / or, Update the second state variable to a sequence number greater than the fifth sequence number of the received data packet of the latest first state variable, or a sequence number after the fifth sequence number.

26. The method according to claim 25, characterized in that, Also includes: Once it is determined that the updated second state variable is greater than the latest first state variable, the discard timer is started.

27. The method according to claim 19, characterized in that, Also includes: A first state variable is determined, and the discard timer is started; the first state variable is used to indicate the lower limit of the receiving window of the receiving end.

28. The method according to claim 21 or 27, characterized in that, Also includes: The discard timer is started based on the update of the first state variable.

29. The method according to claim 21 or 27, characterized in that, The method further includes: Based on the timeout of the discard timer, it is determined that the data packet with the sequence number equal to the latest first state variable has been discarded.

30. The method according to claim 21 or 27, characterized in that, Also includes: Based on the timeout of the discard timer, update the first state variable to the sequence number of the first incompletely received data packet whose sequence number is greater than the first state variable.

31. The method according to claim 19, characterized in that, The receiving end includes a Radio Link Control (RLC) layer and a Packet Data Convergence Protocol (PDCP) layer, wherein the RLC layer maintains the discard timer and the PDCP layer maintains the reordering timer; it also includes: The PDCP layer updates the third state variable to the sequence number of the first incompletely received data packet whose sequence number is greater than or equal to the fourth state variable when the reordering timer times out; and / or, the PDCP layer updates the fourth state variable to the sequence number of the first incompletely received data packet whose sequence number is greater than the latest third state variable. The PDCP layer sends the fifth information to the RLC layer; The RLC layer updates the first state variable based on the fifth information; The third state variable is used to indicate the next sequence number after the maximum sequence number of the data packets received completely in sequence by the receiving end; the fourth state variable is used to indicate the sequence number of the first incompletely received data packet that is greater than the third state variable; and the first state variable is used to indicate the lower limit of the receiving window of the receiving end.

32. The method according to claim 19, characterized in that, The receiving end includes a Radio Link Control (RLC) layer and a Packet Data Convergence Protocol (PDCP) layer, wherein the RLC layer maintains the discard timer and the PDCP layer maintains the reordering timer; the method further includes: Based on the timeout of the discard timer, the RLC layer determines that packets with sequence numbers less than or equal to the second state variable have been discarded; The RLC layer sends the sixth message to the PDCP layer; Based on the sixth information, the PDCP layer stops the reordering timer and updates the third and / or fourth state variables; The third state variable is used to indicate the next sequence number after the maximum sequence number of the data packets received completely in sequence by the receiving end, and the fourth state variable is used to indicate the sequence number of the first incompletely received data packet that is greater than the third state variable.

33. A communication device, characterized in that, The communication device includes a processing unit and a transceiver unit, and is used to execute a program or instructions for a data packet notification method as described in any one of claims 1 to 18, or a program or instructions for a data packet notification method as described in any one of claims 19 to 32.

34. A communication device, characterized in that, The device includes a processor coupled to a memory storing a program or instructions for performing a data packet notification method as described in any one of claims 1 to 18, or the memory storing a program or instructions for performing a data packet notification method as described in any one of claims 19 to 32.

Images