技术领域

本发明涉及通信技术领域， 尤其涉及一种发送数据包、 PDCP层超帧号 状态更新和维护、 数据处理的方法及装置。

背景技术

在现有 LTE ( Long Term Evolution, 长期演进 ) 系统中， 为了保证经过 空口传输的数据在接收端可以被按序地传递到 应用层， 因此在发送端采用 了为数据包分配序号的方法，即在 PDCP( Packet Data Convergence Protocol, 分组数据汇聚协议）层按照接收到的数据包的 顺序为数据包分配计数值 ( Count )。所述计数值包含两个部分： 超帧号（HFN, Hyper Frame Number ) 和序号 （SN, Sequence Number )。 在数据传送过程中， 将计数值 Count中 的序号 SN与数据内容同时发送给接收端；同时在发送� ��和接收端各维护一 个 HFN状态， 两侧的 HFN状态要保持同步。

由于只有 SN被携带在数据包中传递， 因此接收端只能根据接收到的 SN值来推测出发送端在处理该数据包时所使用� �� HFN值， 以此对接收端 的 HFN值进行更新。

此外， 为了保证数据的机密性和完整性， 在 PDCP层还需要对发送的 数据内容进行加密和 /或完整性保护。 在现有的加密和完整性保护算法中， 都需要使用 Count值作为一个输入参数。 发送端在加密或完整性保护过程 中使用 Count值， 相应地接收端在解密和完整性验证过程中使用 Count值。 对于同一个数据包， 只有发送端和接收端同时使用相同的 Count值时， 数 据包才能被成功接收， 否则将导致解密和 /或完整性验证过程失败， 进而导 致数据包不能正确接收。

在实现上述数据传送的过程中， 发明人发现现有技术中至少存在如下 问题：

如果一个数据包中的 SN值在空口传输过程中被修改，而接收端仍然� �� 为接收到的数据包中的 SN值是可信的， 此时接收端根据接收到的 SN值来 更新本地维护的 HFN值时可能会导致 HFN值被错误更新， 进而致使发送 端和接收端使用的 Count值不一致。 那么后续的数据包解密和 /或完整性验 证将无法正常进行， 数据包无法正确接收； 这样不仅浪费了空口的资源， 同时也影响用户的感受。

此外， 如果接收端 PDCP层根据所接收到数据包中的协议数据单元 ( Protocol Data Unit, PDU )数据包头中所携带的 SN判断得知， 所述接收 端 PDCP层不需要该数据包中所携带的业务数据单� �（ Service Data Unit, SDU ), 但是由于 PDCP层的 ROHC ( Robust Header Compression, 鲁棒头 压缩）实体需要该 PDU 中所携带的头压缩信息， 因此所述接收端仍然需要 对该 PDU进行解密 （ Deciphering ), 并将解密后的数据交给 ROHC实体处 理， 进一步获得头压缩的信息， 然后将 PDU解密后得到的 SDU进行丢弃 处理。

然而， ROHC是依赖于基站配置的可选功能；对于终端� �一个承载（例 如链路或通道）来说，可以不配置 ROHC算法或配置 ROHC算法为 NULL, 表示不使用头压缩。 在该场景下， 所述接收端 PDCP层还是会继续对所述 PDU进行解密， 这样只会增加终端的处理开销。

发明内容

一方面， 本发明的实施例提供一种发送数据包、 PDCP层超帧号状态更 新和维护的方法及装置， 用以解决数据接收端 PDCP层的超帧号被错误更 新的问题。 为达到上述目的， 本发明的实施例采用如下技术方案： 一种 PDCP层超帧号状态更新方法， 包括：

接收数据包；

对接收到的所述数据包中的序号进行防篡改验 证；

若验证结果表明所述序号通过了防篡改验证， 则根据所述序号对所述 数据包接收端的超帧号状态进行更新。

一种数据包发送方法， 包括：

对待发送的数据包包头中的序号进行防篡改保 护；

对所述数据包进行组装并发送给接收端。

一种 PDCP层超帧号状态维护方法， 包括：

根据接收到的数据包中的序号对超帧号的状态 进行更新；

