Superframe number synchronization method and apparatus, communication device, chip, and chip module

Abstract

This application relates to a superframe number synchronization method, apparatus, communication device, chip, and chip module. The method includes: extracting the actually received first Packet Data Convergence Protocol Sequence Number (PDCP SN) from received downlink data packets; generating multiple candidate superframe numbers based on the local superframe number in response to the first PDCP SN being less than the locally expected second PDCP SN; decrypting the downlink data packets based on each candidate superframe number to obtain multiple candidate decryption results; verifying the validity of the multiple candidate decryption results; determining the target superframe number corresponding to the candidate decryption result that passed the validity verification from the multiple candidate superframe numbers; and updating the local superframe number according to the target superframe number. This method can prevent HFN (High-Frequency Packet Number) synchronization failure.

Description

Technical Field

[0001] This application relates to the field of wireless communication technology, and in particular to a superframe number synchronization method, apparatus, communication device, chip, and chip module. Background Technology

[0002] In the 3rd Generation Partnership Project (3GPP) protocol suite, the Packet Data Convergence Protocol (PDCP) layer is responsible for data encryption, decryption, and integrity protection to ensure transmission security. When the receiving end receives a downlink data packet, it needs to deduce the COUNT value used for encryption based on the actual received Packet Data Convergence Protocol Sequence Number (PDCP SN) and the locally maintained Hyper Frame Number (HFN) to complete the decryption operation. Since the COUNT value is composed of the PDCP SN and HFN, the HFN of the sending end and the receiving end must be synchronized to correctly reconstruct the data. However, the HFNs of the sending and receiving ends are maintained independently and do not carry each other's HFNs during interaction. Nevertheless, their HFNs need to be synchronized; therefore, the receiving end's HFN needs to be updated to synchronize with the sending end's HFN. If the HFN update at the receiving end is incorrect, it will lead to an incorrect COUNT value, resulting in the decryption of an incorrect data packet (different from the data packet sent by the sending end). Therefore, HFN synchronization between the sending and receiving ends is crucial.

[0003] In related technologies, when HFN synchronization failure occurs, a reconstruction process is typically triggered to forcibly restore synchronization. However, this method still cannot prevent HFN synchronization failure from occurring, and the reconstruction process causes significant service interruption, thereby affecting the service continuity at the receiving end. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, communication device, chip, and chip module for superframe number synchronization that can prevent HFN from losing synchronization, in order to address the above-mentioned technical problems.

[0005] Firstly, this application provides a superframe number synchronization method, including:

[0006] Extract the actual received first packet data aggregation protocol sequence number (PDCPSN) from the received downlink data packets;

[0007] In response to the first PDCP SN being less than the locally expected second PDCP SN, multiple candidate superframe numbers are generated based on the local superframe number;

[0008] The downlink data packet is decrypted based on each of the multiple candidate superframe numbers to obtain multiple candidate decryption results;

[0009] The validity of the multiple candidate decryption results is verified, and the target superframe number corresponding to the candidate decryption result that has passed the validity verification is determined from the multiple candidate superframe numbers.

[0010] Update the local superframe number based on the target superframe number.

[0011] In one embodiment, determining the target superframe number corresponding to the candidate decryption result that has passed the validity verification from the plurality of candidate superframe numbers includes: in response to the number of candidate decryption results that have passed the validity verification being plurality, selecting any one candidate superframe number corresponding to the candidate decryption result that has passed the validity verification from the plurality of candidate superframe numbers as the target superframe number, wherein the any one candidate superframe number is different from the local superframe number.

[0012] In one embodiment, determining the target superframe number corresponding to the candidate decryption result that has passed the validity verification from the plurality of candidate superframe numbers includes: in response to the number of candidate decryption results that have passed the validity verification being plurality of, selecting the maximum value among the candidate superframe numbers corresponding to the candidate decryption results that have passed the validity verification as the target superframe number, wherein the maximum candidate superframe number is different from the local superframe number.

[0013] In one embodiment, generating multiple candidate superframe numbers based on the local superframe number includes:

[0014] Multiple candidate superframe numbers are generated based on the local superframe number and at least one preset offset, wherein the offset is an integer greater than or equal to 1.

[0015] In one embodiment, the step of decrypting the downlink data packet based on each of the plurality of candidate superframe numbers to obtain a plurality of candidate decryption results includes: determining a candidate count value corresponding to each candidate superframe number according to each candidate superframe number and the first PDCPSN; and using each candidate count value to decrypt the downlink data packet to obtain a candidate decryption result corresponding to each candidate superframe number.

[0016] In one embodiment, the method further includes: in response to all the candidate decryption results failing the validity verification, sending a reconstruction request to the radio resource control layer; wherein the reconstruction request is used to notify the radio resource control layer to initiate a radio resource control reconstruction process.

[0017] Secondly, this application also provides a superframe number synchronization device, comprising:

[0018] The extraction module is used to extract the actual received first packet data aggregation protocol sequence number (PDCP SN) from the received downlink data packets;

[0019] The generation module is used to generate multiple candidate superframe numbers based on the local superframe number in response to the first PDCP SN being less than the second PDCP SN expected to be received locally.

[0020] The decryption module is used to decrypt the downlink data packet based on each of the multiple candidate superframe numbers to obtain multiple candidate decryption results;

[0021] The determination module is used to verify the validity of the plurality of candidate decryption results and determine the target superframe number corresponding to the candidate decryption result that has passed the validity verification from the plurality of candidate superframe numbers;

[0022] The update module is used to update the local superframe number based on the target superframe number.

[0023] Thirdly, this application also provides a communication device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method provided in the first aspect.

[0024] Fourthly, this application also provides a chip including a processor and a communication interface, the processor being configured to cause the chip to perform the steps of the method provided in the first aspect.

[0025] Fifthly, this application also provides a chip module, including a communication module, a power module, a storage module, and a chip, wherein:

[0026] The power module is used to provide power to the chip module;

[0027] The storage module is used to store data and instructions;

[0028] The communication module is used for internal communication within the chip module, or for communication between the chip module and external devices.

[0029] The chip is used to perform the steps of the method provided in the first aspect above.

[0030] Sixthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method provided in the first aspect.

[0031] In a seventh aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in the first aspect.

