Communication method, and related device and system

Abstract

Embodiments of the present application provide a communication method, and a related device and system. When a receiving PDCP entity updates a first PDCP status variable, the receiving PDCP entity can indicate first indication information to a receiving RLC entity. The first PDCP status variable may be used for indicating the sequence number of a first data packet that has not been delivered to an upper layer by the receiving PDCP entity. Upon receiving the first indication information, the receiving RLC entity can update a first RLC status variable. The first RLC status variable may be used for indicating the sequence number of a data packet that has not been completely received by the receiving RLC entity. In this way, when a PDCP layer discards a data packet, the receiving RLC entity is triggered to also advance a window and perform RLC discarding, so that an RLC layer no longer maintains the data packet discarded by the PDCP layer, thereby avoiding unnecessary RLC retransmissions.

Description

Communication method, related device and system

[0001] The present application claims priority to the Chinese patent application No. 202411083158.X, filed on August 7, 2024, and entitled "Communication method, related device and system", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present application relates to the technical field of wireless communication, in particular to a communication method, related device and system. BACKGROUND

[0003] In the acknowledgement mode (AM), the receiving end feeds back the receiving status of the data packet through the radio link control (RLC) status report, and the sending end decides whether to perform retransmission according to the RLC status report. This is the RLC retransmission, which can guarantee the reliable transmission of the data packet. The conditions for triggering the receiving end to send the RLC status report can include:

[0004] (1) The reassembly timer expires;

[0005] (2) The receiving end receives the poll of the sending end and meets certain conditions. The poll is used to inquire whether the data packet is correctly received. The triggering conditions of the poll include that the number or byte size of the newly sent data packet has been greater than the threshold, or there is no data packet in the sending end buffer that needs to be newly transmitted or retransmitted.

[0006] Currently, after the packet data convergence protocol (PDCP) layer discards the data packet, if the RLC layer has already delivered the data packet to the lower layer, the RLC layer will not discard the data packet, but will perform retransmission, which will cause unnecessary data packets to continue to be transmitted, resulting in waste of air interface resources. SUMMARY

[0007] In a first aspect, the embodiments of the present application provide a communication method, which can include: in a case where a receiving PDCP entity updates a first PDCP status variable, the receiving PDCP entity indicates first indication information to a receiving RLC entity. In a case where the receiving RLC entity receives the first indication information, the receiving RLC entity updates a first RLC status variable.

[0008] The first PDCP status variable is used to indicate the sequence number of the first data packet that has not been delivered to the upper layer by the receiving PDCP entity, and the first RLC status variable is used to indicate the sequence number after the highest sequence number of the data packets received in sequence by the receiving RLC entity.

[0009] The communication method provided in the first aspect can trigger the receiving RLC entity to push the RLC receiving window to move in the case that the receiving PDCP entity pushes the receiving PDCP window to move, perform RLC discard, and the RLC layer no longer maintains the data packet discarded by the PDCP layer, thereby avoiding unnecessary RLC retransmission.

[0010] In combination with the first aspect, in some embodiments, the trigger condition for the receiving PDCP entity to update the first PDCP state variable includes any one of the following:

[0011] The reordering timer expires, the first PDCP state variable is less than or equal to the maximum COUNT value of the discarded data packet, or the number of the data packet received by the receiving PDCP entity is equal to the first PDCP state variable.

[0012] In combination with the first aspect, in some embodiments, the receiving PDCP entity updating the first PDCP state variable can include: the receiving PDCP entity updating the first PDCP state variable according to the data packet discarded by the sending PDCP entity.

[0013] In combination with the first aspect, in some embodiments, the receiving PDCP entity further receives a first sequence number gap report, and the first sequence number gap report is used to indicate the data packet discarded by the sending PDCP entity.

[0014] In combination with the first aspect, in some embodiments, the receiving PDCP entity updating the first PDCP state variable according to the data packet discarded by the sending PDCP entity includes:

[0015] In the case that the reordering timer expires, the receiving PDCP entity updates the first PDCP state variable to the number of the data packet that is first after the second PDCP state variable and has not been submitted to the upper layer and has not been discarded by the sending PDCP entity. The second PDCP state variable is used to indicate the number after the number of the data packet triggering the reordering timer.

[0016] In combination with the first aspect, in some embodiments, the receiving PDCP entity updating the first PDCP state variable according to the data packet discarded by the sending PDCP entity includes:

[0017] In the case that the first PDCP state variable is less than or equal to the maximum COUNT value of the discarded data packet, or the number of the data packet received by the receiving PDCP entity is equal to the first PDCP state variable, the receiving PDCP entity updates the first PDCP state variable to the number of the data packet that is first after the first PDCP state variable and has not been submitted to the upper layer and has not been discarded by the sending PDCP entity.

[0018] In some embodiments, the updating the first RLC status variable comprises: updating the first RLC status variable to a number of a first data packet that has not been completely received after the second data packet; and the second data packet has a number at the PDCP layer equal to the updated first PDCP status variable, or the second data packet has a number at the PDCP layer less than or equal to a third PDCP status variable, the third PDCP status variable indicating a number of a next data packet expected to be received by the receiving PDCP entity.

[0019] In some embodiments, the first indication information indicates that the first PDCP status variable is updated to a number of the second data packet.

[0020] In some embodiments, the communication method further comprises:

[0021] If the updated first RLC status variable is greater than the second RLC status variable, the receiving RLC entity updates the second RLC status variable to a number of a data packet that has not been completely received after the updated first RLC status variable, the second RLC status variable indicating a highest possible number when a status PDU needs to be built.

[0022] In some embodiments, the communication method further comprises: if the updated first RLC status variable is greater than a third RLC status variable, the receiving RLC entity updates the third RLC status variable to be equal to a fourth RLC status variable, the third RLC status variable indicating a number after a number of a RLC SDU triggering a reassembly timer, the fourth RLC status variable indicating a number after a highest number of the RLC SDU.

[0023] In some embodiments, after updating the first RLC status variable, the receiving RLC entity further sends a first report to the sending RLC entity, the first report indicating a receiving status of the data packet.

[0024] In some embodiments, the first report specifically indicates that a receiving status of the data packet between the first RLC status variable before the updating and the first RLC status variable after the updating is a confirmed receiving.

[0025] In some embodiments, the first report specifically indicates one or more of: a receiving status of a data packet between the first RLC status variable after the updating and the second RLC status variable after the updating is an unconfirmed receiving, and a receiving status of a data packet between the first RLC status variable after the updating and the second RLC status variable after the updating is a confirmed receiving.

[0026] In some embodiments of the first aspect, the condition that the receiving PDCP entity indicates the first indication information to the receiving RLC entity or the receiving RLC entity updates the first RLC status variable can include any of the following: the receiving PDCP entity does not receive a non-in-sequence delivery indication, the receiving PDCP entity receives the second indication information, or the receiving RLC entity receives the second indication information.

[0027] The second indication information can be used to indicate that the receiving PDCP entity updates the first PDCP status variable, or can be used to indicate that the receiving RLC entity updates the first RLC status variable.

[0028] In the second aspect, the embodiments of the present application provide another communication method, which can include: in the case that the receiving RLC entity determines that there is an incompletely received data packet between the fourth RLC status variable and the first RLC status variable, starting a discard timer. When the discard timer expires, the receiving RLC entity updates the first RLC status variable.

[0029] The first RLC status variable can be used to indicate the number of the incompletely received data packet of the receiving RLC entity, and the fourth RLC status variable can be used to indicate the number of the first data packet delivered to the upper layer of the receiving RLC entity.

[0030] The communication method provided in the second aspect can trigger the receiving RLC entity to push the RLC receiving window to move and perform RLC discard in the case that there is a gap in the delivery data packet number of the RLC layer, and the RLC layer no longer discards the data packet, thereby avoiding unnecessary RLC retransmission.

[0031] In some embodiments of the second aspect, updating the first RLC status variable can specifically include updating the first RLC status variable to the number of the first incompletely received data packet after the fourth RLC status variable.

[0032] In some embodiments of the second aspect, the receiving RLC entity can also update the fourth RLC status variable to the number of the first data packet delivered to the upper layer after the updated first RLC status variable.

[0033] In some embodiments of the second aspect, if the updated first RLC status variable is greater than the second RLC status variable, the receiving RLC entity can update the second RLC status variable to the number of the data packet that has not been completely received after the updated first RLC status variable. The second RLC status variable is used to indicate the next number of the number of the data packet triggering the reordering timer.

[0034] With reference to the second aspect, in some embodiments, if the updated first RLC status variable is greater than the third RLC status variable, the receiving RLC entity can update the third RLC status variable to be equal to the fourth RLC status variable.

