Data packet transmit window adjustment method, data packet receive window adjustment method, communication device, and storage medium

Abstract

The present application provides a data packet transmit window adjustment method and a data packet receive window adjustment method. The data packet transmit window adjustment method may be executed by a transmitting end and comprises: transmitting an indication of a data packet discarding state to a receiving end; monitoring feedback of the data packet discarding state from the receiving end; and adjusting a data packet transmit window in response to receiving the feedback.

Description

Method for adjusting data packet sending window and receiving window, communication device and storage medium TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of wireless communication, in particular to a method for adjusting data packet sending window and receiving window, a communication device and a storage medium. BACKGROUND

[0002] In today's information age, low-latency services are increasingly becoming an important driving force for the development of emerging network technologies. For example, in the field of extended reality (XR), low-latency network transmission not only relates to the smoothness of user experience, but also is a key element for achieving immersive interaction. XR, as a comprehensive technology that integrates virtual reality (VR), augmented reality (AR), and mixed reality (MR), has applications in online education, telemedicine, virtual tourism, interactive entertainment, and other fields. However, these application scenarios require extremely high data processing speed and transmission efficiency, and the latency and jitter problems of such low-latency services pose a huge challenge to wireless air transmission. Latency refers to the time required from the sending end to receive data at the receiving end, while jitter refers to the fluctuation of latency. In XR applications, latency and jitter can directly affect user experience. If the latency is too large or the jitter is too severe, users may experience frame freezing, intermittent sound, and even symptoms such as dizziness and nausea. In the process of wireless air transmission, due to factors such as signal attenuation, interference, and multipath effect, latency and jitter problems are difficult to avoid. Therefore, how to reduce latency and jitter is a key challenge for the application of low-latency services such as XR technology in 5G.

[0003] In wireless communication systems, particularly in LTE (Long Term Evolution) and 5G NR (New Radio), the RLC (Radio Link Control) layer provides reliability for data transmission. The Acknowledged Mode (AM) in the RLC layer is a mode designed to ensure reliable data transmission. In this mode, RLC AM utilizes the concepts of transmit window (Tx window) and receive window (Rx window) to implement a sliding window mechanism, thereby providing sequence control and error recovery.

[0004] The sliding window mechanism not only ensures reliable data transmission, but also adjusts the sending and receiving rates by controlling the size and sliding speed of the window, optimizing network congestion control. In addition, this mechanism also supports a retransmission mechanism, which can request retransmission for data blocks that have not been correctly received, improving the accuracy and reliability of data transmission.

[0005] However, in some cases, for example, when the sending device or the receiving device discards data packets and affects the corresponding window, the sending window of the sending device and the receiving window of the receiving device can be out of step. This can also adversely affect the delay of the corresponding data transmission.

[0006] SUMMARY

[0007] Embodiments of the present application provide a method for adjusting a data packet sending window and a data packet receiving window, a communication device and a storage medium, to solve the problems in the prior art.

[0008] In one aspect, the present application provides a method for adjusting a data packet sending window, executed by a sending device. The method comprises: sending an indication of a data packet discard state to a receiving device; listening for feedback of the data packet discard state from the receiving device; and adjusting the data packet sending window in response to receiving the feedback.

[0009] In another aspect, the present application provides a method for adjusting a data packet receiving window, executed by a receiving device. The method comprises: receiving an indication of a data packet discard state from a sending device; sending feedback of the data packet discard state to the sending device; and adjusting the data packet receiving window according to the indication of the data packet discard state.

[0010] In another aspect, the present application provides a method for adjusting a data packet sending window, executed by a sending device. The method comprises: sending window synchronization information to a receiving device.

[0011] In another aspect, the present application provides a method for adjusting a data packet receiving window, executed by a receiving device. The method comprises: receiving window synchronization information from a sending device.

[0012] In another aspect, the present application provides a method for adjusting a data packet sending window, executed by a sending device. The method comprises: receiving a data packet receiving state from a receiving device; and adjusting the data packet sending window according to the data packet receiving state.

[0013] In another aspect, the present application provides a method for adjusting a data packet receiving window, executed by a receiving device. The method comprises: in response to a data packet discard: adjusting the data packet receiving window; and sending a data packet receiving state to a sending device; wherein the receiving state of the discarded data packet is indicated as an acknowledgement ACK.

[0014] In another aspect, the present application provides a communication device. The communication device comprises a processor and a memory, wherein the memory is configured to store program instructions, which, when executed by the processor, implement any of the preceding methods.

[0015] In another aspect, the present application provides a readable storage medium for storing program instructions, which when executed by a processor, implement any of the foregoing methods. BRIEF DESCRIPTION OF DRAWINGS

[0016] The accompanying drawings, which are included to provide a further understanding of the present application and are incorporated in and constitute a part of this application, illustrate embodiments of the present application and together with the description serve to explain the present application. In the drawings:

[0017] FIG. 1 shows a diagram of the sending window and its related parameters of the RLC sending end.

[0018] FIG. 2 shows a diagram of the receiving window and its related parameters of the RLC receiving end.

[0019] FIG. 3 shows a scenario where the lower boundary variable of the receiving window and the reassembly timer variable are aligned.

[0020] FIG. 4 shows a scenario where there is a gap between the lower boundary of the receiving window and the maximum SN variable.

[0021] FIG. 5 shows a scenario where the state variable is updated and the timer is triggered again.

[0022] FIG. 6 shows a scenario where the receiving end sends an enhanced RLC status report.

[0023] FIG. 7 shows a mechanism for avoiding out-of-sync in the RLC AM mode in the prior art.

[0024] FIG. 8 shows a scenario where the outdated packet information indicated by the RLC AM sending end to the RLC AM receiving end is lost during transmission, resulting in incorrect reception.

[0025] FIG. 9 shows a scenario where the receiving end feeds back an RLC status report to the sending end in the joint discard scheme of the RLC AM sending end and receiving end.

[0026] FIG. 10 shows a scenario where the sending window and the receiving window are temporarily out-of-sync in the discard mechanism of the RLC AM receiving end.

[0027] FIG. 11 shows timers and receiving window parameters involved in the discard mechanism of the RLC AM receiving end.

[0028] FIG. 12 shows a flowchart of a method for adjusting the sending window and the receiving window according to an embodiment of the present application.

[0029] FIG. 13 shows a flowchart of a method for adjusting the sending window and the receiving window according to another embodiment of the present application.

[0030] FIG. 14 shows an example of a discard status indication report indicating valid packets.

[0031] FIG. 15 shows an example of a discard status indication report indicating discarding of a data packet.

[0032] FIG. 16 shows an example of a feedback message containing a packet discard status indication of LastDiscard_SN or LastSend_SN.

[0033] FIG. 17 shows another example of a feedback message containing a packet discard status indication of LastDiscard_SN or LastSend_SN.

[0034] FIG. 18 shows an example of an AMD PDU carrying discard indication reception feedback.

[0035] FIG. 19 shows an example of retransmission of discard indication information by an RLC AM sender.

[0036] FIG. 20 shows an example of sending of discard indication information (Tx_Status) by an RLC sender according to an inquiry message from a receiver.

[0037] FIG. 21 shows an example of an inquiry message sent by a receiver.

[0038] FIG. 22 shows a flowchart of a method for adjusting a sending window and a receiving window according to an embodiment of the present application.

[0039] FIG. 23 shows a flowchart of a method for adjusting a sending window and a receiving window according to another embodiment of the present application.

[0040] FIG. 24 shows a scenario in which a sender periodically sends window synchronization information to a receiver.

[0041] FIG. 25 shows an example of synchronization information.

[0042] FIG. 26 shows a flowchart of a method for adjusting a sending window and a receiving window according to an embodiment of the present application.

[0043] FIG. 27 shows a flowchart of a method for adjusting a sending window and a receiving window according to another embodiment of the present application.

[0044] FIG. 28 shows a scenario in which a receiver reports a data packet reception status when a discard timer expires but a reassembly timer does not expire.

[0045] FIG. 29 shows a scenario in which a receiver receives two data packet fragments and configures discard timers for the two data packets respectively.

[0046] FIG. 30 shows an example of a data packet header of a PDU Set data set supporting PSIHI processing.

[0047] Figure 31 shows a scenario where periodic data burst occurs with jitter or periodic variation.

[0048] Figure 32 shows multiple logical channel groups containing latency sensitive data or non-latency sensitive data.

[0049] Figure 33 shows a structural diagram of a communication device according to an embodiment of the present application. DETAILED DESCRIPTION

[0050] The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of the present application.

[0051] It should be understood that the term "and / or" herein is only to describe the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B can represent the following three cases: A exists alone, A and B exist together, and B exists alone. In addition, the character " / " herein generally represents an "or" relationship between the associated objects before and after it.

[0052] It should be noted that most of the parameters, configuration elements, processes, etc. in the present application are mainly described in the mode of Radio Link Control Acknowledgment (RLC-AM), but the method provided by the embodiments of the present application can also be applied to other modes or system frameworks that apply similar sliding window mechanisms. For example, the solutions of the embodiments of the present application can be extended to other modes such as RLC UM, etc., or other protocol layers such as PDCP layer, as long as the mechanism involves window sliding and synchronization.

[0053] To facilitate understanding of the method provided by the present application, the processing mechanism of the sending window and the receiving window in the RLC AM mode according to TS38.322 will be briefly introduced below.

[0054] Sliding window processing mechanism of RLC sending end (Tx)

[0055] As shown in Figure 1, the window of the sending end of RLC Tx maintains two variables: TX_Next_Ack and TX_Next. TX_Next_Ack is the lower boundary of the transmission window, recording the minimum sequence number (SN) waiting for the feedback of the receiving end. The range of the transmission window is [TX_Next_Ack ~ TX_Next_Ack + AM_Window_Siz], where AM_Window_Siz is the size of the transmission window. TX_Next records the number of data packet sent by the sending end.

[0056] RLC Tx sending end, when sending data, transmits RLC control PDUs first, then RLC AMD PDUs, among which retransmission packets are transmitted first, then new transmission packets.

[0057] RLC sending end, when receiving a data packet from high layer, assigns a sequence number to the data packet, the value of which is the SN number maintained by variable TX_Next, and then increments TX_Next (TX_Next++).

[0058] In addition, RLC Tx sending end maintains a transmission window with a range of [TX_Next_Ack~TX_Next_Ack+AM_Window_Siz], and only indicates data packets with SNs falling into the range of the transmission window to lower layer (MAC layer).

[0059] For data packets in the transmission window, RLC sending end relies on the status report feedback from RLC receiving end, i.e. RLC status report, to process the data packets in the window. Specifically, for data packets indicated as unacknowledged (NACK) in the RLC status report, retransmission is performed; for data packets indicated as ACK in the RLC status report, high layer (PDCP layer) is notified that the data packets are correctly accepted. If the data packet with SN indicated by lower boundary of the window TX_Next_Ack is also indicated as ACK, the window will slide to the right, and TX_Next_Ack will be updated to the SN of the data packet with the smallest SN in the transmission window and not indicated as ACK.

[0060] In addition to the above processing, RLC AM sending end entity also performs the following processing:

[0061] 1) Accepts status PDU from RLC AM receiving end entity;

[0062] 2) Discards data packets according to the indication of PDCP sending end;

