WO2022193932A1

WO2022193932A1 - Lte pdcp data decryption enhancement method and apparatus

Info

Publication number: WO2022193932A1
Application number: PCT/CN2022/078045
Authority: WO
Inventors: 郑锐; 孙金重
Original assignee: 翱捷科技股份有限公司
Priority date: 2021-03-19
Filing date: 2022-02-25
Publication date: 2022-09-22
Also published as: CN113132978A

Abstract

The present application discloses an LTE PDCP data decryption enhancement method. A PDCP layer at a UE side determines, according to a maintained state variable, whether a newly received downlink data packet is out of a window. If not, the PDCP layer at the UE side performs, according to a maintained superframe number, software decryption on a starting k length of a first IP data packet which is within the window, and determines the validity of the IP data packet. If the IP data packet is determined to be invalid, the PDCP layer at the UE side performs software decryption on the starting k length of the IP data packet according to the maintained superframe number+1, and determines the validity of the IP data packet. If the IP data packet is determined to be invalid, the PDCP layer at the UE side performs software decryption on the starting k length of the IP data packet according to the maintained superframe number+2, and determines the validity of the IP data packet. If the IP data packet is determined to be invalid, the PDCP layer at the UE side reports that downlink decryption of an AS layer is abnormal, and the AS layer at the UE side recovers a data link in a manner of releasing the link and completely reconstructing. The method can reduce the processing time and improve the user experience.

Description

A method and device for LTE PDCP data decryption enhancement

technical field

This application relates to an LTE (Long-Term Evolution, long-term evolution) decryption method for downlink data by mobile terminals.

Background technique