[0035] With reference to the second aspect, in some embodiments, the receiving PDCP entity can update the first PDCP status variable in case the reordering timer expires before the receiving RLC entity determines that there is an incompletely received data packet between the fourth RLC status variable and the first RLC status variable. The first PDCP status variable can be used to indicate the number of the first data packet that has not been delivered to the upper layer by the receiving PDCP entity.

[0036] With reference to the second aspect, in some embodiments, the receiving PDCP entity updating the first PDCP status variable can specifically include: the receiving PDCP entity updating the first PDCP status variable to the number of the first data packet that has not been delivered to the upper layer and has not been discarded by the sending PDCP entity after the receiving PDCP entity updates the first PDCP status variable to the second PDCP status variable. The second PDCP status variable can be used to indicate the number after the number of the data packet that triggers the reordering timer.

[0037] With reference to the second aspect, in some embodiments, the receiving RLC entity can further receive a discard timer configured by the sending RLC entity.

[0038] With reference to the second aspect, in some embodiments, after the receiving RLC entity updates the first RLC status variable and the fourth RLC status variable, the receiving RLC entity can further send a first report to the sending RLC entity, the first report being used to indicate the reception status of the data packet.

[0039] With reference to the second aspect, in some embodiments, the first report can be specifically used to indicate that the reception status of the data packet between the first RLC status variable before the update and the fourth RLC status variable before the update is received.

[0040] In a third aspect, a communication device is provided, which is configured to perform the communication method described in the first aspect. The communication device can include a memory, a processor coupled to the memory, a transmitter and a receiver, wherein the transmitter is configured to transmit signals to another wireless communication device, the receiver is configured to receive signals transmitted by another wireless communication device, the memory is configured to store the implementation code of the communication method described in the first aspect, and the processor is configured to execute the program code stored in the memory, i.e., execute the communication method described in any one of the possible implementation manners of the first aspect.

[0041] In a fourth aspect, a communication device is provided for performing the communication method described in the second aspect. The communication device can include a memory, and a processor, a transmitter and a receiver coupled to the memory, wherein the transmitter is configured to transmit signals to another wireless communication device, the receiver is configured to receive signals transmitted by another wireless communication device, the memory is configured to store program codes for implementing the communication method described in the second aspect, and the processor is configured to execute the program codes stored in the memory, i.e., to perform the communication method described in any one of the possible implementation manners of the second aspect.

[0042] In a fifth aspect, a computer readable storage medium is provided, which stores instructions thereon, and the instructions, when executed on a computer, cause the computer to perform the communication method described in the first aspect.

[0043] In connection with the sixth aspect, a computer program product is provided, which contains instructions, and the instructions, when executed on a computer, cause the computer to perform the communication method described in the second aspect. BRIEF DESCRIPTION OF DRAWINGS

[0044] In order to more clearly illustrate the technical solutions in the embodiments or the background art of the present application, the drawings needed to be used in the embodiments or the background art of the present application will be described below.

[0045] FIG. 1 shows various state variables relied on by a PDCP receiving window;

[0046] FIG. 2 shows various state variables relied on by an RLC sending window;

[0047] FIG. 3 shows various state variables relied on by an RLC receiving window;

[0048] FIG. 4 shows an example of a reordering timer timeout triggering a receiving PDCP entity to push a window;

[0049] FIG. 5 shows a format of a PDCP control PDU carrying a first SN gap report;

[0050] FIG. 6A shows a 12-bit status report;

[0051] FIG. 6B shows an 18-bit status report;

[0052] FIG. 7 shows the overall flow of a communication method provided by the embodiments of the present application;

[0053] FIG. 8 shows an example of updating state variables of a PDCP receiving window and state variables of an RLC receiving window;

[0054] FIG. 9 shows an interaction flow of the communication method shown in FIG. 7 at both sides of a transceiver;

[0055] FIG. 10 shows a general flow of another communication method according to an embodiment of the present application;

[0056] FIG. 11 shows another example of updating the state variables of the RLC receiving window;

[0057] FIG. 12 shows an interaction flow of the communication method shown in FIG. 10 at both the transmitting side and the receiving side;

[0058] FIG. 13 shows a user equipment 200 according to an embodiment of the present application;

[0059] FIG. 14 shows a network equipment 300 according to some embodiments of the present application;

[0060] FIG. 15 shows a wireless communication system according to the present application;

[0061] FIG. 16 shows a processing apparatus according to the present application. DETAILED DESCRIPTION

[0062] The terms used in the embodiments section of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application.

[0063] First, some state variables of the PDCP layer and the RLC layer are introduced.

[0064] The transmitting PDCP entity needs to maintain the following state variables:

[0065] a) TX_NEXT

[0066] This state variable is used to indicate the COUNT value of the next PDCP service data unit (SDU) to be transmitted.

[0067] FIG. 1 shows various state variables relied on by the PDCP receiving window. The receiving PDCP entity needs to maintain these state variables:

[0068] a) RX_NEXT

[0069] This state variable is used to indicate the COUNT value of the next PDCP SDU expected to be received.

[0070] b) RX_DELIV

[0071] As shown in FIG. 1, RX_DELIV is the lower boundary of the PDCP receiving window. This state variable is used to indicate the COUNT value of the first PDCP SDU that has not been submitted to the upper layer.

[0072] c) RX_REORD

[0073] This state variable is used to indicate the COUNT value after the COUNT value of the PDCP data PDU that triggers the reordering timer (t-Reordering).

[0074] As shown in Figure 1, RX_DELIV is the lower boundary of the PDCP receiving window. In the case of reordering timer timeout, RX_DELIV is directly updated to the COUNT value of the first data packet after RX_REORD that has not been delivered to the upper layer, the undelivered data packets are abandoned, and the PDCP receiving window is pushed forward.

[0075] Figure 2 shows the state variables that the RLC sending window depends on. The transmitting RLC entity needs to maintain these state variables:

[0076] a) TX_Next_Ack: As shown in Figure 2, it is the lower boundary of the RLC sending window, and is kept at the serial number (SN) of the next data packet of the data packet that has been received in order and has been acknowledged (ACK), i.e., the SN of the first data packet that is waiting for an acknowledgement (ACK). Once the SN of the data packet that has been acknowledged is equal to TX_Next_Ack, the transmitting PDCP entity needs to update TX_Next_Ack.

[0077] b) AM_Window_Size: The size of the AM window, which is related to the number of bits occupied by the SN of the RLC layer data packet, etc., for example, when the SN of the RLC layer data packet occupies 12 bits, AM_Window_Size = 2048. The size of AM_Window_Size is determined by the protocol.

[0078] c) TX_Next: It is kept at the SN of the next newly generated AMD PDU (acknowledgement mode data packet data unit). Once the SN of the AMD PDU that the transmitting RLC entity has generated is equal to TX_Next, TX_Next needs to be updated. The AMD PDU includes a complete RLC SDU (radio link control service data unit) or a segment of the RLC SDU.

[0079] Figure 3 shows the state variables that the RLC reception window depends on. The RLC reception window refers to a data processing range that the receiving RLC entity needs to maintain when processing data. Data outside the RLC reception window can be ignored by the receiving RLC entity. The state variables that the RLC reception window depends on determine the size of the window and where the boundaries of the window are.

[0080] The receiving RLC entity needs to maintain the following state variables:

[0081] a) RX_Next: as shown in Figure 3, it is the lower boundary of the reception window. This state variable holds the SN value after the last RLC SDU that was received in-sequence and completely. RX_Next is updated as soon as the receiving PDCP entity receives a packet with SN equal to RX_Next.

[0082] b) RX_Next_Status_Trigger: it holds the SN after the SN of the RLC SDU that triggered the reassembly timer (t-Reassembly). When out-of-sequence occurs, the reassembly timer is started, requiring the packet before the RLC SDU to be received before the reassembly timer expires, otherwise the sender is notified of the packet loss. If all the packets before RX_Next_Status_Trigger are received before the reassembly timer expires, the reassembly timer is stopped.

[0083] c) RX_Highest_Status: used to indicate the highest sequence number of the status report, in which the un-ACK_SN can be indicated. When the reassembly timer is triggered, RX_Highest_Status is set to the SN that triggered the reassembly timer, i.e. RX_Next_Status_Trigger, to identify the reassembly timer expiration, which packets need to be filled in the status report, and to determine whether there is a new packet loss.

[0084] d) RX_Next_Highest: it holds the SN after the highest SN in the received RLC SDU.

[0085] where the SN after can be the next SN.

[0086] The RLC reception window refers to a data processing range that the receiving RLC entity needs to maintain when processing data. Data outside the RLC reception window can be ignored by the receiving RLC entity.

[0087] The discarding of data by the receiving PDCP entity and the pushing of the window forward can include the following scenarios:

[0088] Case 1, reordering timer (t-Reordering) expires.

[0089] The receiving PDCP entity shall:

[0090] After performing header decompression, deliver the PDCP SDUs in ascending order of associated COUNT value to upper layers, if not already decompressed;