[0063] 3) Retransmission: performs data packet retransmission according to the NACK indication of data in the status PDU (only looks at the feedback information of data packets already sent by the sending end); records the number of retransmissions, and indicates to high layer when the maximum number of retransmissions is reached;

[0064] 4) Polling: records the total amount of data packets already sent, and initiates polling indication (carried on the data packet subheader) to RLC AM receiving end to indicate the receiving end to feedback status report.

[0065] • Sliding window processing mechanism of RLC Rx receiving end

[0066] As shown in Fig. 2, the receiving end of the RLC AM maintains a receiving window by the following variables: RX_Next, RX_Next_Status_Trigger, RX_Highest_Status, and RX_Next_Highest. Among them, RX_Next is the lower boundary of the window, and this status variable holds the next sequence number (SN) of the latest completely received RLC SDU, which is the lower boundary of the receiving window. It is initially set to 0, and is updated when the AM RLC entity receives the RLC SDU with the sequence number RX_Next. RX_Next_Status_Trigger is the reassembly timer status variable, and this status variable holds the next sequence number of the sequence number of the RLC SDU that triggers the reassembly timer. RX_Highest_Status is the maximum status transmission status variable, and this status variable holds the highest possible value of the sequence number that can be indicated by the "ACK_SN" when a STATUS PDU needs to be constructed. It is initially set to 0, and it indicates that all the data packets before this sequence number (SN) (not including those indicated by NACK) have been received by the receiving end. RX_Next_Highest is the highest reception status variable, and this status variable holds the next sequence number of the RLC SDU with the highest sequence number among the received RLC SDUs. It is initially set to 0, which represents the next sequence number of the data packet with the largest sequence number (SN) received by the receiving end.

[0067] At the receiving end of the AM RLC entity, a receiving window should be maintained according to the status variable RX_Next, and the specific rules are as follows: if RX_Next <= SN < RX_Next + AM_Window_Size, the sequence number (SN) falls within the receiving window; otherwise, the sequence number (SN) falls outside the receiving window.

[0068] When an AMD PDU is received from the lower layer, the receiving end of the AM RLC entity should perform the following operations: either discard the received AMD PDU, or put it into the receiving buffer. If the received AMD PDU is put into the receiving buffer: update the status variable, reassemble and deliver the RLC SDU to the upper layer, and start / stop the reassembly timer (t-Reassembly) as needed. When the reassembly timer (t-Reassembly) expires, the receiving end of the AM RLC entity should: update the status variable as needed and start the reassembly timer (t-Reassembly).

[0069] When an AM RLC entity receives an AMD PDU containing byte segments y to z of an RLC SDU with sequence number (SN) x from the lower layer, the receiving side of the AM RLC entity shall perform the following operations: If x is outside the receiving window, or if byte segments y to z of the RLC SDU with sequence number (SN) x have already been received before, the received AMD PDU shall be discarded without being placed in the receiving buffer; otherwise, the received AMD PDU shall be placed in the receiving buffer and the duplicated byte segments, if any, of the RLC SDU contained in the AMD PDU shall be discarded.

[0070] As can be seen, the first step of the receiving side is to determine the sequence number (SN) of the received data packet. Only the data packet falling within the receiving window and not duplicated is placed in the buffer.

[0071] When an AMD PDU with sequence number x is placed in the receiving buffer, the receiving side of the AM RLC entity shall perform the following operations: If x >= RX_Next_Highest (i.e. if the received data packet has a sequence number greater than the largest sequence number already in the window), then update RX_Next_Highest to x+1; if all bytes of the RLC SDU with sequence number x have been received, reassemble the RLC SDU from the AMD PDU(s) with sequence number x, remove the RLC header, and deliver the reassembled RLC SDU to the upper layer; if x = RX_Highest_Status (i.e. if the received is the "ACK_SN" in the status report), then update RX_Highest_Status to the sequence number of the first RLC SDU after the current RX_Highest_Status that has not yet been completely received; if x = RX_Next (i.e. if the received is the data packet at the lower edge of the window), then update RX_Next to the sequence number of the first RLC SDU after the current RX_Next that has not yet been completely received.

[0072] Figure 3 shows a scenario where the lower edge variable of the receive window and the reassembly timer variable are aligned. The conditions for a running reassembly timer to stop are as follows (these conditions are based on the comparison of the lower edge and the reassembly timer status variables): 1) RX_Next_Status_Trigger = RX_Next; 2) RX_Next_Status_Trigger = RX_Next + 1 (i.e. the data segment of the lower edge has been completely received), and there is no missing segment of bytes before the last byte of all received segments related to the SDU with sequence number RX_Next; or 3) RX_Next_Status_Trigger falls outside the receive window, and RX_Next_Status_Trigger is not equal to RX_Next + AM_Window_Size. The conditions for a non-running reassembly timer to start are as follows (these conditions are based on the comparison of the lower edge and the received maximum sequence number variable): 1) RX_Next_Highest > RX_Next + 1; or 2) RX_Next_Highest = RX_Next + 1 (i.e. there is a data segment of the lower edge of the window not completely received), and there is at least one segment of bytes missing before the last byte of all received segments related to the SDU with sequence number RX_Next. Normally, there is a gap between RX_Highest and RX_Next + 1, i.e. the reassembly timer needs to be started to handle this gap case; in addition, RX_Next_Status_Trigger needs to be updated to the current maximum sequence number variable RX_Next_Highest. Figure 4 shows a scenario where there is a gap between the lower edge and the maximum SN variable.

[0073] When the reassembly timer (t-Reassembly) expires, the receiving side of the AM RLC entity shall perform the following actions - in this case, the timer expiry can be due to the lower edge failing to arrive all the time, and the receiving side needs to update the status variable and send a status report to the transmitting side based on this variable ("ACK_SN"): update RX_Highest_Status to the SN of the first RLC SDU with SN greater than or equal to RX_Next_Status_Trigger and for which all bytes have not been received; and acknowledge the reception failure of the AMD PDU (i.e. the receiving side considers the lower edge reception failure). When t-Reassembly expires, the receiving side of the AM RLC entity shall trigger a status report, and the expiry of t-Reassembly triggers both the update of RX_Highest_Status and the triggering of the status report, but the status report shall be triggered after the update of RX_Highest_Status. It can be seen that when the timer expires, the receiving window does not move due to the lower edge reception failure, and a status report is triggered to ask the transmitting side to retransmit. Until the lower edge is received and an ACK is fed back to the transmitting side, the windows of both sides can move. If the retransmission fails all the time, the DRB (Data Radio Bearer) will report RLF (Radio Link Failure).

[0074] Figure 5 shows the scenario of the status variable update triggering the timer again. If 1) RX_Next_Highest > RX_Highest_Status + 1; or 2) RX_Next_Highest = RX_Highest_Status + 1 (i.e. the lower edge has some segments not received), and at least one segment is missing before the last byte of all received segments related to the SDU with SN RX_Highest_Status, t-Reassembly will be started again (i.e. the gap between the two variables triggers the timer again), and RX_Next_Status_Trigger will be set to the current maximum sequence number variable RX_Next_Highest. It should be noted that if the lower edge of the receiving window has not been received all the time, the status variable will be updated and a status report will be sent after the first timer expires; and the update of the status variable can cause the reassembly timer to start again, and after the second expiry, the status variable will be updated again and a status report will be sent. In this case, as long as the data packets in the receiving window arrive all the time, the receiving side will continuously feed back the status report to the transmitting side.

[0075] In addition to the above processing, the RLC AM receiving entity also performs the following processing: 1) when receiving a polling indication from the sending entity; or 2) when the RLC AM receiving window timer expires (t-Reassembly), the RLC AM receiving entity feeds back the data packet receiving status to the RLC AM sending entity (through an independent RLC control PDU), such as the enhanced RLC status report shown in FIG. 6.

[0076] The current standard agrees to avoid sending or receiving unnecessary outdated data through the sending entity mechanism and the receiving entity mechanism, and means that the sending entity or the receiving entity discards the outdated data, which may cause the window out-of-sync problem of the sending entity and the receiving entity in this case. Before analyzing the RLC sending / receiving entity window out-of-sync problem in the data discarding mechanism supporting the RLC AM mode, we first analyze the RLC sending / receiving entity window out-of-sync processing mechanism in the RLC AM mode (i.e., without supporting autonomous discarding of data packets) in the reference technology.

[0077] FIG. 7 shows the mechanism for avoiding out-of-sync in the RLC AM mode in the reference technology. When the window variable of the RLC AM receiving entity is full, the receiving entity reassembly timer expires, and the receiving entity feeds back an RLC status report to the sending entity, and the receiving side window moves to the right. If the RLC status report fed back by the RLC AM receiving entity to the sending entity is lost, the sending entity window does not move to the right (the data packet with TX_Next_ACK = 1 is indicated as ACK in the RLC receiving entity window, but the sending entity does not receive this indication information). The RLC sending / receiving entity windows are out-of-sync. When the RLC AM receiving entity sends the RLC status report next time, if the sending entity receives it, the sending entity can determine that the data packet with TX_Next_ACK = 1 is indicated as ACK in the RLC receiving entity window, and the sending entity moves the window, and the RLC sending / receiving entity window out-of-sync disappears, and the sending / receiving entity is synchronized again.

[0078] In addition, in order to avoid the transmission of invalid data packets, there are several ways of enhancement. Way one: RLC AM sending end data packet discard scheme: the RLC AM sending end discards outdated data packets, and the sending end also indicates to the receiving end which packets are outdated. Way two: RLC AM receiving end data packet discard scheme: the RLC AM receiving end starts an acceptance timer for each received data packet, and when the timer expires, the receiving end discards the data packets. In addition, the receiving end also needs to indicate to the sending end the discarded data packet information. Way three: RLC AM sending end and receiving end data packet joint discard scheme: the RLC AM sending end discards data packets according to the PDCP indication without indicating to the receiving end, and the receiving end discards data packets according to the receiving end timer. The sending end and the receiving end discard data packets independently. From the above enhanced discard scheme, it can be seen that any discard scheme may cause the out-of-sync of the window of the opposite end due to the movement of the discard window of one end. Therefore, the possible out-of-sync of each discard mechanism needs to be analyzed, and a corresponding solution is provided for the out-of-sync.

[0079] For the out-of-sync problem of the RLC AM sending end data packet discard mechanism, according to the latest progress of the discussion of the 3GPP organization, the RLC AM sending end data packet discard scheme supports the RLC sending end to discard outdated data packets, and at the same time, the RLC AM sending end needs to further indicate the discarded outdated data packet information to the receiving end to make the receiving end window move in time. However, the outdated data packet information indicated by the RLC AM sending end to the RLC AM receiving end may be lost or timed out during transmission, resulting in incorrect reception, and thus causing the sending window and the receiving window to be out of sync. As shown in FIG. 8, the RLC AM sending end discards outdated data packets 1, 2, 3, and 4, the sending end RLC transmission window moves to the right, and the TX_Next_ACK variable is updated. However, since the discard indication status report 1 is lost during transmission, the RLC AM receiving end cannot obtain the relevant information, thereby causing the sending window and the receiving window to be out of sync. Therefore, related enhancement schemes need to be considered to handle the possible out-of-sync situation.