[0032] The aforementioned superframe number synchronization method, apparatus, communication equipment, chip, and chip module extract the actually received first Packet Data Convergence Protocol Sequence Number (PDCP SN) from the received downlink data packets; in response to the first PDCP SN being less than the locally expected second PDCP SN, generate multiple candidate superframe numbers based on the local superframe number; decrypt the downlink data packets based on each candidate superframe number to obtain multiple candidate decryption results; verify the validity of the multiple candidate decryption results, and determine the target superframe number corresponding to the candidate decryption result that has passed the validity verification from the multiple candidate superframe numbers; update the local superframe number according to the target superframe number. It is evident that, compared to the inevitable service interruption caused by the passive reliance on the reconstruction process to handle HFN synchronization failures in related technologies, this application embodiment actively triggers and completes the HFN synchronization process when the received first PDCP SN is less than the locally expected second PDCP SN, fundamentally reducing or even avoiding reliance on the reconstruction process. This prevents local superframe number synchronization failures caused by downlink data packet loss or out-of-order delivery, thereby improving the robustness of downlink data packet reception. In addition, the embodiments of this application can realize HFN synchronization in a timely manner when the first abnormal downlink data packet (the first PDCP SN is less than the second PDCP SN) arrives, thereby avoiding service flow interruption without the user's awareness and ensuring service continuity at the receiving end. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a state diagram of the PDCP reception sequence in scenarios a and b under the LTE standard;

[0035] Figure 2 This is a schematic diagram of the packet receiving logic, receiver state variable maintenance, and reordering window operation in LTE RLC UM mode.

[0036] Figure 3This is a state diagram of the PDCP reception sequence at a certain moment under the LTE standard;

[0037] Figure 4 This is a schematic diagram of data transmission between RLC and PDCP;

[0038] Figure 5 This is a diagram illustrating the application environment of a superframe number synchronization method in one embodiment.

[0039] Figure 6 This is a flowchart illustrating a superframe number synchronization method in one embodiment;

[0040] Figure 7 This is a schematic diagram illustrating the decryption process of PDCP handling data packet sequence number wrapping in one embodiment;

[0041] Figure 8 This is a flowchart illustrating a superframe number synchronization method in an example.

[0042] Figure 9 This is a structural block diagram of a superframe number synchronization device in one embodiment;

[0043] Figure 10 This is an internal structure diagram of a communication device in one embodiment;

[0044] Figure 11 This is an internal structure diagram of a chip module in one embodiment. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0046] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0047] Explanation of terms used in the embodiments of this application:

[0048] Long Term Evolution (LTE): is a core radio access technology standard for fourth-generation mobile communication (4G) defined by 3GPP.

[0049] Voice over LTE (VoLTE): A technology that enables high-definition voice calls based on the LTE network.

[0050] User Equipment (UE): refers to the terminal equipment that initiates or receives communication services in a mobile communication network.

[0051] Data Radio Bearer (DRB): A logical transmission channel used to carry user plane data in a radio access network.

[0052] Packet Data Convergence Protocol (PDCP): Located in the 3GPP protocol stack, it is a protocol layer responsible for packet header compression, encryption / decryption, and transmission security.

[0053] Radio Link Control (RLC): Located below the PDCP layer, it refers to the protocol layer responsible for link control functions such as data segmentation, retransmission, and in-order delivery.

[0054] Medium Access Control (MAC): Located below the RLC layer, it refers to the protocol layer responsible for scheduling, multiplexing, and physical layer resource access control.

[0055] Unacknowledged Mode (UM): A working mode of the RLC layer, suitable for services that are sensitive to latency but have relatively low reliability requirements.

[0056] Hyper Frame Number (HFN): The high-order part used to generate the encryption count value (COUNT), which is a key parameter to ensure encryption and decryption synchronization.

[0057] Data Radio Bearer (DRB): A logical channel established between a user equipment (UE) and a base station specifically for transmitting user plane data.

[0058] New Radio (NR) is a global radio access technology standard developed by 3GPP for fifth-generation mobile communication systems (5G).

[0059] For the LTE standard, section 5.1.2.1.3 of 3GPP 36.323 describes the downlink data packet reception logic of the DRB mapped to the RLC UM when the reordering function is not enabled. In the UE downlink reception scenario, the base station is the transmitter and the UE is the receiver. If the UE's reordering function is not used, and the actually received PDCP SN (hereinafter referred to as the first PDCP SN) is less than the locally expected next PDCP SN (hereinafter referred to as the second PDCP SN), the local superframe number (RX_HFN) will be incremented by 1. Similarly, in the base station downlink reception scenario, where the UE is the transmitter and the base station is the receiver, the same logic applies.

[0060] For the NR standard, there is a similar description in section 5.2.2.1 of the 3GPP 38.323 protocol, which states that when receiving data in the PDCP downlink, if RCVD_SN is less than SN(RX_DELIV) – Window_Size, then RCVD_HFN is updated to HFN(RX_DELIV) plus 1.

[0061] The RX_HFN and PDCP SN are concatenated to form the COUNT value, which is used in the PDCP layer decryption process. The HFN at the sending end and the HFN at the receiving end are maintained independently, and they do not carry their respective HFN values ​​during interaction. However, their HFNs need to be synchronized. If the receiving end's HFN update is incorrect, it will lead to an incorrect COUNT value, resulting in the decryption of an incorrect data packet (different from the data packet sent by the sending end, not a normal IP packet). After the receiving end's PDCP layer delivers the incorrect data packet to the upper layer, the upper layer cannot parse the data packet, thus affecting the normal operation of data services. The following provides a detailed background introduction, describing the relevant technical implementation scheme and its shortcomings.

[0062] Based on the above description, for the LTE standard, the PDCP downlink data packet reception logic of the DRB mapped to RLC UM when the reordering function is not enabled is described in the 36.323 protocol as follows (direct translation of the original text):

[0063] If the received PDCP SN is less than Next_PDCP_RX_SN:

[0064] Increment RX_HFN by 1;

[0065] As specified in Section 5.6, the PDCP data PDU is decrypted using a COUNT based on RX_HFN and the received PDCP SN;

[0066] Set Next_PDCP_RX_SN to the received PDCP SN plus 1;

[0067] If Next_PDCP_RX_SN is greater than Maximum_PDCP_SN:

[0068] Set Next_PDCP_RX_SN to 0;

[0069] Increment RX_HFN by 1;

[0070] Perform header decompression on the decrypted PDCP data PDU according to the specifications in Section 5.5.5 (if configured).

[0071] The obtained PDCP SDU is submitted to the upper layer.

[0072] For the NR standard, the PDCP downlink data packet reception logic is described in the 38.323 protocol as follows (literal translation):

[0073] When a PDCP data unit is received from the lower layer, the receiving PDCP entity should determine the count value of the received PDCP data unit, i.e., RCVD_COUNT, in the following manner:

[0074] If RCVD_SN < SN(RX_DELIV) – Window_Size:

[0075] RCVD_HFN = HFN(RX_DELIV) + 1;

[0076] Otherwise, if RCVD_SN >= SN(RX_DELIV) + Window_Size:

[0077] RCVD_HFN = HFN(RX_DELIV) – 1;

[0078] otherwise:

[0079] RCVD_HFN = HFN(RX_DELIV);

[0080] RCVD_COUNT = [RCVD_HFN, RCVD_SN].

[0081] The standard correspondence of key terms is as follows:

[0082] RCVD_SN: The currently received PCDN sequence number;

[0083] SN(RX_DELIV): The sequence number corresponding to the state variable RX_DELIV, which usually represents the next in-order sequence number expected to be received;

[0084] RCVD_HFN: HFN of the PDCP receiver;

[0085] HFN(RX_DELIV): The HFN of the latest submitted data, associated with the state variable RX_DELIV;

[0086] Window_Size: Reorders the window size;

[0087] RCVD_COUNT: The received count value, which is composed of the superframe number and the sequence number.

[0088] Let's take the LTE standard as an example. Figure 1 It represents the status of the received packet sequence number (sn) at a certain moment in LTE PDCP. Figure 1 The circles in the diagram represent that PDCP_SN cycles clockwise (the direction of sn increment) in time. Figure 1 Explanation of various terms in Chinese:

[0089] 0 point: SN wrap-around point (returns to 0 after the maximum value);

[0090] Next_PDCP_RX_SN: The current expected receive SN;

[0091] PDCP_SN(a): Scenario a, the currently received sn is less than Next_PDCP_RX_SN;

[0092] PDCP_SN(b): Scenario b, the currently received sn is greater than Next_PDCP_RX_SN.

[0093] In scenario a, RX_HFN is updated to RX_HFN+1:

[0094] ;

[0095] In scenario b, RX_HFN is not updated:

[0096] .

[0097] In other words, RX_HFN and PDCP_SN are concatenated together to form the COUNT value, which is used for data packet decryption.

[0098] According to section 5.1.2.2 of the 36.322 RLC protocol, the UM RLC downlink data packet reception logic is described as follows (literal translation of the original text):

[0099] When the lower layer receives a UMD PDU with a sequence number (SN) equal to x, the receiving-side UM RLC entity should perform the following operations:

[0100] If VR(UR) < x < VR(UH) and a UMD PDU with a sequence number (SN) equal to x has been received previously; or,

[0101] If (VR(UH) – UM_Window_Size) <= x < VR(UR):

[0102] Discard the received UMD PDU;

[0103] Otherwise:

[0104] Put the received UMD PDU into the receive buffer.

[0105] According to Section 5.2.2.2.2 of the 38.322 RLC protocol, the UM RLC downlink packet reception logic is described as follows (literal translation of the original text):

[0106] When the lower layer receives a UMD PDU, the receiving side UM RLC entity shall perform the following operations:

[0107] If the header of the UMD PDU does not contain a sequence number (SN):

[0108] Remove the RLC header and deliver the RLC SDU to the upper layer;

[0109] Otherwise if (RX_Next_Highest – UM_Window_Size) <= sequence number (SN) < RX_Next_Reassembly:

[0110] Discard the received UMD PDU;

[0111] Otherwise: Put the received UMD PDU into the receive buffer.

[0112] Taking the LTE system as an example. Figure 2 It is a schematic diagram of the packet reception logic of the LTE RLC UM mode, the maintenance of the state variables at the receiving end, and the reordering window.

[0113] According to the protocol description and Figure 2 the example, PDUs that meet the following two conditions will be discarded, and PDUs in other cases will be saved:

[0114] 1). If VR(UR) < x < VR(UH) and a UMD PDU with SN = x has been successfully received previously, then this PDU is a duplicate packet and should be discarded;

[0115] 2). Since the receiving end believes that all PDUs with SN < VR(UR) have been successfully received, when (VR(UH) – UM_Window_Size) ≤ x < VR(UR), this PDU will also be discarded.

[0116] According to the 36.321 / 38.321 MAC protocol description, the transmitting end may have Hybrid Automatic Repeat reQuest (HARQ) retransmissions, which may cause the SN of the data packets received by the receiving end's PDCP layer to be out of order. The out-of-order N may incorrectly update the local HFN of the receiving end, resulting in the out-of-synchronization of the HFN between the transmitting end and the receiving end.

[0117] Taking the LTE standard as an example, Figure 3 shows the wrap-around loop of the sequence number. Figure 3 In:

[0118] The circle: represents the value range of SN, such as from 0 to the maximum value.

[0119] The clockwise direction: represents the increasing direction of SN.

[0120] Next_PDCP_RX_SN: the PDCP_SN of the next packet expected to be received.

[0121] PDCP_SN: the SN of the currently actually received packet.

[0122] The 0 point: the SN wrap-around point (returns to 0 after the maximum value).

[0123] As Figure 3 shown, the actually received PDCP_SN on the ring is in the counterclockwise direction (i.e., the smaller value area) of Next_PDCP_RX_SN, and this "lag" is not the normal out-of-order within the window, but because the SN has wrapped around (returned to 0), which means the transmitting end has entered the next HFN cycle. At this time, the receiving end needs to update RX_HFN to RX_HFN + 1 and calculate the COUNT value with the new HFN for decryption.

[0124] Figure 4 is an example timing diagram, which gives an example of the above problem scenario (the base station is the transmitting end and the UE is the receiving end), where the RLC sn is 5 bits, the PDCP sn is 7 bits, RX_HFN_N represents the HFN used by the PDCP layer on the base station side for encryption, and RX_HFN_U represents the HFN used by the UE side for decryption.

[0125] As Figure 4As shown, because of the downlink HARQ retransmission, the RLC PDU with RLC sn equal to 0 (carrying PDCP sn equal to 118) was not initially received by the RLC, and the subsequent RLC PDU receptions were normal. After the RLC sn was updated to 27, this retransmitted packet was successfully received and delivered to the RLC, which caused the RLC receive window to slide. Subsequently, the RLC received PDUs with sn equal to 28, 29, 30, and 31 (PDU with 31 carrying PDCP sn equal to 25). The sns within the RLC receive window were consecutive, and the RLC delivered the PDUs within the receive window to the PDCP. At this time, the Next_PDCP_RX_SN of the PDCP was updated to 119. Subsequently, the RLC received a PDU with sn equal to 0 (normal sn) again. The RLC determined it as a duplicate packet and discarded it. Then it received a PDU with RLC sn equal to 1 (carrying PDCP sn equal to 27). At this time, the state variable of the PDCP satisfied received PDCP SN < Next_PDCP_RX_SN, and the HFN was updated to X + 1. The UE used the COUNT value corresponding to HFN equal to X + 1 to decrypt this SDU.