在后续出现数据包出错时， 判断所述超帧号是否已经被修改； 若所述超帧号已经被修改， 则将所述超帧号恢复至修改前的状态。 一种 PDCP层超帧号状态更新装置， 包括：

接收单元， 用于接收数据包；

验证单元， 用于对接收到的所述数据包中的序号进行防篡 改验证； 更新单元， 用于在所述验证单元输出的验证结果表明所述 序号通过了 防篡改验证时， 根据所述序号对所述数据包接收端的超帧号状 态进行更新。

一种数据包发送装置， 包括：

保护单元， 用于对待发送的数据包包头中的序号进行防篡 改保护； 组装单元， 用于对所述数据包进行组装；

发送单元， 用于将组装好的数据包发送给接收端。

一种 PDCP层超帧号状态维护装置， 包括：

更新单元， 用于根据接收到的数据包中的序号对超帧号的 状态进行更 新；

判断单元， 用于在后续出现数据包出错时， 判断所述超帧号是否已经 被修改； 恢复单元， 用于在所述判断单元输出的判断结果表明所述 超帧号已经 被修改时， 将所述超帧号恢复至修改前的状态。

本发明实施例提供的发送数据包、 PDCP层超帧号状态更新和维护的方 法及装置， 在接收到数据包之后对该数据包中的序号进行 防篡改验证之后 再对超帧号状态进行更新， 或者在接收端对接收到的数据包进行相应处理 的过程中出错时判断出超帧号已经被修改的情 况下对超帧号状态进行恢 复， 从而解决现有技术中由于超帧号错误更新导致 后续数据包解密失败等 问题。 与现有技术相比， 利用本发明实施例中的方案可以解决 PDCP层数 据包对应的超帧号被错误更新的问题， 进而保证后续数据包解密和 /或完整 性验证等过程的正常进行； 这样， 不仅可以提高数据传输的成功率和可靠 性， 而且提升了系统的服务质量。

另一方面， 本发明实施例还提供了一种 PDCP层数据处理的方法及装 置， 用以降氏接收端处理开销。

为达到上述目的， 本发明的实施例采用如下技术方案：

一种 PDCP层数据处理方法， 包括：

根据接收到的数据包中的序号判断是否需要读 取所述数据包中的业务 数据单元；

在无需读取所述数据包中的业务数据单元时， 判断当前的 PDCP 实体 或该 PDCP实体对应的承载链路是否配置使用头压缩� �法；

若判断结果表明所述数据包或者当前的 PDCP 实体配置未使用头压缩 算法， 则将所述数据包中的业务数据单元丢弃。

一种 PDCP层数据处理装置， 包括：

第一判断单元， 用于根据接收到的数据包中的序号判断是否需 要读取 所述数据包中的业务数据单元；

第二判断单元， 用于在所述第一判断单元的输出结果表明无需 读取所 述数据包中的业务数据单元时， 判断当前的 PDCP实体或该 PDCP实体对 应的承载链路是否配置使用头压缩算法； 第一处理单元， 用于在所述第二判断单元输出的判断结果表明 所述数 据包或者当前的 PDCP 实体配置未使用头压缩算法时， 将所述数据包中的 业务数据单元丢弃。 本发明实施例中的 PDCP层数据处理的方法及装置，在数据包接收� � 不需要所述数据包中携带的业务数据单元时， 在对接收到的数据包中的协 议数据单元 PDU进行解密之前判断 PDCP实体或该 PDCP实体对应的承 载链路是否配置使用头压缩算法，并根据判断 结果确定是否需要对数据包 中的 PDU进行解密， 从而减少一些非必要的解密和解压缩处理， 降低接 收端的处理开销。

附图说明

为了更清楚地说明本发明实施例或现有技术中 的技术方案， 下面将对 实施例描述中所需要使用的附图作筒单地介绍 ， 显而易见地， 下面描述中 的附图仅仅是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不 付出创造性劳动的前提下， 还可以根据这些附图获得其他的附图。

图 1为本发明实施例一中的 PDCP层超帧号状态更新方法的流程图； 图 为本发明实施例一中的用于实现 PDCP层超帧号状态更新的装置 的结构示意图；