[0080] For the problem of out-of-sync in the joint discard mechanism of RLC AM sending and receiving packets, according to the latest progress of the discussion of the 3GPP organization, the joint discard scheme of RLC AM sending and receiving packets supports that the RLC AM sending end directly discards packets according to the PDCP indication without indicating to the receiving end, and the receiving end can also discard packets according to the receiving end timer. The sending end and the receiving end discard packets independently. As shown in FIG. 9, the RLC sending end can discard a large number of packets based on the indication of the PDCP layer, when the lower boundary TX_Next_ACK of the sending window is discarded, the sending window will move to the right. And the RLC receiving end can also discard packets based on the discard timer, when the lower boundary RX_Next of the receiving window is discarded or received, the receiving window will move to the right. It can be seen that in this joint discard mechanism of the sending end and the receiving end, the sending and receiving parties can independently move the window based on the discard, although the receiving end will feedback the RLC status report to the sending end based on the event trigger to make the sending end aware of the information of the receiving window, but the sending end window information cannot be known by the receiving end, which may cause the sending end to keep moving to the right, while the receiving end is always waiting for the data packets of the lower window, thereby causing serious out-of-sync.

[0081] For the problem of out-of-sync in the joint discard mechanism of RLC AM sending and receiving packets, according to the latest progress of the discussion of the 3GPP organization, the joint discard scheme of RLC AM sending and receiving packets supports that the RLC AM sending end directly discards packets according to the PDCP indication without indicating to the receiving end, and the receiving end can also discard packets according to the receiving end timer. The sending end and the receiving end discard packets independently. As shown in FIG. 9, the RLC sending end can discard a large number of packets based on the indication of the PDCP layer, when the lower boundary TX_Next_ACK of the sending window is discarded, the sending window will move to the right. And the RLC receiving end can also discard packets based on the discard timer, when the lower boundary RX_Next of the receiving window is discarded or received, the receiving window will move to the right. It can be seen that in this joint discard mechanism of the sending end and the receiving end, the sending and receiving parties can independently move the window based on the discard, although the receiving end will feedback the RLC status report to the sending end based on the event trigger to make the sending end aware of the information of the receiving window, but the sending end window information cannot be known by the receiving end, which may cause the sending end to keep moving to the right, while the receiving end is always waiting for the data packets of the lower window, thereby causing serious out-of-sync.

[0082] The above analysis shows that the RLC AM receiver's packet dropping mechanism can experience synchronization issues, but it can recover on its own. However, another issue to consider is that the sliding of the RLC AM receiver window maintains several variables (as shown in Figure 11): RX_Next, RX_Next_Status_Trigger, RX_Highest_Status, and RX_Next_Highest. Since the receiver's packet dropping needs to be based on a new timer (different from the existing reassembly timer T-reassembely), the new timer will affect the updates of existing timers and receiver window variables. Therefore, it is necessary to reconsider the receiver window variable update mechanism after introducing a drop timer at the RLC AM receiver.

[0083] This application, building upon existing RLC AM transceiver entities' support for autonomous packet dropping, introduces support for handling synchronization issues caused by packet dropping within the transceiver window at the RLC AM transceiver end. This includes mechanisms such as the sender instructing the receiver to indicate dropping information, the sender dropping packets based on the receiver's dropping instruction response, the sender periodically or trigger-based instructing the receiver to provide synchronization information, the sender repeatedly transmitting dropping instructions, and the receiver providing dropping instruction feedback. It should be understood that the embodiments of this application can also be applied to other systems or modes employing similar sliding window mechanisms besides RLC AM.

[0084] Figure 12 shows a flowchart of a method for adjusting the sending and receiving windows according to an embodiment of this application. As shown in Figure 12, the method includes operations S101 to S106.

[0085] In S101, the sending end sends an indication of the packet loss status to the receiving end, and the receiving end receives the indication of the packet loss status from the sending end.

[0086] Taking RLC AM mode as an example, the transmitter can send an RLC AM discard status indication report to the receiver. When the RLC AM transmitter discards data that has already been transmitted (after which RLC sequence numbers have been assigned and delivered to the MAC layer), the transmitter can indicate the discarded outdated data sequence number (SN) information to the receiver through the discard status report, preventing the transmitter and receiver windows from falling out of sync.

[0087] In some embodiments, the content of the discard status indication report may indicate valid data packets (i.e., data packets that were not discarded by the sender). Specifically, the data packet discard status indication may include one or more valid data packet sequence number indications, which are used to indicate the sequence numbers of one or more valid data packets after the sender performs data packet discarding.

[0088] Optionally, the indication of the packet discard status can further comprise a last valid packet sequence number indication for indicating a sequence number of a last valid packet or a sequence number of a next packet of the last valid packet among all the transmitted packets after the packet discard is performed by the transmitting end. Alternatively, the indication of the packet discard status can further comprise a last discarded packet sequence number indication for indicating a sequence number of a last discarded packet or a sequence number of a next packet of the last discarded packet among all the transmitted packets after the packet discard is performed by the transmitting end.

[0089] Optionally, the indication of the packet discard status can further comprise one or more valid packet range sequence number indications corresponding to the one or more valid packet sequence number indications respectively for indicating one or more valid packet ranges from the one or more valid packets respectively. When the indication report comprises a plurality of valid packet sequence numbers and a plurality of valid packet range sequence numbers, the plurality of valid packet sequence numbers and the plurality of valid packet range sequence numbers correspond to each other respectively. The valid packet range sequence numbers indicate a range of one or more valid packets from a corresponding valid packet respectively.

[0090] For example, assume that the transmitting end transmits 10 packets to the receiving end with sequence numbers 1 to 10 respectively, and the transmitting end performs packet discard to discard packets 2, 3, 4 and 5. In the discard status indication report, the valid packet sequence number indication {1, 6, 7, 8, 9, 10} can be included. Alternatively, the valid packet sequence number indication {1, 6, 7, 8, 9} and the last valid packet sequence number indication {10} can be included in the discard status indication report. Alternatively, the valid packet sequence number indication {1, 6, 7, 8, 9, 10} and the last discarded packet sequence number indication {5} can be included in the discard status indication report. Alternatively, the valid packet sequence number indication {1, 6} and the valid packet range sequence number indication {4} associated with the valid packet {6} can be included in the discard status indication report, where the valid packet range sequence number {4} indicates that the four packets after the 6th packet are all valid packets.

[0091] Figure 14 shows an example of discard status indication report indicating valid data packets. Field CPT indicates that this message is RLC control data. Field LastSend_SN indicates the RLC SN of the last valid data packet among all the valid data packets of the data packets that have been sent or assigned RLC SNs by the current sender after the sender performs data packet discard. Upon receiving this field, the receiver can consider that there is at least one or more data packet discards by the sender before the LastSend_SN. Field Send_SN indicates the valid data packet SNs before the LastSend_SN. It is noted that Send_SN can be multiple since the data packets that can be discarded at one time can not be all, i.e. there can be multiple valid data packets before the LastSend_SN. Field Send Range indicates the range of valid data packet SNs before the LastSend_SN. Upon receiving this field, the receiver can consider that the data packets starting from Send SN and including the consecutive number of Send Range are all valid data packets.

[0092] In addition to the example of Figure 14, the RLC discard status indication report can also be in the form of a combination of valid data packet SNs and the last discarded data packet SN. For example, the report can include fields LastDiscard_SN, Send_SN and Send Range. Field LastDiscard_SN indicates the RLC SN of the data packet with the largest SN among the discarded data packets after the current sender performs data packet discard on the data packets that have been sent or assigned RLC SNs. Upon receiving this field, the receiver can consider that there is at least one or more data packet discards by the sender before the LastDiscard_SN. Field Send_SN indicates the valid data packet SNs before the LastSend_SN. It is noted that Send_SN can be multiple since the data packets that can be discarded at one time can not be all, i.e. there can be multiple valid data packets before the LastSend_SN. Field Send Range indicates the range of valid data packet SNs before the LastSend_SN. Upon receiving this field, the receiver can consider that the data packets starting from Send SN and including the consecutive number of Send Range are all valid data packets.

[0093] In some other embodiments, the content of the discard status indication report can indicate discarded data packets (or referred to as invalid data packets, i.e. data packets discarded by the sender). Specifically, the data packet discard status indication can include one or more discarded data packet sequence number indications for indicating the sequence number of one or more discarded data packets by the sender after performing data packet discard.

[0094] Optionally, the indication of the packet discard status can further comprise a last valid packet sequence number indication for indicating a sequence number of a last valid packet or a sequence number of a next packet of the last valid packet among all the transmitted packets after the packet discard is performed by the transmitting end. Alternatively, the indication of the packet discard status can further comprise a last discarded packet sequence number indication for indicating a sequence number of a last discarded packet or a sequence number of a next packet of the last discarded packet among all the transmitted packets after the packet discard is performed by the transmitting end.

[0095] Optionally, the indication of the packet discard status can further comprise one or more discarded packet range sequence number indications corresponding to the one or more discarded packet sequence number indications respectively for indicating one or more discarded packet ranges from the one or more discarded packets respectively.

[0096] For example, assume that the transmitting end transmits 10 packets to the receiving end with sequence numbers 1 to 10, and the transmitting end performs packet discard to discard packets 2, 3, 4 and 5. In the discard status indication report, the discarded packet sequence number indication {2, 3, 4, 5} can be included. Alternatively, the discarded packet sequence number indication {2, 3, 4} and the last discarded packet sequence number indication {5} can be included in the discard status indication report. Alternatively, the discarded packet sequence number indication {2, 3, 4, 5} and the last valid packet sequence number indication {10} can be included in the discard status indication report. Alternatively, the discarded packet sequence number indication {2} and the discarded packet range sequence number indication {3} associated with the discarded packet {2} can be included in the discard status indication report, where the range sequence number indicates that the 3 packets after the 2nd packet are discarded packets.

[0097] Figure 15 shows an example of the discard status indication report indicating discarded data packets. The field CPT indicates that the message is RLC control data. The field LastDiscard_SN indicates the RLC SN of the largest data packet among the discarded data packets after the current sender discards data packets with already sent or assigned RLC SNs. When the receiver receives this field, it can be considered that there is at least one or more discarded data packets before the data packet with the RLC SN of LastDiscard_SN. The field Discard_SN indicates the SNs of other discarded data packets before LastDiscard_SN. It should be noted that there can be multiple Discard_SNs because there can be multiple data packets discarded at one time. The field Discard Range indicates that multiple data packets after the discarded data packet with Discard_SN are discarded. The discarded data packets after Discard_SN are indicated by Discard Range. When the receiver receives this field, it can be considered that the data packets from Discard SN to Discard Range are discarded data packets.

[0098] In addition to the example of Figure 15, the RLC discard status indication report can also be in the form of a combination of discarded data packet SNs and the SN of the last valid data packet. For example, the report can include the fields LastSend_SN, Discard_SN and Discard Range. The field LastSend_SN indicates the RLC SN of the last valid data packet among all the sent data packets after the current sender discards data packets with already sent or assigned RLC SNs. When the receiver receives this field, it can be considered that there is at least one or more discarded data packets before the data packet with the RLC SN of LastSend_SN. The field Discard_SN indicates the SNs of other discarded data packets before LastDiscard_SN. It should be noted that there can be multiple Discard_SNs because there can be multiple data packets discarded at one time. The field Discard Range indicates that multiple data packets after the discarded data packet with Discard_SN are discarded. The discarded data packets after Discard_SN are indicated by Discard Range. When the receiver receives this field, it can be considered that the data packets from Discard SN to Discard Range are discarded data packets.