[0091] All stored PDCP SDUs with consecutive associated COUNT values from RX_REORD, including the COUNT value of the stored PDCP SDU and the COUNT value of the PDCP SDU considered as discarded;

[0092] All stored PDCP SDUs with consecutive associated COUNT values from RX_REORD, including the COUNT value of the stored PDCP SDU and the COUNT value of the PDCP SDU considered as discarded;

[0093] Update RX_DELIV to the COUNT value of the first PDCP SDU not delivered to upper layers and not considered as discarded, which is greater than RX_REORD;

[0094] If RX_DELIV is less than RX_NEXT, update RX_REORD to RX_NEXT and start the reordering timer.

[0095] That is, if the reordering timer expires, update RX_DELIV to the COUNT value of the first PDCP SDU received after RX_REORD, not delivered to upper layers and not considered as discarded.

[0096] Figure 4 shows an example of reordering timer expiry triggering the receiving PDCP entity to push the window. As shown in Figure 4, RX_DELIV is kept at SN1, the receiving PDCP entity receives SN1 and waits for delivery to upper layers, does not receive SN2 to SN9, but receives SN10, a SN gap occurs, RX_REORD is kept at SN10, and the reordering timer is started. The reordering timer expires, as shown in Figure 4, RX_DELIV is updated to the COUNT value of the first PDCP SDU received after RX_REORD, not delivered to upper layers, i.e. SN17, and the PDCP discards the PDCP SDUs between SN1 and SN17.

[0097] Case 2, the COUNT value of the received PDCP SDU is equal to RX_DELIV.

[0098] The receiving PDCP entity shall:

[0099] After performing header decompression, deliver the PDCP SDUs in ascending order of associated COUNT value to upper layers, if not already decompressed;

[0100] all stored PDCP SDUs with consecutive associated COUNT values from COUNT = RX_DELIV, including COUNT values of stored PDCP SDUs and COUNT values of PDCP SDUs considered as discarded;

[0101] update RX_DELIV to the COUNT value of the first data packet not delivered to upper layers and not considered as discarded, which is greater than RX_DELIV.

[0102] That is, if the COUNT value of the received data packet is equal to RX_DELIV, update new RX_DELIV to the sequence number of the first data packet not delivered to upper layers and not discarded by the receiving PDCP entity after new RX_DELIV.

[0103] Case 3, RX_DELIV is less than or equal to the maximum COUNT value of discarded data packets.

[0104] The receiving PDCP entity shall:

[0105] If RX_NEXT is less than or equal to the COUNT value of the last discarded data packet indicated in the first sequence gap report, update RX_NEXT to the maximum COUNT value of discarded data packets + 1;

[0106] If RX_DELIV is equal to any COUNT value of discarded data packets, deliver the data packets to upper layers in ascending order of associated COUNT values after performing header decompression, if not decompressed before;

[0107] all stored PDCP SDUs with consecutive associated COUNT values from COUNT = RX_DELIV + 1, including COUNT values of stored PDCP SDUs and COUNT values of PDCP SDUs considered as discarded;

[0108] update RX_DELIV to the COUNT value of the first data packet not delivered to upper layers and not considered as discarded, which is greater than RX_DELIV.

[0109] If the reordering timer is running and RX_DELIV is greater than or equal to RX_REORD, stop and reset the reordering timer;

[0110] If the reordering timer is not running and RX_DELIV is less than RX_NEXT, update RX_REORD to RX_NEXT and start the reordering timer.

[0111] If RX_DELIV is less than or equal to the maximum COUNT value of the discarded packets, RX_DELIV is updated to the COUNT value of the first packet that is not delivered to upper layers and not considered as discarded after RX_DELIV if RX_DELIV is equal to any COUNT value of the discarded packets.

[0112] The discarded packets at PDCP layer can be indicated by PDCP SN gap report. PDCP SN gap report is used to inform the PDCP receiving side about the discarded packets at PDCP transmitting side. PDCP SN gap report can be referred to as first sequence number gap report.

[0113] After the receiving PDCP entity discards the packet by advancing the window, if the RLC layer has already delivered the packet to lower layer, the receiving RLC entity will not discard the packet by advancing the window, but will continue to maintain the packet and trigger retransmission. However, this will cause unnecessary retransmission and waste of air interface resources. Moreover, the PDU set discard at PDCP layer is introduced in Rel-18 enhanced (XR) version, and the larger discard at PDCP layer will trigger larger RLC retransmission, resulting in more serious waste of air interface resources.

[0114] Secondly, the first SN gap report (PDCP SN gap report) is introduced.

[0115] Figure 5 shows the format of PDCP control PDU carrying the first SN gap report. The format is applicable to unacknowledge mode (UM) data bearers and acknowledge mode (AM) data bearers. As shown in Figure 5, the format includes a plurality of first discard COUNT (FDC) fields and a plurality of discard bitmap fields. Among them, the FDC field is the first discarded COUNT value, and this field indicates the COUNT value of the discarded packet with the smallest COUNT value. The discard bitmap field indicates which packets are discarded and which packets are not discarded. The position of the Nth bit in the discard bitmap is N. When the bit value is 0, the packet with the COUNT value of (FDC+bit position) modulo 232 is not discarded; when the bit value is 1, the packet with the COUNT value of (FDC+bit position) modulo 232 is discarded. Among them, bit position represents the position of the bit, and modulo represents the modulo operation.

[0116] Furthermore, the status report fed back by the receiving end to the transmitting end is introduced.

[0117] The status report may include a status report load and an RLC control PDU header. The RLC control PDU header includes a D / C (data or control) and a Control PDU type (CPT) field.

[0118] Figure 6A shows a 12-bit status report, and Figure 6B shows an 18-bit status report. (See Figures 6A and 6B.)

[0119] 1) Description of the ACK_SN field (length is 12 bits or 18 bits)

[0120] The ACK_SN field indicates the SN of the next RLC SDU that was not received and was not reported as lost in the status report. When the sender of the acknowledgment RLC entity receives the status PDU, all RLC SDUs except those indicated in the status report, except for: (1) RLC SDUs indicating NACK_SN; (2) RLC SDUs indicating NACK_SN and SOstart and SOend; (3) RLC SDUs indicating NACK_SN and NACK_range; (4) RLC SDUs indicating NACK_SN, NACK_range, SOstart, and SOend, have been received. That is, all RLC SDUs smaller than ACK_SN except for the above four types have been correctly received.

[0121] 2) Description of E1 field (1 bit)

[0122] For an explanation of the E1 field, please refer to Table 1.

[0123] Table 1

[0124] The E1 field is used to indicate whether NACK_SN, E1, E2, and E3 will be present in the subsequent sequence. When E1 is 0, it indicates that NACK_SN, E1, E2, and E3 will not be present in the subsequent sequence.

[0125] 3) NACK_SN field (12 bits or 18 bits)

[0126] NACK_SN is used to indicate that the RLC SDU (or RLC SDU segment) of this SN is detected and discarded on the receiving side.

[0127] 4) E2 field (1 bit)

[0128] For an explanation of the E2 field, please refer to Table 2.

[0129] Table 2

[0130] The E2 field indicates whether there is SOstart and SOend following, i.e. whether it indicates RLC SDU segmentation.

[0131] 5) SO start field (16 bits)

[0132] The SOstart field (together with the SOend field) is used to indicate that the part (segment) of the RLC SDU with SN NACK_SN is detected to be discarded. The SOstart field indicates the position of the first byte of the RLC SDU part in the original RLC SDU. That is, the first byte of the original RLC SDU is 0000000000000000, i.e. starts with 0.

[0133] 6) SO end field (16 bits)

[0134] When E3 is 0, the SOend field (together with the SOstart field) indicates that the part (segment) of the RLC SDU with SN NACK_SN (SOend related Soend) is detected to be discarded. The SOend field indicates the position of the last byte of the RLC SDU part in the original RLC SDU.

[0135] When E3 is 1, the SOend field indicates that the part of the RLC SDU with SN NACK_SN + NACK range - 1 is detected to be missing.

[0136] 7) E3 field (1 bit)

[0137] The E3 field can be referred to Table 3 for explanation.

[0138] Table 3

[0139] The E3 field is used to indicate whether there is a continuous RLC SDU sequence that is not received.

[0140] 8) NACK field (8 bits)

[0141] The NACK range field is used to indicate the number of RLC SDUs missing consecutively from NACK_SN.

[0142] 9) CPT field

[0143] The CPT field indicates the type of RLC control PDU. The CPT field can be referred to Table 4 for explanation.

[0144] Table 4

[0145] In order to effectively avoid unnecessary retransmission, in the case that the PDCP layer discards the data packet, the receiving RLC entity is triggered to push the window forward and perform RLC discard according to the embodiments of the present application. The RLC layer no longer maintains the data packet discarded by the PDCP layer, thereby avoiding unnecessary RLC retransmission.

