Data synchronization methods, receiving terminals, electronic devices, and storage media

Abstract

This invention discloses a data synchronization method, a receiving terminal, an electronic device, and a storage medium. The data deletion method, applied at the receiving end, includes: the Receiving Controller (RLC) attempts to parse a PDCP PDU segmented from the received RLC PDU or PDU, and reports this to the PDCP for synchronization. When the PDCP has already received a PDCP PDU from another RLC entity or has received a PDCP PDU with a higher SN number, it feeds back to the RLC entity, informing it of the highest consecutive SN number received. The RLC, combined with the SN number provided by the PDCP, updates its local state variables and sends a status report to the peer with the latest VR(MS), notifying the peer to delete the RLC PDU that is being transmitted over the air interface but has not yet been received or fully received by the receiving end. This invention optimizes the discard mechanism and the peer's status report response mechanism under the existing protocol framework.

Description

[0001] This application is a divisional application of Chinese patent application filed on October 16, 2020, with application number 2020111107525, entitled "Data Deletion and Synchronization Method and Transceiver Terminal, Electronic Device and Storage Medium". Technical Field

[0002] This invention belongs to the field of wireless communication, and particularly relates to a data synchronization method, a receiving terminal, an electronic device, and a storage medium. Background Technology

[0003] To achieve higher throughput and lower latency at the access network layer, LTE (Long Term Evolution, a wireless data communication technology standard) employs the EN-DC (E-UTRA and NR dual connectivity connected to the LTE EPC) method to share NR (New Radio) access network resources, thereby achieving higher transmission rates and reliability. Simultaneously, the PDCP duplication function (Packet Data Convergence Protocol) is specifically designed. This function requires that data packets be transmitted simultaneously on both the primary and secondary connections, with acknowledgment performed at the peer's PDCP / RLC (Radio Link Control) (either the primary or secondary connection). However, since one entity at the receiving end always receives the duplication's SN (sequence number) data packet from the transmitting end first (e.g., the primary connection receives it earlier), the secondary connection's RLC needs to be notified to perform the corresponding duplicate packet deletion action. However, since the protocol specification does not specify the constraints for duplicate packet deletion based on the higher-level discard command in RLC, and what the difference is between the non-duplication function and the following two optimization scenarios may occur:

[0004] 1. For packets that the peer has already acknowledged receipt of, the other RLC, although it has not received a status packet confirmation, has received an ACK from the MAC (Media Access Control) layer. According to the existing procedure, the packet will not be discarded in this situation. Since the peer has already acknowledged receipt, the RLC will confirm receipt when the next status report arrives. However, according to the protocol, the PDCP discard RLC will not respond at this time, so memory cannot be released in a timely manner, affecting actual performance.

[0005] 2. For the peer RLC, the protocol specification does not explicitly define the difference between sending status packets and non-duplication scenarios. Therefore, according to the current process, the local RLC must wait until it receives the data before replying to the peer with an ACK. However, due to the uncertainty of the air interface, the other RLC may have already received the data packet. In this case, if the current process is followed without sending a status report, it will affect the peer RLC's confirmation speed and may also introduce additional air interface duplicate packet retransmissions, reducing the effective value of T-Put and affecting the user experience. Summary of the Invention

[0006] The technical problem to be solved by this invention is to overcome the defect in the prior art that, in the PDCP duplication scenario, the RLC only actively deletes data packets that have not yet been assembled into an RLC PDU, but does not delete data packets that have been assembled, which leads to the memory not being released in time and affecting the actual performance. It also overcomes the defect in the prior art that, in the PDCP duplication scenario, the RLC only replies to the peer ACK after receiving data, which affects the confirmation speed of the peer RLC and may also introduce additional air interface duplicate packet retransmissions, reducing the effective value of T-Put. The invention provides a data deletion and synchronization method, as well as a transceiver terminal, electronic device and storage medium.

[0007] The present invention solves the above-mentioned technical problems through the following technical solutions:

[0008] A data deletion method for PDCP duplication scenarios, wherein the data deletion method is applied at the originating end, and the data deletion method includes:

[0009] In the PDCP duplication scenario, when the RLC receives a deletion instruction from the PDCP, if the PDCP PDU to be deleted by the deletion instruction has already been assembled into an RLC PDU, the decision on whether to delete the PDCP PDU to be deleted is based on the current transmission status of the RLC PDU on the air interface.

[0010] Preferably, the decision to delete the indicated PDCP PDU is made based on the current transmission status of the RLC PDU over the air interface, specifically including:

[0011] The deletion operation is performed on the PDCP PDU that is to be deleted after all MAC HARQ processes involved in the PDCP PDU that is to be deleted have received ACK or reached the maximum number of retransmissions with NACK.

[0012] Preferably, in a PDCP duplication scenario, when the RLC receives a deletion instruction from the PDCP, if the PDCP PDU to be deleted by the deletion instruction has already been assembled into an RLC PDU, then the RLC determines whether to delete the PDCP PDU to be deleted based on the current transmission status of the RLC PDU on the air interface. Specifically, this includes the RLC performing the following steps:

[0013] Receive deletion instructions from PDCP;

[0014] Determine whether the PDCP PDU to be deleted has already been incorporated into an RLC PDU. If not, delete the PDCP PDU to be deleted. If so, then:

[0015] Determine if the current RLC send queue has been completely traversed to attempt to search for an RLCPDU containing the PDCP PDU that was instructed to be deleted. If not, then:

[0016] Determine if the searched RLC PDU contains the PDCP PDU that was instructed to be deleted. If not, return to the step of determining whether the current RLC send queue has been traversed. If yes, then:

[0017] Determine whether the PDCP PDU to be deleted has been fully assembled into an RLC PDU and whether there are any unassembled payloads. If so, determine whether all RLC PDUs containing the PDCP PDU to be deleted have received a complete HARQ ACK from the MAC layer. If not, delete the unassembled PDCP PDU portion, find all RLC PDUs related to the PDCP PDU to be deleted, and then determine whether all RLC PDUs containing the PDCP PDU to be deleted have received a complete HARQ ACK from the MAC layer.

[0018] If it is determined that all RLC PDUs containing the PDCP PDU to be deleted have received a complete HARQ ACK from the MAC layer, then delete the PDCP PDU to be deleted; otherwise, check if all RLC PDUs containing the PDCP PDU to be deleted that have not yet received a complete HARQ ACK have been traversed. If yes, return to the step of checking if all RLC PDUs containing the PDCP PDU to be deleted have received a complete HARQ ACK from the MAC layer; if no, then:

[0019] Determine whether all MAC PDUs contained in a single RLC PDU have received HARQ ACK. If yes, return to the step of determining whether all RLC PDUs containing the PDCP PDU that was instructed to be deleted have received complete HARQ ACKs from the MAC layer. If no, then:

[0020] Determine if all MAC PDUs containing RLC PDUs that have not yet been HARQ acknowledged have been traversed. If yes, return to the step of determining if all MAC PDUs contained in a single RLC PDU have received HARQ ACKs. If no, then:

[0021] Determine whether a single MAC PDU has received a HARQ ACK from the MAC. If yes, return to the step of determining whether all MAC PDUs contained in a single RLCPDU have received a HARQ ACK. If no, wait for a subsequent HARQ ACK before notifying the RLC PDU to delete it, and then return to the step of determining whether all MAC PDUs contained in a single RLC PDU have received a HARQ ACK.