[0099] It should be understood that the sender can indicate the discarded data packets or the valid data packets in addition to the range indication by using a bitmap or the like, which is not limited in the present application.

[0100] In some embodiments, the indication of the discard status of the data packets can be used to indicate the first sent data packet to be acknowledged other than the discarded data packets. That is, the indication of the discard status can include the TX_NEXT_ACK, the minimum SN of the next data packet to be acknowledged, in the sending window. This parameter can be used by the receiving end to align the lower boundary of the receiving window.

[0101] In S102, the sending end listens to the feedback of the discard status of the data packets from the receiving end.

[0102] After sending the discard status of the data packets, the sending end can wait for the corresponding feedback from the receiving end.

[0103] Optionally, the sending end can start a listening timer at the same time of sending the discard status indication report or after sending the discard status indication report, and wait for the feedback of the discard status indication report of the RLC AM receiving end within the time limit of the listening timer.

[0104] In S103, the receiving end adjusts the data packet receiving window.

[0105] After receiving the discard status indication, the receiving end can adjust the data packet receiving window based on the discard status indication, for example, by updating one or more variables related to the receiving window to move the window. Also, the receiving end can discard data packets accordingly. For different types and forms of the discard status indication report, the receiving end can have multiple ways of adjusting the data packet receiving window.

[0106] In one way, the discard status indication is used to indicate the valid data packets, and includes the parameter LastSend_SN. When the receiving end receives the RLC discard status report sent by the sending end, it can determine the valid data packet information according to the related fields in the report. If the data packet with SN less than LastSend_SN is not indicated as a valid data packet in the status report, it is considered as an invalid data packet discarded by the sending end or a data packet to be discarded. Further, the receiving end determines whether RX_Next of its window variable is a valid data packet or a discarded data packet. If RX_Next is a valid data packet, the receiving end will continue to wait for the data packet. If RX_Next is a discarded data packet, the receiving end immediately moves the receiving window, and updates RX_Next to the SN of the next valid data packet that has not been completely received after the original variable RX_Next.

[0107] In one mode, the discard status indication is used to indicate valid data packets, and includes a parameter LastDiscard_SN. When the receiving end receives the RLC discard status report sent by the sending end, it can determine the valid data packet information according to the relevant fields in the report. If the data packet with SN less than LastDiscard_SN is not indicated as a valid data packet in the status report, it is considered to be an invalid data packet discarded by the sending end or a data packet to be discarded. Further, the receiving end determines whether its window variable RX_Next is a valid data packet or a discarded data packet. If RX_Next is a valid data, the receiving end will continue to wait for the data packet. If RX_Next is a discarded data packet, the receiving end immediately moves the receiving window and updates RX_Next to the SN of the next valid data packet that has not been completely received after the original variable RX_Next. Alternatively, the updated value of RX_Next can be before (i.e. indicated) Last SN, or after.

[0108] In one mode, the discard status indication is used to indicate discarded data packets, and includes a parameter LastDiscard_SN. When the receiving end receives the RLC discard status report sent by the sending end, it can determine the discarded data packet information according to the relevant fields in the report. If the data packet within the receiving window with SN less than LastDiscard_SN is not indicated as a discarded data packet in the status report, it is considered to be a valid data packet sent by the sending end. If it is a data packet outside the window, the receiving end considers it to be a discarded data packet. Further, the receiving end determines whether its window variable RX_Next is a valid data packet or a discarded data packet. If RX_Next is a valid data, the receiving end will continue to wait for the data packet. If RX_Next is a discarded data packet, the receiving end immediately moves the receiving window and updates RX_Next to the SN of the next valid data packet that has not been completely received after the original variable RX_Next.

[0109] In one approach, the discard status indication is used to indicate discarded data packets and includes a parameter LastSend_SN. When the receiving end receives the RLC discard status report sent by the sending end, it can determine the discarded data packet information according to the relevant fields in the report. If the SN of a data packet is less than the data packets in the acceptance window of LastSend_SN, it is considered that the data packet is a valid data packet sent by the sending end if it is not indicated as a discarded data packet in the status report. If the data packet is outside the window, the receiving end considers it to be a discarded data packet. Further, the receiving end determines whether its window variable RX_Next is a valid data packet or a discarded data packet. If RX_Next is a valid data packet, the receiving end continues to wait for the data packet. If RX_Next is a discarded data packet, the receiving end immediately moves the acceptance window and updates RX_Next to the SN of the next valid data packet that has not been completely received after the original variable RX_Next.

[0110] Of course, if the discard status indication directly indicates all valid / invalid data packets, the receiving end can directly determine whether its window variable RX_Next is a valid / invalid data packet according to the received indication and adjust the window accordingly.

[0111] In addition, other relevant variables of the receiving window can also be adjusted according to the received discard status indication. For example, if RX_Next_Highest is indicated to be discarded, RX_Next_Highest is updated to the SN of the valid data packet with the largest SN in the acceptance window waiting for the receiving end to confirm, or to the SN of the next SN after the largest data packet SN that is newly received. Alternatively, if RX_Next is indicated to be discarded, RX_Next is updated to the SN of the first valid data packet to be completely accepted in the acceptance window with a SN greater than the original RX_Next. Alternatively, if RX_Highest_Status is indicated to be discarded, RX_Highest_Status is updated to the SN of the first valid data packet to be completely received in the acceptance window with a SN greater than the original RX_Highest_Status.

[0112] In S104, the receiving end sends feedback of the data packet discard status to the sending end.

[0113] Corresponding to the adjustment of the receiving window, the receiving end can send feedback of the data packet discard status to the sending end. It should be noted that the order of performing the action of sending the feedback message and the action of adjusting the receiving window is not limited. For example, the receiving end can first adjust the receiving window and then send feedback of the data packet discard status accordingly, or the receiving end can first send feedback of the data packet discard status and then adjust the parameters of the receiving window accordingly. Alternatively, the two operations can be performed simultaneously.

[0114] In some embodiments, the feedback message can be a data packet status report, such as an RLC status report. For data packets that have been sent by the sending end but are considered to have been or will be discarded by the sending end according to the discard status indication, they are indicated as acknowledged (ACK) in the status report; for data packets that have been sent by the sending end and are considered to be valid according to the discard status indication, their status is indicated as not acknowledged (NACK) in the report. When the sending end receives the data packet status report, the sending end determines whether the data packet status report is feedback of the indication of the data packet discard status according to the acknowledged ACK and / or not acknowledged NACK status of the data set received in the data packet status report. Specifically, the sending end can compare the discard set of the discarded data packets with the ACK set, and if the data packet SN information of the ACK set fed back by the receiving end is a subset of the data packet SN information of the discard set of the sending end, or is matched (i.e., the data packets indicated by the sending end to be discarded are no longer indicated as NACK in the data packet status report by the receiving end), the sending end considers that the receiving end confirms to have received the discard indication, and the sending end can slide the window to the right. Otherwise, the sending end can consider that the receiving end does not accept the discard indication.

[0115] In some embodiments, the indication of the data packet discard status includes a last valid data packet sequence number indication, and the feedback includes the last valid data packet sequence number indication; or the indication of the data packet discard status includes a last discarded data packet sequence number indication, and the feedback includes the last discarded data packet sequence number indication. For example, if the indication of the discard status includes LastDiscard_SN, and the sending end receives a response control message containing the LastDiscard_SN, the sending end considers that the feedback of the discard status indication is received; or if the indication of the discard status includes LastSend_SN, and the sending end receives a response control message containing the LastSend_SN, the sending end considers that the feedback of the discard status indication is received. This embodiment is also applicable to the case where multiple data packet discard status indications exist at the same time, and by comparing the sent LastDiscard_SN / LastSend_SN and the received LastDiscard_SN / LastSend_SN in the control message, the sending end can confirm which data packet discard status indication of the sent ones the control message corresponds to. FIG. 16 shows an example of a feedback message of a data packet discard status indication containing LastDiscard_SN or LastSend_SN. FIG. 17 shows another example of a feedback message of a data packet discard status indication containing LastDiscard_SN or LastSend_SN.

[0116] In some embodiments, the feedback message can include a 1-bit acknowledgement indication. For example, the acknowledgement indication can be included in one of the following: a dedicated discard response control packet, a radio link control (RLC) status report, or a pending data packet subheader. In other words, the receiving end can use 1 bit in the feedback message to indicate "received" or "not received" packet discard status indication. Figure 18 shows an example of a control protocol data unit (AMD PDU) carrying the discard indication reception feedback, in which the field with value shown as Ack can be used to indicate that the packet discard status indication is acknowledged.

[0117] It should be appreciated that the foregoing several ways can be applied individually or in combination. For example, the ACK, LastSend_SN, and LastDiscard_SN described above can be included in the packet subheader at the same time as the feedback of the packet discard status.

[0118] In S105, in response to receiving the feedback, the sending end adjusts the packet sending window.

[0119] When the feedback of the packet discard status indication is acknowledged, the sending end can adjust the packet sending window. Specifically, the lower boundary of the sending window can be changed to correspond to the first sent packet to be acknowledged other than the discarded packet.

[0120] According to the provided sending window and receiving window adjustment method of the present embodiment, when the sending end discards a packet, the sending end sends the receiving end an indication of the packet discard status, and after acknowledging the feedback from the receiving end, the sending end adjusts the packet sending window. Accordingly, the receiving end adjusts the packet receiving window according to the received indication of the packet discard status. By implementing the present method, the out-of-sync problem of the transmission windows of the sending and receiving ends caused by the sending end discarding a packet can be avoided or mitigated, for example, in the RLC AM mode.

[0121] Figure 13 shows a sending window and receiving window adjustment method according to another embodiment of the present application. Based on the method shown in Figure 12, the method of the present embodiment further considers the case where the sending end does not receive the feedback of the packet discard status indication from the receiving end. The steps of the present method that are the same as or similar to the foregoing method will not be described again. The method shown in Figure 13 includes the following steps:

[0122] 1) The sending end discards an outdated packet.

[0123] 2) The sending end indicates the discard status to the receiving end. For example, the RLC AM sending end can send the RLC AM receiving end a data control packet: RLC discard status indication report.

[0124] 3) Optionally, the sender moves the sending window. If the packet indicated by the TX_Next_ACK variable at this time has been discarded, the RLC AM sender can decide to slide the sending window. Of course, if the packet discard status indicates that the packet indicated by TX_Next_ACK has not been discarded, the sender can not slide the sending window.

[0125] 4) Optionally, the sender starts a listening timer (or waiting timer). The sender can start a listening timer when sending the discard indication report and wait for a receiving response of the discard indication report from the RLC AM receiver.

[0126] 5) The sender determines whether the receiver is subject to the discard status indication.

[0127] 6) If it is confirmed that the receiver is subject to the discard status indication, the sender stops the timer and moves the sending window.