[0146] FIG. 7 shows the overall flow of a communication method according to an embodiment of the present application. Details are described below.

[0147] S11, in the case that the receiving PDCP entity updates the first PDCP state variable, the receiving PDCP entity can indicate the first indication information to the receiving RLC entity. The first PDCP state variable can be used to indicate the number of the first data packet that has not been delivered to the upper layer by the receiving PDCP entity. The first PDCP state variable can be the state variable RX_DELIV of the aforementioned PDCP receiving window.

[0148] S12, after the receiving RLC entity receives the first indication information, the receiving RLC entity can update the first RLC state variable. The first RLC state variable can be used to indicate the number after the highest number of the data packet received in sequence by the receiving RLC entity. The first RLC state variable can be the state variable RX_Next of the aforementioned RLC receiving window.

[0149] The first indication information is the interlayer indication information between the PDCP layer and the RLC layer, which can be used to trigger the receiving RLC entity to push the window forward by updating the first RLC state variable, perform RLC discard, no longer maintain the data packet discarded by the PDCP layer, and avoid unnecessary RLC retransmission. The number can be SN or COUNT value, which is SN at the RLC layer and COUNT value at the PDCP layer.

[0150] The trigger condition for the receiving PDCP entity to update the first PDCP state variable can include any of the following: reordering timer timeout, the COUNT value (RCVD_COUNT) of the data packet received by the receiving PDCP entity being equal to the first PDCP state variable, the first PDCP state variable being less than or equal to the maximum COUNT value of the data packet discarded by the PDCP layer (the first PDCP state variable being equal to the COUNT value of the discarded data packet). These trigger conditions can also be referred to as the window pushing condition or the window pushing trigger condition of the PDCP receiving window.

[0151] The receiving PDCP entity can update the first PDCP state variable according to the data packet discarded by the sending PDCP entity.

[0152] In particular, in case the reordering timer expires, the receiving PDCP entity can update the first PDCP status variable to the number of the first data packet which has not been delivered to upper layers and has not been discarded by the transmitting PDCP entity after the second PDCP status variable. The second PDCP status variable can be used to indicate the number after the number of the data packet which triggers the reordering timer. The second PDCP status variable can be the aforementioned RX_REORD.

[0153] For example, as shown in Figure 8, the PDCP reception status variable RX_DELIV is originally kept at SN 1 and RX_REORD is kept at SN 6. Once the reordering timer expires, the receiving PDCP entity discards the delivery of the data packets which have not been received, and the PDCP reception status variable RX_DELIV is updated to the number of the first data packet which has not been delivered to upper layers and has not been discarded by the transmitting PDCP entity after RX_REORD, since the first data packet which has not been delivered to upper layers and has not been discarded by the transmitting PDCP entity after RX_REORD is SN 7, RX_DELIV is updated to SN 7.

[0154] In particular, in case the first PDCP status variable is less than or equal to the maximum COUNT value of the discarded data packets, or the receiving PDCP entity receives the data packet with the number equal to the first PDCP status variable, the receiving PDCP entity can also update the first PDCP status variable to the number of the first data packet which has not been delivered to upper layers and has not been discarded by the transmitting PDCP entity after the first PDCP status variable.

[0155] The number of the data packet kept by the updated first PDCP status variable can be less than or equal to the third PDCP status variable, or the first PDCP status variable can also be greater than the third PDCP status variable. The third PDCP status variable can be used to indicate the number of the next data packet which the receiving PDCP entity expects to receive, which can be the aforementioned PDCP reception window status variable RX_Next.

[0156] The first indication information can be used to indicate the position of the updated PDCP reception window. In particular, the first indication information is used to indicate that the first PDCP status variable is updated to the number of the second data packet, wherein the first indication information indicates the number of the second data packet. The number of the second data packet is equal to the updated first PDCP status variable, or the number of the second data packet is less than or equal to the third PDCP status variable which is used to indicate the number of the next data packet which the receiving PDCP entity expects to receive. In this way, the receiving RLC entity knows the current position of the PDCP reception window and understands which data packets are discarded by the PDCP layer, so as to push the RLC reception window forward accordingly.

[0157] When the third PDCP status variable is updated according to the first SN gap report, the third PDCP status variable can be greater than the corresponding PDCP number of all the data packets of the RLC transmission, because the condition for sending the PDCP trigger status report includes that the data packet is discarded because of the expiry of the discard timer, and the COUNT value of the stored data packet is greater than the discarded data packet, and the data packet is not delivered to the RLC layer. When the PDCP receiving entity receives the report, the RX_NEXT is updated according to the discarded data packet, and therefore the RX_NEXT can be updated to the COUNT value of the data packet that has not been transmitted in the RLC layer. If the first PDCP status variable is updated according to the discarded data packet and is greater than or equal to the third PDCP status variable, the first PDCP status variable is greater than the variable value of the receiving window maintained by the receiving RLC entity, and the PDCP notifies the RLC of the first PDCP status variable, and the receiving RLC entity cannot obtain the SN number of the data packet corresponding to the first PDCP status variable, because the transmitting RLC entity has not numbered the data packet, and the RLC entity cannot be updated. Therefore, when the receiving PDCP transmits the first indication information to the RLC entity, the transmitted status variable is less than or equal to the RX_NEXT before the update, i.e., the RX_NEXT value before the update due to the discard report, so that the RLC entity can be correctly updated.

[0158] In an implementation manner, the number of the second data packet is equal to the updated first PDCP status variable, and in this case, the updated first PDCP status variable is less than the third PDCP status variable before the update.

[0159] In an implementation manner, the number of the second data packet is less than or equal to the third PDCP status variable, and in this case, the updated first PDCP status variable is greater than the third PDCP status variable before the update.

[0160] After receiving the first indication information, the specific implementation of updating the first RLC status variable by the receiving RLC entity can include: updating the first RLC status variable to the number of the first data packet that has not been completely received after the number of the second data packet (including the number of the second data packet itself). Here, after includes the number itself. The number of the second data packet in the PDCP layer can be equal to the updated first PDCP status variable, or the number of the second data packet in the PDCP layer can be less than or equal to the third PDCP status variable, which is used to indicate the number of the next data packet expected to be received by the receiving PDCP entity. The third PDCP status variable can be the aforementioned PDCP receiving status variable RX_NEXT.

[0161] Still taking Figure 8 as an example, the RLC reception variable RX_Next originally keeps at SN1, after the reordering timer expires, the lower boundary status variable RX_DELIV of the PDCP reception window is updated to SN7. In response to the first indication information, the receiving RLC entity updates the RLC reception variable RX_Next to the number of the first data packet that has not been completely received after (including SN7 itself) SN7. Since the first data packet that has not been completely received after (including SN7 itself) SN7 is SN7, the RLC reception variable RX_Next is updated to SN7. This also means that the RLC layer no longer maintains SN1-SN6, performs RLC discard, and the receiving RLC entity will not trigger retransmission for the data packets that have not been received in SN1-SN6.

[0162] When updating the lower boundary of the RLC reception window, other state variables on which the RLC reception window depends can also be updated:

[0163] If the updated first RLC state variable is greater than the second RLC state variable, the receiving RLC entity can update the second RLC state variable to the number of the data packet that has not been completely received after the updated first RLC state variable. The second RLC state variable can be used to indicate the number after the number of the data packet that triggers the reassembly timer, which can be the aforementioned RLC reception window state variable RX_Highest_Status.

[0164] If the updated first RLC state variable is greater than the third RLC state variable, the receiving RLC entity can update the third RLC state variable to be equal to the fourth RLC state variable. The third RLC state variable keeps the number after the number of the data packet that triggers the reassembly timer (t-Reassembly), which can be the aforementioned RLC reception window state variable RX_Next_Status_Trigger. The fourth RLC state variable can be used to indicate the next number of the highest number in the received RLC SDU, which can be the aforementioned RLC reception window state variable RX_NEXT_Highest.

[0165] Figure 9 shows an interaction flow of the communication method shown in Figure 7 on both the transmitting side and the receiving side. The transmitting side includes a transmitting PDCP entity and a transmitting RLC entity, and the steps performed by the two entities are the steps performed by the transmitting device; the receiving side includes a receiving PDCP entity and a receiving RLC entity, and the steps performed by the two entities are the steps performed by the receiving device. As shown in Figure 9:

[0166] S21, the sender sends a first sequence number gap report (e.g. PDCP SN gap report) through the sending PDCP entity. Correspondingly, the receiver can receive the first sequence number gap report through the receiving PDCP entity.

[0167] The discarded data packets of the sending PDCP entity can be notified to the receiving PDCP entity through the first sequence number gap report (e.g. PDCP SN gap report). Specifically, the first sequence number gap report can include a discard bitmap, through which the discarded data packets of the PDCP layer are indicated.