[0022] A data synchronization method for PDCP duplication scenarios, wherein the data synchronization method is applied at the sending end, and the data synchronization method includes:

[0023] RLC determines whether the current time is within the Pbit prohibit timer protection range;

[0024] If it is not within the protection of the Pbit prohibit timer, the RLC will actively trigger the RLC PDU carrying the Pbit to send to the peer, instructing the peer to reply with a status report and notify the peer to synchronize the status variables with the PDCP.

[0025] If within the Pbit prohibit timer protection period, the RLC will wait for the Pbit prohibit timer to expire and then actively trigger the RLC PDU carrying the Pbit to be sent to the peer, instructing the peer to reply with a status report and notifying the peer to synchronize the status variables with the PDCP.

[0026] Preferably, the data synchronization method is executed after the data deletion method described above is executed.

[0027] Preferably, the data synchronization method further includes:

[0028] RLC receives a full ACK status report and requests MAC to release RLC PDU resources;

[0029] After receiving an RLC request, MAC determines whether the RLC PDU that needs to be released is contained in the HARQ buffer. If it is, it determines whether the HARQ has stopped. If it has stopped, it replies to RLC that the PDU can be deleted. Otherwise, it waits for the HARQ to stop before replying to RLC that the PDU resource can be deleted.

[0030] After receiving a response from the MAC indicating that PDU deletion is possible, the RLC deletes the confirmed PDU resources. A data synchronization method for a PDCP duplication scenario is also provided, applied at the receiving end, comprising:

[0031] The RLC attempts to parse the PDCP PDU based on the received RLC PDU or PDU segment and reports it to the PDCP for synchronization. When the PDCP has already received the PDCP PDU or a PDCP PDU with a higher SN number in another RLC entity, it will feed back to the RLC entity, informing it of the highest consecutive SN number received. The RLC, in conjunction with the SN number given by the PDCP, determines whether it has ever received an RLC PDU or PDU segment containing this SN. Based on the determination result, it updates its local status variables and gives the peer a status report with the latest VR (MS), notifying the peer to delete the RLC PDU that is being transmitted over the air interface but has not yet been received or fully received by the receiving end.

[0032] Preferably, the data synchronization method specifically includes:

[0033] RLC determines whether the RLC packet corresponding to VR(MS) can be parsed to obtain the PDCP header. If so, it finds the PDCP SN number corresponding to the VR(MS) RLC packet. Otherwise, it finds the PDCP SN number corresponding to the nearest RLC packet or fragment that can be parsed to obtain the PDCP header.

[0034] The RLC reports the PDCP SN number I found to the PDCP;

[0035] PDCP finds the highest continuously received PDCP SN number M, compares M with I. If M>=I, it informs RLC that all packets before the PDCP SN number reported by RLC have been received normally and informs RLC the highest continuously received PDCP SN number M of the current PDCP instance. If M<I, it informs RLC that all packets before the PDCP SN number reported by RLC have not been fully received and informs RLC the highest continuously received PDCP SN number M of the current PDCP instance.

[0036] If all packets prior to the PDCP SN number reported by PDCP to RLC in the aforementioned steps have been received normally, then after RLC receives the PDCP query result M:

[0037] If the RLC packet SN corresponding to the reported PDCP SN is obtained by parsing the RLC packet corresponding to VR(MS), then it is determined whether the highest consecutively received PDCP SN=M in the current PDCP reply can be found in the RLC receive queue to be included. If RLC SN=L can be found, then VR(MS) is updated to the first non-consecutive PDUSN after L-1, and then VR(R) is updated to the last consecutively received packet before VR(MS), and the relevant NACK SN is updated. If it cannot be found, then VR(R) is updated to the last consecutively received packet before VR(MS), and the relevant NACK SN is updated.

[0038] If the RLC packet SN corresponding to the reported PDCP SN is obtained by parsing the RLC packet or fragment SN=K that is before VR(MS) and closest to VR(MS), then try to update the last consecutive complete packet after V(R)=K-1, and then try to update VR(MS) to max(the last non-consecutive complete packet after K-1, the original VR(MS));

[0039] Then, reply to the peer's status report based on the updated status variables;

[0040] If, in the preceding steps, all packets prior to the PDCP SN number reported by PDCP to RLC have not been fully received, then after RLC receives the PDCP query result M:

[0041] If packets prior to the currently reported PDCP SN have not been successfully received, then:

[0042] Determine whether the highest consecutively received PDCP SN=M in the current PDCP reply can be found in the RLC receive queue and included. If RLC SN=L can be found, then update VR(MS) to the first non-consecutive PDU SN after L-1.

[0043] Reply to the peer's status report based on the updated status variables.

[0044] A sending terminal for performing data deletion in a PDCP duplication scenario, the sending terminal comprising:

[0045] The data deletion module is used in PDCP duplication scenarios. When the RLC receives a deletion instruction from the PDCP, if the PDCP PDU to be deleted by the deletion instruction has been assembled into an RLC PDU, the module determines whether to delete the PDCP PDU to be deleted based on the current transmission status of the RLC PDU on the air interface.

[0046] Preferably, the decision to delete the indicated PDCP PDU is made based on the current transmission status of the RLC PDU over the air interface, specifically including:

[0047] The deletion operation is performed on the PDCP PDU that is to be deleted after all MAC HARQ processes involved in the PDCP PDU that is to be deleted have received ACK or reached the maximum number of retransmissions with NACK.

[0048] Preferably, the data deletion module includes:

[0049] The instruction receiving unit is used to receive deletion instructions sent by PDCP at the RLC layer;

[0050] The execution unit is removed for implementation at the RLC layer:

[0051] Determine whether the PDCP PDU to be deleted has already been incorporated into an RLC PDU. If not, delete the PDCP PDU to be deleted. If so, then:

[0052] Determine if the current RLC send queue has been completely traversed to attempt to search for an RLCPDU containing the PDCP PDU that was instructed to be deleted. If not, then:

[0053] Determine if the searched RLC PDU contains the PDCP PDU that was instructed to be deleted. If not, check again whether the current RLC send queue has been traversed. If yes, then:

[0054] Determine whether the PDCP PDU to be deleted has been fully assembled into an RLC PDU and whether there are any unassembled payloads. If so, determine whether all RLC PDUs containing the PDCP PDU to be deleted have received a complete HARQ ACK from the MAC layer. If not, delete the unassembled PDCP PDU portion, find all RLC PDUs related to the PDCP PDU to be deleted, and then determine whether all RLC PDUs containing the PDCP PDU to be deleted have received a complete HARQ ACK from the MAC layer.

[0055] If it is determined that all RLC PDUs containing the PDCP PDU to be deleted have received a complete HARQ ACK from the MAC layer, then delete the PDCP PDU to be deleted; otherwise, check if all RLC PDUs containing the PDCP PDU to be deleted that have not yet received a complete HARQ ACK have been traversed. If so, check again whether all RLC PDUs containing the PDCP PDU to be deleted have received a complete HARQ ACK from the MAC layer. If not, then:

[0056] Determine whether all MAC PDUs contained in a single RLC PDU have received HARQ ACK. If yes, then determine again whether all RLC PDUs containing the PDCP PDU that was instructed to be deleted have received complete HARQ ACKs from the MAC layer. If not, then:

[0057] Determine if all MAC PDUs containing RLC PDUs that have not yet been HARQ acknowledged have been traversed. If yes, then check again if all MAC PDUs contained in a single RLC PDU have received HARQ ACKs. If no, then:

[0058] Determine whether a single MAC PDU has received a HARQ ACK from the MAC. If yes, then determine whether all MAC PDUs contained in a single RLCPDU have received a HARQ ACK. If no, wait for subsequent HARQ ACKs before notifying the RLCPDU to delete it, and then determine again whether all MAC PDUs contained in a single RLC PDU have received a HARQ ACK.

[0059] A transmitting terminal for data synchronization in a PDCP duplication scenario, the transmitting terminal comprising:

[0060] The data synchronization module includes:

[0061] Synchronization indicator unit, used for implementation at the RLC layer:

[0062] Determine if the current time is within the Pbit prohibit timer protection range;

[0063] If it is not within the protection of the Pbit prohibit timer, the RLC will actively trigger the RLC PDU carrying the Pbit to send to the peer, instructing the peer to reply with a status report and notify the peer to synchronize the status variables with the PDCP.

[0064] If within the Pbit prohibit timer protection period, the RLC will wait for the Pbit prohibit timer to expire and then actively trigger the RLC PDU carrying the Pbit to be sent to the peer, instructing the peer to reply with a status report and notifying the peer to synchronize the status variables with the PDCP.

[0065] Preferably, the data synchronization module operates after the sending terminal has completed data deletion.

[0066] Preferably, the data synchronization module further includes:

[0067] The release request unit is used in the RLC layer to implement: upon receiving a full ACK status report, requesting the release of RLC PDU resources from the MAC layer;

[0068] The judgment and response unit is used in the MAC layer to implement: after receiving the RLC request, it determines whether the RLCPDU that needs to be released is contained in the HARQ buffer. If it is contained, it determines whether the current HARQ has stopped. If it has stopped, it replies to the RLC that the PDU can be deleted. Otherwise, it waits for the HARQ to stop before replying to the RLC that the PDU resource can be deleted.

[0069] The deletion operation unit is used in the RLC layer to perform the deletion operation on the confirmed PDU resource after receiving a reply from the MAC indicating that PDU deletion is possible.

[0070] A receiving terminal for data synchronization in a PDCP duplication scenario, the receiving terminal comprising:

[0071] The data synchronization module is used at the RLC layer to: attempt to parse the PDCPPDU based on the received RLC PDU or PDU segment, and report to the PDCP for synchronization. When the PDCP has already received the PDCP PDU or a PDCP PDU with a higher SN number in another RLC entity, it will feed back to the RLC entity, informing the RLC entity of the highest consecutive SN number received. The RLC, in conjunction with the SN number given by the PDCP, determines whether it has received an RLC PDU or PDU segment containing this SN. Based on the determination result, it updates the local status variables and gives the peer a status report with the latest VR(MS), notifying the peer to delete the RLC PDU that is being transmitted over the air interface but has not yet been received or fully received by the receiving terminal.

[0072] Preferably, the data synchronization module includes:

[0073] The SN parsing unit is used at the RLC layer to: determine whether the RLC packet corresponding to VR(MS) can be parsed to obtain the PDCP header; if so, find the PDCP SN number corresponding to the VR(MS) RLC packet; otherwise, find the PDCP SN number corresponding to the nearest RLC packet or fragment that can be parsed to obtain the PDCP header.

[0074] The SN reporting unit is used at the RLC layer to report the found PDCP SN number I to the PDCP.

[0075] The SN comparison unit is used at the PDCP layer to: find the highest continuously received PDCP SN number M, compare M with I, if M>=I, then inform the RLC that all packets before the PDCP SN number reported by the RLC have been received normally and inform the RLC the highest continuously received PDCP SN number M of the current PDCP instance; if M<I, then inform the RLC that all packets before the PDCP SN number reported by the RLC have not been fully received and inform the RLC the highest continuously received PDCP SN number M of the current PDCP instance.

[0076] State update unit, used to implement in the RLC layer:

[0077] If all packets prior to the PDCP SN number reported by PDCP to RLC have been received normally, then after RLC receives the PDCP query result M:

[0078] If the RLC packet SN corresponding to the reported PDCP SN is obtained by parsing the RLC packet corresponding to VR(MS), then it is determined whether the highest consecutively received PDCP SN=M in the current PDCP reply can be found in the RLC receive queue to be included. If RLC SN=L can be found, then VR(MS) is updated to the first non-consecutive PDUSN after L-1, and then VR(R) is updated to the last consecutively received packet before VR(MS), and the relevant NACK SN is updated. If it cannot be found, then VR(R) is updated to the last consecutively received packet before VR(MS), and the relevant NACK SN is updated.

[0079] If the RLC packet SN corresponding to the reported PDCP SN is obtained by parsing the RLC packet or fragment SN=K that is before VR(MS) and closest to VR(MS), then try to update the last consecutive complete packet after V(R)=K-1, and then try to update VR(MS) to max(the last non-consecutive complete packet after K-1, the original VR(MS));

[0080] If all packets have not been fully received before the PDCP SN number reported by the RLC is communicated by the PDCP, the RLC control unit is also used to control the RLC to perform the following functions after receiving the PDCP query result M:

[0081] If packets prior to the currently reported PDCP SN have not been successfully received, then:

[0082] Determine whether the highest consecutively received PDCP SN=M in the current PDCP reply can be found in the RLC receive queue and included. If RLC SN=L can be found, then update VR(MS) to the first non-consecutive PDU SN after L-1.

[0083] The report sending unit is used at the RLC layer to implement: replying to the peer's status report based on the updated status variables.

[0084] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described above.

[0085] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0086] Based on common knowledge in the field, the above-mentioned preferred conditions can be combined arbitrarily to obtain various preferred embodiments of the present invention.

[0087] The positive and progressive effects of this invention are as follows: It optimizes the discard mechanism and the peer's status report response mechanism within the existing protocol framework, addressing some specific constraints under the current PDCP duplication function. When PDCP duplication is enabled, it ensures that, without altering the reliability of air interface transmission, no additional invalid duplicate packets occur at the air interface, thus avoiding additional memory consumption and performance impact.

[0088] Existing technologies, which strictly adhere to protocol constraints for packet deletion at the sending end and status report transmission at the receiving end, can lead to the consumption of additional data storage space and the transmission of additional duplicate packets over the air interface in some scenarios, artificially reducing effective T-put. This invention, by combining the characteristics of the sending and receiving ends when PDCP duplication is enabled, effectively optimizes the process. Firstly, it increases the effective T-put at the sending end by reducing the transmission of duplicate packets without compromising transmission reliability. Secondly, it enables the receiving end to respond to the peer's acknowledgment status report in the fastest possible way, accelerating memory cleanup at the peer and ensuring system stability during large-scale data exchange. Attached Figure Description

[0089] Figure 1 This is a flowchart illustrating the deletion of duplicate packets by the originating RLC instance related to the PDCP duplication function in Embodiment 1 of the present invention.

[0090] Figure 2 This is a flowchart of a data deletion method in a PDCP duplication scenario according to Embodiment 1 of the present invention;

[0091] Figure 3 This is a flowchart illustrating the relevant processing steps after the Secondary RLC at the originating end executes the PDCP discard instruction in Embodiment 1 of the present invention.

