[发明专利]一种LTE PDCP数据解密增强的方法及装置

说明书

本申请公开了一种LTE PDCP数据解密增强的方法。UE侧的PDCP层根据维护的状态变量判断新收到的下行数据包是否出窗。如果否，UE侧的PDCP层根据维护的超帧号对落窗的第一个IP数据包的开始k长度进行软件解密，判断该IP数据包的合法性。如果判定该IP数据包不合法，则UE侧的PDCP层根据维护的超帧号+1对该IP数据包的开始k长度进行软件解密，判断该IP数据包的合法性。如果判定该IP数据包不合法，则UE侧的PDCP层根据维护的超帧号+2对该IP数据包的开始k长度进行软件解密，判断该IP数据包的合法性。如果判定该IP数据包不合法，则UE侧的PDCP层上报AS层下行解密异常，UE侧的AS层采取释放链接彻底重建的方式恢复数据链路。上述方法能够减少处理时间，提高用户体验。

技术领域

本申请涉及一种LTE（Long-Term Evolution，长期演进）移动终端对下行数据的解密方法。

背景技术

LTE移动终端的PDCP（Packet Data Convergence Protocol，分组数据汇聚协议）层的一个重要功能就是对数据以及信令的加密解密。PDCP层的加解密参数包括密钥（key）和计数（Count）值。计数值由PDCP层维护的超帧号（Hyper Frame Number，HFN）以及序列号（Sequence Number，SN）组成。其中序列号记录在PDCP头部中，不会出错。超帧号需要UE（User Equipment，用户设备，即移动终端）侧与网络侧共同维护同步，如果失步（即不同步，同步失败），则移动终端对下行数据的解密就会失败。为了维护同步超帧号，3GPP PDCP协议定义了详细的窗口管理机制。但是由于空口质量的影响，网络侧的PDCP的丢弃定时器（discard timer）超时会引起丢包。此时虽然网络侧的RLC（radio link conrtol，无线链路控制）层的序列号是连续的，但是在协议栈架构上位于RLC层之上的网络侧的PDCP层的序列号出现了非连续状况，这属于正常场景，但是极端情况下会引起UE侧与网络侧的超帧号失步，从而使移动终端对下行数据的解密失败。

请参阅图1，现有的LTE移动终端的PDCP层对数据解密的方法包括如下步骤。

步骤S11：UE侧的PDCP层收到新的下行数据包。

步骤S12：UE侧的PDCP层根据维护的状态变量LastSubmittedPdcpSn、reorderingwindow以及新收到的下行数据包的序列号receivedSn判断新接收的下行数据包是否出窗。LastSubmittedPdcpSn表示UE侧的PDCP层上一次提交给高层的PDCP SDU（Service DataUnit，服务数据单元，也称业务数据单元）的序列号，reordering window表示UE侧的PDCP层用来维护序列号按序接收的窗口大小范围，receivedSn表示UE侧的PDCP层最新接收到的PDU（Protocol Data Unit，协议数据单元）的序列号。当receivedSn－LastSubmittedPdcpSn＞Reordering_Window或者0≤LastSubmittedPdcpSn－receivedSn＜Reordering_Window时，判定新接收的下行数据包出窗；否则判定新接收的下行数据包落窗（即在窗口内）。

如果是，丢弃出窗的数据包，所述状态变量LastSubmittedPdcpSn、reorderingwindow保持不变，回到步骤S11。

如果否，进入步骤S13。

步骤S13：UE侧的PDCP层使用维护的超帧号对下行数据包解密，并将解密后的数据提交给UE侧的应用层。