[0168] S22, after receiving the first sequence number gap report through the receiving PDCP entity, the receiver can determine which data packets are discarded by the PDCP layer, and update the first PDCP status variable according to the discarded data packets.

[0169] S23, in the receiver, the receiving PDCP entity indicates the first indication information to the receiving RLC entity. Correspondingly, the receiving RLC entity receives the first indication information.

[0170] S24, after receiving the first indication information, the receiving RLC entity can update the first RLC status variable, push the RLC receiving window to move forward, and avoid unnecessary retransmission.

[0171] S25, the receiver can receive a first report sent by the receiving RLC entity. Correspondingly, the sender can receive the first report through the sending RLC entity. The first report can be used to indicate the receiving status of the data packets.

[0172] Specifically, the receiving RLC entity receiving the first indication information and updating the first RLC status variable can trigger a status report, which is used to send the status report in time. The first report can be used to indicate that the receiving status of the data packets between the first RLC status variable before updating (RX_NEXT) and the first RLC status variable after updating is confirmed to be received, wherein the first RLC status variable after updating can not be included, i.e. the first RLC status variable before updating to the first RLC status variable after updating-1. In this way, the ACK feedback for the data packets between the first RLC status variable before updating and the first RLC status variable after updating will not trigger RLC retransmission.

[0173] The first report can be a status report, and the reception status of "acknowledged reception" can be represented as ACK, and the reception status of "non-acknowledged reception" can be represented as NACK. In the implementation mode in which the first report is implemented as a status report, the first report can include ACK for packet feedback between the first RLC state variable before the update and the first RLC state variable after the update.

[0174] The first report can also be a discard report, and can include the number of packets of "acknowledged reception" and the number of packets of "non-acknowledged reception". Further, in the implementation mode in which the first report is implemented as a discard report, the receiver can additionally feedback the reception status of the packets between the first RLC state variable after the update (RX_NEXT) and the second RLC state variable after the update (RX_Highest_Status). For example, the first report can also include the number of packets of "acknowledged reception" and the number of packets of "non-acknowledged reception" between the first RLC state variable and the second RLC state variable after the update.

[0175] S26, after receiving the first report through the sending RLC entity, the sender does not retransmit the packets with the reception status of "acknowledged reception". In this way, RLC retransmission will not be performed for the RLC discarded packets.

[0176] In addition, the interaction process between the transceiver sides can further include S20, the sender configures the receiver to perform RLC discard. The configuration is a prerequisite for the receiver to update the first RLC state variable of the receiving RLC entity in the case that the receiving PDCP entity updates the first PDCP state variable, or a prerequisite for the receiving PDCP entity to send the first indication information to the receiving RLC entity. In summary, the configuration can be a prerequisite for the receiver to perform RLC discard.

[0177] The condition for the receiving PDCP entity to indicate the first indication information to the receiving RLC entity, or the condition for the receiving RLC entity to update the first RLC state variable, can include any of the following: the receiving PDCP entity does not receive a non-in-sequence delivery indication, the receiving PDCP entity receives second indication information, and the receiving RLC entity receives second indication information. Among them, the second indication information can be used to indicate the first indication information to the receiving RLC entity in the case that the receiving PDCP entity updates the first PDCP state variable, or to indicate the receiving RLC entity to update the first RLC state variable.

[0178] It can be seen that the communication method provided by the embodiment of the application shown in FIG. 7 triggers the receiving RLC entity to push the RLC receiving window to move in the case that the receiving PDCP entity pushes the receiving PDCP window to move, performs RLC discarding, and the RLC layer no longer maintains the data packet discarded by the PDCP layer, thereby avoiding unnecessary RLC retransmission.

[0179] FIG. 10 shows the overall flow of another communication method provided by the embodiment of the application. The following is expanded.

[0180] S31, in the case that the receiving RLC entity determines that there is an incompletely received data packet between the fourth RLC state variable and the first RLC state variable, the receiving RLC entity starts a discarding timer.

[0181] The first RLC state variable can be used to indicate the number of the data packet incompletely received by the receiving RLC entity. The first RLC state variable can be the state variable RX_Next of the aforementioned RLC receiving window.

[0182] The fourth RLC state variable can be a new state variable introduced by the embodiment of the application for the RLC receiving window, which can be marked as RX_DELIV. It can be used to indicate the number of the first data packet delivered to the upper layer by the receiving RLC entity. Here, the first refers to the smallest delivered data packet in the current RLC receiving window, which is relative to the current RLC receiving window. The lower boundary of the RLC receiving window is RX_Next. That is, the receiving RLC entity maintains a state variable indicating the number of the smallest delivered data packet in the current RLC receiving window.

[0183] In the case that the receiving RLC entity determines that there is an incompletely received data packet between the fourth RLC state variable and the first RLC state variable. That is, there is a SN gap between the fourth RLC state variable and the first RLC state variable, and the fourth RLC state variable is greater than the first RLC state variable.

[0184] S32, the discarding timer times out, and the receiving RLC entity can update the first RLC state variable.

[0185] Once the RLC layer receives a complete data packet, it delivers the data packet to the PDCP layer. There are incomplete received data packets between the fourth RLC state variable and the first RLC state variable, which means there is a gap in the data packets delivered by the RLC layer to the upper layer, and these data packets can be discarded by the PDCP layer. For this gap, the RLC layer can start a specific timer, which is referred to as a discard timer in this paper. If all the data packets pointed to by the gap are not completely received before the discard timer expires, RLC discard is performed, and the RLC receiving window is pushed forward. If all the data packets pointed to by the gap are completely received before the discard timer expires, i.e., the first RLC state variable is greater than or equal to the fourth RLC state variable during the running of the discard timer, the timer is stopped, and in this case, the timer does not expire, and the fourth RLC state variable is updated to the number of the first data packet delivered to the upper layer after the first RLC state variable, and if the updated fourth RLC state variable is greater than the first RLC state variable, the discard timer is started.

[0186] The length of the discard timer can be set to be the same as the length of the reordering timer.

[0187] The first RLC state variable can be updated, specifically, the first RLC state variable can be updated to the number of the first incomplete received data packet after the fourth RLC state variable. Thereafter, the receiving RLC entity can also update the fourth RLC state variable, specifically, the fourth RLC state variable can be updated to the number of the first delivered data packet to the upper layer after the updated first RLC state variable. In this way, the receiving RLC entity can timely push the RLC receiving window to move, and the data packets before the fourth RLC state variable can not be maintained, which can effectively avoid unnecessary RLC retransmission.

[0188] For example, as shown in FIG. 11, SN1 has not been completely received and thus has not been submitted to the upper layer, and the RLC reception status variable RX_Next remains at SN1. However, SN6 to SN10 have all been submitted to the upper layer, and SN6 is the smallest submitted SN in the current RLC reception window, and the RLC reception status variable RX_DELIV is at SN6. This indicates that there are uncompletely received data packets between SN6 and SN1. Thus, the discard timer is triggered at RX_DELIV. As shown in FIG. 11, once the discard timer expires, the receiving RLC entity discards the data packets before RX_DELIV (SN6), updates RX_Next to the number of the first uncompletely received data packet after RX_DELIV (SN6) (i.e., SN11), and then updates RX_DELIV to the number of the next smallest submitted data packet in the RLC reception window, i.e., updates RX_DELIV to the number of the first submitted data packet to the upper layer after the updated RX_Next (SN14). The lower boundary of the next RLC reception window is the updated RX_Next. In this way, the receiving RLC entity does not maintain the data packets before SN6, and unnecessary RLC retransmission can be effectively avoided.

[0189] Before S31, the communication method shown in FIG. 10 can further include the following process:

[0190] S33, the reordering timer expires, and the receiving PDCP entity updates the first PDCP status variable. The first PDCP status variable can be used to indicate the number of the first data packet that has not been submitted to the upper layer by the receiving PDCP entity. The first PDCP status variable can be the aforementioned PDCP reception window status variable RX_DELIV.

[0191] Specifically, the receiving PDCP entity can update the first PDCP status variable to the number of the first data packet that has not been submitted to the upper layer and has not been discarded by the sending PDCP entity after the second PDCP status variable. The second PDCP status variable can be used to indicate the number after the number of the data packet that triggers the reordering timer. The second PDCP status variable can be the aforementioned RX_REORD. For specific examples, reference can be made to the related content of the aforementioned example of FIG. 8, which will not be described herein again.

[0192] When updating the lower boundary of the RLC reception window, other status variables on which the RLC reception window depends can also be updated:

[0193] If the updated first RLC status variable is greater than the second RLC status variable, the receiving RLC entity can update the second RLC status variable to the number of the data packet that has not been completely received after the updated first RLC status variable. The second RLC status variable can be used to indicate the next number of the number of the data packet triggering the reassembly timer, which can be the aforementioned RLC receiving window status variable RX_Highest_Status.