[0126] Because the base station encrypted this packet using the COUNT value corresponding to HFN equal to X, the UE also needs to decrypt this packet using the COUNT value corresponding to HFN equal to X. Otherwise, the UE will decrypt abnormally. The above situation will cause the HFN on the UE side and the base station side to become out of sync. All subsequent SDUs on this data bearer will be decrypted abnormally. After the abnormally decrypted data packets are delivered to the upper layer (AP), the upper layer will discard them. In this way, the upper layer on the UE side will no longer be able to receive data packets on this data bearer, and the data service carried on this data bearer cannot operate normally.

[0127] The key point of the above scenario is that due to HARQ retransmission, the receiving end received a previous PDCP SN, which led to an incorrect update of the state variable maintained by the PDCP and caused the subsequent COUNT values to be out of sync continuously. For this scenario to occur, the receiving end also needs to meet two conditions: 1. The bit length of the RLC SN is less than the bit length of the PDCP SN, that is, the RLC SN wraps around faster than the PDCP SN. In this way, the PDUs retransmitted by HARQ received by the receiving end will be normally received by the RLC instead of being discarded by the RLC as out-of-window packets; 2. The RLC SN of this HARQ-retransmitted packet is exactly within the receiving window at the receiving end, and the corresponding SN has not been received by the RLC before, and then it can be normally delivered to the PDCP.

[0128] The above describes the packet processing logic for the PDCP and RLC layers as specified in the protocol. Currently, modems (modulator-demodulators) and base stations strictly adhere to the 3GPP protocol in executing packet transmission and reception procedures, with each layer implementing its relevant logic according to its respective protocol specifications. However, protocol layers may influence each other, leading to undesirable results. As described above in this application, this can cause HFN synchronization issues, resulting in continuous decryption failures at the receiving end. Therefore, this application needs to consider scenarios where inter-layer interactions may occur and specifically handle and protect them. Of course, considering inter-layer interactions inevitably introduces implementation complexity; this application aims to simplify the implementation mechanism as much as possible.

[0129] As described above, 3GPP protocols (such as 36.323 and 38.323) define a state machine algorithm based on sequence number comparison to determine whether to increment RX_HFN. The core logic is: when the received PDCP SN (received_PDCP_SN) is less than the receiver's expected next SN (Next_PDCP_RX_SN or SN(RX_DELIV)), the receiver determines that the PDCP SN has undergone a complete cycle of wraparound, and therefore needs to increment RX_HFN by 1. However, in-depth research and practice have revealed that this decision mechanism based on pure sequence number comparison has drawbacks. In certain network scenarios, it is highly susceptible to erroneous updates of RX_HFN, leading to HFN synchronization issues at both ends. The fundamental reason is that attributing a smaller received SN solely to HFN cycle flipping ignores another scenario: abnormal SN sequences within the same HFN cycle caused by HARQ retransmissions or out-of-order packet delivery at the lower RLC layer. If the local superframe number RX_HFN is incorrectly updated, the receiving end will use an incorrect COUNT value for decryption, resulting in garbled data packets that cannot be recognized by the upper layer, causing silent interruption of data services and a poor user experience.

[0130] In related technologies, when HFN synchronization failure occurs, it is usually necessary to rely on triggering connection reconstruction or bearer reconstruction procedures to restore synchronization. While this method is effective, it causes significant service interruption latency and additional signaling overhead, failing to meet the requirements of high-reliability, low-latency services. Furthermore, this is a reactive recovery mechanism and cannot prevent synchronization failures from occurring in the first place. Therefore, a technical solution is needed that can proactively and in real-time prevent or correct HFN erroneous updates at the PDCP receiver to improve the robustness and continuity of wireless data services without frequently triggering reconstruction procedures.

[0131] To address this, this application provides a superframe number synchronization method. The problem it aims to solve is that when the PDCP layer at the receiving end processes downlink data packets, it estimates the transmission status of the PDCP layer at the sending end, including state variables and HFN updates, based on the decryption results of the PDCP layer. To prevent the aforementioned RX_HFN synchronization failure, some protection mechanisms are implemented at the receiving end (UE or base station) to prevent RX_HFN (RCVD_HFN) anomalies caused by downlink packet loss or out-of-order delivery, ensuring the robustness of downlink packet reception. This will be explained below.

[0132] The superframe number synchronization method provided in this application can be applied to, for example, Figure 5 In the application environment shown, terminal 502 communicates wirelessly with base station 501. Terminal 502 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. Base station 501 can be a single base station or a cluster of base stations. The number of terminals 502 can be at least one.

[0133] In one exemplary embodiment, such as Figure 6 As shown, a superframe number synchronization method is provided, which is executed by the receiving end, and this method is applied to... Figure 5 The following steps are used as an example, taking a terminal (as a receiving end) or a chip / chip module with data processing capabilities: 601 to 605.

[0134] Step 601: Extract the actual received first packet data aggregation protocol sequence number (PDCP SN) from the received downlink data packets.

[0135] For example, when the receiving PDCP layer receives a downlink data packet sent by a lower layer (such as the RLC layer), it extracts the packet data aggregation protocol sequence number carried by the data packet from the packet header of the downlink data packet, thus obtaining the first PDCPSN.

[0136] Step 602: In response to the first PDCP SN being less than the locally expected second PDCP SN, generate multiple candidate superframe numbers based on the local superframe number.

[0137] Here, the second PDCP SN refers to the next packet data aggregation protocol sequence number expected to be received, which is locally maintained by the receiver and corresponds to the state variable Next_PDCP_RX_SN. The local superframe number refers to the superframe number (RX_HFN) currently maintained locally by the receiver.

[0138] For example, to determine whether packet loss has occurred, the receiving PDCP layer compares the first PDCP SN with the second PDCP SN. If the first PDCP SN and the second PDCP SN are the same, it indicates that the data packets arrived in order and no packet loss occurred, and the receiving PDCP layer processes the downlink data packets according to the normal procedure. If the first PDCP SN and the second PDCP SN are different, it indicates that the receiving state is abnormal and packet loss may have occurred. If the first PDCP SN is less than the second PDCP SN, it indicates (very likely) that large-scale packet loss may have occurred, and the superframe number has been flipped. At this time, the HFN of the receiving end and the sending end are out of sync, triggering the superframe number synchronization process of this embodiment: First, multiple candidate superframe numbers are generated based on the local superframe number (RX_HFN), and then step 603 is performed to synchronize the superframe numbers based on the multiple candidate superframe numbers. Optionally, all candidate superframe numbers include at least the local superframe number and the value obtained after a positive or negative offset based on the local superframe number.