[0092] Figure 4 This is a flowchart of a data synchronization method in a PDCP duplication scenario according to Embodiment 1 of the present invention;

[0093] Figure 5 This is a schematic block diagram of a transmitting terminal according to Embodiment 2 of the present invention;

[0094] Figure 6 This is a schematic block diagram of a transmitting terminal according to Embodiment 3 of the present invention;

[0095] Figure 7 This is a schematic block diagram of a receiving terminal according to Embodiment 4 of the present invention;

[0096] Figure 8 This is a schematic diagram of the structure of an electronic device according to Embodiment 5 of the present invention. Detailed Implementation

[0097] The present invention will be further illustrated by way of embodiments below, but the present invention is not limited to the scope of the embodiments described herein.

[0098] Example 1

[0099] Based on current technology, RLC only actively deletes packets that haven't yet been assembled into RLC PDUs. This is correct and reasonable in non-duplication scenarios. However, when duplication is enabled, since the peer's PDCP has already been received, deletion is possible in certain situations. For example, if the MAC has received an ACK, but the status report wasn't received in time due to a prohibit timer or other reasons (the acknowledgment of this status report will definitely be received), RLC can discard the corresponding assembled PDU.

[0100] For the above considerations, this embodiment provides a data deletion method for the PDCP duplication scenario applied to the originator, so as to realize that in the PDCP duplication scenario, even if no status report is received, the PDCP PDU that has been assembled into an RLC PDU can be deleted when the MAC has received an ACK.

[0101] According to existing technology, when the peer RLC replies with a status report, it strictly sets the ACK / NACK status based on the current reception status of its own RLC. However, if the PDCP has already confirmed receipt, in some scenarios, even if no data has been received, an ACK can still be replied in advance. For example, if the PDCP is continuously receiving data, and the PDCP SN number contained in the RLC PDU indicated by the Pbit falls within the range of continuous PDCP reception, a full ACK can be replied without needing to reply with NACK based on the current actual situation.

[0102] For the above considerations, this embodiment provides a data synchronization method for PDCP duplication scenarios applied to both the sending and receiving ends, so that even if no data is received, an ACK can be sent in advance in the PDCP duplication scenario, and the receiving end can reply to the peer's confirmation status report in the fastest way, thus accelerating the peer's memory cleanup.

[0103] Based on the existing protocol description process, this embodiment details the interaction process between Primary RLC / Secondary RLC and PDCP, such as... Figure 1 As shown (this embodiment takes the Primary RLC receiving first as an example), steps S11 to S16 are basically the standard process specified by the protocol. Here, in order to make the process more coherent, they are listed together as practical steps:

[0104] Step S11: Activate Duplication. Figure 1 The left side shows two duplication activation scenarios.

[0105] Scenario 1: Duplication is activated collaboratively by RRC and MAC. The specific process includes:

[0106] Step S1111: Configure Duplication via network-side RRC;

[0107] Step S1112: UE (User Equipment) side RRC response, PDCP Duplication is configured but not activated;

[0108] Step S1113: Configure RRC to enable MAC-CE;

[0109] Step S1114: eNodeB initiates PDCP duplication active MAC-CE;

[0110] Step S1115: MAC instructs PDCP to activate duplication.

[0111] Scenario 2: Duplication is activated by RRC. The specific process includes:

[0112] Step S1121: Configure and activate Duplication directly from the base station side;

[0113] Step S1122: After receiving the information, the UE configures PDCP via RRC and directly enables Duplication.

[0114] Step S12: The originating PDCP organization sends the PDU with SN=1 to both the originating Secondary RLC and the originating Primary RLC.

[0115] Step S13: The sending Primary RLC assembles the SN=J PDU and sends it to the MAC and transmits it to the peer over the air interface; the behavior of the sending Secondary RLC is not constrained except for failing to send the PDU to the peer before the Primary RLC. Specific behavioral scenarios are illustrated in subsequent diagrams.

[0116] Step S14: The peer Primary RLC first receives the RLC PDU with SN=J.

[0117] Step S15: The peer Primary RLC reports the RLC PDU with SN=J to the peer PDCP, and at the same time sends a status report to the originating Primary RLC instance according to the protocol specification.

[0118] Step S16: The originating Primary RLC receives an acknowledgment status report of SN=J.

[0119] Step S17: The sending Primary RLC reports the status to the sending PDCP. The sending PDCP parses the RLC status packet to determine that the packet with SN=1 has been acknowledged as received.

[0120] Step S18: The sending PDCP instructs the sending Secondary RLC to perform the corresponding deletion operation.

[0121] Since the protocol explicitly stipulates that PDCP PDUs that have already been assembled into packets cannot be deleted, this invention provides a data deletion method for PDCP duplication scenarios at the sending end, which can delete PDCP PDUs that have already been assembled into packets under certain conditions. This method includes: in PDCP duplication scenarios, when the RLC receives a deletion instruction from the PDCP, if the PDCP PDU to be deleted by the deletion instruction has already been assembled into an RLCPDU, then a decision is made based on the current transmission status of the RLC PDU on the air interface whether to perform the deletion operation on the PDCP PDU to be deleted. Specifically, determining whether to perform the deletion operation on the PDCP PDU to be deleted based on the current transmission status of the RLC PDU on the air interface can include: performing the deletion operation on the PDCP PDU to be deleted only after all MACHARQ processes related to the PDCP PDU to be deleted have received ACKs or reached the maximum number of retransmissions (NACK).

[0122] The following outlines the specific steps of a data deletion method applied to the PDCP duplication scenario at the origin, such as... Figure 2 As shown, for each PDCP PDU with a PDCP deletion instruction, the RLC (specifically, the originating Secondary RLC in this embodiment) performs the following actions (the deletion order is from low to high to ensure the rationality of air interface timing):

[0123] Step S1801: Receive the deletion instruction from PDCP;

[0124] Step S1802: Determine whether the PDCP PDU to be deleted has been assembled into an RLC PDU. If not, proceed to step S1803; if yes, proceed to step S1804.

[0125] Step S1803: Delete the PDCP PDU that was instructed to be deleted;

[0126] Step S1804: Determine whether the current RLC transmission queue has been traversed to attempt to search for an RLC PDU containing the PDCP PDU that was instructed to be deleted. If yes, it means that after the traversal, no corresponding PDCP PDU was found, indicating that the PDCP PDU has been successfully confirmed and deleted, and no further deletion is needed; otherwise, proceed to step S1805:

[0127] Step S1805: Determine whether the searched RLC PDU contains the PDCP PDU that was instructed to be deleted. If not, return to step S1804; if yes, proceed to step S1806.

[0128] Step S1806: Determine whether the PDCP PDU to be deleted has been fully assembled into an RLC PDU and whether there are no unassembled payloads. If yes, proceed to step S1807; otherwise, proceed to step S1808.

[0129] Step S1807: Determine whether all RLC PDUs containing the PDCP PDUs that were instructed to be deleted have received the HARQ ACK from the MAC layer. If yes, proceed to step S1809; otherwise, proceed to step S1810.

[0130] Step S1808: Delete the contents of the PDCP PDU that has not yet been packaged, then find all RLC PDUs that are related to the PDCP PDU that has been instructed to be deleted, and then execute step S1807.