[0194] If the updated first RLC status variable is greater than the third RLC status variable, the receiving RLC entity can update the third RLC status variable to be equal to the updated first RLC status variable. The third RLC status variable is kept at the number after the number of the data packet triggering the reassembly timer (t-Reassembly), which can be the aforementioned RLC receiving window status variable RX_Next_Status_Trigger.

[0195] FIG. 12 shows an interaction flow of the communication method shown in FIG. 10 on both sides of the transceiver. The sender includes a sending PDCP entity and a sending RLC entity, and the steps performed by the two entities are the steps performed by the sender device; the receiver includes a receiving PDCP entity and a receiving RLC entity, and the steps performed by the two entities are the steps performed by the receiver device. As shown in FIG. 12:

[0196] S41, the sender can configure a discard timer to the receiver through the sending RLC entity. Correspondingly, the receiver can receive the discard timer configured by the sender through the receiving RLC entity. Not limited to this, the discard timer can also be locally configured by the receiver.

[0197] S42, the receiver can determine through the receiving RLC entity that there are uncompletedly received data packets between the fourth RLC status variable and the first RLC status variable, and start the discard timer.

[0198] S43, the discard timer times out, and the receiving RLC entity updates the first RLC status variable and the fourth RLC status variable.

[0199] S44, the receiver can send the first report through the receiving RLC entity. Correspondingly, the sender can receive the first report through the sending RLC entity. The first report can be used to indicate the receiving status of the data packet.

[0200] S45, after receiving the first report through the sending RLC entity, the sender does not retransmit the data packet with the receiving status of “acknowledged receiving”. In this way, RLC retransmission will not be performed for the RLC discarded data packet.

[0201] The first report can be implemented as a status report, and the content of the status report is ACK or NACK for the feedback of the status of the data packet. The timeout of the discard timer can trigger the status report, so that the receiving end sends the status report in time. The first report can also be implemented as a discard report, and the content of the discard report can include the number of the data packet that is "confirmed to be received" and the number of the data packet that is "not confirmed to be received". The specific description of the first report can refer to the related content in the embodiment of FIG. 7, and will not be described here.

[0202] As can be seen, the communication method provided by the embodiment of the application shown in FIG. 10 triggers the receiving RLC entity to push the RLC receiving window to move and perform RLC discard in the case that there is a gap in the submitted data packet number of the RLC layer, and the data packet that is no longer discarded by the RLC layer avoids unnecessary RLC retransmission.

[0203] FIG. 13 shows the user equipment 200 provided by the embodiment of the application.

[0204] The user equipment 200 can be the sender mentioned in the foregoing embodiments, or can be the receiver mentioned in the foregoing embodiments. The user equipment 200 can also integrate the sender and the receiver, and assume the role of the sender in the uplink transmission scenario and assume the role of the receiver in the downlink transmission scenario.

[0205] As shown in FIG. 13, the user equipment 200 can include one or more terminal processors 201, a memory 202, a communication interface 203, a receiver 205, a transmitter 206, a coupler 207, an antenna 208, a user interface 209, and an input and output module (including an audio input and output module 210, a key input module 211, and a display 212). These components can be connected through a bus 204 or other means, and FIG. 13 takes the connection through the bus as an example. Among them:

[0206] The communication interface 203 can be used for the user equipment 200 to communicate with other communication equipment, for example, a network device. Specifically, the network device can be the network device 300 shown in FIG. 14. The user equipment 200 can also be configured with a wired communication interface 203, for example, a local access network (Local Access Network, LAN) interface, in addition to a wireless communication interface.

[0207] The transmitter 206 can be configured to perform transmit processing on signals outputted from the terminal processor 201, such as signal modulation. The receiver 205 can be configured to perform receive processing on mobile communication signals received by the antenna 208, such as signal demodulation. In some embodiments of the present application, the transmitter 206 and the receiver 205 can be regarded as a wireless modem. In the user equipment 200, the number of the transmitter 206 and the receiver 205 can be one or more. The antenna 208 can be configured to convert electromagnetic energy in a transmission line into electromagnetic waves in free space, or convert electromagnetic waves in free space into electromagnetic energy in a transmission line. The coupler 207 can be configured to split the mobile communication signals received by the antenna 208 into multiple paths, and distribute the mobile communication signals to multiple receivers 205.

[0208] In addition to the transmitter 206 and the receiver 205 shown in FIG. 13, the user equipment 200 can further comprise other communication components, such as a GPS module, a Bluetooth module, a Wireless Fidelity (Wi-Fi) module, etc. The user equipment 200 can support other wireless communication signals, such as satellite signals, short wave signals, etc., without being limited to the wireless communication signals described above. Without being limited to wireless communication, the user equipment 200 can be further configured with a wired network interface (such as a LAN interface) to support wired communication.

[0209] The input / output module can be configured to implement the interaction between the user equipment 200 and the user / external environment, and can mainly comprise an audio input / output module 210, a key input module 211, a display 212, etc. Specifically, the input / output module can further comprise a camera, a touch screen, a sensor, etc. The input / output module communicates with the terminal processor 201 through the user interface 209.

[0210] The memory 202 is coupled to the terminal processor 201, and is configured to store various software programs and / or multiple sets of instructions. Specifically, the memory 202 can comprise a high-speed random access memory, and can further comprise a non-volatile memory, such as one or more disk storage devices, flash memory devices or other non-volatile solid-state storage devices. The memory 202 can store an operating system. The memory 202 can further store a network communication program, which can be configured to communicate with one or more additional devices, one or more user equipment, one or more network devices. The memory 202 can further store a user interface program, which can display the content of an application in a lifelike manner through a graphical operation interface, and receive the control operation of the application by the user through input controls such as menus, dialog boxes and keys.

[0211] In some embodiments of the present application, the memory 202 can be configured to store the computer program of the communication method provided by the foregoing embodiments for implementation at the sender and / or the receiver. The terminal processor 201 can be configured to read and execute the computer program to implement the communication method provided by the embodiments of the present application.

[0212] The user equipment 200 can be implemented as a mobile device, a mobile station, a mobile unit, an M2M terminal, a wireless unit, a remote unit, a user agent, a mobile client, etc.

[0213] The user equipment 200 shown in FIG. 13 is only one implementation of the embodiments of the present application, and in actual applications, the user equipment 200 can also include more or fewer components, which are not limited herein.

[0214] FIG. 14 shows a network device 300 according to some embodiments of the present application.

[0215] The network device 300 can be the sender mentioned in the foregoing embodiments, or the receiver mentioned in the foregoing embodiments. The network device 300 can also integrate the sender and the receiver, and assume the role of the receiver in the uplink transmission scenario and assume the role of the sender in the downlink transmission scenario.

[0216] As shown in FIG. 14, the network device 300 can include one or more network device processors 301, a memory 302, a communication interface 303, a transmitter 305, a receiver 306, a coupler 307, and an antenna 308. These components can be connected through a bus 304 or other means, and FIG. 14 takes the bus connection as an example. Among them:

[0217] The communication interface 303 can be configured to enable the network device 300 to communicate with other communication devices, such as the user equipment 200 shown in FIG. 14 or other network devices. The network device 300 can also be configured with a wired communication interface 303 to support wired communication, for example, the backhaul link between one network device 300 and another network device 300 can be a wired communication connection.

[0218] The transmitter 305 can be configured to perform transmit processing on signals output by the network device processor 301, such as signal modulation. The receiver 306 can be configured to perform receive processing on mobile communication signals received by the antenna 308, such as signal demodulation. In some embodiments of the present application, the transmitter 305 and the receiver 306 can be regarded as a wireless modem. In the network device 300, the number of the transmitter 305 and the receiver 306 can each be one or more. The antenna 308 can be configured to convert electromagnetic energy in a transmission line into electromagnetic waves in free space, or convert electromagnetic waves in free space into electromagnetic energy in a transmission line. The coupler 307 can be configured to split a mobile communication signal into multiple paths and distribute the mobile communication signal to multiple receivers 306.

[0219] The memory 302 is coupled to the network device processor 301 and configured to store various software programs and / or sets of instructions. Specifically, the memory 302 can include high-speed random access memory, and can also include non-volatile memory, such as one or more disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. The memory 302 can store an operating system (hereinafter referred to as a system), such as an embedded operating system, uCOS, VxWorks, RTLinux, etc. The memory 302 can also store a network communication program, which can be configured to communicate with one or more additional devices, one or more user devices, and one or more network devices.

[0220] The network device processor 301 can be configured to perform wireless channel management, implement establishment and removal of a call and a communication link, and provide cell handover control for users in the current control area, etc.

[0221] In some embodiments of the present application, the memory 202 can be configured to store a computer program for implementing the communication method provided in the foregoing embodiments at the sender and / or the receiver. The network device processor 301 can be configured to read and execute the computer program to implement the communication method provided in the embodiments of the present application.