[0128] 7) If it is not confirmed that the receiver is subject to the discard status indication, the sender determines whether it is subject to a polling message from the receiver. That is, the receiver can autonomously send a polling message to the sender, and the polling message is used to request the sender for an indication of the packet discard status.

[0129] 8) In response to receiving the polling message from the receiver, the sender transmits the indication of the packet discard status to the receiver. Alternatively, in response to not receiving the feedback and the listening timer expiring, the sender transmits the indication of the packet discard status to the receiver.

[0130] In some embodiments, if the sender transmits the indication of the packet discard status belongs to retransmission, the sender adjusts the packet sending window after transmitting the indication of the packet discard status to the receiver, without waiting for the feedback from the receiver. In addition, if the sender performs packet discard again between two transmissions, the sender can update the indication of the packet discard status according to the latest packet discard before retransmitting the indication of the packet discard status.

[0131] In some embodiments, after the RLC AM sender sends the discard indication information to the receiver, if the sender does not receive the feedback from the receiver matching the confirmation response until the listening timer of the discard indication expires, the sender re-sends the RLC discard indication information (updated). In this scenario, the RLC AM sender can slide the window and update the variables due to the packet discard, and then re-indicate the previous RLC discard indication information. The retransmitted RLC discard indication information is based on the latest discard indication. FIG. 19 shows an example of retransmission of the discard indication information by the RLC AM sender.

[0132] In some embodiments, after the RLC AM sender sends the discard indication information to the receiver, and during the process of waiting for the receiver's feedback of the discard indication response, the sender receives the receiver's query message (indicating the sender to send the discard indication information), then the sender also re-sends the RLC discard indication information (updated). If the sender's listening timer is running at this time, the listening timer is stopped. Or at any time the sender receives the receiver's query, the sender also sends the RLC discard indication information in time. Figure 20 shows an example of the RLC sender sending the discard indication information (Tx_Status) according to the receiver's query message.

[0133] The RLC receiver can send the query message autonomously when it needs to know the receiver's data packet discard situation. Or the receiver can also determine the conditions for sending the query message in advance. For example, the conditions for the receiver to send the query message can include at least one of the following:

[0134] 1) The remaining delay of the discard timer of the lower boundary of the data packet receiving window is less than the preset delay, that is, the remaining delay of the receiver's discard timer of RX_Next is less than the preset threshold value, which can be the timeout warning delay threshold configured by the network side or the fixed preset threshold.

[0135] 2) The number of low-delay-required data in the receiver's buffer is greater than the preset number, that is, the total number of time-critical data in the receiver's window buffer is greater than the preset threshold, which can be the quotient of the total amount and total byte threshold of the timeout warning threshold configured by the network side, wherein the receiver's time-critical data can be determined as data whose remaining delay of the discard timer is less than the threshold (for example: the timeout warning delay threshold configured by the network side).

[0136] 3) The number of data packets with unconfirmed NACK feedback in the data packet receiving window is greater than the preset threshold. The preset threshold can be the quotient of the total amount and total NACK threshold of the timeout warning NACK times configured by the network side.

[0137] Figure 21 shows an example of the query message sent by the receiver. The field P2 is used for the RLC receiver to request the sender to feedback the data packet discard status indication. In some embodiments, the query message is also used to indicate the range of the queried data packets. For example, the query message can also include the query sequence number (Poll_SN), which is used by the RLC receiver to indicate the sender to feedback the discard and / or sending information of the data packets before POLL_SN. After receiving the query message, the sender can feedback the sender's data packet discard status indication to the receiver in the next transmission opportunity.

[0138] According to the method of the embodiment, the sending end can transmit or retransmit the indication of the packet discard state in response to the query message from the receiving end or in response to the timeout of the listening timer, thereby avoiding the out-of-sync between the sending window of the sending end and the receiving window of the receiving end when the sending end discards the packets. The method can increase the transmission reliability of the discard indication of the sending end. The receiving end also informs the sending end of the subsequent possible timeout discard of the packets to some extent. The sending end can also discard the packets of the sending end according to the indication.

[0139] In the joint packet discard mechanism of the RLC AM sending end and receiving end, since the sending end does not indicate the discard information to the receiving end, the RLC AM sending end packet autonomous discard for sending window moving and the receiving window not being aware of the window moving can cause the RLC AM sending and receiving window out-of-sync problem. Since the receiving end continuously feeds back the RLC status report to the sending end in the RLC AM mode, the sending end can perceive the information of the receiving window, so as long as the moving of the sending window is consistent with the receiving window out-of-sync, the problem can be avoided. Accordingly, another embodiment of the application provides a method for adjusting the sending window of the sending end and the receiving window of the receiving end. As shown in FIG. 22, the method includes operations S201 to S203.

[0140] In S201, the sending end sends the window synchronization information to the receiving end, and the receiving end receives the window synchronization information.

[0141] The window synchronization message is used to indicate one or more parameters of the sending window of the sending end, for example, the indication of the lower boundary sequence number (SN) information of the sending window. These parameters can be referred to as synchronization indication. In other examples, the window synchronization message can also indicate the adjustment value of the sending window related parameter.

[0142] In some embodiments, the sending end sends the window synchronization information to the receiving end according to a preset period. In this case, the sending end needs to maintain a period timer. The sending end starts a period timer when starting to send the packets, and indicates the synchronization indication information when the timer is timed out. Then, the sending end starts a timer again, and sends the synchronization indication again when the timer is timed out. As shown in FIG. 24, it is to be noted that if the sending end has determined that the sending and receiving ends are synchronized through the RLC status report of the receiving end, the sending end can not send the synchronization indication.

[0143] The synchronization information can be carried in a subheader of a next data packet to be sent by the sending end, or the sending end can indicate the synchronization information to the receiving end through a new RLC control PDU. FIG. 25 shows an example of the synchronization information. The field Sync_SN represents the SN of the data packet of the window boundary TX_Next_ACK of the RLC sending end, and is used to inform the receiving end about the moving of the sending end window. Optionally, the field can also be the maximum SN of the latest data packet sent by the sending end, i.e., the SN corresponding to the TX_Next variable, and is used to inform the receiving end about the sending end.

[0144] In some embodiments, the sending end performs data packet discard, and sends the window synchronization information to the receiving end in response to the data packet discard. That is, the sending end sends the window synchronization information to the receiving end as long as it performs data packet discard, regardless of whether the parameters of the sending window are affected by the data packet discard.

[0145] In some embodiments, the sending end obtains the data packet reception status from the receiving end, and sends the window synchronization information to the receiving end when it is determined based on the data packet reception status that the data packet sending window is not synchronized with the data packet reception window of the receiving end. Specifically, the RLC AM sending end receives the status report of the RLC receiving end, and then determines the ACK data set indicating the data packets with ACK based on the receiving end RLC status report. Then the sending end compares the discard set of the data packets to be discarded with the ACK set, and if the SN information of the data packets of the ACK set fed back by the receiving end is a subset of the SN information of the data packets of the discard set of the sending end, it means that the sending end and the receiving end are synchronized, and the sending end does not need to send the window synchronization information and slide the window to the right. Otherwise, the sending end determines that the sending window and the receiving window are not synchronized, and the sending end window does not move and the window synchronization information is sent.

[0146] In S202, the sending end adjusts the data packet sending window. The window synchronization information corresponds to the adjustment of the data packet sending window.

[0147] It should be understood that not every window synchronization information has a corresponding sending window adjustment. For example, in some modes, the window synchronization information is periodically transmitted instead of being transmitted in response to data packet discard or window desynchronization.

[0148] In addition, the order of the operation of the sending end to adjust the sending window and the operation of the sending end to send the window synchronization information is not limited.

[0149] In S203, the receiving end adjusts the receiving window based on the window synchronization information.

[0150] The receiving end can update the receiving window according to the moving of the lower boundary window of the sending end after receiving the synchronization indication of the sending end. For example, when it is found that the window of the sending end has moved to the right of the receiving window (it can also be on the left of the receiving end, for example, in the scenario of SN rollover), that is, the receiving end perceives that the window of the sending end has moved, the receiving end can determine that the data packet of RX_Next has been discarded by the receiving end, and based on this, the receiving end can also timely move the window to keep the synchronization of the windows of the sending end and the receiving end.

[0151] It should be understood that not every time the window synchronization information corresponds to the adjustment of the receiving window. If the parameters of the sending window indicated in the window synchronization information have no change, or the parameters of the sending window have a change but do not affect the result of the receiving end feeding back the receiving state of the data packet, the receiving window does not need to be adjusted.

[0152] FIG. 23 shows a flowchart of another window adjustment method applying the window synchronization information. As shown in FIG. 23, after the RLC AM sending end discards the data packet, the sending end indicates the synchronization information to the receiving end; or the synchronization information can also be periodically indicated. Further, the sending end receives the data receiving state report (such as the RLC status report) from the receiving end, and if it is determined that the discarded data set of the sending end is a subset of the ACK set of the receiving end, the sending end updates the sending window variable and moves the sending window; if it is determined that the discarded data set of the sending end is not a subset of the ACK set of the receiving end, the action of indicating the synchronization information to the receiving end is triggered.

[0153] The foregoing method introduces the mechanism of indicating the synchronization indication information from the sending end to the receiving end, which helps to solve the perception of the receiving end to the position of the sending window in the scenario of joint autonomous discarding of the sending end and the receiving end, and further solves the out-of-sync problem, and realizes the synchronized data transmission of the sending window and the receiving window in the scenario.

[0154] In the data packet discarding mechanism of the RLC AM receiving end, the windows of the sending end and the receiving end will have the out-of-sync problem, but will also recover by themselves. Therefore, the out-of-sync problem in the mechanism scheme does not need to be additionally enhanced, but in the mechanism scheme, a discarding timer is newly introduced to control the time of each received data packet in the buffer of the receiving end, and the timer has an influence on the sliding of the existing receiving window, especially when the discarding timer T-timer of the lower boundary RX_Next of the receiving window expires, the window of the receiving window will be moved, and therefore the variable of the receiving end will be updated. Based on this, the application also provides a method for adjusting the sending window and the receiving window, as shown in FIG. 26, which includes operations S301 to S303.

[0155] In S301, the receiving end sends the receiving state of the data packet to the sending end, and the sending end receives the receiving state of the data packet from the receiving end.

[0156] The data packet reception status can indicate the reception status of the data packet at the receiving end, such as an acknowledgement (ACK) or a non-acknowledgement (NACK). In the RLC AM mode, the data packet reception status can be carried in the RLC status report.

[0157] In some embodiments, the receiving end sends the data packet reception status to the sending end in response to the discarding of the data packet, and the reception status of the discarded data packet is indicated as an acknowledgement (ACK).

[0158] In some embodiments, when the discard timer of the data packet corresponding to the lower boundary of the data packet reception window of the receiving end expires, and the reassembly timer of the data packet corresponding to the lower boundary of the data packet reception window is still running, the receiving end adjusts the data packet reception window and sends the data packet reception status to the sending end.