[0139] Step 603: Decrypt the downlink data packet based on each candidate superframe number among multiple candidate superframe numbers to obtain multiple candidate decryption results.

[0140] For example, for each candidate superframe number obtained above, the payload portion of the downlink data packet is decrypted based on it to obtain a candidate decryption result corresponding to each candidate superframe number.

[0141] Optionally, decryption can be performed in parallel to obtain each candidate decryption result.

[0142] Optionally, the candidate superframe numbers are prioritized to obtain their priority order. Then, the downlink data packets are decrypted sequentially based on each candidate superframe number according to their priority order to obtain the decryption results. Specifically, the candidate superframe numbers can be prioritized according to their size; for example, a larger candidate superframe number has a higher priority, and a smaller candidate superframe number has a lower priority.

[0143] Step 604: Verify the validity of multiple candidate decryption results, and determine the target superframe number corresponding to the candidate decryption result that has passed the validity verification from multiple candidate superframe numbers.

[0144] Validity verification refers to checking the candidate decryption results to determine whether they conform to a predetermined data format or logical rules. If they do, the candidate decryption result is correct and valid; otherwise, it is incorrect or invalid. Validity verification can include Internet Protocol (IP) packet checking, specifically checking whether the IP header fields in the candidate decryption result conform to the specifications. The target superframe number refers to one of at least one candidate superframe number corresponding to a candidate decryption result that has passed validity verification among all candidate superframe numbers.

[0145] For example, each candidate decryption result is validated. If a candidate decryption result passes the validation, the decryption performed using that candidate decryption result is determined to be successful and valid. Based on the validation results, candidate decryption results that pass the validation are identified, and a target superframe number corresponding to the validated candidate decryption result is selected from multiple candidate superframe numbers.

[0146] Optionally, when decryption is performed in parallel, the validity of multiple candidate decryption results can be verified in parallel to obtain the verification results of all candidate decryption results.

[0147] Optionally, if decryption is performed according to the priority order of each candidate superframe number, each candidate decryption result is validated, and then decryption is performed based on the next candidate superframe number to obtain the next candidate decryption result. This process of decryption and validation is repeated until the validation results of all candidate decryption results are obtained.

[0148] Then, based on the verification results of all candidate decryption results, at least one candidate decryption result that has passed verification can be obtained. Further, the candidate superframe number corresponding to each of these candidate decryption results is obtained, i.e., at least one candidate superframe number that has passed verification is obtained. A candidate superframe number is then determined or selected from at least one candidate superframe number according to preset rules, and this selected superframe number is used as the target superframe number. The preset rules can be pre-defined based on historical experience, actual needs, or application scenarios.

[0149] Step 605: Update the local superframe number based on the target superframe number.

[0150] For example, after obtaining the target superframe number, the value of the local superframe number is replaced with the value of the target superframe number to update the local superframe number. After this update, the receiving end and the sending end are synchronized on the superframe number, and subsequent downlink data packets can be decrypted normally using the updated superframe number.

[0151] For example, if the received first PDCP SN=5 and the expected second PDCP SN=7, this indicates that the packet with SN=6 may still be in transmission (unacknowledged packet loss) or has already been lost. In this case, the receiving PDCP layer first generates multiple candidate superframe numbers, such as three of different sizes. Then, it decrypts the downlink data packets based on each candidate superframe number, obtaining three candidate decryption results. The validity of each candidate decryption result is verified, and a target superframe number is selected from the three candidate superframe numbers based on the verification result. Finally, the local superframe number is updated using the target superframe number.

[0152] It should be noted that the received first PDCP SN is less than the expected received second PDCP SN. This could be due to normal packet loss, or it could be due to the following scenario: For a 7-bit PDCP scenario (maximum SN is 127), an example is given below:

[0153] Expected to receive SN 5, currently receiving SN 4 (the receiving end, such as the UE, does not know whether the current network uses X or X+1 to encrypt this packet as SN 4):

[0154] (1) Normal packet loss. The network uses X+1 to encrypt sn 4. At this time, 5~127 and 0~3 are all dropped. The UE can successfully decrypt sn 4 using X+1.

[0155] (2) There is no packet loss. The network uses X to encrypt sn 4. The UE cannot successfully decrypt sn 4 using X+1. Without using the embodiment of this application, the UE's local HFN is updated to X+1. The UE then receives packets after sn 6 and cannot decrypt them. Based on the embodiment of this application, the local HFN will not be updated to X+1 and will remain X. The subsequent sn 6 can also be decrypted normally.

[0156] If the RLC layer receives data continuously, the PDCP layer must also receive data continuously. The scenario encountered in this application embodiment is that the RLC layer has bit errors, which causes the PDCP layer to receive data out of order.

[0157] In the aforementioned superframe number synchronization method, the first received Packet Data Convergence Protocol Sequence Number (PDCP SN) is extracted from the received downlink data packets; in response to the first PDCP SN being less than the locally expected second PDCP SN, multiple candidate superframe numbers are generated based on the local superframe number; the downlink data packets are decrypted based on each candidate superframe number to obtain multiple candidate decryption results; the validity of the multiple candidate decryption results is verified, and the target superframe number corresponding to the candidate decryption result that has passed the validity verification is determined from the multiple candidate superframe numbers; the local superframe number is updated according to the target superframe number. It is evident that, compared to the inevitable service interruption caused by the passive reliance on the reconstruction process to handle HFN synchronization failures in related technologies, this embodiment actively triggers and completes the HFN synchronization process when the received first PDCP SN is less than the locally expected second PDCP SN, fundamentally reducing or even avoiding reliance on the reconstruction process. This prevents local superframe number synchronization failures caused by downlink data packet loss or out-of-order delivery, thereby improving the robustness of downlink data packet reception. In addition, the embodiments of this application can realize HFN synchronization in a timely manner when the first abnormal downlink data packet (the first PDCP SN is less than the second PDCP SN) arrives, thereby avoiding service flow interruption without the user's awareness and ensuring service continuity at the receiving end.

[0158] The steps described above are illustrated below.

[0159] In an exemplary embodiment, step 604, determining the target superframe number corresponding to the candidate decryption result that has passed the validity verification from a plurality of candidate superframe numbers, includes: in response to the number of candidate decryption results that have passed the validity verification being one, taking the candidate superframe number corresponding to the candidate decryption result that has passed the validity verification as the target superframe number; and in response to the number of candidate decryption results that have passed the validity verification being a plurality of candidate superframe numbers, selecting any candidate superframe number corresponding to the candidate decryption result that has passed the validity verification from a plurality of candidate superframe numbers as the target superframe number.