[0222] The network device 300 can be implemented as a base transceiver station, a wireless transceiver, a gNodeB, an access point or a transmission node (TRP), a central unit (CU) or other network entity, and can include some or all of the functions of the above network entities.

[0223] The network device 300 shown in FIG. 14 is only one implementation of the embodiments of the present application, and in actual applications, the network device 300 can include more or fewer components, which are not limited herein.

[0224] FIG. 15 shows a wireless communication system provided by the present application. The wireless communication system can be a 5th Generation (5G) system, or a future mobile communication system, a Machine to Machine (M2M) communication system, etc.

[0225] As shown in FIG. 15, the wireless communication system 10 includes a receiving device 400 and a sending device 500. In a downlink transmission scenario, the receiving device 400 can be the user equipment 200 in the embodiment of FIG. 13, and the sending device 500 can be the network device 300 in the embodiment of FIG. 14. In an uplink transmission scenario, the receiving device 400 can be the network device 300 in the embodiment of FIG. 14, and the sending device 500 can be the user equipment 200 in the embodiment of FIG. 13.

[0226] As shown in FIG. 15, the receiving device 400 can include a processing unit 401 and a communication unit 403, and the sending device 500 can include a communication unit 501 and a processing unit 503.

[0227] The receiving device 400 and the sending device 500 for implementing the communication method shown in FIG. 7 and the communication method shown in FIG. 10 are described below respectively.

[0228] 1. For implementing the communication method shown in FIG. 7:

[0229] The receiving device 400

[0230] The communication unit 403 can be configured to receive the data packet transmitted by the sending device 500.

[0231] The communication unit 403 can also be configured to receive the first sequence number gap report to learn which data packets are discarded by the PDCP layer.

[0232] The processing unit 401 can be configured to update the first PDCP state variable, and in the case of updating the first PDCP state variable, indicate the first indication information to the receiving RLC entity. The first PDCP state variable can be configured to indicate the sequence number of the first data packet that has not been delivered to the upper layer by the receiving PDCP entity. The first PDCP state variable can be the state variable RX_DELIV of the aforementioned PDCP receiving window.

[0233] The processing unit 401 can also be configured to update the first RLC state variable after the receiving RLC entity receives the first indication information. The first RLC state variable can be configured to indicate the sequence number of the data packet that has not been completely received by the receiving RLC entity. The first RLC state variable can be the state variable RX_Next of the aforementioned RLC receiving window.

[0234] The first indication information is interlayer indication information between the PDCP layer and the RLC layer, which can be used to trigger the receiving RLC entity to push the window forward by updating the first RLC state variable, perform RLC discard, and no longer maintain the data packets discarded by the PDCP layer, thereby avoiding unnecessary RLC retransmission.

[0235] For how the processing unit 401 updates the first PDCP state variable and the first RLC state variable, reference can be made to the related content in the foregoing embodiments, which will not be repeated here.

[0236] The communication unit 403 can also be configured to send a first report to indicate the receiving status of the data packets to the sending device 500. For the specific implementation of the first report, reference can be made to the related content in the foregoing embodiments, which will not be repeated here.

[0237] The communication unit 403 can also be configured to receive indication information of starting RLC discard from the sending device 500 before updating the first RLC state variable, to trigger RLC discard. The indication information can be RLC configuration information or PDCP configuration information. The communication unit 403 can also be configured to receive non-in-order delivery indication from the sending device 500 before updating the first RLC state variable, to trigger RLC discard.

[0238] Specifically, for the specific implementation of each functional unit included in the receiving device 400, reference can be made to the functions of the receiver in the communication method shown in FIG. 7, which will not be repeated here.

[0239] The sending device 500

[0240] The communication unit 501 can be configured to send the data packets.

[0241] The communication unit 501 can also be configured to send a first sequence number gap report to indicate which data packets are discarded by the PDCP layer.

[0242] The communication unit 501 can also be configured to receive the first report sent by the receiving device 400.

[0243] The processing unit 503 can be configured to determine the data packets that are not retransmitted according to the first report.

[0244] Specifically, for the specific implementation of each functional unit included in the sending device 500, reference can be made to the functions of the sender in the communication method shown in FIG. 7, which will not be repeated here.

[0245] 2. For implementing the communication method shown in FIG. 10:

[0246] The receiving device 400

[0247] The communication unit 403 can be configured to receive the data packets transmitted by the sending device 500.

[0248] The communication unit 403 can also be configured to receive the discard timer configured by the sending device.

[0249] The processing unit 401 can be configured to determine that there is uncompletely received data packet between the fourth RLC state variable and the first RLC state variable, and start the discard timer.

[0250] The processing unit 401 can also be configured to update the first RLC state variable and the fourth RLC state variable in case that the discard timer expires.

[0251] The first RLC state variable can be used to indicate the sequence number of the first data packet that has not been completely received by the receiving RLC entity. The first RLC state variable can be the state variable RX_Next of the aforementioned RLC reception window.

[0252] The fourth RLC state variable can be a new state variable introduced by the embodiments of the present application for the RLC reception window, which can be marked as RX_DELIV. It can be used to indicate the sequence number of the first data packet delivered to the upper layer by the receiving RLC entity.

[0253] For how to update the first RLC state variable and the fourth RLC state variable, reference can be made to the related content in the communication method shown in FIG. 8, which will not be repeated here.

[0254] The processing unit 401 can also be configured to update the first PDCP state variable by the receiving PDCP entity in case that the reordering timer expires. The first PDCP state variable can be used to indicate the sequence number of the first data packet that has not been delivered to the upper layer by the receiving PDCP entity. The first PDCP state variable can be the state variable RX_DELIV of the aforementioned PDCP reception window.

[0255] Specifically, the processing unit 401 can be configured to update the first PDCP state variable to the sequence number of the first data packet that has not been delivered to the upper layer and has not been discarded by the sending PDCP entity after the second PDCP state variable. The second PDCP state variable can be used to indicate the sequence number after the sequence number of the data packet triggering the reordering timer. The second PDCP state variable can be the aforementioned RX_REORD.

[0256] The communication unit 403 can also be configured to send the first report, which indicates the receiving status of the data packet to the sending device through the first report. For the specific implementation of the first report, reference can be made to the related content in the aforementioned embodiments, which will not be repeated here.

[0257] Specifically, for the specific implementation of each functional unit included in the receiving device 400, reference can be made to the functions of the receiving device in the communication method shown in FIG. 10, which will not be repeated here.

[0258] The sending device 500

[0259] The communication unit 501 can be configured to send the data packet.

[0260] The communication unit 501 can also be configured to configure the discard timer to the receiving side.

[0261] The communication unit 501 can also be configured to receive the first report sent by the receiving device 400.

[0262] The processing unit 503 can be configured to determine the data packet not to be retransmitted according to the first report.

[0263] Specifically, the specific implementation of each functional unit included in the sending device 500 can refer to the functions of the sender in the communication method shown in FIG. 10, which will not be repeated here.

[0264] FIG. 16 shows a processing device provided in the present application. As shown in FIG. 16, the device 50 can include a processor 504 and one or more interfaces 502 coupled to the processor 504. Wherein:

[0265] The processor 504 can be configured to read and execute computer readable instructions. In a specific implementation, the processor 504 can mainly include a controller, an arithmetic unit and a register. Wherein, the controller is mainly responsible for instruction decoding and sending control signals for the operation of the instruction. The arithmetic unit is mainly responsible for performing fixed-point or floating-point arithmetic operations, shift operations and logic operations, etc., and can also perform address operations and conversion. The register is mainly responsible for saving the register operands and intermediate operation results temporarily stored in the instruction execution process, etc. In a specific implementation, the hardware architecture of the processor 504 can be an Application Specific Integrated Circuits (ASIC) architecture, a MIPS architecture, an ARM architecture or an NP architecture, etc. The processor 504 can be single-core or multi-core.

[0266] The interface 502 can be configured to input the data to be processed to the processor 504, and can output the processing result of the processor 504 to the outside. In a specific implementation, the interface 502 can be a General Purpose Input Output (GPIO) interface, which can be connected with a plurality of peripheral devices (such as a radio frequency module, etc.). The interface 502 can also include a plurality of independent interfaces, such as an Ethernet interface, a mobile communication interface (such as an X1 interface), etc., which are respectively responsible for the communication between different peripheral devices and the processor 504.

[0267] In the embodiments of the present application, the processor 504 can be configured to call the implementation program of the communication method provided by the embodiments of the present application from the memory, and execute the program. The interface 502 can be configured to output the execution result of the processor 504. In the present application, the interface 502 can be specifically configured to output the processing result of the processor 504. The communication method provided by one or more embodiments of the present application can refer to the foregoing embodiments, which will not be described here.