[0131] Step S1809: Delete the PDCP PDU that was instructed to be deleted;

[0132] Step S1810: Determine whether all RLC PDUs containing the PDCP PDU that has not yet been fully HARQ ACKed have been traversed. If yes, return to step S1807; otherwise, proceed to step S1811.

[0133] Step S1811: Determine whether all MAC PDUs contained in a single RLC PDU have received HARQ ACK. If yes, return to step S1807; otherwise, proceed to step S1812.

[0134] Step S1812: Determine whether all MAC PDUs containing RLC PDUs that have not yet been confirmed by HARQ have been traversed. If yes, return to step S1811; otherwise, proceed to step S1813.

[0135] Step S1813: Determine whether a single MAC PDU has received the MAC's HARQ ACK. If yes, return to step S1811; otherwise, proceed to step S1814.

[0136] Step S1814: Wait for the subsequent HARQ ACK before notifying the RLC PDU to delete, and then return to step S1811.

[0137] After the Secondary RLC has completed the duplication instruction and discarded the PDCP PDU, the flowchart of the originating behavior is as follows: Figure 3 As shown:

[0138] In the case of PDCP duplication, after the PDCP instructs the RLC to delete the PDCP PDU, according to the process described above, the UE deletes some RLC PDUs associated with the PDCP PDU before receiving the status report from the peer. At this point, the state variables of the transmitting and receiving ends of the RLC sublayer may not be synchronized, so the peer needs to send a status report for synchronization. The method for the transmitting end to confirm with the peer is to send a P-bit SN PDU to the peer to trigger a status report. Since the protocol strictly requires that sending the P-bit requires meeting several conditions, such as the P parameter (the number of PDUs or bytes sent exceeds a threshold), windowing, or no new or retransmitted data, this embodiment adds a supplementary PDU carrying the P-bit SN to inform the receiving end to confirm the status packet quickly. Therefore, this embodiment provides a data synchronization method applied to the PDCP duplication scenario at the transmitting end, such as... Figure 3 As shown, it includes:

[0139] Step S21: RLC determines whether it is currently within the protection range of the Pbit prohibit timer. If it is not within the protection range, proceed to step S22. If it is within the protection range of the Pbit prohibit timer, proceed to step S23.

[0140] Step S22: The RLC actively triggers the RLC PDU carrying Pbit to send to the peer, instructing the peer to reply with a status report and notifying the peer to synchronize status variables with the PDCP;

[0141] Step S23: After the Pbit prohibit timer expires, the RLC actively triggers the RLC PDU carrying Pbit to send to the peer, instructing the peer to reply with a status report and notifying the peer to synchronize status variables with the PDCP.

[0142] The data synchronization method of this embodiment can be executed after the data deletion method of embodiment 1, that is, after the RLC deletes duplicate packets, the above steps are used to instruct the peer to reply with a status report.

[0143] This embodiment also provides a data synchronization method applied to the receiving end in a PDCP duplication scenario, which includes: the RLC attempts to parse the PDCP PDU based on the received RLC PDU or PDU segment, and reports it to the PDCP for synchronization. When the PDCP has already received the PDCP PDU or a PDCP PDU with a higher SN number in another RLC entity, it will feed back to the RLC entity, informing the RLC entity of the highest consecutive SN number received. The RLC, in conjunction with the SN number provided by the PDCP, determines whether it has previously received an RLC PDU or PDU segment containing this SN, updates its local status variables based on the determination result, and provides a status report to the peer end with the latest VR(MS), notifying the peer end to delete the RLC PDU that is being transmitted over the air interface but has not yet been received or fully received by the receiving end. The VR(MS) record is the highest SN number value of the ACK_SN in the status report, with an initial value of 0.

[0144] The following describes the specific steps of a data synchronization method applied to a PDCP duplication scenario at the receiving end, such as... Figure 4 As shown:

[0145] Step S301: RLC determines whether the RLC packet corresponding to VR(MS) can be parsed to obtain the PDCP header. If yes, proceed to step S302; otherwise, proceed to step S303.

[0146] Step S302: The RLC finds the PDCP SN number corresponding to the VR(MS)RLC packet, and then executes step S304;

[0147] Step S303: The RLC finds the PDCP SN number corresponding to the RLC packet or fragment whose PDCP header can be parsed from the VR (MS) closest to it, and then executes step S304;

[0148] Step S304: The RLC reports the found PDCP SN number I to the PDCP;

[0149] Step S305: PDCP finds the highest continuously received PDCP SN number M, compares M with I. If M>=I, then proceed to step S306; if M<I, then proceed to step S314.

[0150] Step S306: PDCP informs RLC that all packets previously reported with the PDCP SN number have been received normally and informs RLC of the highest consecutively received PDCP SN number M of the current PDCP instance;

[0151] Step S307: After receiving the query result M from PDCP, RLC determines whether the RLC packet SN corresponding to the reported PDCP SN is parsed from the RLC packet corresponding to VR(MS). If yes, it is considered that all RLC packets less than VR(MS) have been received normally, and step S308 is executed. If no, that is, the RLC packet SN corresponding to the reported PDCP SN is parsed from the RLC packet or fragment SN=K that is before VR(MS) and closest to VR(MS), it is considered that all RLC packets less than SN=K have been received normally, and step S311 is executed.

[0152] Step S308: Determine whether the highest consecutively received PDCP SN=M in the current PDCP reply can be found in the RLC receive queue and included in the corresponding RLC PDU or fragment. If RLC SN=L can be found, proceed to step S309. If not, proceed to step S310.

[0153] Step S309: Update VR(MS) to the first discontinuous PDU SN after L-1;

[0154] Step S310: Attempt to update VR(R) to the last consecutive received packet before VR(MS), update the relevant NACKSN, and then proceed to step S313;

[0155] Step S311: Attempt to update the last consecutive complete packet after V(R) = K-1;

[0156] Step S312: Attempt to update VR(MS) to max(the last non-contiguous complete packet after K-1, the original VR(MS));

[0157] Step S313: Reply to the peer's status report based on the updated status variables.

[0158] Step S314: PDCP informs RLC that all packets before the reported PDCP SN number have not been fully received and informs RLC of the highest consecutively received PDCP SN number M of the current PDCP instance;

[0159] Step S315: Determine whether the highest consecutively received PDCP SN=M in the current PDCP reply can be found in the RLC receive queue and included in the corresponding RLC PDU or fragment. If RLC SN=L can be found, proceed to step S316; otherwise, proceed to step S317.

[0160] Step S316: Update VR(MS) to the first non-contiguous PDU SN after L-1, and then execute step S317;

[0161] Step S317: Reply to the peer's status report based on the updated status variables.

[0162] The following example illustrates this: PDCP responds with PDCP SN=5, RLC VR(MS)=3 (corresponding to PDCP SN=4), VR(R)=1. The RLC receiver receives SN=1, 3 (incomplete), 6 (incomplete), and 7. PDCP SN=5 can find the received PDU fragment on the RLC side. RLC SN=6, so VR(MS) starts searching for the complete received PDU from SN=6. Since RLC SN=6 is a fragment, VR(MS) is updated to 6, and VR(R) is updated to VR(MS)-1=5. The status report is then responded based on the updated status variables.

[0163] After the receiving end replies with a status report, the data synchronization method in the PDCP duplication scenario applied to the sending end in this embodiment may further include:

[0164] Step S41: The RLC receives a full ACK status report and requests the MAC to release the RLC PDU resources;

[0165] Step S42: After receiving the RLC request, the MAC determines whether the RLC PDU that needs to be released is contained in the HARQbuffer. If it is, then proceed to step S43.

[0166] Step S43: The MAC determines whether the current HARQ has stopped (i.e., whether an ACK has been received or the maximum number of retransmissions has been reached). If it has stopped, proceed to step S44. If it has not stopped, proceed to step S44 after waiting for the HARQ to stop.

[0167] Step S44: MAC responds to RLC to perform PDU deletion;

[0168] Step S45: After receiving the MAC's reply that the PDU can be deleted, the RLC performs the deletion operation on the confirmed PDU resource.

[0169] This embodiment addresses some specific constraints under the current PDCP duplication function, optimizing the discard mechanism and the peer's status report response mechanism within the existing protocol framework. When PDCP duplication is enabled, it ensures that, without altering the reliability of air interface transmission, no additional invalid duplicate packets occur at the air interface, thus avoiding additional memory consumption and performance impact. Based on the characteristics of the sending and receiving ends when PDCP duplication is enabled, effective optimizations are made: firstly, it improves the effective T-put at the sending end, reducing duplicate packet transmission without compromising transmission reliability; secondly, it allows the receiving end to respond to the peer's acknowledgment status report in the fastest possible way, accelerating peer memory cleanup and ensuring system stability during large-scale data exchange.

[0170] Example 2

[0171] This embodiment provides a sending terminal for data deletion in a PDCP duplication scenario. For example... Figure 5 As shown, the transmitting terminal includes:

[0172] The data deletion module 51 is used in the PDCP duplication scenario. When the RLC receives a deletion instruction from the PDCP, if the PDCP PDU to be deleted by the deletion instruction has been assembled into an RLC PDU, the module determines whether to delete the PDCP PDU to be deleted based on the current transmission status of the RLC PDU on the air interface.

[0173] In this embodiment, determining whether to delete the PDCP PDU that is indicated for deletion based on the current transmission status of the RLC PDU on the air interface can specifically include:

[0174] The deletion operation is performed on the PDCP PDU that is to be deleted after all MAC HARQ processes involved in the PDCP PDU that is to be deleted have received ACK or reached the maximum number of retransmissions with NACK.

[0175] In this embodiment, the data deletion module 51 may include:

[0176] The instruction receiving unit 511 is used to receive the deletion instruction sent by PDCP at the RLC layer;

[0177] Execution unit 512 is removed for implementation in the RLC layer:

[0178] Determine whether the PDCP PDU to be deleted has already been incorporated into an RLC PDU. If not, delete the PDCP PDU to be deleted. If so, then:

[0179] Determine if the current RLC send queue has been completely traversed to attempt to search for an RLCPDU containing the PDCP PDU that was instructed to be deleted. If not, then:

[0180] Determine if the searched RLC PDU contains the PDCP PDU that was instructed to be deleted. If not, check again whether the current RLC send queue has been traversed. If yes, then:

[0181] Determine whether the PDCP PDU to be deleted has been fully assembled into an RLC PDU and whether there are any unassembled payloads. If so, determine whether all RLC PDUs containing the PDCP PDU to be deleted have received a complete HARQ ACK from the MAC layer. If not, delete the unassembled PDCP PDU portion, find all RLC PDUs related to the PDCP PDU to be deleted, and then determine whether all RLC PDUs containing the PDCP PDU to be deleted have received a complete HARQ ACK from the MAC layer.

[0182] If it is determined that all RLC PDUs containing the PDCP PDU to be deleted have received a complete HARQ ACK from the MAC layer, then delete the PDCP PDU to be deleted; otherwise, check if all RLC PDUs containing the PDCP PDU to be deleted that have not yet received a complete HARQ ACK have been traversed. If so, check again whether all RLC PDUs containing the PDCP PDU to be deleted have received a complete HARQ ACK from the MAC layer. If not, then:

[0183] Determine whether all MAC PDUs contained in a single RLC PDU have received HARQ ACK. If yes, then determine again whether all RLC PDUs containing the PDCP PDU that was instructed to be deleted have received complete HARQ ACKs from the MAC layer. If not, then:

[0184] Determine if all MAC PDUs containing RLC PDUs that have not yet been HARQ acknowledged have been traversed. If yes, then check again if all MAC PDUs contained in a single RLC PDU have received HARQ ACKs. If no, then:

[0185] Determine whether a single MAC PDU has received a HARQ ACK from the MAC. If yes, then determine whether all MAC PDUs contained in a single RLCPDU have received a HARQ ACK. If no, wait for subsequent HARQ ACKs before notifying the RLCPDU to delete it, and then determine again whether all MAC PDUs contained in a single RLC PDU have received a HARQ ACK.

[0186] Example 3

[0187] This embodiment provides a sending terminal for data synchronization in a PDCP duplication scenario. For example... Figure 6 As shown, the transmitting terminal includes:

[0188] Data synchronization module 61 includes:

[0189] Synchronization indicator unit 611 is used to implement the following at the RLC layer:

[0190] Determine if the current time is within the Pbit prohibit timer protection range;

[0191] If it is not within the protection of the Pbit prohibit timer, the RLC will actively trigger the RLC PDU carrying the Pbit to send to the peer, instructing the peer to reply with a status report and notify the peer to synchronize the status variables with the PDCP.

[0192] If within the Pbit prohibit timer protection period, the RLC will wait for the Pbit prohibit timer to expire and then actively trigger the RLC PDU carrying the Pbit to be sent to the peer, instructing the peer to reply with a status report and notifying the peer to synchronize the status variables with the PDCP.

[0193] In this embodiment, the data synchronization module 61 can run after the sending terminal has completed data deletion.

[0194] In this embodiment, the data synchronization module 61 may further include:

[0195] Release request unit 612 is used to implement in the RLC layer: upon receiving a full ACK status report, request the MAC to release RLCPDU resources;

[0196] The judgment and response unit 613 is used in the MAC layer to implement: after receiving the RLC request, it determines whether the RLCPDU that needs to be released is contained in the HARQ buffer. If it is contained, it determines whether the current HARQ has stopped. If it has stopped, it replies to the RLC that the PDU can be deleted. Otherwise, it waits for the HARQ to stop before replying to the RLC that the PDU resource can be deleted.

[0197] The deletion operation unit 614 is used in the RLC layer to perform the deletion operation on the confirmed PDU resource after receiving a reply from the MAC indicating that PDU deletion is possible.

[0198] Example 4

[0199] This embodiment provides a receiving terminal for data synchronization in a PDCP duplication scenario. For example... Figure 7 As shown, the receiving terminal includes:

[0200] The data synchronization module 71 is used to implement the following at the RLC layer: attempt to parse the PDCPPDU based on the received RLC PDU or PDU segment, and report to the PDCP for synchronization. When the PDCP has already received the PDCP PDU or a PDCP PDU with a higher SN number in another RLC entity, it will feed back to the RLC entity, informing the RLC entity of the highest consecutive SN number received. The RLC, in conjunction with the SN number given by the PDCP, determines whether it has received an RLC PDU or PDU segment containing this SN. Based on the determination result, it updates the local status variables and gives the peer a status report with the latest VR(MS), notifying the peer to delete the RLC PDU that is being transmitted over the air interface but has not yet been received or fully received by the receiving terminal.