[0160] In this case, any candidate superframe number is different from the local superframe number.

[0161] For example, the number of candidate decryption results that pass the validity verification can be determined from the results. If the candidate decryption result that passes the verification is a single candidate decryption result B1, then the candidate superframe number A1 corresponding to candidate decryption result B1 is taken as the target superframe number. If the candidate decryption result that passes the verification is multiple candidate decryption results, such as B1 and B3, then according to a preset priority rule, any one of the candidate superframe numbers (such as A3 or A1) corresponding to B1 and B3 (assuming that A1 and A3 are both different from the local superframe number) is selected as the target superframe number.

[0162] In other words, select any candidate superframe number other than the local superframe number from among the multiple candidate superframes that have passed decryption verification as the target superframe number.

[0163] Therefore, in this embodiment, when there are multiple candidate decryption results that have passed the validity verification, selecting any candidate superframe number other than the local superframe number from the corresponding multiple candidate superframe numbers as the target superframe number can improve the selection efficiency.

[0164] It should be noted that, in addition to randomly selecting the target superframe number as described above, the target superframe number can also be selected according to preset rules, as illustrated below.

[0165] In one exemplary embodiment, step 604, determining the target superframe number corresponding to the candidate decryption result that has passed the validity verification from multiple candidate superframe numbers, includes: in response to the number of candidate decryption results that have passed the validity verification being multiple, selecting the maximum value among the candidate superframe numbers corresponding to the candidate decryption results that have passed the validity verification as the target superframe number.

[0166] The largest candidate superframe number is different from the local superframe number.

[0167] For example, if the verified candidate decryption results are multiple candidate decryption results such as B1, B2 and B3, then the maximum value A1 is selected as the target superframe number from the candidate superframe numbers A1, A2 and A3 corresponding to B1, B2 and B3 respectively (A1, A2 and A3 in descending order, where A3 is the local superframe number).

[0168] Therefore, this embodiment selects the largest candidate superframe number (excluding the local superframe number) among the multiple candidate superframe numbers as the target superframe number. This ensures that when the superframe number of the sending end has actually completed its increment due to the sequence number flip, the receiving end can accurately synchronize with the superframe number of the sending end, thereby correcting the out-of-synchronization caused by large-scale packet loss and ensuring synchronization robustness.

[0169] The following describes a specific implementation for generating multiple candidate superframe numbers.

[0170] In one exemplary embodiment, step 602, generating multiple candidate superframe numbers based on the local superframe number, includes: generating multiple candidate superframe numbers according to the local superframe number and at least one preset offset, wherein the offset is an integer greater than or equal to 1.

[0171] For example, the receiving end PDCP layer first obtains its current local superframe number X as the basis for generating candidate superframe numbers, and simultaneously obtains a preset offset set, which includes N+1 offsets of different sizes (N is a positive integer greater than or equal to 1). Then, the sum of X and the N+1 offsets of different sizes is used as the candidate superframe number. Assuming that the local superframe number RX_HFN at a certain moment is X, then the candidate superframe numbers can include: X, X+1, ..., X+N-1 and X+N.

[0172] The offset set is set in advance based on the network environment, actual needs, or historical experience. For example, in scenarios where packet loss is likely to occur, a larger offset set can be set to cope with more severe loss of synchronization.

[0173] Therefore, this embodiment generates multiple candidate superframe numbers based on the local superframe number and at least one offset, which can cover the most likely out-of-sync situations (small deviations) and can also cope with more extreme out-of-sync situations through configuration expansion, providing an effective search range for subsequent decryption attempts and synchronization.

[0174] In an exemplary embodiment, step 603 includes: determining a candidate count value corresponding to each candidate superframe number based on each candidate superframe number and the first PDCP SN; and using each candidate count value to decrypt downlink data packets to obtain a candidate decryption result corresponding to each candidate superframe number.

[0175] For example, firstly, for each candidate superframe number, the candidate superframe number and the first PDCP SN are concatenated to generate a candidate count value. The concatenation operation follows the 3GPP protocol specifications, such as using the superframe number as the high-order part and the sequence number as the low-order part to form a complete count value. That is, N+1 candidate count values ​​are generated based on N+1 combinations. The N+1 combinations are: (X,SN), (X+1,SN), ..., (X+N-1, SN), (X+N,SN), where SN refers to the first PDCP SN. Then, each candidate count value and the corresponding encryption key are used to decrypt the payload part of the downlink data packet to obtain the corresponding candidate decryption result. The mapping relationship between each candidate decryption result and its corresponding candidate superframe number is stored for subsequent use.

[0176] Figure 7 This illustrates the decryption process of the PDCP layer (located on the user side) handling packet sequence number wrapping. For example... Figure 7As shown, when the RLC layer sends a data packet with sequence number 1, the PDCP detects that the locally expected sequence number is 27, determines that sequence number wrapping has occurred, and updates the local superframe number from X to X+1. Next, the decryption module needs to generate two possible candidate count values ​​for this data packet with sequence number 1: COUNT_1 and COUNT_2, one using candidate superframe number X and the other using candidate superframe number X+1. Then, it attempts to decrypt using these two COUNT values ​​to obtain candidate decryption results. Each candidate decryption result is then checked using IP packets, resulting in two check results: IP_check_result_1 and IP_check_result_2. Finally, based on these two check results, it determines which superframe period the data packet belongs to.

[0177] Therefore, this embodiment enables decryption attempts for multiple candidate superframe numbers, ensuring the correctness of decryption and further ensuring the effectiveness of superframe number synchronization.

[0178] It should be noted that in practical applications, there may be cases where all candidate decryption results fail the validity verification. In this case, the candidate superframe number can be expanded to obtain a new candidate superframe number, and the process returns to step 503, that is, the superframe number synchronization process is performed based on the new candidate superframe number. If all candidate decryption results still fail the validity verification, the synchronization can be restored by relying on the reconstruction process.

[0179] In one exemplary embodiment, the method further includes: sending a reconstruction request to the radio resource control layer in response to all candidate decryption results failing validity verification.

[0180] The reconstruction request is used to notify the radio resource control layer to initiate the radio resource control reconstruction process.