[0159] The lower boundary of the reception window can start a reassembly timer T-reassembly (e.g. in the case of RX_Next_Highest > RX_Next + 1), and the acceptance window RX_Next can also start a discard timer T-discardtimer (e.g. when RX_Next receives part of the data fragments but not all of the entire data packet). The discard timer T-discard can correspond to one data packet or multiple data packets (such as a data set, etc.) of the receiving end. The starting condition of the discard timer T-discardtimer is that the RX_Next fragment or the group of data parts containing RX_Next is received, and the stopping condition of the discard timer T-discardtimer is that the entire data of RX_Next or the group of data containing RX_Next is received. As shown in FIG. 28, when the discard timer T-discardtimer expires and the reassembly timer T-reassembly is still running, the receiving end can decide to discard the RX_Next data packet, or no longer wait for the reception of the data packet. Alternatively, in response to the expiration of the discard timer, the receiving end can discard the data packet with a SN greater than RX_Next. Alternatively, the receiving end can also discard the associated data packet (e.g. if the receiving end can understand the association between the data packets / data sets of the receiving end, when a data packet in a data set is discarded, the associated data packets are also discarded). In this case, the receiving end can send a data packet reception status report to the sending end.

[0160] Conversely, if the reassembly timer T-reassembly expires while the discard timer T-discard is still running, the receiver processes the received data as in the conventional processing mechanism, i.e. updates the variable to trigger the status report feedback. The received data is discarded only when the discard timer T-discard expires.

[0161] In S302, the sender adjusts the data packet sending window according to the data packet receiving status.

[0162] Specifically, when the receiving status of the data packet corresponding to the lower boundary of the data packet sending window is ACK, the lower boundary of the sending window is changed to correspond to the first subsequent sent data packet to be acknowledged.

[0163] Conversely, when the receiving status of the data packet corresponding to the lower boundary of the data packet sending window is NACK, the sender does not perform the operation of adjusting the data packet sending window.

[0164] In S303, the receiver adjusts the data packet receiving window.

[0165] The receiver can adjust the lower boundary of the data packet receiving window to correspond to the first valid data packet to be received after the original corresponding data packet. In other words, the lower boundary RX_Next of the receiver window is moved to update to the SN of the first data packet that has not been completely received after the original RX_Next (excluding the discarded data packet).

[0166] In some embodiments, other variables of the receiving window can be further updated. For example, the parameter RX_Highest_Status of the data packet receiving window is adjusted to correspond to the first valid data packet to be received after the original corresponding data packet, i.e. if RX_Next_Highest is discarded, RX_Next_Highest is updated to the SN of the data packet with the largest SN in the receiving window waiting for the receiver, or is updated to the SN of the next SN of the largest data packet received. For example, the parameter RX_Next_Highest_Status of the data packet receiving window is adjusted to correspond to the first valid data packet to be received after the original corresponding data packet, i.e. if RX_Highest_Status is discarded, RX_Highest_Status is updated to the SN of the first data packet to be completely received in the receiving window with a SN greater than the original RX_Highest_Status.

[0167] Optionally, if RX_Highest_Status < RX_Next, update RX_Highest_Status to the SN of the first data packet with all segments received for which RX_Next_Status_Trigger is >= RX_Next_Status_Trigger.

[0168] Optionally, according to the possible update of RX_Highest_Status (corresponding to the value of "ACK_SN" in the RLC status report), the receiving end feeds back the latest RLC status report to the sending end, wherein the data packets discarded by the receiving end are indicated as ACK by default, i.e., the indication not displayed is NACK.

[0169] Optionally, if: 1) RX_Next_Highest > RX_Next+1; or 2) if RX_Next_Highest = RX_Next+1 and at least one segment byte is missing before the last byte of all received segments related to the SDU with sequence number RX_Next; or 3) if RX_Next_Highest > RX_Highest_Status+1; or 4) if RX_Next_Highest = RX_Highest_Status+1 and at least one segment byte is missing before the last byte of all received segments related to the SDU with sequence number RX_Highest_Status, the receiving end starts the t-Reassembly timer and sets RX_Next_Status_Trigger to the current largest sequence number variable RX_Next_Highest.

[0170] Figure 27 shows another method flow diagram of the receiving end variable update based on discarding and the mechanism of feeding back the status report to the sending end. As shown in Figure 27, the RLC AM receiving end entity starts a discarding timer T-timer for each accepted data packet segment, and optionally, starts a discarding timer for each accepted data packet segment. When the discarding timer T-timer of a data packet expires, if the data packet is a data packet not received completely in the receiving window, the data packet is discarded, and in addition, the continuous discarding of data packets can be supported. When the discarding timer T-timer of a data packet expires, if the data packet is the lower boundary RX_Next of the receiving window, if the reassembly timer T-reassembly is still running, update RX_Next to the SN of the next data packet not received or not received completely, move the receiving window and update the variables of the receiving end, and stop the reassembly timer. After the receiving end discards the data packet, the receiving end triggers the feedback of the RLC status report to the sending end.

[0171] The foregoing method introduces a receiving end variable update based on discarding and a state report feedback mechanism to a sending end. The method comprises: when the receiving end discards a data packet due to a timer timeout, the receiving end stops a T-reassembly timer, updates a RX_STATUS_Highest variable, and feeds back an RLC state report based on variable update to the sending end, while discarding the data packet and moving an acceptance window. The problem of variable update when one of two timers started by the receiving end is timed out in a scenario of supporting autonomous discarding by the receiving end and the problem of discarding feedback by the receiving end are solved. The sending end can perceive discarding by the receiving end in this scenario, and thus the sending end sends data for synchronization of the sending window and the receiving window.

[0172] The application also provides a timer-based discarding mechanism of a receiving end. The receiving end receives a data packet of a receiving window every time, and if the data packet is a complete data packet, the data packet is delivered to a higher layer, and if the data packet is a fragment, a timer T-discard timer is started for the data packet. Considering real-time performance of the data packet, a discarding time of an un-received data packet between received data packets (a scenario of a received data packet of the receiving end having a hole) also needs to be defined. As shown in FIG. 29, the receiving end receives a fragment of a data packet SN=3 and a fragment of a data packet SN=10, and starts two discarding timers for the two data packets. A waiting time / discarding time of data packets SN=4 to SN=9 that have been sent by the sending end but not received by the receiving end needs to be determined, and starting of discarding timers of the data packets needs to be discussed.

[0173] A specific scheme of the timer-based discarding mechanism of the receiving end will be described as follows.

[0174] In scheme one, in an accepted data packet SN hole section, a preceding data packet is discarded and triggers a state report feedback of the receiving end when the preceding data packet times out, and a discarding timer of a following data packet is started. For example, a discarding timer of a data packet SN=3 times out, the data packet SN=3 is discarded, and an acceptance of the receiving end is fed back to the sending end. Meanwhile, a discarding timer of a data packet SN=4 is started, and if the discarding timer times out, the data packet SN=4 is discarded, an acceptance of the receiving end is fed back to the sending end, and a discarding timer of a data packet SN=5 is started.

[0175] In scheme two, in the accepted data packet SN hole section, when a discarding timer of a first data packet or a last data packet times out, data packets in the SN hole section are abandoned, and are directly discarded. Meanwhile, a state report feedback of the receiving end is triggered.

[0176] In scheme three, according to the difference between the remaining time of the discard timer of the first data packet and the last data packet in the received data packet SN hole segment, the number of hole data packets is determined, the remaining time of the discard timer of each hole data packet is determined, and the hole data packet is discarded according to the corresponding remaining time. For example, the data packet with SN = 3 has 100 ms left, and the data packet with SN = 10 has 170 ms left. Then, the remaining time of the data packet from SN = 3 to SN = 10 is inferred, such as the data packet with SN = 4 has 110 ms left, the data packet with SN = 5 has 120 ms left, the data packet with SN = 6 has 130 ms left, the data packet with SN = 7 has 140 ms left, the data packet with SN = 8 has 150 ms left, and the data packet with SN = 4 has 160 ms left. Then, the receiving end determines the time that the hole data packet needs to wait or starts the discard timer with the corresponding remaining time according to the remaining time. If the time is exceeded or the timer is exceeded, the data packet is discarded or abandoned, and the state report feedback of the receiving end is triggered.

[0177] The above-mentioned discard of the sending end or the receiving end is based on the discard of one data packet, that is, the granularity of the data packet. In actual situations, the XR data may have an association relationship of PDU Set (a data set containing multiple data packets). When the PSIHI (PDU Set integrity requirement) of a PDU Set of the sending end is enabled, the discard of one data packet will lead to the discard of the data packets of the entire PDU Set. In this scenario of data packet discard with PDU Set as granularity, the RLC transceiver needs to be enhanced, that is, to support a large number of data packet discard mechanisms to enhance the real-time performance of data processing. The specific scheme is described as follows.

[0178] The sending end needs to indicate the association relationship between the data packets in the data set to the receiving end. Since the 3GPP R18 XR standard project discusses not directly indicating the PDU SET SN (association relationship between data packets in the data set) information over the Uu air interface, but can be indirectly indicated.

[0179] As shown in FIG. 30, the SN of the last packet is indicated in the header of the first packet of the PDU Set data set supporting PSIHI processing.

[0180] The sending end behavior is as follows: when the sending end receives NACK for a data packet in a PDU Set supporting PSIHI processing, all data packets in the PDU Set are discarded. The RLC sending end no longer retransmits the data packets, and if the sending end window lower boundary TX_Next_ACK is discarded, the window lower boundary of the RLC sending window is also updated to the SN of the next data packet to be acknowledged.

[0181] Wherein, the receiving end behavior is: through accepting the information of the Nth data packet indicated by the first data packet in a certain PDU Set, the receiving end knows that the 1st to Nth data packets are a data set supporting PSIHI processing, when any data packet in the data set times out or the receiving end confirms NACK, discarding the received data packets in the entire data set, and giving up waiting for the un-received data packets. Meanwhile, the sending end lower window boundary RX_Next is discarded, and the receiving end window lower boundary of the RLC needs to be updated to the SN of the next data packet to be acknowledged.

[0182] In the above scheme, the sending end only needs to indicate the SN of the last data packet of the entire data set in the sub-header of the first data packet of the PDU Set. The possible problem is that when the first data packet is lost, the receiving end cannot perceive the data set information of the receiving end. Therefore, further enhancement can be considered: indicating the SN of the last data packet in the data packet sub-header of the first data packet of the sending end data set; indicating the SN of the first and last data packets in the data packet sub-header of the data packets in the sending end data set; or indicating the SN of the first data packet in the sub-header of the last data packet of the sending end data set.

[0183] In addition, the indication of supporting continuous discard processing can also be carried in the sub-header of the first data packet of the data set.

[0184] For uplink (UL) data transmission, the user equipment (UE) indicates the transmission model of XR service to a certain extent through the semi-static indication of UAI parameters such as burstArrivalTime and jitterRange, but cannot dynamically show the specific arrival time of the actual service.

[0185] Data service burst (Burst) may arrive periodically, but considering the jitter feature, the arrival time of Burst may have a certain deviation from the expected period. In addition, the service may also support dynamic period, if the data service period and jitter both change, the arrival of the service will become unpredictable. As shown in FIG. 31, the arrival of the periodic Burst3 of the service is accompanied by changes in jitter and period, and the arrival time becomes unpredictable for the receiving end. Therefore, it can be considered to indicate the information related to the UL service to the base station to assist the base station in scheduling. The following introduces the indication of the information about the uplink data of the UE to the base station.