[0201] In this embodiment, the data synchronization module 71 includes:

[0202] The SN parsing unit 711 is used in the RLC layer to: determine whether the RLC packet corresponding to VR(MS) can be parsed to obtain the PDCP header; if so, find the PDCP SN number corresponding to the VR(MS) RLC packet; otherwise, find the PDCP SN number corresponding to the nearest RLC packet or fragment that can be parsed to obtain the PDCP header.

[0203] SN reporting unit 712 is used at the RLC layer to report the found PDCP SN number I to the PDCP;

[0204] The SN comparison unit 713 is used at the PDCP layer to: find the highest continuously received PDCP SN number M, compare M with I, if M>=I, then inform the RLC that all packets before the PDCP SN number reported by the RLC have been received normally and inform the RLC the highest continuously received PDCP SN number M of the current PDCP instance; if M<I, then inform the RLC that all packets before the PDCP SN number reported by the RLC have not been fully received and inform the RLC the highest continuously received PDCP SN number M of the current PDCP instance.

[0205] State update unit 714 is used to implement the following in the RLC layer:

[0206] If all packets prior to the PDCP SN number reported by PDCP to RLC have been received normally, then after RLC receives the PDCP query result M:

[0207] If the RLC packet SN corresponding to the reported PDCP SN is obtained by parsing the RLC packet corresponding to VR(MS), then it is determined whether the highest consecutively received PDCP SN=M in the current PDCP reply can be found in the RLC receive queue to be included. If RLC SN=L can be found, then VR(MS) is updated to the first non-consecutive PDUSN after L-1, and then VR(R) is updated to the last consecutively received packet before VR(MS), and the relevant NACK SN is updated. If it cannot be found, then VR(R) is updated to the last consecutively received packet before VR(MS), and the relevant NACK SN is updated.

[0208] If the RLC packet SN corresponding to the reported PDCP SN is obtained by parsing the RLC packet or fragment SN=K that is before VR(MS) and closest to VR(MS), then try to update the last consecutive complete packet after V(R)=K-1, and then try to update VR(MS) to max(the last non-consecutive complete packet after K-1, the original VR(MS));

[0209] If all packets have not been fully received before the PDCP SN number reported by the RLC is communicated by the PDCP, the RLC control unit is also used to control the RLC to perform the following functions after receiving the PDCP query result M:

[0210] If packets prior to the currently reported PDCP SN have not been successfully received, then:

[0211] Determine whether the highest consecutively received PDCP SN=M in the current PDCP reply can be found in the RLC receive queue and included. If RLC SN=L can be found, then update VR(MS) to the first non-consecutive PDU SN after L-1.

[0212] The report sending unit 715 is used to implement, at the RLC layer, replying to the peer's status report based on the updated status variables.

[0213] Example 5

[0214] Figure 8 This is a schematic diagram of an electronic device according to Embodiment 5 of the present invention. The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the method of Embodiment 1. Figure 8 The electronic device 80 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0215] like Figure 8As shown, the electronic device 80 can be manifested as a general-purpose computing device, such as a server device. The components of the electronic device 80 may include, but are not limited to: at least one processor 81, at least one memory 82, and a bus 83 connecting different system components (including memory 82 and processor 81).

[0216] Bus 83 includes a data bus, an address bus, and a control bus.

[0217] The memory 82 may include volatile memory, such as random access memory (RAM) 821 and / or cache memory 822, and may further include read-only memory (ROM) 823.

[0218] The memory 82 may also include a program / utility 825 having a set (at least one) of program modules 824, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0219] The processor 81 executes various functional applications and data processing, such as the method provided in Embodiment 1 of the present invention, by running computer programs stored in the memory 82.

[0220] The electronic device 80 can also communicate with one or more external devices 84 (e.g., keyboard, pointing device, etc.). This communication can be performed via input / output (I / O) interface 85. Furthermore, the model-generating device 80 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 86. Figure 8 As shown, network adapter 86 communicates with other modules of the model-generated device 80 via bus 83. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the model-generated device 80, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (disk array) systems, tape drives, and data backup storage systems.

[0221] It should be noted that although several units / modules or sub-units / modules of the electronic device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided and embodied by multiple units / modules.

[0222] Example 6

[0223] This embodiment provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method provided in Embodiment 1.

[0224] The readable storage medium may be more specifically adopted, including but not limited to: portable disk, hard disk, random access memory, read-only memory, erasable programmable read-only memory, optical storage device, magnetic storage device, or any suitable combination thereof.

[0225] In a possible implementation, the present invention can also be implemented as a program product comprising program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps of any of the methods described in Embodiment 1.

[0226] The program code for executing the present invention can be written in any combination of one or more programming languages. The program code can be executed entirely on the user device, partially on the user device, as a standalone software package, partially on the user device and partially on a remote device, or entirely on a remote device.

[0227] While specific embodiments of the present invention have been described above, those skilled in the art should understand that these are merely illustrative examples, and the scope of protection of the present invention is defined by the appended claims. Those skilled in the art can make various changes or modifications to these embodiments without departing from the principles and essence of the present invention, but all such changes and modifications fall within the scope of protection of the present invention.

Claims

1. A data synchronization method for PDCP repetitive function scenarios, characterized in that, The data synchronization method is applied at the receiving end, and the data synchronization method includes: The RLC attempts to parse the PDCP PDU based on the received RLC PDU or PDU segment and reports it to the PDCP for synchronization. When the PDCP has already received the PDCP PDU or a PDCP PDU with a higher SN number in another RLC entity, it will feed back to the RLC entity, informing it of the highest consecutive SN number received. The RLC, in conjunction with the SN number given by the PDCP, determines whether it has received an RLC PDU or PDU segment containing this SN. Based on the determination result, it updates the local status variables and gives the peer a status report with the latest VR (MS), notifying the peer to delete the RLC PDU that is being transmitted over the air interface but has not yet been received or fully received by the receiving end. The data synchronization method specifically includes: RLC determines whether the RLC packet corresponding to VR(MS) can be parsed to obtain the PDCP header. If so, it finds the PDCP SN number corresponding to the VR(MS) RLC packet. Otherwise, it finds the PDCP SN number corresponding to the nearest RLC packet or fragment that can be parsed to obtain the PDCP header. The RLC reports the PDCP SN number I found to the PDCP; PDCP finds the highest continuously received PDCP SN number M, compares M with I. If M>=I, it informs RLC that all packets before the PDCP SN number reported by RLC have been received normally and informs RLC the highest continuously received PDCP SN number M of the current PDCP instance. If M<I, it informs RLC that all packets before the PDCP SN number reported by RLC have not been fully received and informs RLC the highest continuously received PDCP SN number M of the current PDCP instance. If all packets prior to the PDCP SN number reported by PDCP to RLC in the aforementioned steps have been received normally, then after RLC receives the PDCP query result M: If it is determined that all RLC packets less than VR(MS) have been received normally, then it is determined whether the highest consecutively received PDCP SN = M in the current PDCP reply can be found in the RLC receive queue to be included. If RLC SN = L can be found, then VR(MS) is updated to the first non-consecutive PDU SN after L-1, and then VR(R) is updated to the last consecutively received packet before VR(MS), and the relevant NACK SN is updated. If it cannot be found, then VR(R) is updated to the last consecutively received packet before VR(MS), and the relevant NACK SN is updated. If it is determined that all RLC packets less than SN=K have been received normally, then try to update the last consecutive complete packet after V(R)=K-1, and then try to update VR(MS) to max(the last non-consecutive complete packet after K-1, the original VR(MS)). If, in the preceding steps, all packets prior to the PDCP SN number reported by PDCP to RLC have not been fully received, then after RLC receives the PDCP query result M: If packets prior to the currently reported PDCP SN have not been successfully received, then: Determine whether the highest consecutively received PDCP SN = M in the current PDCP response can be found in the RLC receive queue and included in the corresponding RLC PDU or fragment. If RLC SN = L can be found, then update VR(MS) to the first non-consecutive PDU SN after L-1.