[0181] For example, after verifying the validity of all candidate decryption results, if the verification result shows that all candidate decryption results have passed verification, it indicates that the active synchronization of the superframe number has failed. The deviation between the local superframe number at the receiving end and the superframe number actually used by the sending end may have exceeded the range covered by all candidate superframe numbers, or there may be other fundamental problems such as encryption key errors or serious inconsistencies in the underlying protocol state, which cannot be repaired within the current protocol layer. At this time, the PDCP layer generates a reconstruction request, which at least includes an identifier indicating the failure type (such as all candidate decryption results failing verification or HFN synchronization failure). Then, the PDCP layer sends the reconstruction request to the protocol entity above it, namely the Radio Resource Control layer, through the inter-layer interface defined in the protocol stack.

[0182] Upon receiving this request, the Radio Resource Control (RRC) layer triggers the RRC connection reconstruction process according to the 3GPP protocol specifications, thereby restoring the synchronization of the superframe number.

[0183] For example, suppose the RX_HFN at a certain moment is X. If the first PDCP SN is less than the locally expected second PDCP SN, taking N=1 as an example, two candidate superframe numbers X and X+1 are generated. Downlink data packets are decrypted based on X and X+1 respectively, resulting in two candidate decryption results B1 (corresponding to X) and B2 (corresponding to X+1). IP packet checks are performed on B1 and B2 in parallel. The check results and the update of the local superframe number RX_HFN have the following four possibilities:

[0184] First method: If the IP packet check of B2 is normal and the IP packet check of B1 is abnormal, then update RX_HFN to X+1.

[0185] The second method: If the IP packet check of B2 is abnormal, while the IP packet check of B1 is normal, then update RX_HFN to X.

[0186] The third method: If the IP packet check of B2 is abnormal, or the IP packet check of B1 is abnormal, then the RRC layer is notified to trigger the reconstruction process.

[0187] The fourth method: If the IP packet check of B2 is normal and the IP packet check of B1 is normal, then update RX_HFN to X+1.

[0188] In this embodiment, it is ensured that even in the worst case (active synchronization failure), the system will not fall into a state of continuously sending incorrect data, but will be able to force synchronization to be restored by triggering a higher-level recovery mechanism.

[0189] The following example illustrates the specific implementation of the superframe number synchronization method.

[0190] In a specific example, such as Figure 8 As shown, the superframe number synchronization method includes the following steps:

[0191] Step 801: Extract the first PDCP SN actually received from the received downlink data packets;

[0192] Step 802: Determine whether the first PDCP SN is less than the second PDCP SN expected to be received locally; if not, proceed to step 812; if yes, proceed to step 803.

[0193] Step 803: Generate multiple candidate superframe numbers based on the local superframe number and at least one preset offset;

[0194] Step 804: Determine the candidate count value based on each candidate superframe number and the first PDCP SN;

[0195] Step 805: Use each candidate count value to decrypt the downlink data packet to obtain the candidate decryption result corresponding to each candidate superframe number;

[0196] Step 806: Verify the validity of multiple candidate decryption results;

[0197] Step 807: Determine if there are any candidate decryption results that have passed verification. If yes, proceed to step 808; otherwise, proceed to step 813.

[0198] Step 808: Determine whether there is only one candidate decryption result that has passed the verification. If yes, proceed to step 809; otherwise, proceed to step 810.

[0199] Step 809: Use the candidate superframe number corresponding to the verified candidate decryption result as the target superframe number;

[0200] Step 810: Select any one of the multiple candidate superframe numbers (excluding the local superframe number) or the largest candidate superframe number from among the multiple candidate superframe numbers corresponding to the verified candidate decryption results as the target superframe number.

[0201] Step 811: Update the local superframe number according to the target superframe number;

[0202] Step 812: Process the downlink data packets according to the standard procedure;

[0203] Step 813: Send a reconstruction request to the Radio Resource Control layer.

[0204] In summary, UM RLC mode is an unreliable reception mode. If there is packet loss in the data delivered from the RLC layer to the PDCP layer, it will cause discontinuity in the downlink SN of the PDCP layer. If there is a lot of packet loss or the received SN is out of order, it is very likely that the RX_HFN (RCVD_HFN) of the sending and receiving ends will be out of sync. This will result in the COUNT value used by the receiving end for decryption being inconsistent with the COUNT value used by the sending end for encryption. The receiving end's PDCP layer will then decrypt the data packets abnormally. The abnormally decrypted data packets cannot be further parsed by higher layers and will be discarded by higher layers. This will cause the current data-carrying service to fail normally, resulting in a poor user experience. The embodiments of this application can identify this scenario and implement some targeted protection mechanisms, namely, superframe number synchronization based on candidate superframe numbers, thereby avoiding continuous decryption abnormalities in the downlink data at the PDCP layer due to superframe number out-of-sync, thus ensuring the robustness of downlink data reception.

[0205] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0206] Based on the same inventive concept, this application also provides a superframe number synchronization device for implementing the superframe number synchronization method described above. This device can be applied to or integrated into a chip or chip module, for example. The solution provided by this device is similar to the implementation scheme described in the above method; therefore, the specific limitations of one or more superframe number synchronization device embodiments provided below can be found in the limitations of the superframe number synchronization method described above, and will not be repeated here.

[0207] In one exemplary embodiment, such as Figure 9 As shown, a superframe number synchronization device is provided, including: an extraction module 901, a generation module 902, a decryption module 903, a determination module 904, and an update module 905.

[0208] Extraction module 901 is used to extract the actual received first packet data aggregation protocol sequence number (PDCP SN) from the received downlink data packets; generation module 902 is used to generate multiple candidate superframe numbers based on the local superframe number in response to the first PDCP SN being less than the locally expected second PDCP SN; decryption module 903 is used to decrypt the downlink data packets based on each candidate superframe number among the multiple candidate superframe numbers to obtain multiple candidate decryption results; determination module 904 is used to verify the validity of the multiple candidate decryption results and determine the target superframe number corresponding to the candidate decryption result that has passed the validity verification from the multiple candidate superframe numbers; update module 905 is used to update the local superframe number according to the target superframe number.

[0209] In one embodiment, the determining module 904 is specifically configured to: in response to the number of candidate decryption results that have passed the validity verification being multiple, select any candidate superframe number corresponding to the candidate decryption result that has passed the validity verification as the target superframe number from the multiple candidate superframe numbers, wherein the any candidate superframe number is different from the local superframe number.

[0210] In another embodiment, the determining module 904 is specifically configured to: in response to the number of candidate decryption results that have passed the validity verification being multiple, select the maximum value among the candidate superframe numbers corresponding to the candidate decryption results that have passed the validity verification as the target superframe number, wherein the maximum candidate superframe number is different from the local superframe number.