[0186] The reporting content can include an indication of period change, time to next burst (TTNB), max data burst volume (MDBV), and offset. The indication of period change is dynamic indication of updated period information in the packet subheader of the previous burst. The TTNB is the time of arrival of the next burst, and the period information is dynamically updated in the packet subheader of the previous burst. The MDBV is the size of the maximum buffer size, and indicates the size of the real-time buffer size. The offset indicates the time difference between the arrival time of the next burst and the period time.

[0187] The reporting form can include: 1) through the data plane, such as through the PDCP packet header indication, or the BSR indication; 2) through the control plane, such as the uplink auxiliary information UAI indication; 3) through the combination of the control plane and the data plane, that is, part of the information is indicated through the control plane, and part of the information is indicated through the data plane; 4) the network side can configure the offset threshold, that is, when the period offset time of the burst arrival exceeds the offset threshold configured by the network, the UE reports the information such as TTNB.

[0188] In addition, in the multi-mode data transmission scenario, there is a synchronous association relationship between the UL multi-mode services, so it is necessary to consider indicating the synchronization related information of the uplink service to the base station to assist the base station in performing the synchronization scheduling of the UL data and improving the transmission performance of the uplink data. Specifically, through the uplink auxiliary information (UAI, UL Assistant Information) of the control plane (CP), the UE can report the following information to the base station: multi-mode service data indication, multi-mode service data identification and processing capability indication, multi-mode service data associated QoS flow ID information (such as QFI or MMSID), or multi-mode QoS flow to DRB mapping intention information (prefer flows-to-one-DRB mapping).

[0189] Through the packet subheader of the control plane or the UP, the UE can report the following information to the base station: the real-time transmission timestamp (relative time, sampling time unit) of the multi-mode data stream, the NTP timestamp (absolute time) of the real-time transmission control packet (RTCP) of the multi-mode data stream, or the multi-mode data synchronization source information SSRC.

[0190] In the newly passed standard related to delay status report (DSR), in order to support the base station to report the multiple sets of remaining time and buffer of one LCG (logical channel group), the network side configures multiple remaining time thresholds for each LCG of the UE. That is, in the DSR reporting process, one LCG has multiple remaining time reporting thresholds.

[0191] And for each LCG, there is only one trigger threshold. Since the trigger threshold and the reporting threshold are both remaining time information, the specific reporting of delay critical data and non-delay critical data needs to be considered in the case of different remaining time thresholds and reporting thresholds.

[0192] DSR reporting in multiple reporting threshold scenarios is specifically illustrated. For example, the trigger delay threshold is 3ms (packets with a remaining time of <3ms are judged as delay critical data, and packets with a remaining time of >3ms are judged as non-delay critical data), the reporting delay threshold is 5ms, 10ms (may also appear in the form of a range, such as threshold 1: [0-5ms), threshold 2: [5-10ms), etc.). In this case, in FIG. 32, the data in LCH1, LCH2, and LCH3 will all be reported. Among them, the sum of the data of LCH1 and LCH3 in the range of [0-5ms) delay, and the sum of the data of LCH2 in the range of [5-10ms) delay. Then the UE constructs a DSR and sends the DSR in the transmission resource. In this scenario, if there is not enough resource to send the DSR, the UE needs to send an SR, and the configuration of the SR depends on the LCH that triggers the DSR, for example, LCH1 in this scenario.

[0193] In addition, when reporting the data information in the specific reporting threshold range, it can be further considered how much the data amount of the reported data with high PSI is and how much the data amount of the reported data with low PSI is. Or only one of them is selected for reporting.

[0194] In addition, it also needs to consider the scenario when the LCH that triggers the DSR and the LCH that reports the DSR are different, that is, the LCHs that report the DSR do not contain the LCH that triggers the DSR. When an SR needs to be reported to apply for the resource of reporting the DSR, it is necessary to define which LCH associated SR configuration the selected SR configuration is. The specific scheme can consider the SR configuration of any one LCH in the LCG or consider the first LCH to report the remaining delay or data amount or the LCH in the LCG that triggers the DSR reporting.

[0195] The application also provides a method for indicating uplink congestion feedback.

[0196] According to the latest standard progress, when the uplink transmission is congested, the network side needs to feedback the uplink congestion information to the UE. Specifically, we can consider the following scheme to realize the uplink congestion indication notification of the network side to the UE.

[0197] Method one: indicating UL transmission congestion with DRB / LCH / LCG as granularity; the indication can be feedback through control message DL MAC CE or RRL or PDCP control PDU or RLC control PDU, or through data packet subheader indication. Optionally, it can also be indicated in the IP subheader of the data packet (similar to the two-bit indication of ECN), that is, directly indicating only congestion information.

[0198] Method two: congestion level indication, which can have the following several congestion level indications: 1) congestion warning: this is a preliminary congestion reminder indication (mild), used by the receiving end to notify the sending end that there may be preliminary uplink transmission congestion. The receiving end can feedback special bits with the data packet, or feedback together with the status report; the sending end receives the indication and immediately adjusts the possible sending rate according to the actual transmission; 2) congestion indication: this is an explicit congestion indication (moderate), the receiving end informs the uplink transmission that it has been congested but can still be processed. The indication can be feedback with special bits with the data packet, or feedback together with the status report; the sending end receives the indication and immediately adjusts the sending rate or discards unimportant data packets according to the actual transmission, or the sending end can also reduce unnecessary retransmission; 3) severe congestion: this is a serious congestion indication (severe), the receiving end informs the uplink transmission that it has been severely congested and cannot be processed. The indication can be feedback with special bits with the data packet, or feedback together with the status report; the sending end receives the indication and immediately discards data packets, such as data packets that have been transmitted but not yet confirmed. Or the sending end can also reduce unnecessary retransmission.

[0199] In addition, regarding the content of the UL congestion information feedback by the base station, in addition to the congestion level discussed above, it can also refer to the information of the existing flow control / congestion mechanism such as DDDS and ECN congestion feedback, such as:

[0200] ● The percentage of data radio bearer congestion level in UL

[0201] ● The required buffer size of data radio bearer

[0202] ● The required data rate

[0203] Summary: When the base station feedbacks the UL congestion information to the UE, the base station can feedback information such as: UL congestion level, required buffer size of data radio bearer, required data rate, etc.

[0204] In order to avoid frequent UL congestion feedback of the base station, the triggering mechanism of the UL congestion feedback needs to be considered. The event-triggered UL congestion feedback can be considered, such as the polling mechanism of the UE or when the base station detects that the UL congestion is serious congestion; in addition, the base station can periodically feedback the UL congestion situation to the UE. However, from the perspective of congestion control performance and signaling overhead, it is recommended to trigger the UL congestion feedback based on the event.

[0205] Further, when the congestion is released, the network side can further transmit the congestion release indication to the UE by controlling the message DL MAC CE or RRL or PDCP control PDU or RLC control PDU with DRB / LCH / LCG as the granularity, so as to avoid that the UE always transmits the UL data in the congestion mechanism to cause the low efficiency of the UL transmission. For example, the base station directly indicates the congestion release of the DRB by 1 bit in the DL MAC CE.

[0206] After the UE receives the congestion indication feedback by the base station, the following processing can be performed: discarding the received congestion indication, and discarding the data packet according to the PSI can be considered, for example, preferentially discarding the data packet with low PSI.

[0207] After the UE receives the congestion release indication feedback by the base station, the following processing can be performed: adjusting the transmission rate of the data packet of the sending end, and continuing to retransmit the data packet that has not been correctly transmitted.

[0208] FIG. 33 is a schematic block diagram of a communication device 400 provided by an embodiment of the present application. As shown in FIG. 33, the communication device 400 includes a processor 402 and a memory 404, and the processor 402 and the memory 404 are communicatively connected. The communication device 400 can be a sending end device or a receiving end device in any embodiment of the present application, for example but not limited to, a base station, a user equipment (UE), or other network elements. In some embodiments, the communication device 400 can further include a transceiver for sending / receiving data, or only include a sending circuit for sending data, or only include a receiving circuit for receiving data. The memory 404 of the communication device 400 is used to store program instructions, which can be executed by the processor 402 to implement the sending window or receiving window adjustment method described in any embodiment of the foregoing.

[0209] It should be understood that the processor of the embodiments of the present application can be an integrated circuit chip with a signal processing capability. In the implementation process, each step of the method embodiments described above can be completed by an integrated logic circuit or an instruction in the form of software in the processor.

[0210] It can be appreciated that the memory in the embodiments of the application can be a volatile or non-volatile memory, or can include both volatile and non-volatile memory. It should be noted that the memory of the system and method described herein is intended to include, but not be limited to, these and any other suitable type of memory. The embodiments of the application also provide a computer-readable storage medium for storing a computer program.

[0211] Optionally, the computer-readable storage medium can be applied to the communication device in the embodiments of the application, and the computer program causes the computer to execute the corresponding procedures realized by the communication device in the various methods of the embodiments of the application. For brevity, details are not repeated here. Alternatively, the computer-readable storage medium can be applied to the sending end device or the receiving end device in any of the embodiments of the application, and the computer program causes the computer to execute the procedures realized by the sending end device or the receiving end device in the various methods of the embodiments of the application. For brevity, details are not repeated here.

[0212] The embodiments of the application also provide a computer program product comprising computer program instructions.

[0213] Optionally, the computer program product can be applied to the communication device in the embodiments of the application, and the computer program instructions cause the computer to execute the corresponding procedures realized by the communication device in the various methods of the embodiments of the application. For brevity, details are not repeated here.

[0214] Those skilled in the art can appreciate that the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be realized in electronic hardware, or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the application.

[0215] The above is only a specific implementation of the application, but the protection scope of the application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the application, which should be covered within the protection scope of the application. Therefore, the protection scope of the application should be subject to the protection scope of the claims.

Claims

1. A method for adjusting a data packet sending window, performed by a sending end, comprising: sending an indication of a data packet discard status to a receiving end; listening for a feedback of the data packet discard status from the receiving end; and adjusting a data packet sending window in response to receiving the feedback. 2.The method of claim 1, further comprising: transmitting the indication of the data packet discard status to the receiving end in response to receiving a query message from the receiving end; or transmitting the indication of the data packet discard status to the receiving end in response to not receiving the feedback and a listening timer expiring, wherein the listening timer corresponds to a time window for listening for the feedback of the data packet discard status from the receiving end. 3.The method of claim 2, further comprising: adjusting the data packet sending window after transmitting the indication of the data packet discard status to the receiving end. before transmitting the indication of the data packet discard status to the receiving end, further comprising: updating the indication of the data packet discard status according to a latest data packet discard of the sending end.

4. The method of claim 2, wherein, 5.The method of claim 1, wherein the adjusting the data packet sending window comprises: changing a lower bound of the sending window to correspond to a first sent pending acknowledgement data packet other than a discarded data packet. 6.The method of claim 1, wherein: the indication of the data packet discard status is for indicating valid data packets. the indication of the data packet discard status comprises: one or more valid data packet sequence number indications for indicating one or more valid data packet sequence numbers of the sending end after performing data packet discard.

7. The method of claim 6, wherein, the indication of the data packet discard status further comprises: a last valid data packet sequence number indication for indicating a sequence number of a last valid data packet of all sent data packets of the sending end after performing data packet discard or a sequence number of a next data packet of the last valid data packet.