PDCP (Packet Data An important function of the Convergence Protocol layer is the encryption and decryption of data and signaling. The encryption and decryption parameters of the PDCP layer include a key (key) and a count (Count) value. The count value consists of a Hyper Frame Number (HFN) and a sequence number (Sequence Number, SN) maintained by the PDCP layer. Where the serial number is recorded in the PDCP header, there is no error. The superframe number requires the UE (User Equipment, user equipment, that is, mobile terminal) side to maintain synchronization with the network side. If the synchronization is lost (ie, out of synchronization, synchronization failure), the mobile terminal will fail to decrypt the downlink data. To maintain synchronous superframe numbers, 3GPP The PDCP protocol defines a detailed window management mechanism. However, due to the influence of the air interface quality, the timeout of the PDCP discard timer (discard timer) on the network side will cause packet loss. At this time, although the serial numbers of the RLC (radio link conrtol, radio link control) layer on the network side are continuous, the serial numbers of the PDCP layer on the network side located above the RLC layer in the protocol stack architecture appear discontinuous. , this is a normal scenario, but in extreme cases, the superframe numbers of the UE side and the network side may be out of sync, so that the mobile terminal fails to decrypt the downlink data.

Referring to FIG. 1 , a method for decrypting data by the PDCP layer of an existing LTE mobile terminal includes the following steps.

Step S11: The PDCP layer on the UE side receives a new downlink data packet.

Step S12: The PDCP layer on the UE side determines whether the newly received downlink data packet is out of the window according to the maintained state variables LastSubmittedPdcpSn, the reordering window and the sequence number receivedSn of the newly received downlink data packet. LastSubmittedPdcpSn indicates the PDCP SDU (Service Data Unit, service data unit, also called business data unit) serial number, reordering window represents the window size range used by the PDCP layer on the UE side to maintain the sequence number received in sequence, and receivedSn represents the sequence number of the PDU (Protocol Data Unit, protocol data unit) newly received by the PDCP layer on the UE side. When receivedSn－LastSubmittedPdcpSn>Reordering_Window or 0≤LastSubmittedPdcpSn－receivedSn<Reordering_Window, it is determined that the newly received downlink data packet is out of the window; otherwise, it is determined that the newly received downlink data packet is out of the window (that is, within the window).

If yes, discard the data packet out of the window, the state variables LastSubmittedPdcpSn and reordering window remain unchanged, and go back to step S11.

If not, go to step S13.

Step S13: The PDCP layer on the UE side decrypts the downlink data packet using the maintained superframe number, and submits the decrypted data to the application layer on the UE side.

It is assumed that in step S11, the discard timer of the PDCP layer on the network side expires due to an air interface quality problem, causing a large number of packet losses, and the sequence numbers of the PDCP layer on the network side are no longer consecutive. If the network side has reached the maximum PDCP sequence number after a large amount of packet loss, the sequence number starts from 0 and starts a new round of recounting. The change of the superframe number depends on the change of the sequence number. When the sequence number reaches the maximum count and restarts the calculation, the superframe number will be incremented by 1. Next, in step S12, the sequence number of the downlink data packet received by the UE side falls within the legal window of the PDCP layer on the UE side. Next, in step S13, the PDCP layer on the UE side will perform data decryption. However, the superframe number used by the UE side is from the previous round, and the UE side does not know that the sequence number on the network side is from a new round, resulting in a decryption error on the UE side.

The above steps show the situation in which the desynchronization of the superframe number occurs on the UE side and the network side, resulting in a decryption failure. After the decryption fails, if the UE side does not take measures, the data communication will be interrupted, because the IP packets (IP Packets, also called IP packets) received by the application layer on the UE side are all wrong.

technical problem

The technical problem to be solved by this application is to propose an enhanced PDCP downlink decryption method under the premise of following the 3GPP standard, to cope with the scenario where the superframe number is out of synchronization between the UE side and the network side, and to minimize the superframe number out of synchronization Caused by the decryption failure.

technical solutions

To solve the above technical problems, the present application provides a method for enhancing LTE PDCP data decryption, including the following steps. Step S21: The PDCP layer on the UE side receives a new downlink data packet. Step S22: The PDCP layer on the UE side judges whether the newly received downlink data packet is out of the window according to the maintained state variables LastSubmittedPdcpSn, reordering window and the sequence number of the newly received downlink data packet receivedSn; wherein, LastSubmittedPdcpSn represents the PDCP layer on the UE side The sequence number of the PDCP SDU last submitted to the upper layer, reordering window represents the window size range used by the PDCP layer on the UE side to maintain the sequence number received in sequence, and receivedSn represents the sequence number of the PDU newly received by the PDCP layer on the UE side. If it is, discard the data packets out of the window, the super frame number maintained by the PDCP layer on the UE side and the state variables LastSubmittedPdcpSn, reordering The window remains unchanged, while the PDCP layer on the UE side is in state A, and returns to step S21. If not, go to step S23. Step S23: The PDCP layer on the UE side performs software decryption on the start k length of the first IP data packet of the dropped window according to the maintained superframe number, and judges the validity of the IP data packet. If it is determined that the IP data packet is valid, the PDCP layer on the UE side exits state A, the superframe number maintained by the PDCP layer on the UE side remains unchanged, and the process returns to step S21. If it is determined that the IP data packet is invalid, step S24 is entered. Step S24: The PDCP layer on the UE side performs software decryption on the initial k length of the IP data packet according to the maintained superframe number+1, and judges the validity of the IP data packet. If it is determined that the IP data packet is valid, the superframe number maintained by the PDCP layer on the UE side is changed to superframe number+1, the PDCP layer on the UE side exits state A, and returns to step S21. If it is determined that the IP data packet is invalid, then go to step S25. Step S25: The PDCP layer on the UE side performs software decryption on the initial k length of the IP data packet according to the maintained superframe number+2, and judges the validity of the IP data packet. If it is determined that the IP data packet is valid, the superframe number maintained by the PDCP layer on the UE side is changed to superframe number+2, the PDCP layer on the UE side exits state A, and returns to step S21. If it is determined that the IP data packet is invalid, the PDCP layer on the UE side reports that the downlink decryption of the AS layer is abnormal, and the AS layer on the UE side restores the data link by releasing the link and rebuilding it completely. The above method first attempts to correct according to the most likely superframe number out-of-synchronization situation. When the correction fails at most twice, the link is automatically released and the link is completely reconstructed, which reduces the processing time and improves the user experience.

Further, in the step S22, when receivedSn-LastSubmittedPdcpSn>Reordering_Window or 0≤LastSubmittedPdcpSn-receivedSn<Reordering_Window, it is determined that the newly received downlink data packet is out of the window; otherwise, it is determined that the newly received downlink data packet is out of the window, that is, within the window . This is a specific implementation of step S22.

Preferably, in the step S23, the step S24, and the step S25, the length of k is all 20 bytes. The length of the downlink IP data packet is generally about 1500 bytes, and the first 20 bytes basically cover the basic information of the header of the IP data packet, so this length can quickly verify whether the decryption of the IP data packet is accurate, and the processing time is short.

Further in the step S25, the "release link and complete reconstruction" means that the PDCP layer on the UE side actively informs the AS layer to disconnect the link at the first time, and then the AS layer on the UE side re-establishes the link. This is a supplementary explanation to step S25.

The present application also provides an apparatus for enhancing LTE PDCP data decryption, including a receiving unit, a judging unit, a decrypting unit, a first correcting unit and a second correcting unit. The receiving unit is configured to allow the UE side to receive a new downlink data packet sent by the network side. The judging unit uses the state variables LastSubmittedPdcpSn and reordering maintained according to the PDCP layer on the UE side. window and the sequence number of the newly received downlink data packet receivedSn determine whether the newly received downlink data packet is out of the window; if so, the judging unit discards the out-of-window data packet, the super frame number maintained by the PDCP layer on the UE side and The state variables LastSubmittedPdcpSn and reordering window remain unchanged, so that the PDCP layer on the UE side is in state A; if not, the judgment unit sends the IP data packet to the decryption unit. Described decryption unit is used to carry out software decryption according to the super frame number that the PDCP layer of UE side maintains to the starting k length of the IP data packet sent by the judgment unit, and judges the legality of this IP data packet; If it is judged that this IP data packet is legal , the decryption unit makes the PDCP layer on the UE side exit state A, and the superframe number maintained by the PDCP layer on the UE side remains unchanged; if it is determined that the IP data packet is illegal, the decryption unit sends the IP data packet to the first Correction unit. Described first correcting unit is used for adopting the super frame number+1 maintained by the PDCP layer of the UE side to carry out software decryption to the starting k length of the IP data packet sent by the decryption unit, to judge the legitimacy of this IP data packet; The IP data packet is legal, and the first correcting unit changes the super frame number maintained by the PDCP layer on the UE side to the super frame number + 1, so that the PDCP layer on the UE side exits state A; if it is determined that the IP data packet is illegal, the The first correcting unit sends the IP data packet to the second correcting unit. Described second correcting unit is used for adopting the super frame number+2 maintained by the PDCP layer of UE side to carry out software decryption to the starting k length of the IP data packet sent by the first correcting unit, to judge the legitimacy of this IP data packet; It is determined that the IP data packet is legal, and the second correction unit changes the superframe number maintained by the PDCP layer on the UE side to superframe number+2, so that the PDCP layer on the UE side exits state A; if it is determined that the IP data packet is illegal , the second correcting unit reports the downlink decryption abnormality to the AS layer on the UE side, and the AS layer on the UE side restores the data link by releasing the link and rebuilding it completely. The above device first attempts to correct according to the most likely superframe number out-of-synchronization situation, and when the correction fails at most two times, it actively releases the link and completely rebuilds it, reducing processing time and improving user experience.

Further, when receivedSn-LastSubmittedPdcpSn>Reordering_Window or 0≤LastSubmittedPdcpSn-receivedSn<Reordering_Window, the judging unit determines that the newly received downlink data packet is out of the window; otherwise, it is determined that the newly received downlink data packet falls out of the window, that is, it is within the window. This is a specific implementation of the judgment unit.

Preferably, the length of k is 20 bytes. The length of the downlink IP data packet is generally about 1500 bytes, and the first 20 bytes basically cover the basic information of the header of the IP data packet, so this length can quickly verify whether the decryption of the IP data packet is accurate, and the processing time is short.

Further, the legality judgment of the IP data packet is to check whether the header information of the decrypted IP data packet is legal, including checking the IP version field, IP One or more of the head length field and the IP packet total length field. This is a means of quickly verifying that the decryption of an IP packet was successful.

Further, the "release link and complete re-establishment" means that the PDCP layer on the UE side actively informs the AS layer to disconnect the link at the first time, and then the AS layer on the UE side re-establishes the link. This is a supplement to the second correction unit.

beneficial effect

The technical effect achieved by the present application is to design and implement a new enhanced decryption process based on the original downlink decryption process of the PDCP layer of the LTE mobile terminal, which enhances and improves the decryption of downlink data packets that often occurs in actual networks. unusual scene. It has been well verified in practical applications or special laboratory test scenarios, and has a good use effect.

Description of drawings

FIG. 1 is a flowchart of a method for decrypting data by a PDCP layer of an existing LTE mobile terminal.

FIG. 2 is a flowchart of a method for enhancing data decryption by the PDCP layer of an LTE mobile terminal proposed in the present application.

FIG. 3 is a schematic structural diagram of a device for enhancing data decryption by the PDCP layer of an LTE mobile terminal proposed in the present application.

Reference numerals in the figure indicate: 21 is a receiving unit; 22 is a judgment unit; 23 is a decryption unit; 24 is a first correcting unit; 25 is a second correcting unit.

Embodiments of the present invention

Referring to FIG. 2 , the enhanced method for data decryption by the PDCP layer of an LTE mobile terminal proposed in this application includes the following steps.

Step S21: The PDCP layer on the UE side receives a new downlink data packet.

Step S22: The PDCP layer on the UE side determines whether the newly received downlink data packet is out of the window according to the maintained state variables LastSubmittedPdcpSn, the reordering window and the sequence number receivedSn of the newly received downlink data packet. Among them, LastSubmittedPdcpSn indicates the sequence number of the PDCP SDU submitted by the PDCP layer on the UE side to the upper layer last time, reordering window represents the window size range used by the PDCP layer on the UE side to maintain the sequence number received in sequence, and receivedSn represents the sequence number of the PDU newly received by the PDCP layer on the UE side. When receivedSn－LastSubmittedPdcpSn>Reordering_Window or 0≤LastSubmittedPdcpSn－receivedSn<Reordering_Window, it is determined that the newly received downlink data packet is out of the window; otherwise, it is determined that the newly received downlink data packet is out of the window (that is, within the window).

If it is, discard the data packets out of the window, the super frame number maintained by the PDCP layer on the UE side and the state variables LastSubmittedPdcpSn, reordering The window remains unchanged, while the PDCP layer on the UE side is in state A, and returns to step S21. The state A indicates that there is a high probability that the superframe numbers of the UE side and the network side are out of synchronization at this time.

If not, go to step S23.

Step S23: The PDCP layer on the UE side performs software decryption on the start k length of the first IP data packet of the dropped window according to the maintained superframe number, and judges the validity of the IP data packet. Preferably, the length of k is 20 bytes, because the length basically includes the basic information of the header (header) of the IP data packet. Judging the validity of IP data packets is to check whether the header information of the decrypted IP data packets is legal, such as checking IP version (IP data packet version), IP head length (IP data packet header length), IP packet One or more of the total length (IP packet total length) fields.

If it is determined that the IP data packet is valid, the PDCP layer on the UE side exits state A (if the PDCP layer on the UE side is in state A), the superframe number maintained by the PDCP layer on the UE side remains unchanged, and returns to step S21.

If it is determined that the IP data packet is invalid, step S24 is entered.

Step S24: The PDCP layer on the UE side performs software decryption on the initial k length of the IP data packet according to the maintained superframe number+1, and judges the validity of the IP data packet. Preferably, the length of k is 20 bytes. Judging the legitimacy of IP data packets is to check whether the header information of the decrypted IP data packets is legal, such as checking IP One or more of the version, IP head length, and IP packet total length fields.

If it is determined that the IP data packet is valid, the superframe number maintained by the PDCP layer on the UE side is changed to superframe number+1, the PDCP layer on the UE side exits state A, and returns to step S21.

If it is determined that the IP data packet is invalid, then go to step S25.

Step S25: The PDCP layer on the UE side performs software decryption on the initial k length of the IP data packet according to the maintained superframe number+2, and judges the validity of the IP data packet. Preferably, the length of k is 20 bytes. Judging the legitimacy of IP data packets is to check whether the header information of the decrypted IP data packets is legal, such as checking IP One or more of the version, IP head length, and IP packet total length fields.

If it is determined that the IP data packet is valid, the superframe number maintained by the PDCP layer on the UE side is changed to superframe number+2, the PDCP layer on the UE side exits state A, and returns to step S21.

If it is determined that the IP data packet is invalid, the PDCP layer on the UE side reports that the downlink decryption of the AS (Access Stratum, access) layer is abnormal, and the AS layer on the UE side restores the data link by releasing the link and rebuilding it completely. The "release link is completely re-established" means that the PDCP layer on the UE side actively informs the AS layer to disconnect the link at the first time, and then the AS layer on the UE side re-establishes the link. This can shorten the error data communication time and shorten the waiting time.

Referring to FIG. 3 , the device for enhancing data decryption by the PDCP layer of an LTE mobile terminal proposed in this application includes a receiving unit 21 , a judging unit 22 , a decrypting unit 23 , a first correcting unit 24 and a second correcting unit 25 .

The receiving unit 21 is configured to allow the UE side to receive a new downlink data packet sent by the network side.

The judging unit 22 judges whether the newly received downlink data packet is out of the window according to the state variables LastSubmittedPdcpSn, the reordering window and the sequence number receivedSn of the newly received downlink data packet maintained by the PDCP layer on the UE side. When receivedSn－LastSubmittedPdcpSn>Reordering_Window or 0≤LastSubmittedPdcpSn－receivedSn<Reordering_Window, it is determined that the newly received downlink data packet is out of the window; otherwise, it is determined that the newly received downlink data packet is out of the window (that is, within the window). If yes, the judging unit 22 discards the data packets out of the window, the super frame number maintained by the PDCP layer on the UE side and the state variables LastSubmittedPdcpSn, reordering The window remains unchanged, so that the PDCP layer on the UE side is in state A. If not, the judgment unit 22 sends the IP data packet to the decryption unit 23 .

The decryption unit 23 is configured to perform software decryption on the start k length of the IP data packet sent by the judgment unit 22 according to the superframe number maintained by the PDCP layer on the UE side, and judge the validity of the IP data packet. Preferably, the length of k is 20 bytes. If it is determined that the IP data packet is valid, the decryption unit causes the PDCP layer on the UE side to exit state A (if the PDCP layer on the UE side is in state A), and the superframe number maintained by the PDCP layer on the UE side remains unchanged. If it is determined that the IP data packet is invalid, the decryption unit 23 sends the IP data packet to the first correction unit 24 .

The first correcting unit 24 is configured to perform software decryption on the initial k length of the IP data packet sent by the decryption unit 23 using the superframe number maintained by the PDCP layer on the UE side + 1, and determine the validity of the IP data packet. Preferably, the length of k is 20 bytes. If it is determined that the IP data packet is valid, the first correcting unit 24 changes the superframe number maintained by the PDCP layer on the UE side to superframe number+1, so that the PDCP layer on the UE side exits state A. If it is determined that the IP data packet is invalid, the first correcting unit 24 sends the IP data packet to the second correcting unit 25 .

Described second correcting unit 25 is used for adopting the super frame number+2 maintained by the PDCP layer of the UE side to perform software decryption on the initial k length of the IP data packet sent by the first correcting unit 24, to judge the legitimacy of this IP data packet . Preferably, the length of k is 20 bytes. If it is determined that the IP data packet is valid, the second correcting unit 25 changes the superframe number maintained by the PDCP layer on the UE side to superframe number+2, so that the PDCP layer on the UE side exits state A. If it is determined that the IP data packet is invalid, the second correcting unit 25 reports the downlink decryption abnormality to the AS layer on the UE side, and the AS layer on the UE side restores the data link by releasing the link and rebuilding it completely. The "release link is completely re-established" means that the PDCP layer on the UE side actively informs the AS layer to disconnect the link at the first time, and then the AS layer on the UE side re-establishes the link.

Compared with the prior art, the present application has the following beneficial effects.

First, in the prior art, when the superframe number maintained by the PDCP layer on the UE side is not synchronized with the network side, the data communication between the UE side and the network side is due to decryption errors and transmission data errors. After accumulating for a certain period of time, The application link will be automatically disconnected, and the waiting time will be long, resulting in a poor user experience. On the one hand, the present application attempts to correct the superframe number maintained by the PDCP on the UE side. If the correction is successful, the impact of the out-of-synchronization of the superframe number will be minimized, and the user will hardly notice it. On the other hand, the present application adopts the method of releasing the link and rebuilding it completely when the correction fails, so that the waiting time is short and the user experience is improved.

Second, the IP data packet received by the PDCP layer on the UE side is generally about 1500 bytes in length. This application uses software to decrypt the first k length of the IP data packet (for example, 20 bytes) to verify whether the IP data packet is Normal, to save time as much as possible.

Third, the superframe number maintained by the UE side and the network side is out of sync. The most likely reason is that the superframe number maintained by the PDCP layer of the UE side is 1 or 2 smaller than that of the network side. For these two most likely superframe number out-of-sync situations, the present application attempts to correct the superframe number maintained by the PDCP on the UE side. If the correction is unsuccessful at most two times, it indicates that the super frame number is out of sync is too serious, and then take the method of releasing the link and rebuilding it completely.

The above are only preferred embodiments of the present application, and are not intended to limit the present application. Various modifications and variations of this application are possible for those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this application shall be included within the protection scope of this application.

Claims

A method for LTE PDCP data decryption enhancement, characterized in that it comprises the following steps;

Step S21: the PDCP layer on the UE side receives a new downlink data packet;

Step S22: The PDCP layer on the UE side judges whether the newly received downlink data packet is out of the window according to the maintained state variables LastSubmittedPdcpSn, reordering window and the sequence number of the newly received downlink data packet receivedSn; wherein, LastSubmittedPdcpSn represents the PDCP layer on the UE side The last PDCP submitted to the upper level Serial number of SDU, reordering window represents the window size range used by the PDCP layer on the UE side to maintain the sequence number received in sequence, and receivedSn represents the sequence number of the PDU newly received by the PDCP layer on the UE side;

If yes, discard the data packet out of the window, the superframe number maintained by the PDCP layer on the UE side, the state variables LastSubmittedPdcpSn, and the reordering window remain unchanged, while the PDCP layer on the UE side is in state A, and go back to step S21;

If not, go to step S23;

Step S23: the PDCP layer on the UE side performs software decryption on the start k length of the first IP data packet of the dropped window according to the maintained superframe number, and judges the validity of the IP data packet;

If it is determined that the IP data packet is legal, the PDCP layer on the UE side exits state A, the superframe number maintained by the PDCP layer on the UE side remains unchanged, and returns to step S21;

If it is determined that the IP data packet is illegal, then enter step S24;

Step S24: the PDCP layer on the UE side performs software decryption on the initial k length of the IP data packet according to the maintained superframe number+1, and judges the validity of the IP data packet;

If it is determined that the IP data packet is legal, the superframe number maintained by the PDCP layer on the UE side is changed to the superframe number+1, the PDCP layer on the UE side exits state A, and returns to step S21;

If it is determined that the IP data packet is illegal, then enter step S25;

Step S25: the PDCP layer on the UE side performs software decryption on the initial k length of the IP data packet according to the maintained superframe number+2, and judges the validity of the IP data packet;

If it is determined that the IP data packet is legal, the superframe number maintained by the PDCP layer on the UE side is changed to the superframe number+2, the PDCP layer on the UE side exits state A, and returns to step S21;

If it is determined that the IP data packet is invalid, the PDCP layer on the UE side reports that the downlink decryption of the AS layer is abnormal, and the AS layer on the UE side restores the data link by releasing the link and rebuilding it completely.
The method for enhancing LTE PDCP data decryption according to claim 1, wherein in step S22, when receivedSn-LastSubmittedPdcpSn>Reordering_Window or 0≤LastSubmittedPdcpSn-receivedSn<Reordering_Window, it is determined that the newly received downlink data packet is out of the window ; otherwise, it is determined that the newly received downlink data packet falls into the window, that is, it is within the window.
The method for enhancing LTE PDCP data decryption according to claim 1, wherein, in the step S23, the step S24, and the step S25, the length of k is all 20 bytes.
The method for decrypting and enhancing LTE PDCP data according to claim 1, wherein in the step S25, the "completely re-establishing the link release" means that the PDCP layer on the UE side actively informs the AS layer to disconnect the link at the first time , and then the AS layer on the UE side re-establishes the link.
A device for decrypting and enhancing LTE PDCP data, comprising a receiving unit, a judging unit, a decrypting unit, a first correcting unit and a second correcting unit;

The receiving unit is configured to allow the UE side to receive a new downlink data packet sent by the network side;

The judging unit uses the state variables LastSubmittedPdcpSn, reordering window and the sequence number receivedSn of the newly received downlink data packet maintained by the PDCP layer on the UE side to judge whether the newly received downlink data packet is out of the window; if so, the judging unit Discard the data packets out of the window, the superframe number maintained by the PDCP layer on the UE side, the state variables LastSubmittedPdcpSn, and the reordering window remain unchanged, so that the PDCP layer on the UE side is in state A; if not, the judgment unit The data packet is sent to the decryption unit;

Described decryption unit is used to carry out software decryption according to the super frame number that the PDCP layer of UE side maintains to the starting k length of the IP data packet sent by the judgment unit, and judges the legality of this IP data packet; If it is judged that this IP data packet is legal , the decryption unit makes the PDCP layer on the UE side exit state A, and the superframe number maintained by the PDCP layer on the UE side remains unchanged; if it is determined that the IP data packet is illegal, the decryption unit sends the IP data packet to the first correction unit;

Described first correcting unit is used for adopting the super frame number+1 maintained by the PDCP layer of the UE side to carry out software decryption to the starting k length of the IP data packet sent by the decryption unit, to judge the legitimacy of this IP data packet; The IP data packet is legal, and the first correcting unit changes the super frame number maintained by the PDCP layer on the UE side to the super frame number + 1, so that the PDCP layer on the UE side exits state A; if it is determined that the IP data packet is illegal, the The first correcting unit sends the IP data packet to the second correcting unit;

Described second correcting unit is used for adopting the super frame number+2 maintained by the PDCP layer of UE side to carry out software decryption to the starting k length of the IP data packet sent by the first correcting unit, to judge the legitimacy of this IP data packet; It is determined that the IP data packet is legal, and the second correction unit changes the superframe number maintained by the PDCP layer on the UE side to superframe number+2, so that the PDCP layer on the UE side exits state A; if it is determined that the IP data packet is illegal , the second correcting unit reports the downlink decryption abnormality to the AS layer on the UE side, and the AS layer on the UE side restores the data link by releasing the link and rebuilding it completely.
The device for enhancing LTE PDCP data decryption according to claim 5, wherein when receivedSn-LastSubmittedPdcpSn>Reordering_Window or 0≤LastSubmittedPdcpSn-receivedSn<Reordering_Window, the judgment unit judges that the newly received downlink data packet is out of the window; otherwise It is determined that the newly received downlink data packet falls into the window, that is, it is within the window.
The apparatus for enhancing LTE PDCP data decryption according to claim 5, wherein the length of k is 20 bytes.
The device for enhancing LTE PDCP data decryption according to claim 5, wherein the judgment of the validity of the IP data packet is to check whether the header information of the decrypted IP data packet is legal, including checking the IP version field, IP One or more of the head length field and the IP packet total length field.
The device for enhancing LTE PDCP data decryption according to claim 5, wherein the "release link is completely rebuilt" means that the PDCP layer on the UE side actively informs the AS layer to disconnect the link at the first time, and then the AS layer on the UE side actively informs the AS layer to disconnect the link. Layer re-links.