2. The data synchronization method as described in claim 1, characterized in that, The data synchronization method further includes: Reply to the peer's status report based on the updated status variables.

3. The data synchronization method as described in claim 2, characterized in that, It has been confirmed that all RLC packets smaller than VR(MS) have been received normally, including: After receiving the query result M from PDCP, RLC determines whether the RLC packet SN number corresponding to the reported PDCP SN number is obtained by parsing the RLC packet corresponding to VR(MS); If so, then it is confirmed that all RLC packets smaller than VR(MS) have been received normally.

4. The data synchronization method as described in claim 2, characterized in that, It has been confirmed that all RLC packets with a length less than SN=K have been received correctly, including: After receiving the query result M from PDCP, RLC determines whether the RLC packet SN corresponding to the reported PDCP SN is obtained by parsing the RLC packet or fragment SN = K that is before VR(MS) and closest to VR(MS); If so, then it is confirmed that all RLC packets with a length less than SN=K have been received normally.

5. The data synchronization method as described in claim 2, characterized in that, The VR(MS) record is the highest SN value of ACK_SN in the status report, with an initial value of 0.

6. The data synchronization method according to any one of claims 1-5, characterized in that, The RLCPDU or PDU segments received by the receiving end are sent by the peer end; wherein, if the peer end's PLC determines that it is not currently within the Pbit prohibit timer protection, it actively triggers an RLC PDU carrying Pbit to send to the receiving end; if the peer end's PLC determines that it is currently within the Pbit prohibit timer protection, it waits for the Pbit prohibit timer to expire and then actively triggers an RLC PDU carrying Pbit to send to the receiving end, so as to instruct the receiving end to reply with a status report and notify the receiving end to synchronize status variables with PDCP.

7. A receiving terminal for data synchronization in a PDCP repetitive function scenario, characterized in that, The receiving terminal includes: The data synchronization module is used at the RLC layer to: attempt to parse the PDCP PDU based on the received RLC PDU or PDU segment, and report to the PDCP for synchronization. When the PDCP has already received the PDCP PDU or received a PDCP PDU with a higher SN number in another RLC entity, it will feed back to the RLC entity, informing the RLC entity of the highest consecutive SN number received. The RLC, in conjunction with the SN number given by the PDCP, determines whether it has received an RLC PDU or PDU segment containing this SN. Based on the determination result, the local status variable is updated, and the latest VR (MS) is given to the peer to report the status, notifying the peer to delete the RLC PDU that is being transmitted over the air interface but has not yet been received or fully received by the receiving terminal. The data synchronization module includes: The SN parsing unit is used at the RLC layer to: determine whether the RLC packet corresponding to VR(MS) can be parsed to obtain the PDCP header; if so, find the PDCP SN number corresponding to the VR(MS) RLC packet; otherwise, find the PDCP SN number corresponding to the nearest RLC packet or fragment that can be parsed to obtain the PDCP header. The SN reporting unit is used at the RLC layer to report the found PDCP SN number I to the PDCP. The SN comparison unit is used at the PDCP layer to: find the highest continuously received PDCP SN number M, compare M with I, if M>=I, then inform the RLC that all packets before the PDCP SN number reported by the RLC have been received normally and inform the RLC the highest continuously received PDCP SN number M of the current PDCP instance; if M<I, then inform the RLC that all packets before the PDCP SN number reported by the RLC have not been fully received and inform the RLC the highest continuously received PDCP SN number M of the current PDCP instance. The state update unit is used to implement the following at the RLC layer: If all packets prior to the PDCP SN number reported by PDCP to RLC have been received normally, then after RLC receives the PDCP query result M: If it is determined that all RLC packets less than VR(MS) have been received normally, then it is determined whether the highest consecutively received PDCP SN = M in the current PDCP reply can be found in the RLC receive queue to be included. If RLC SN = L can be found, then VR(MS) is updated to the first non-consecutive PDU SN after L-1, and then VR(R) is updated to the last consecutively received packet before VR(MS), and the relevant NACK SN is updated. If it cannot be found, then VR(R) is updated to the last consecutively received packet before VR(MS), and the relevant NACK SN is updated. If it is determined that all RLC packets less than SN=K have been received normally, then try to update the last consecutive complete packet after V(R)=K-1, and then try to update VR(MS) to max(the last non-consecutive complete packet after K-1, the original VR(MS)). If all packets before the PDCP SN number reported by the RLC have not been fully received, the RLC, upon receiving the PDCP query result M, will perform the following functions: If packets prior to the currently reported PDCP SN have not been successfully received, then: Determine whether the highest consecutively received PDCP SN = M in the current PDCP response can be found in the RLC receive queue and included in the corresponding RLC PDU or fragment. If RLC SN = L can be found, then update VR(MS) to the first non-consecutive PDU SN after L-1.

8. The receiving terminal as described in claim 7, characterized in that, The data synchronization module also includes: The report sending unit is used at the RLC layer to implement: replying to the peer's status report based on the updated status variables.

9. The receiving terminal as described in claim 8, characterized in that, Once it is determined that all RLC packets corresponding to values ​​less than VR(MS) have been received normally, the state update unit is specifically used for: After receiving the query result M from PDCP, RLC determines whether the RLC packet SN number corresponding to the reported PDCP SN number is obtained by parsing the RLC packet corresponding to VR(MS); If so, then it is confirmed that all RLC packets smaller than VR(MS) have been received normally.

10. The receiving terminal as described in claim 8, characterized in that, Once it is determined that all RLC packets smaller than SN=K have been received normally, the state update unit is specifically used for: After receiving the query result M from PDCP, RLC determines whether the RLC packet SN corresponding to the reported PDCP SN is obtained by parsing the RLC packet or fragment SN = K that is before VR(MS) and closest to VR(MS); If so, then it is confirmed that all RLC packets with a length less than SN=K have been received normally.

11. The receiving terminal as described in any one of claims 7-10, characterized in that, The RLC PDU or PDU segments received by the receiving terminal are sent by the peer; wherein, if the peer PLC determines that it is not currently under Pbit prohibit timer protection, it actively triggers the RLC PDU carrying Pbit to be sent to the receiving terminal; if the peer PLC determines that it is currently under Pbit prohibit timer protection, it waits for the Pbit prohibit timer to expire and then actively triggers the RLC PDU carrying Pbit to be sent to the receiving terminal, so as to instruct the receiving terminal to reply with a status report and notify the receiving terminal to synchronize status variables with PDCP.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method of any one of claims 1 to 6.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images