8. The method of claim 7, wherein, the indication of the data packet discard status further comprises: a last discarded data packet sequence number indication for indicating a sequence number of a last discarded data packet of all sent data packets of the sending end after performing data packet discard or a sequence number of a next data packet of the last discarded data packet.

9. The method of claim 7, wherein, the indication of the data packet discard status further comprises: one or more valid data packet range sequence number indications corresponding to the one or more valid data packet sequence number indications, respectively, for indicating one or more valid data packet ranges from the one or more valid data packets, respectively.

10. The method of claim 7, wherein, 11.The method of claim 1, wherein: the indication of the data packet discard status is for indicating discarded data packets. the indication of the data packet discard status comprises: one or more discarded data packet sequence number indications for indicating one or more discarded data packet sequence numbers of the sending end after performing data packet discard.

12. The method of claim 11, wherein, the indication of the data packet discard status further comprises: ​ 13. The method of claim 11, wherein, ​ a last discarded packet sequence number indication, for indicating a sequence number of a last discarded packet or a sequence number of a next packet of the last discarded packet among all sent packets after performing packet discarding by the sending end.

14. The method of claim 11, wherein, The indication of the packet discarding status further comprises: a last valid packet sequence number indication, for indicating a sequence number of a last valid packet or a sequence number of a next packet of the last valid packet among all sent packets after performing packet discarding by the sending end.

15. The method of claim 11, wherein, The indication of the packet discarding status further comprises: one or more discarded packet range sequence number indications, respectively corresponding to the one or more discarded packet sequence number indications, for indicating one or more discarded packet ranges from the one or more discarded packets.

16. The method of claim 1, wherein, the indication of the packet discarding status is for indicating a first sent packet to be acknowledged other than a discarded packet.

17. The method of claim 1, wherein, the sending end judges whether the packet status report is the feedback of the indication of the packet discarding status according to an acknowledgement ACK and / or a non-acknowledgement NACK status of a data set received in the packet status report.

18. The method of claim 1, wherein, the indication of the packet discarding status comprises a last valid packet sequence number indication, and the feedback comprises the last valid packet sequence number indication; or the indication of the packet discarding status comprises a last discarded packet sequence number indication, and the feedback comprises the last discarded packet sequence number indication.

19. The method of claim 1, wherein, the feedback comprises a 1-bit acknowledgement identifier, which is contained in one of: a dedicated discard response control packet, a radio link control RLC status report, or a data packet subheader.

20. A method for adjusting a packet receiving window, performed by a receiving end, comprising: receiving, from a sending end, an indication of a packet discarding status; sending, to the sending end, a feedback of the packet discarding status; and adjusting a packet receiving window according to the indication of the packet discarding status.

21. The method of claim 20, further comprising: before the receiving, from the sending end, the indication of the packet discarding status, sending, to the sending end, a query message, wherein the query message is for requesting the indication of the packet discarding status from the sending end. the sending, to the sending end, the query message is performed in response to one of:

22. The method of claim 21, wherein, a remaining time delay of a discard timer of a lower boundary of the packet receiving window being less than a preset time delay; or a number of low time delay requirement data in a buffer of the receiving end being greater than a preset number; or a number of packets with a non-acknowledgement NACK feedback in the packet receiving window being greater than a preset threshold.

23. The method of claim 21, wherein, the query message is further for indicating a queried packet range.

24. The method of claim 20, wherein, the indication of the packet discarding status is for indicating a valid packet. ​ 25. The method of claim 24, wherein, The indication of the data packet discard status comprises: one or more valid data packet sequence number indications, for indicating sequence numbers of one or more valid data packets after the data packet discard is performed by the sending end.

26. The method of claim 25, wherein, The indication of the data packet discard status further comprises: a last valid data packet sequence number indication, for indicating a sequence number of a last valid data packet among all sent data packets after the data packet discard is performed by the sending end, or a sequence number of a next data packet of the last valid data packet.

27. The method of claim 25, wherein, The indication of the data packet discard status further comprises: a last discard data packet sequence number indication, for indicating a sequence number of a last discard data packet among all sent data packets after the data packet discard is performed by the sending end, or a sequence number of a next data packet of the last discard data packet.

28. The method of claim 25, wherein, The indication of the data packet discard status further comprises: one or more valid data packet range sequence number indications, respectively corresponding to the one or more valid data packet sequence number indications, for respectively indicating one or more valid data packet ranges from the one or more valid data packets.

29. The method of claim 20, wherein, the indication of the data packet discard status is for indicating discarded data packets.

30. The method of claim 29, wherein, The indication of the data packet discard status comprises: one or more discard data packet sequence number indications, for indicating sequence numbers of one or more discard data packets after the data packet discard is performed by the sending end.

31. The method of claim 30, wherein, The indication of the data packet discard status further comprises: a last discard data packet sequence number indication, for indicating a sequence number of a last discard data packet among all sent data packets after the data packet discard is performed by the sending end, or a sequence number of a next data packet of the last discard data packet.

32. The method of claim 30, wherein, The indication of the data packet discard status further comprises: a last valid data packet sequence number indication, for indicating a sequence number of a last valid data packet among all sent data packets after the data packet discard is performed by the sending end, or a sequence number of a next data packet of the last valid data packet.

33. The method of claim 30, wherein, The indication of the data packet discard status further comprises: one or more valid data packet range sequence number indications, respectively corresponding to the one or more valid data packet sequence number indications, for respectively indicating one or more valid data packet ranges from the one or more valid data packets.

34. The method of claim 20, wherein, the indication of the data packet discard status is for indicating a first sent data packet to be acknowledged after discarded data packets.

35. The method of claim 20, wherein, The sending of the feedback of the data packet discard status to the sending end comprises: sending a data packet status report to the sending end, wherein the data packet status report indicates acknowledgement ACK and / or non-acknowledgement NACK status of a data set.

36. The method of claim 20, wherein, the indication of the data packet discard status comprises a last valid data packet sequence number indication, and the feedback comprises the last valid data packet sequence number indication; or the indication of the data packet discard status comprises a last discard data packet sequence number indication, and the feedback comprises the last discard data packet sequence number indication.

37. The method of claim 20, wherein the feedback comprises a one-bit acknowledgement indication included in one of: a dedicated discard response control packet, a radio link control (RLC) status report, or a data packet subheader. The adjusting the data packet reception window according to the indication of the data packet discard status comprises:

38. The method of claim 20, wherein, changing a lower boundary of the reception window to correspond to a first valid data packet to be received after an original data packet corresponding to the lower boundary of the reception window when the data packet discard status indicates that the original data packet is discarded. The adjusting the data packet reception window according to the indication of the data packet discard status comprises:

39. The method of claim 20, wherein, changing RX_Highest_Status of the reception window to correspond to a first valid data packet to be received after an original RX_Highest_Status of the reception window when the data packet discard status indicates that the original RX_Highest_Status is discarded; and / or changing RX_Next_Highest_Status of the reception window to correspond to a first valid data packet to be received after an original RX_Next_Highest_Status of the reception window when the data packet discard status indicates that the original RX_Next_Highest_Status is discarded.

40. A method for adjusting a data packet transmission window, performed by a transmitting end, comprising: transmitting window synchronization information to a receiving end.

41. The method of claim 40, further comprising: adjusting the data packet transmission window, wherein the window synchronization information corresponds to the adjusting of the data packet transmission window. The transmitting window synchronization information to the receiving end comprises:

42. The method of claim 40, wherein, transmitting the window synchronization information to the receiving end at a predetermined period. further comprising:

43. The method of claim 40, wherein, performing data packet discard; wherein the transmitting window synchronization information to the receiving end is performed in response to the data packet discard. The transmitting window synchronization information to the receiving end comprises:

44. The method of claim 40, wherein, obtaining data packet reception status from the receiving end; and transmitting the window synchronization information to the receiving end when it is determined that the data packet transmission window is not synchronized with a data packet reception window of the receiving end based on the data packet reception status.

45. The method of claim 40, wherein the synchronization information comprises a synchronization indication indicating a lower boundary data packet SN (sequence number of a first data packet to be acknowledged by the receiving end) of the data packet transmission window or a maximum SN of data packets transmitted by the transmitting end.

46. The method of claim 40, wherein the synchronization information is carried in a next data packet subheader.

47. A method for adjusting a data packet reception window, performed by a receiving end, comprising: receiving window synchronization information from a transmitting end.

48. The method of claim 47, further comprising: adjusting the data packet reception window based on the window synchronization information.

49. The method of claim 47, wherein the window synchronization information is transmitted periodically.

50. The method of claim 47, wherein the window synchronization information is transmitted in response to a data packet discard. ​ ​ ​ ​ The window synchronization information is sent in response to the sender performing packet discard.

51. The method of claim 47, further comprising: sending a packet reception status to the sender; wherein the window synchronization information is sent in response to the sender determining that the packet sending window is not synchronized with a packet reception window of the receiver based on the packet reception status.

52. The method of claim 47, wherein: the synchronization information comprises a synchronization indication, the synchronization indication indicating a lower boundary of the packet sending window.

53. A method for adjusting a packet sending window, performed at a sender, comprising: receiving a packet reception status from a receiver; and adjusting the packet sending window based on the packet reception status. The adjusting the packet sending window based on the packet reception status comprises:

54. The method of claim 53, wherein, when a reception status of a packet corresponding to a lower boundary of the packet sending window is acknowledgement (ACK), changing the lower boundary of the packet sending window to correspond to a first subsequent sent valid packet to be acknowledged. The packet reception status is sent in response to:

55. The method of claim 53, wherein, a discard timer of a packet corresponding to a lower boundary of a packet reception window of the receiver expires, and a reassembly timer of the packet corresponding to the lower boundary of the packet reception window is still running.

56. A method for adjusting a packet reception window, performed at a receiver, comprising: in response to a packet being discarded: adjusting the packet reception window; and sending a packet reception status to a sender; wherein the reception status of the discarded packet is acknowledgement (ACK).

57. The method of claim 56, wherein: the adjusting the packet reception window and sending the packet reception status to the sender is performed when a discard timer of a packet corresponding to a lower boundary of a packet reception window of the receiver expires, and a reassembly timer of the packet corresponding to the lower boundary of the packet reception window is still running. The adjusting the packet reception window comprises:

58. The method of claim 56, wherein, adjusting the lower boundary of the packet reception window to correspond to a first subsequent valid packet to be received after a packet to which the lower boundary originally corresponds. The adjusting the packet reception window further comprises:

59. The method of claim 56, wherein, adjusting a parameter RX_Highest_Status of the packet reception window to correspond to a first subsequent valid packet to be received after a packet to which the parameter RX_Highest_Status originally corresponds; and / or adjusting a parameter RX_Next_Highest_Status of the packet reception window to correspond to a first subsequent valid packet to be received after a packet to which the parameter RX_Next_Highest_Status originally corresponds.

60. A communication device comprising a processor and a memory, the memory storing program instructions that, when executed by the processor, implement a method as claimed in any one of claims 1 to 59. The program instructions, when executed by the processor, implement a method as claimed in any one of claims 1 to 59.

61. A readable storage medium for storing program instructions, wherein, ​

Images