图 3为本发明实施例一中的数据包发送方法的流� �图；

图 4为本发明实施例一中的数据包发送装置的结� �示意图；

图 5为本发明实施例二中的超帧号状态更新方法� �流程图；

图 6为本发明实施例二中的 PDCP层超帧号状态更新装置的结构示意 图；

图 7为本发明实施例二中的数据包发送装置的结� �示意图；

图 8为本发明实施例三中的 PDCP层超帧号状态维护方法的流程图； 图 9为本发明实施例三中的 PDCP层超帧号状态维护装置的结构示意 图；

图 10为本发明实施例四中的超帧号状态维护方法� ��流程图； 图 11为本发明实施例四中的超帧号 HFN状态示意图一； 图 12为本发明实施例四中的超帧号 HFN状态示意图二；

图 13为本发明实施例五中的 PDCP层数据处理方法的流程图； 图 14为本发明实施例五中的 PDCP层数据处理装置的结构示意图； 图 15为本发明实施例六中的 PDCP层数据处理方法的流程图； 图 16为本发明实施例六中的序号 SN状态示意图；

图 17为本发明实施例六中的 PDCP层数据处理装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进 行清楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而不是全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没 有作出创造性劳动前提下所获得的所有其他实 施例， 都属于本发明保护的 范围。

实施例一：

如图 1所示， 本发明实施例中提供的 PDCP层超帧号状态更新方法， 包括：

101、 接收数据包。

102、 对接收到的所述数据包中的序号 SN进行防篡改验证。

在本实施例中， 所述防篡改验证可以是： 完整性验证和 CRC ( Cyclic Redundancy Check, 循环冗余校验码）校验中的至少一种。

103、 若验证结果表明所述序号通过了防篡改验证， 则根据所述序号对 所述数据包接收端的超帧号状态进行更新。

上述各步骤的执行主体为数据包的接收端， 其可以是终端侧， 也可以 是网络侧。

对应于上述方法， 本发明实施例中还提供了一种用于实现超帧号 状态 更新的装置。 如图 2所示， 所述装置包括： 接收单元 21 , 用于接收数据包；

验证单元 22, 用于对接收到的所述数据包中的序号进行防篡 改验证； 更新单元 23, 用于在所述验证单元输出的验证结果表明所述 序号通过 了防篡改验证时， 根据所述序号对所述数据包接收端的超帧号状 态进行更 新。

上述 PDCP层超帧号状态更新方法是由数据包接收端� �执行的， 相应 地在本发明实施例中还提供了一种由数据包发 送端来执行的数据包发送方 法； 如图 3所示， 本实施例中的数据包发送方法包括：

301、 对待发送的数据包包头中的序号进行防篡改保 护。

在本实施例中， 所述防篡改保护可以是： 完整性保护和循环冗余校验 码（CRC )保护中的至少一种。

302、 对所述数据包进行组装并发送给接收端。

上述各步骤的执行主体为数据包的发送端， 其可以是网络侧， 也可以 是终端侧。

对应于上述数据包发送方法， 本实施例还提供了一种用于实现上述发 送方法的数据包发送装置； 如图 4所示， 所述数据包发送装置包括：

保护单元 41 , 用于对待发送的数据包包头中的序号进行防篡 改保护； 组装单元 42, 用于对所述数据包进行组装；

发送单元 43 , 用于将组装好的数据包发送给接收端。

本发明实施例中提供的 PDCP层超帧号状态更新方法及装置， 在接收 到数据包之后对该数据包中的序号 SN进行防篡改验证，在验证通过的情况 下才对数据包接收端的超帧号状态进行更新， 从而解决现有技术中由于超 帧号错误更新导致后续数据包解密失败等问题 。 利用上述方案可以解决 PDCP层数据包对应的超帧号被错误更新的问题� �进而保证后续数据包解密 和 /或完整性验证等过程的正常进行； 这样， 不仅可以提高数据传输的成功 率和可靠性， 而且提升了系统的服务质量。

实施例二： 在本实施例中， 将以一具体实例来对本发明实施例中提供的超 帧号状 态更新方法做进一步说明。