[0268] It should be noted that the functions of the processor 504 and the interface 502 can be realized by hardware design, software design, or a combination of software and hardware, which is not limited here.

[0269] The steps of the method or algorithm described in connection with the embodiments of the present application can be implemented in hardware, or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in RAM, flash memory, ROM, erasable programmable read-only memory (EPROM), electrically EPROM (EEPROM), register, hard disk, mobile hard disk, compact disc read-only memory (CD-ROM), or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor, so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and the storage medium can be located in an ASIC. In addition, the ASIC can be located in a transceiver or a relay device. Of course, the processor and the storage medium can also exist as discrete components in a wireless access network device or a terminal device.

[0270] Those skilled in the art should realize that in one or more of the above examples, the functions described by the embodiments of the present application can be implemented by hardware, software, firmware or any combination thereof. When implemented by software, these functions can be stored in a computer readable medium or transmitted as one or more instructions or codes on a computer readable medium. The computer readable medium includes computer storage medium and communication medium, wherein the communication medium includes any medium that facilitates the transmission of computer programs from one place to another. The storage medium can be any available medium that can be accessed by a general or special purpose computer.

[0271] The above detailed description of the embodiments of the present application is only for the purpose of illustrating the principles of the present application and its application, and is not intended to limit the scope of the present application as defined in the appended claims.

Claims

1. A communication method characterized by comprising: Comprising: In case that the receiving PDCP entity updates the first PDCP status variable, the receiving PDCP entity indicates the first indication information to the receiving RLC entity; the first PDCP status variable is used to indicate the number of the first data packet which has not been delivered to the upper layer by the receiving PDCP entity; In case that the receiving RLC entity receives the first indication information, the receiving RLC entity updates the first RLC status variable, which is used to indicate the number of the data packet which is received by the receiving RLC entity in sequence continuously and after which the number is not received.

2. The method of claim 1, wherein, The trigger condition of the receiving PDCP entity updating the first PDCP status variable comprises any one of the following: The reordering timer expires, the first PDCP status variable is less than or equal to the maximum COUNT value of the discarded data packet, or the receiving PDCP entity receives the data packet with the number equal to the first PDCP status variable.

3. The method of any one of claims 1-2, wherein, The receiving PDCP entity updates the first PDCP status variable according to the discarded data packet of the sending PDCP entity.

4. The method of claim 3, wherein, Further comprising: The receiving PDCP entity receives the first sequence number gap report, which is used to indicate the discarded data packet of the sending PDCP entity.

5. The method of claim 3 or 4, wherein, The receiving PDCP entity updates the first PDCP status variable according to the discarded data packet of the sending PDCP entity, comprising: In case that the reordering timer expires, the receiving PDCP entity updates the first PDCP status variable to the number of the first data packet which has not been delivered to the upper layer and has not been discarded by the sending PDCP entity after the second PDCP status variable; the second PDCP status variable is used to indicate the number after the number of the data packet which triggers the reordering timer.

6. The method of claim 3 or 4, wherein, The receiving PDCP entity updates the first PDCP status variable according to the discarded data packet of the sending PDCP entity, comprising: In case that the first PDCP status variable is less than or equal to the maximum COUNT value of the discarded data packet, or the receiving PDCP entity receives the data packet with the number equal to the first PDCP status variable, the receiving PDCP entity updates the first PDCP status variable to the number of the first data packet which has not been delivered to the upper layer and has not been discarded by the sending PDCP entity after the first PDCP status variable.

7. The method of any one of claims 1-6, wherein, The updating of the first RLC status variable comprises updating the first RLC status variable to the number of the first data packet which has not been received completely after the second data packet; the number of the second data packet at the PDCP layer is equal to the updated first PDCP status variable, or the number of the second data packet at the PDCP layer is less than or equal to the third PDCP status variable which is used to indicate the number of the next data packet expected to be received by the receiving PDCP entity.

8. The method of claim 7, wherein, The first indication information is used to indicate that the first PDCP status variable is updated to the number of the second data packet.

9. The method of any one of claims 1-8, wherein, Further comprising: If the updated first RLC status variable is greater than a second RLC status variable, the receiving RLC entity updates the second RLC status variable to a number of a data packet that has not been completely received after the updated first RLC status variable; the second RLC status variable is used to indicate a highest possible number when a status PDU needs to be built.

10. The method of any one of claims 1-9, wherein, Further comprising: If the updated first RLC status variable is greater than a third RLC status variable, the receiving RLC entity updates the third RLC status variable to be equal to a fourth RLC status variable, the third RLC status variable is used to indicate a number after a number of a RLC SDU triggering a reassembly timer, and the fourth RLC status variable is used to indicate a number after a highest number of a RLC SDU received.

11. The method of any one of claims 1-10, wherein, After the updating the first RLC status variable, further comprising: the receiving RLC entity sending a first report, the first report being used to indicate a receiving status of the data packets.

12. The method of claim 11, wherein, The first report is specifically used to indicate that a receiving status of the data packets between the first RLC status variable before the updating and the first RLC status variable after the updating is a confirmed receiving.

13. The method of claim 12, wherein, The first report is specifically used to indicate one or more of the following: a receiving status of the data packets that have not been completely received between the first RLC status variable after the updating and the second RLC status variable after the updating is an unconfirmed receiving, and a receiving status of the data packets that have been completely received between the first RLC status variable after the updating and the second RLC status variable after the updating is a confirmed receiving.

14. The method of any one of claims 1-13, wherein, The receiving PDCP entity indicates the first indication information to the receiving RLC entity or a condition that the receiving RLC entity updates the first RLC status variable comprises any one of the following: the receiving PDCP entity does not receive a non-in-sequence delivery indication, the receiving PDCP entity receives second indication information, and the receiving RLC entity receives the second indication information. The second indication information is used to indicate the first indication information to the receiving RLC entity in a case that the receiving PDCP entity updates the first PDCP status variable, or is used to indicate the receiving RLC entity to update the first RLC status variable.

15. A method of communication, comprising: Further comprising: In a case that the receiving RLC entity determines that there is a data packet that has not been completely received between the fourth RLC status variable and the first RLC status variable, starting a discard timer; The discard timer expires, and the receiving RLC entity updates the first RLC status variable; The first RLC status variable is used to indicate a number of a data packet that has not been completely received by the receiving RLC entity, and the fourth RLC status variable is used to indicate a number of a first data packet delivered to an upper layer by the receiving RLC entity.

16. The method of claim 15, wherein, The updating the first RLC status variable specifically comprises updating the first RLC status variable to a number of a first data packet that has not been completely received after the fourth RLC status variable.

17. The method of claim 16, wherein, Further comprising: updating the fourth RLC status variable to a number of a first packet not completely received after the updated first RLC status variable.

18. The method of claim 17, wherein, Further comprising: if the updated first RLC status variable is greater than the second RLC status variable, the receiving RLC entity updating the second RLC status variable to a number of a first packet not completely received after the updated first RLC status variable; the second RLC status variable being used to indicate a next number of a number of a packet triggering a reordering timer.

19. The method of claim 17 or 18, wherein, Further comprising: if the updated first RLC status variable is greater than the third RLC status variable, the receiving RLC entity updating the third RLC status variable to be equal to the fourth RLC status variable.

20. The method of any one of claims 16-19, wherein, Before the receiving RLC entity determines that there is a packet not completely received between the fourth RLC status variable and the first RLC status variable, the method further comprises: the reordering timer expires, and the receiving PDCP entity updates the first PDCP status variable; the first PDCP status variable being used to indicate a number of a first packet not delivered to an upper layer by the receiving PDCP entity.

21. The method of claim 20, wherein, the receiving PDCP entity updating the first PDCP status variable, specifically comprising: the receiving PDCP entity updating the first PDCP status variable to a number of a first packet not delivered to an upper layer and not discarded by the sending PDCP entity after a second PDCP status variable; the second PDCP status variable being used to indicate a number after a number of a packet triggering a reordering timer.

22. The method of any one of claims 16-21, wherein, Further comprising: the receiving RLC entity receiving the discard timer configured by the sending RLC entity.

23. The method of any one of claims 16-22, wherein, After the receiving RLC entity updates the first RLC status variable and the fourth RLC status variable, the method further comprises: the receiving RLC entity sending a first report, the first report being used to indicate a receiving status of a packet.

24. The method of claim 23, wherein, the first report specifically being used to indicate that a receiving status of a packet between the first RLC status variable before updating and the fourth RLC status variable before updating is received.

25. A communications device, comprising: Comprising: a transmitter, a memory, and a processor coupled to the memory, wherein: the memory has stored thereon a computer program, and the computer program is run by the processor to implement the method of any one of claims 1-15.

26. A communications device, comprising: Comprising: a transmitter, a memory, and a processor coupled to the memory, wherein: the memory has stored thereon a computer program, and the computer program is run by the processor to implement the method of any one of claims 16-24.

Images