[0211] In one embodiment, the generation module 902 is specifically used to: generate multiple candidate superframe numbers based on the local superframe number and at least one preset offset, wherein the offset is an integer greater than or equal to 1.

[0212] In one embodiment, the decryption module 903 is specifically used to: determine the candidate count value corresponding to each candidate superframe number based on each candidate superframe number and the first PDCP SN; and use each candidate count value to decrypt the downlink data packet to obtain the candidate decryption result corresponding to each candidate superframe number.

[0213] In one embodiment, the apparatus further includes: a sending module, configured to send a reconstruction request to the radio resource control layer in response to all candidate decryption results failing validity verification; wherein the reconstruction request is used to notify the radio resource control layer to initiate a radio resource control reconstruction process.

[0214] Regarding the modules / units included in the various devices and products described in the above embodiments, they can be software modules / units, hardware modules / units, or a combination of both. For example, for various devices and products applied to or integrated into a chip, all of their modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits; for various devices and products applied to or integrated into a chip module, all of their modules / units can be implemented using hardware methods such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The components can be implemented using software programs that run on the processor integrated within the chip module. The remaining (if any) modules / units can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into the terminal, each of its components / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or in different components within the terminal. Alternatively, at least some modules / units can be implemented using software programs that run on the processor integrated within the terminal, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits.

[0215] In one exemplary embodiment, a communication device is provided. This computer device may be a terminal, and its internal structure diagram may be as follows: Figure 10 As shown, the communication device includes a processor, memory, input / output interfaces, and a communication interface. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a superframe number synchronization method.

[0216] Those skilled in the art will understand that Figure 10The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the communication device to which the present application is applied. Specific communication devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0217] In one exemplary embodiment, a communication device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement a superframe number synchronization method.

[0218] Based on the same inventive concept, embodiments of this application also provide a chip, including a processor and a communication interface; the communication interface is used to receive or send data; the processor is configured to cause the chip to perform the steps of a superframe number synchronization method.

[0219] It is understood that the chip involved in the embodiments of this application may be a field-programmable gate array (FPGA), may be an application-specific integrated circuit (ASIC), may be a system on chip (SoC), may be a central processor (CPU), may be a network processor (NP), may be a digital signal processor (DSP), may be a microcontroller unit (MCU), may be a programmable logic device (PLD), or other integrated chips, etc.

[0220] Based on the same inventive concept, this application also provides a chip module, such as... Figure 11 As shown, the chip module includes a communication module, a power module, a storage module, and a chip. Among them:

[0221] The power module provides power to the chip module; the storage module stores data and instructions; the communication module enables internal communication within the chip module or communication between the chip module and external devices; this chip corresponds to the chip in the above chip embodiment. The implementation of this chip module can be found in the relevant content of the above chip embodiment, and will not be repeated here.

[0222] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program implementing the steps of a superframe number synchronization method when executed by a processor.

[0223] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of a superframe number synchronization method.

[0224] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. The databases involved in the embodiments provided in this application can include at least one of relational databases and non-relational databases. The processors involved in the embodiments provided in this application can be general-purpose processors, central processing units, graphics processors, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0225] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

Claims

1. A method for synchronizing superframe numbers, characterized in that, The method includes: Extract the actual received first packet data aggregation protocol sequence number (PDCP SN) from the received downlink data packets; In response to the first PDCP SN being less than the locally expected second PDCP SN, multiple candidate superframe numbers are generated based on the local superframe number; The downlink data packet is decrypted based on each of the multiple candidate superframe numbers to obtain multiple candidate decryption results; The validity of the multiple candidate decryption results is verified, and the target superframe number corresponding to the candidate decryption result that has passed the validity verification is determined from the multiple candidate superframe numbers. Update the local superframe number based on the target superframe number.

2. The method according to claim 1, characterized in that, Determining the target superframe number corresponding to the candidate decryption result that has passed the validity verification from the plurality of candidate superframe numbers includes: In response to the fact that there are multiple candidate decryption results that have passed the validity verification, any candidate superframe number corresponding to the candidate decryption result that has passed the validity verification is selected from the multiple candidate superframe numbers as the target superframe number, wherein the candidate superframe number is different from the local superframe number.

3. The method according to claim 1, characterized in that, Determining the target superframe number corresponding to the candidate decryption result that has passed the validity verification from the plurality of candidate superframe numbers includes: In response to the fact that there are multiple candidate decryption results that have passed the validity verification, the largest candidate superframe number among the multiple candidate superframe numbers corresponding to the candidate decryption results that have passed the validity verification is selected as the target superframe number, wherein the largest candidate superframe number is different from the local superframe number.

4. The method according to claim 1, characterized in that, The generation of multiple candidate superframe numbers based on the local superframe number includes: Multiple candidate superframe numbers are generated based on the local superframe number and at least one preset offset, wherein the offset is an integer greater than or equal to 1.

5. The method according to claim 1, characterized in that, The downlink data packet is decrypted based on each of the multiple candidate superframe numbers to obtain multiple candidate decryption results, including: The candidate count value corresponding to each candidate superframe number is determined based on each candidate superframe number and the first PDCP SN; The downlink data packet is decrypted using each of the candidate count values ​​to obtain the candidate decryption result corresponding to each candidate superframe number.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: In response to all of the candidate decryption results failing the validity verification, a reconstruction request is sent to the Radio Resource Control (RRC) layer; wherein the reconstruction request is used to notify the RRC layer to initiate the RRC reconstruction process.

7. A superframe number synchronization device, characterized in that, The device includes: The extraction module is used to extract the actual received first packet data aggregation protocol sequence number (PDCP SN) from the received downlink data packets; The generation module is used to generate multiple candidate superframe numbers based on the local superframe number in response to the first PDCP SN being less than the second PDCP SN expected to be received locally. The decryption module is used to decrypt the downlink data packet based on each of the multiple candidate superframe numbers to obtain multiple candidate decryption results; The determination module is used to verify the validity of the plurality of candidate decryption results and determine the target superframe number corresponding to the candidate decryption result that has passed the validity verification from the plurality of candidate superframe numbers; The update module is used to update the local superframe number based on the target superframe number.

8. A communication device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A chip, characterized in that, The device includes a processor and a communication interface, wherein the processor is configured to cause the chip to perform the steps of the method described in any one of claims 1 to 6.

10. A chip module, characterized in that, This includes communication modules, power modules, storage modules, and chips, among which: The power module is used to provide power to the chip module; The storage module is used to store data and instructions; The communication module is used for internal communication within the chip module, or for communication between the chip module and external devices. The chip is used to perform the steps of the method according to any one of claims 1 to 6.

Images