如图 5所示， 本实施例中的超帧号状态更新方法， 具体包括以下步骤：

501、 数据包发送端在发送数据之前， 对待发送的数据包包头中的序号 SN进行防篡改保护。

在本实施例中，对 SN进行防篡改保护的方式包括：完整性保护和 CRC ( Cyclic Redundancy Check, 循环冗余校验码）保护中的至少一种。 在以下 的描述中， 将以完整性保护为例来介绍本实施例中的超帧 号状态维护方法。

对 SN进行完整性保护的过程大致如下：

Sl、 终端与网络侧通过密钥协商过程确定完整性保 护和完整性验证所 使用的密钥；

52、 网络侧为终端配置完整性保护算法；

53、 数据包发送端， 可以是网络侧也可以是终端， 利用上述完整性保 护算法以及完整性保护的密钥对需要保护的内 容例如序号 SN进行完整性 保护。

在所述完整性保护算法中， 所用到的输入参数除了当前的 SN值之外， 还可以增加其他的输入参数例如计数值 Count和 /或数据的发送方向等。 当 然， 在完整性保护算法中所用到的输入参数越多， 则接收端在对数据包中 的 SN进行完整性验证的准确度就会越高。

如果在后续的完整性验证过程中， 接收端需要使用发送端在进行完整 性保护时所生成的部分或者全部结果， 即数据经过完整性保护处理后得到 的加密后的输出 bit (比特） 串， 则发送端还需要将完整性保护过程中生成 的部分或者全部被用于验证的结果附加到所述 数据包中。

502、 如果接收端需要对 SN执行完整性验证， 发送端需要将完整性验 证所需要的验证信息承载到数据包中。

所述险证信息至少包括： MAC-I(Message Authentication Code for Integrity, 完整性保护信息授权码）中的全部或者部分信 息。 具体地， 可以是 将所述完整性所需要的信息承载到数据包的包 头部分， 也可以是承载到包 尾部分。

如果在后续的完整性验证不需要上述验证信息 ， 那么步骤 502可以跳 过。

503、 发送端的 PDCP实体组装好数据包， 并将数据包传递给底层， 比 如 RLC ( Radio Link Control, 无线链路控制）层， 并通过 RLC层发送给 数据包接收端。

504、接收端在接收到所述数据包之后，读取该 数据包包头中的序号 SN。

505、 如果数据包中携带了完整性验证所需要的信息 ， 接收端根据数据 包中携带的验证信息对 SN执行防篡改验证。

所述防篡改验证包括： 完整性验证和循环冗余校验码校验中的至少一 种。 由于本实施例中是以完整性验证为例， 因此在本步骤中即为接收端根 据数据包中携带的验证信息对 SN执行完整性验证。

如果在所述数据包中未携带验证信息， 则终端可以利用不需要额外验 证信息的完整性验证算法对 SN进行完整性验证。 例如， 接收端可以通过 对数据包中的数据部分进行完整性验证， 并依据验证结果间接地判断所述 序号 SN是否符合完整性验证。 如果所述数据部分未通过完整性验证， 此 时认为所述 SN同样未通过完整性 3 证， 否则认为所述 SN通过完整性马 证。

所述完整性险证， 具体包括： 接收端， 可以是终端也可以是网络侧， 依据完整性保护验证算法， 验证所接收到的内容（序号 SN )是否被篡改。 比如， 接收端通过完整性保护算法并结合密钥等其他 输入信息， 所计算出 的结果不能与数据包中所携带的部分或全部内 容相匹配（或者相同）， 则 接收端认为该数据包的 SN被篡改过， 否则可以认为该数据包的 SN未被 篡改。

如果在步骤 505中完整性验证的验证结果表明 SN通过了完整性验证， 即数据包中的 SN未被篡改， 则执行步骤 506; 否则， 对所述数据包进行 丢弃和 /或通知上层控制部分完整性 3 证失败。

506、如果终端依据所接收的 SN判断出需要对 HFN进行更新， 则数据 包接收端根据所述序号 SN对数据包接收端的超帧号 HFN状态进行更新。

对于无线链路控制层采用确认模式传输的数据 包接收端， 数据包接收 端按照所接收到的 SN来推测发送端在处理该数据包的时候所使用� �� HFN 值； 如果接收端判断出下一个期望接收的 SN减去当前接收到的 SN的差 值大于重排序窗口， 则认为发送端已经开始采用下一个 HFN值， 并将接 收端当前的 HFN值更新为 HFN+1。

对于无线链路控制层采用非确认模式传输的数 据包接收端， 如果所接 收到的 SN小于下一个期望接收到的 SN,则认为发送端已经开始采用下一 个 HFN值， 并将接收端当前的 HFN值更新为 HFN+1。

在上述方法中， 数据包发送端对 SN进行防篡改保护的过程可以是对 SN独立地执行防篡改保护， 也可以是与数据包中的其它数据一同执行防 篡改保护。

对应于上述 PDCP层超帧号更新方法， 本实施例还提供了一种作为数 据包接收端的 PDCP层超帧号状态更新装置和作为数据包发送� �的数据包 发送装置。 其中，

所述 PDCP层超帧号状态更新装置， 如图 6所示， 包括：

接收单元 61 , 用于接收数据包；

验证单元 62, 用于对接收到的所述数据包中的序号进行防篡 改验证； 更新单元 63, 用于在所述验证单元输出的验证结果表明所述 序号通过 了防篡改验证时， 根据所述序号对所述数据包接收端的超帧号状 态进行更 新。

进一步地， 本实施例中的 PDCP层超帧号状态更新装置， 还可以包括： 处理单元 64, 用于在所述验证单元输出的验证结果表明所述 序号未通 过所述防篡改验证时， 将所述数据包丢弃或者通知控制层验证失败。

所述数据包发送装置， 如图 7所示， 包括： 保护单元 71 , 用于对待发送的数据包包头中的序号进行防篡 改保护； 组装单元 72, 用于对所述数据包进行组装；

发送单元 73 , 用于将组装好的数据包发送给接收端。

进一步地， 本实施例中的数据包发送装置， 还可以包括：

添加单元 74,用于将防篡改验证所需的验证信息添加到所 述数据包中， 之后将所述数据包传送给所述组装单元。

通过本发明实施例中提供的数据包发送方法及 装置、 PDCP层超帧号状 态更新方法及装置， 可以在数据包发送端对序号 SN进行防篡改保护， 对 应地， 在数据包接收端即可对接收到的数据包中的 SN进行防篡改验证； 只有在验证通过的情况下， 接收端当前的超帧号 HFN状态才可以被更新， 进而避免由于超帧号 HFN错误更新导致后续数据包解密失败等问题。

实施例三：

本发明实施例提供了一种 PDCP层超帧号状态维护方法， 如图 8所示， 该方法包括：

801、 根据接收到的数据包中的序号对超帧号的状态 进行更新。

802、 在后续出现数据包出错时， 例如数据包解密失败等， 判断所述超 帧号在步骤 801的更新过程中是否已经被修改。

803、若所述超帧号已经被修改，则将所述超帧 号恢复至修改前的状态。 上述各步骤的执行主体为数据包的接收端， 其可以是终端侧， 也可以 是网络侧。

对应于上述 PDCP层超帧号状态维护方法， 本实施例还提供了一种 PDCP层超帧号状态维护装置； 如图 9所示， 所述 PDCP层超帧号状态维护 装置包括：

更新单元 91 , 用于根据接收到的数据包中的序号对超帧号的 状态进行 更新；

判断单元 92, 用于在后续出现数据包出错时， 判断所述超帧号是否已 经被爹改； 恢复单元 93, 用于在所述判断单元输出的判断结果表明所述 超帧号已 经被修改时， 将所述超帧号恢复至修改前的状态。

本发明实施例提供的 PDCP层超帧号状态维护的方法及装置， 如果接 收端在对接收到的数据包进行相应处理的过程 中出错， 则判断超帧号 HFN 是否已经被修改， 并在 HFN已经被修改的情况下对超帧号状态进行恢复 ， 从而解决现有技术中由于超帧号错误更新导致 后续数据包解密失败等问 题。 与现有技术相比， 利用本发明实施例中的方案可以解决 PDCP层数据 包对应的超帧号被错误更新的问题， 进而保证后续数据包解密和 /或完整性 验证等过程的正常进行； 这样， 不仅可以提高数据传输的成功率和可靠性， 而且提升了系统的服务质量。

实施例四：

在本实施例中， 将以另一具体实例来对本发明实施例中提供的 超帧号 状态维护方法做进一步说明。

如图 10所示，本实施例中的超帧号状态维护方法，� ��体包括以下步骤：

1001、 接收端接收到来自发送端的数据包。

所述接收端和发送端可以分别是网络侧和终端 、 或者终端和网络侧。

1002、 接收端读取所接收数据包中的序号 SN。

1003、 接收端根据所述数据包中的序号 SN对数据包接收端的超帧号 HFN进行状态更新。

比如， 对于无线链路控制层采用确认模式传输的数据 包接收端， 当下 一个期望接收的 SN减去当前所接收到的 SN大于重排序窗口时， 则将当前 的 HFN更新为 HFN+1;如果接收端判断不需要更新，则该步骤不 更新 HFN 状态；

再比如， 对于无线链路控制层采用非确认模式传输的数 据包接收端， 如果所接收到的 SN小于下一个期望接收到的 SN,则将当前的 HFN更新为 HFN+1; 如果接收端判断不需要更新， 则该步骤不更新 HFN状态。

1004、 接收端在后续处理过程中， 发现所述数据包出现错误， 比如数 据包解密失败。

1005、 判断数据包接收端所维护的超帧号 HFN状态在执行步骤 1003 的更新过程中是否已经被修改。

如果已经被修改， 则执行步骤 1006; 如果没有被修改， 则无需对 HFN 状态执行任何操作。

1006、 将所述数据包接收端的超帧号 HFN恢复至修改前的状态。

例如， 在步骤 1003中将 HFN更新为 HFN+1 , 那么在数据包出错的情 况下， 就需要将所述 HFN的状态从 HFN+1恢复成原来的 HFN值。

对应于上述方法描述， 本实施例中还提供了一个具体实现的实例。 在无线链路控制层采用确认模式传输的数据包 接收端的场景下， 如图

11所示， 该图表示接收端所维护的超帧号 HFN状态； 其中，

Last_Submitted_PDCP_RX_SN： 接收端上一次向上层递交的数据包的 SN号， 比如 4000;

Next_PDCP_RX_SN: 接收端期望接收到的下一个数据包的 SN号， 比 如 4001;

Received PDCP SN: 接收端当前所接收到的数据包的 SN所在的位置， t匕: ¾口 10;

Reordering Window: 重排序窗口， 全部 SN可以表示范围的一半。 比如 图中全部 SN表示范围为 0-4095, 则 reordering window 为 2048;

接收端的 HFN状态： HFN可以为任意有效数值， 比如 80;

HFN状态的爹改和恢复过程：

对于无线链路控制层采用确认模式传输的数据 包接收端， 结合图 11所 示， 接收端接收到数据包， 并判断出 Next_PDCP_RX_SN - received PDCP SN > Reordering—Window; 则接收端认为该数据包在发送端的处理时刻， 发 送端所使用的 HFN为 81, 而不是接收端当前的 HFN状态 80, 此时接收端 为了实现与发送端 HFN的同步， 接收端将 HFN加 1 , 即 80 + 1 = 81;

在解密过程中， 接收端发现该数据包解密错误， 依据本发明的方式， 接收端需要恢复由该数据包引起的 HFN更新， 接收端将 HFN恢复为未修 改改前的状态， 恢复 HFN=80。

而在无线链路控制层采用非确认模式传输的数 据包接收端的场景下， 结合图 12所示的接收端所维护的超帧号 HFN状态，如果所接收到的 SN(即 Received PDCP SN )小于下一个期望接收到的 SN(即 Next_PDCP_RX_SN ), 则将当前的 HFN更新为 HFN+1。在解密过程中，接收端发现该数据包解� �� 错误， 依据本发明的方式， 接收端需要恢复由该数据包引起的 HFN更新， 接收端将 HFN恢复为未爹改改前的状态。

本发明实施例中提供的超帧号状态维护方法， 在数据包接收端发现数 据包出现错误或者异常时， 判断数据包接收端的超帧号状态是否经过一次 修改； 由于数据包出错或异常在很大程度上可能是由 超帧号错误更新而引 起的， 因此本实施例提供的方案在数据包出错的情况 下对超帧号状态进行 再次更新， 即将超帧号恢复至修改前的状态； 这样， 在后续的数据处理过 程中可以避免再次由超帧号 HFN错误更新导致数据包解密失败等问题。 此外， 在本发明实施例中还可以将上述实施例一、 二中提供的方案与 实施例三、 四中提供的方案结合起来。 比如， 数据包接收端在接收到数据 包后， 可以先通过实施例一、 二中的方案对接收到的数据包进行防篡改验 证， 并在通过防篡改验证的情况下对数据包接收端 的超帧号状态进行更新； 之后， 如果出现了数据包出错的情况， 则可以通过实施例三、 四中的方案 判断超帧号是否已经被修改， 若已经修改则将超帧号恢复至修改前的状态。

在上述各实施例所描述的方案中， 均是对数据包接收端的超帧号 HFN 进行状态更新 /维护； 但是， 本发明的保护范围不限于此， PDCP上下文状 态也可以是与 HFN状态一样， 在通过防篡改验证之后再进行更新或者在发 实施例五：

本发明实施例提供了一种 PDCP层数据处理方法， 如图 13所示， 该方 法包括： 1301、 根据接收到的数据包中的序号判断是否需要读 取所述数据包中 的业务数据单元。

1302、在无需读取所述数据包中的业务数据单� �时， 判断当前的 PDCP 实体或该 PDCP实体对应的承载链路是否配置使用头压缩� �法。

1303、 若判断结果表明所述数据包或者当前的 PDCP 实体配置未使用 头压缩算法， 则将所述数据包中的业务数据单元丢弃。

上述各步骤的执行主体为数据包的接收端， 其可以是终端侧， 也可以 是网络侧。

对应于上述方法， 本实施例中还提供了一种 PDCP层数据处理装置， 如图 14所示， 包括：

第一判断单元 141 ,用于根据接收到的数据包中的序号判断是否� �要读 取所述数据包中的业务数据单元；

第二判断单元 142,用于在所述第一判断单元 141的输出结果表明无需 读取所述数据包中的业务数据单元时， 判断当前的 PDCP 实体或该 PDCP 实体对应的承载链路是否配置使用头压缩算法 ；

第一处理单元 143,用于在所述第二判断单元 142输出的判断结果表明 所述数据包或者当前的 PDCP 实体配置未使用头压缩算法时， 将所述数据 包中的业务数据单元丢弃。

本发明实施例中的 PDCP层数据处理的方法及装置， 在数据包接收端 不需要所述数据包中携带的业务数据单元时， 在对接收到的数据包中的协 议数据单元 PDU进行解密之前判断当前 PDCP实体或该 PDCP实体对应的 承载链路是否配置使用头压缩算法， 并根据判断结果确定是否需要对数据 包中的 PDU进行解密， 从而减少一些非必要的解密和解压缩处理， 降低接 收端的处理开销。

实施例六：

下面将以一具体实施例来对实施例五中提供的 方案做进一步的阐述。 如图 15所示， 本实施例中提供的 PDCP层数据处理的方法， 包括以下 步骤：

1501、根据接收到的数据包中的序号 SN判断是否需要读取所述数据包 中的业务数据单元 SDU。

具体地， 所述判断过程可以参照如下的判断条件（可参 见图 16 ): 如果接收端接收到的数据包满足条件， 即 Received PDCP SN (接收端 当 前 所 接 收 到 的 数 据 包 的 SN 所 在 的 位 置 ） 减 去 Last_Submitted_PDCP_RX_SN (接收端上一次向上层递交的数据包的 SN 号 ) 得到的差值大于 Reordering Window ( 重排序窗 口 ) 或者 Last_Submitted_PDCP_RX_SN减去 Received PDCP SN得到的差值大于等于 0而小于 Reordering Window (见图 16(A) ), 则丢弃 PDCP SDU;

进一步地， 如果 received PDCP SN 大于 Next_PDCP_RX_SN (接收端 期望接收到的下一个数据包的 SN号）（见图 16(B) ), 则对 PDCP PDU进 行解密， 并使用基于 RX_HFN - 1和 received PDCP SN得到的计数值； 如果 received PDCP SN 小于 Next_PDCP_RX_SN (见图 16(C) ), 则对 PDCP PDU进行解密， 并使用基于 RX_HFN和 received PDCP SN得到的 计数值。

由上可知， 如果接收端 PDCP层接收到数据包中的协议数据单元 PDU 数据包头中所携带的 SN满足上述条件，则说明所述接收端 PDCP层不需要 该数据包中所携带的业务数据单元 SDU。

1502、在无需读取所述数据包中的业务数据单� �时， 判断当前的 PDCP 实体或该 PDCP实体对应的承载链路是否配置使用头压缩� �法。

所述配置使用头压缩算法， 可以是配置了有效的头压缩算法， 或者是 头压缩算法不为 NULL。

如果步骤 1502中的判断结果为是， 则执行步骤 1503~1505； 如果步骤 1502中的判断结果为是， 则执行步骤 1505。

1503、 对所述数据包中的协议数据单元 PDU进行解密。

1504、 对解密后的数据包中的 PDU进行解压缩， 以得到其中携带的头 压缩信息和 SDU。

1505, 将接收端 PDCP层获取到的 SDU丢弃。

对应于上述方法描述， 本实施例还提供了一种 PDCP层数据处理装置， 如图 17所示， 该装置包括：

第一判断单元 171 ,用于根据接收到的数据包中的序号判断是否� �要读 取所述数据包中的业务数据单元；

第二判断单元 172,用于在所述第一判断单元 171的输出结果表明无需 读取所述数据包中的业务数据单元时， 判断当前的 PDCP 实体或该 PDCP 实体对应的承载链路是否配置使用头压缩算法 ；

第一处理单元 173,用于在所述第二判断单元 172输出的判断结果表明 所述数据包或者当前的 PDCP 实体配置未使用头压缩算法时， 将所述数据 包中的业务数据单元丢弃。

进一步地， 在本实施例中所述 PDCP层数据处理装置， 还包括： 第二处理单元 174,用于在所述第二判断单元 172输出的判断结果表明 所述数据包或者当前的 PDCP 实体配置使用了头压缩算法时， 对所述数据 包中的协议数据单元进行解密和解压处理以获 取头压缩信息， 并将所述数 据包中的业务数据单元丢弃。

本发明实施例中提供的 PDCP层数据处理方法及装置， 在数据包接收 端无需要所述数据包中携带的业务数据单元时 ， 在对接收到的数据包中的 协议数据单元 PDU进行解密之前判断当前 PDCP实体或该 PDCP实体对应 的承载链路是否配置使用头压缩算法， 并根据判断结果确定是否需要对数 据包中的 PDU进行解密， 从而减少一些非必要的解密和解压缩处理， 降低 接收端的处理开销。 本发明实施例中的方法及装置适用于 LTE等通信系统。

通过以上实施方式的描述， 本领域的技术人员可以清楚地了解到本发 明可借助软件加必需的硬件平台的方式来实现 ， 当然也可以全部通过硬件 来实施。 基于这样的理解， 本发明的技术方案对背景技术做出贡献的全部 或者部分可以以软件产品的形式体现出来， 该计算机软件产品可以存储在 存储介质中， 如 ROM/RAM、 磁碟、 光盘等， 包括若干指令用以使得一台 计算机设备（可以是个人计算机， 服务器， 或者网络设备等）执行本发明 各个实施例或者实施例的某些部分所述的方法 。

以上所述， 仅为本发明的具体实施方式， 但本发明的保护范围并不局 限于此， 任何熟悉本技术领域的技术人员在本发明揭露 的技术范围内， 可 轻易想到的变化或替换， 都应涵盖在本发明的保护范围之内。 因此， 本发 明的保护范围应以权利要求的保护范围为准。