专利名称：检测移动电信系统中的安全性错误的方法和移动电信设备的制作方法
技术领域：
本发明涉及一种在LTE (长期演进)系统的PDCP层使用的用于检 测安全性算法中生成的安全性错误的方法和设备。
背景技术：
图1是LTE(长期演进)系统、相关技术移动通信系统的网络结构。 对于从现有UMTS系统演进而来的LTE系统，在3GPP中正在进行基本标 准化。
LTE网络可以被分成E-UTRAN (演进UMTS地面无线接入网络) 和CN (核心网络)。E-UTRAN包括终端(或UE (用户设备))、基 站(eNB (演进节点B))以及接入网关(aGW)。接入网关可以被分 成处理用户业务的部分以及处理控制业务的部分。在这种情况下，处 理用户业务的接入网关部分以及处理控制业务的接入网关部分可以通 过使用新的接口相互通信。 一个或多个小区可以存在于单个eNB中。在 eNB之间可以使用用于传送用户业务或控制业务的接口。 CN可以包括 用于UE的用户注册的接入网关和节点等。可以使用用于区分E-UTRAN 和CN的接口。
图2示出了基于3GPP无线接入网络标准在UE和E-UTRAN之间的 无线接口协议的控制平面(C-平面)的示例性结构。图3示出了基于3GPP 无线接入网络标准在UE和E-UTRAN之间的无线接口协议的用户平面 (U-平面)的示例性结构。
现在将参考图2和3描述在UE和E-UTRAN之间的无线接口协议的结构。
5无线接口协议具有包括物理层、数据链路层以及网络层的水平层，
并且具有垂直平面，该垂直平面包括用于传送数据信息的用户平面(u-
平面)和用于传送控制信号的控制平面(C-平面)。可以基于在通信 系统中广泛公知的开放式系统互联(OSI)标准模型的三个较低层将图
2和3中的协议层分类为第一层(Ll)、第二层(L2)和第三层(L3)。 无线协议层在UE和E-UTRAN之间成对存在，并且处理在无线接口中的 数据传输。
现在将如下描述图2的无线协议控制平面的层以及图3的无线协议 用户平面的层。
物理层即第一层通过使用物理信道向上层提供信息传递服务。物 理层经由传输信道连接到被称为媒体接入控制(MAC)层的上层。经 由传输信道在MAC层和物理层之间传递数据。根据信道是否是共享的， 将传输信道分成专用传输信道和公共信道。在不同物理层之间，即在 传送侧(发送方)的物理层和在接收侧(接收方)的物理层之间，经 由物理信道传递数据。
第二层包括各种层。首先，媒体接入控制(MAC)层用于将各种 逻辑信道映射到各种传输信道，并且通过将若干逻辑信道映射到单个 传输信道而执行逻辑信道复用。MAC层通过逻辑信道连接到被称为无 线链路控制(RLC)层的上层。根据所传送的信息的类型将逻辑信道分 成用于传送控制平面的信息的控制信道和用于传送用户平面的信息的 业务信道。
RLC (无线资源控制)层即第二层将从上层接收到的数据分段或 接续(concatenate)，以调节数据大小以便较低层适于将数据传送到无 线接口。另外，为了确保每个无线承载RB需要的各种QoS， RLC层提 供三种操作模式TM (透明模式)、UM (未应答模式)和AM (应答模式)。特别地，以AM操作的RLC层(下文中被称为"AMRLC层") 通过用于可靠数据传送的自动重复和请求(ARQ)功能来执行重新传 送功能。
第二层的分组数据汇聚协议(PDCP)层执行用于减小IP分组的报 头的大小的被称为报头压縮的功能，以便在具有较小带宽的无线接口 中有效地传送诸如IPv4或IPv6的IP分组，上述IP分组的报头相对大并且 包括不必要的控制信息。报头压縮通过允许数据的报头部分仅传送必 要信息而提高了在无线接口之间的传送效率。
位于第三层的最上部分处的RRC层仅定义在控制平面中，并且与 无线承载(RB)的配置、重新配置和释放或取消有关地控制逻辑信道、 传送信道和物理信道。这里，RB指的是由无线协议的第一和第二层提 供的用于在UE和UTRAN之间的数据传送的逻辑路径。通常，RB的设 置(配置)指的是规定用于提供特定数据服务所需要的无线协议层和 信道的特性以及设置各自的详细参数和操作方法的过程。
下文中，现在将详细描述PDCP层。PDCP层向上与RRC层或用户 应用连接，并且向下与RLC层连接。在图4中，左侧示出了传送PDCP 实体的功能的结构，并且右侧示出了接收PDCP实体的功能的结构。左 面的传送侧结构示出了当PDCP层从上面的实体接收PDCP SDU时应用 于PDCP SDU的操作，并且右面的接收侧结构示出了当PDCP层从下面 的实体接收PDCP PDU时应用于PDCP PDU的操作。
PDCP用于用户平面和控制平面两者，并且根据所使用的平面而选 择性地应用PDCP的一些功能。S卩，如图4所示，报头压縮功能仅应用 于用户平面的数据，而完整性保护功能仅应用于控制平面的数据。
现在将描述由在图4的左侧的传送PDCP实体执行的数据处理过程。Sl: PDCP层将序列号指配到所接收到的PDCP SDU。
S2:如果所建立的RB是用户平面的RF，贝(JPDCP层对PDCP SDU
执行报头压縮。
S3:如果所建立的RB是控制平面的RB，贝UPDCP层对PDCP SDU
执行完整性保护操作。
S4: PDCP层对根据步骤S2或S3的结果生成的数据块执行加密。S5: PDCP层通过将正确的报头附加到所加密的数据块来配置
PDCP PDU，并且将所配置的PDCP PDU递送到RLC层。
现在将描述由在图4的右侧的接收PDCP实体执行的数据处理过程。
S6: PDCP层移除所接收到的PDCPPDU的报头。S7: PDCP层对移除报头的PDCPPDU执行解密。S8:如果所建立的RB是用户平面的RB，贝ljPDCP层对所解密的
PDCP PDU执行报头解压縮。
S9:如果所建立的RB是控制平面的RB，贝ljPDCP层对所解密的
PDCP PDU执行完整性验证操作。
S10: PDCP层将已经通过步骤S8或S9接收到的数据块(即，PDCP
SDU)递送到上层。如果所建立的RB是用户平面的RB，贝ijPDCP层在
必要时执行重新排序，并且将所述数据块递送到上层。
现在将描述由PDCP层执行的报头压縮。报头压縮基于以下事实减小报头的大小属于相同分组流的每个IP分组的IP报头大部分没有改变。以上下文的形式将未改变的字段存储在传送侧的压縮器中以及接收侧的解压縮器中，并且当形成了上下文时，仅传送改变的字段以由此减小IP报头的开销。在报头压缩的初始阶段，压縮器传送完整报头分组以形成相对于相应的分组流的上下文，因此报头压縮没有增益。但是，当在解压縮器中形成上下文之后，压縮器可以仅传送压縮的报头分组，所以它的增益显著增加。
ROHC (鲁棒报头压縮)是在LTE系统中使用的典型的报头压缩方案，它用于减少诸如RTP (实时传输协议)/UDP (用户数据报协议)/IP(网际协议)的实时分组的报头信息。这里，RTP/UDP/IP分组指的是具有相关报头的分组，该相关报头已经作为从上层穿过RTP、 UDP和IP的数据而被添加。它包括经由因特网向目的地传递数据并恢复数据所需的各种报头信息。通常，对于RTP/UDP/IP分组的报头大小，IPv4 (IP版本4)具有40字节的报头大小，并且IPv6具有60字节的报头大小。当通过使用ROHC压縮了报头时，40或60字节的报头减少成1至3字节的报头，从而获得了显著增益。
图5示出了根据ROHC形成的分组的报头大小的改变。具体地，图5相比较地示出了 一般RTP/UDP/IP分组的报头大小的改变以及应用了ROHC的报头大小的改变。当首先传送分组流时，因为在传送侧的压縮器中以及在接收侧的解压縮器中尚未形成上下文，所以传送完整报头以形成上下文。当在一定程度上传送了完整报头时，形成了上下文，并且因此可以传送压縮的报头。在这个方面中，由于分组中途丢失等造成可能损坏上下文，所以需要以适当的间隔传送完整报头。通常，完整报头包括用于形成上下文的附加信息，所以它稍微大于正常报头。
现在将描述由PDCP层执行的安全性功能。如上所述，安全性包括加密和完整性保护两个功能。在这两个功能中，生成了对于每个分组变化的代码，利用该代码加密原始数据或检査其完整性。
通过使用添加到每个PDCP PDU的报头的PDCP SN(序列号)来生成对于每个分组变化的代码，并且代码生成因子中的一个是COUNT(计数)。该COUNT具有32位的长度，它的最低有效位(LSB)包括PDCPSN，并且其他剩余最高有效位(MSB)包括HFN (超帧号)。PDCP SN的长度是5、 7或12位，即对于每个RB不同，所以HFN的长度对于每种
9情况不同，为27、 25或20位。
以图6所示的方式来执行加密。传送侧通过在原始数据上覆盖对于每个分组改变的代码，即，MASK(掩码)，来生成加密的数据。这里，MASK的覆盖指的是对原始数据执行XOR(异或)并且逐位执行MASK。当接收到因而加密的数据时，接收侧再次在已加密的数据上覆盖MASK以将它解密。这里，MASK具有32位的长度，并且根据各种输入因子来生成。特别地，为了对于每个分组生成不同的值，通过使用对每个PDCPPDU不同的PDCP序列号来生成COUNT ，并且所生成的COUNT被用作MASK生成输入因子中的一个。除了COUNT之外，MASK生成输入因子包括是对应的RB的ID值的"承载"、具有向上或向下值的"方向"、在建立RB期间由终端和网络交换的"CK (加密密钥)"等等。
另外，以如图7所示的方式执行完整性保护。类似于加密处理，在完整性保护处理中，通过使用利用PDCPSN的"COUNT"、是RB的ID值的"承载"、具有向上或向下值的"方向"、在建立RB期间由终端和网络交换的"IK(完整性保护密钥)"等等来生成代码，g卩，"MAC-I(消息认证代码完整性)"。这里，如图7所示，与如图6所示的加密处理的不同之处在于，所生成的"MAC-I"没有与原始数据XOR，而是附连到PDCP PDU。当接收侧接收到附连到PDCP PDU的MAC-I时，它通过使用与在传送侧使用的输入因子相同的输入因子而生成XMAC-I，并且将它与附连到PDCP PDU的MAC-I相比较，如果这两个值(即，XMAC-I和附连到PDCP PDU的MAC-I)相同，则确定数据具有完整性，然而如果这两个值不同，则确定数据中途已经被改变。
由于 一 些原因，传送侧和接收侧的MASK或MAC-I可能被改变以致在加密或完整性保护中出错。MASK或MAC-I被改变的主要原因是因为HFN，即COUNT的MSB，被改变了。这在丢失了许多PDCP SDU时发生。原因是因为COUNT的MSB是HFN并且COUNT的LSB是SN，并且如果PDCPSN达到了最大值，则它返回零(0)并且增加一个HFN，即MSB。艮P，如果PDCP SDU丢失了多达环绕(wrap around) PDCP SN
的空间，则发生HFN的去同步。由于另一个原因，可能存在即使在较低层的CRC (循环冗余码)检验也无法发现的错误，并且在这种情况下，如果PDCP SN值没有在有效范围内，则可能发生HFN去同步。
当发生HFN去同步时，安全性就失败。因此，尽管接收侧接收到数据，但是它无法恢复原始数据，造成接收侧不断地丢弃接收到的数据的问题。
由于发生了该问题，所以将分别描述用户平面的RB和控制平面的RB。
首先，在用户平面的RB的情况下，接收到的PDCP PDU被解密并且经历报头解压缩。此时，如果利用错误的MASK解密PDCPPDU，则在报头压縮处理中不断出现错误，所以接收侧不断丢弃所接收到的PDCP PDU。
其次，在控制平面的RB的情况下，接收到的PDCP PDU被解密并且经历完整性验证。如果利用错误的MASK解密PDCP PDU或将PDCPPDU与错误的XMAC-I相比较，则在完整性验证处理中不断出现错误，所以接收侧不断丢弃所接收到的PDCP PDU。
因为当前没有提供检测HFN去同步的功能，所以出现了该问题。结果， 一旦发生了HFN去同步，则它无法恢复，并且自此所接收到的PDU具有错误并且因此不断地被丢弃。
发明内容
因此，本发明的目的是允许接收侧PDCP通过使用特定条件来确定是否发生HFN去同步，即，安全性失败，并且如果发生了HFN去同步，则通过使用PDCP RESET处理来通知RRC重新建立RB或重新设置传送侧或接收侧的安全性配置。
为了实现以上目的，提供了一种用于检测与在移动通信系统中的 安全性有关的错误的方法，包括(A)对一个或多个接收到的分组当 中的具有错误的分组的数目进行计数；(B)将所计数的具有错误的分 组数目与参考值相比较；以及(C)如果所计数的具有错误的分组的数 目达到了所述参考值，则确定安全性失败。
步骤(A)可以包括接收由传送侧传送的至少一个分组；移除所 接收到的分组的报头；对巳移除报头的分组执行解码；通过执行从已 解码的分组中恢复压縮的报头的处理或执行完整性验证处理来确定所 述分组的安全性失败的错误；以及如果存在已确定具有安全性失败的 错误的分组，则使计数器增加。
所述分组可以是用户平面的数据或控制平面的数据。
所述方法可以进一步包括(D)如果所计数的具有错误的分组的 数目达到了所述参考值以致被确定为安全性失败，则执行安全性配置 的恢复处理。
所述恢复处理可以包括PDCP层的重新设置过程的执行。
所述恢复处理可以包括通知RRC层。
所述RRC层可以重新建立RB (无线承载)，重新建立RRC连接或 针对特定RB重新设置安全性配置。
步骤(A)是在PDCP (分组数据汇聚协议)层的报头解压縮处理 中或在PDCP层的完整性验证处理中执行。所述参考值可以根据RB而不同。
为了实现以上目的，还提供了一种用于检测与在移动通信系统中 的安全性有关的错误的方法，包括接收至少一个分组；对所述至少 一个接收到的分组执行完整性验证或报头解压縮；在执行所述完整性 验证或报头解压縮期间检査所述至少一个接收到的分组是否具有错 误；如果检查到所述至少一个接收到的分组具有错误，则向RRC层报 告所生成的错误；以及一旦接收到所生成的错误，则由所述RRC层执 行重新建立。
所述重新建立可以包括RB重新建立和PDCP层的重新建立中的至
少一个。
所述重新建立可以是RRC连接的重新建立。
所述完整性验证可以使用XMAC-I，并且所述报头解压缩可以使用 上下文。
所述PDCP层的重新建立可以是所述PDCP层的RESET (重新设 置)。
本发明提供了用于当在接收侧的PDCP层处发生了安全性失败时 有效地检测该安全性失败的方法，所以可以防止任何进一步的数据丢 失以及所引起的无线资源的浪费。
图l示出了长期演进(LTE)、相关技术移动通信系统的网络结构； 图2示出了基于3GPP无线接入网络标准的在终端和演进UMTS地 面无线接入网络(UTRAN)之间的无线接口协议的控制平面的架构； 图3示出了基于3GPP无线接入网络标准的在终端和演进UMTS地面无线接入网络(UTRAN)之间的无线接口协议的用户平面的架构； 图4示出了PDCP层的功能结构；
图5示出了根据R0HC形成的分组的报头大小的改变；
图6示出了加密方法； 图7示出了完整性保护方法；
图8是示出根据本发明的实施例的相对于用户平面RB确定安全性 失败的处理的框图；以及
图9是示出根据本发明的实施例的相对于控制平面RB确定安全性 失败的处理的框图。
具体实施例方式
本发明应用于移动电信系统，并且更具体地，应用于已经从UMTS 演进的演进通用移动电信系统(E-UMTS)。然而，不限于此，本发明 还可以应用于可应用本发明的技术特征的任何移动电信系统和通信协 议。
本发明可以可变地修改，并且可以具有各种实施例，特定的实施 例将在附图中图示并被详细地描述。然而，应当理解，下面的本发明 的示例性描述并不意在将本发明限制成本发明的特定形式，而是本发 明意在覆盖包括在本发明的精神和范围中的所有的修改、类似物和替 代。
尽管诸如"第一"和"第二"等的术语可以用于描述各种组件， 但是这样的组件不一定限于以上术语。以上术语仅用于将一个组件与 另一个组件相区分。例如，第一组件可以被称为第二组件，而不背离 本发明的权利范围，并且类似地第二组件可以被称为第一组件。术语 "和/或"既涵盖所公开的多个相关项的组合又涵盖来自所公开的多个 相关项的任何项。
当组件被描述成"连接"到或"接入"另一个组件时，这可以意指它直接连接到或接入另一组件，但是应当理解之间可以存在另一组 件。另一方面，当组件被描述成"直接连接"到或"直接接入"另一 组件时，应当理解之间没有其他组件。
在本申请中使用的术语仅用于描述特定实施例，并且并不意在限 制本发明。单数使用的表达涵盖复数的表达，除非它在上下文中具有 明确不同的含义。在本申请中，应当理解，诸如"包括"、"具有" 等的术语意在指示存在在说明书中公开的特征、数目、操作、动作、 组件、部分或其组合，并且并不意在排除可以存在或可以添加一个或 多个其他特征、数目、操作、动作、组件、部分或其组合的可能性。
除非另外定义，在此使用的所有术语，包括技术或科学术语，具 有与本发明所属领域的普通技术人员通常理解的含义相同的含义。诸 如在通常使用的词典中定义的此类术语应当被解释成具有与在相关领 域中的上下文含义相同的含义，并且不应当被解释成具有理想或过度 正式的含义，除非在本申请中明确地定义。
下面将参考附图详细描述本发明的实施例，在附图中，相同或相 对应的那些组件被赋予了相同的附图标记，而不管附图的编号，并且 省略了冗余的解释。
将描述如下在本发明中使用的术语。
安全性失败指的是传送侧或接收侧的MASK (在U-平面的情况下) 或MAC-I (在C平面的情况下)被改变以致在加密或完整性保护中出错 从而导致HFN去同步的现象。
安全性配置指的是加密和完整性保护，并且在 对用户平面的分 组(数据)执行加密并对控制平面的分组(数据)执行完整性保护。本发明基于当前PDCP没有提供用于检测HFN去同步的功能的这
样的认识。因此，本发明解决了以下问题 一旦发生HFN去同步则它 无法恢复，所以由接收侧接收到的所有PDU具有错误，并且因此，接 收侧不断地丢弃所接收到的P D U 。
本发明的基本概念是l)定义了用于确定安全性失败的条件；2) 接收侧PDCP通过使用特定条件(即，用于确定安全性失败的条件)来 确定是否已经发生HFN去同步，g卩，安全性失败；3)如果确定已经发 生了安全性失败，则接收侧PDCP通知RRC重新建立RB或执行PDCP RESET处理；4)从而重新设置传送侧和接收侧的安全性配置。
现在将详细描述根据本发明的安全性失败的确定条件。
安全性失败的确定条件根据对应的RB属于用户平面还是控制平 面而不同。
首先，现在将描述在U平面RB情况下安全性失败的确定条件。
接收侧对解密的数据执行报头解压縮。如果没有正确地执行解密， 则在报头解压縮期间发生CRC错误，这导致报头解压縮失败。因此， 报头解压縮失败的分组的数目充当HFN去同步的根据。g卩，PDCP在相 对于U平面RB的报头解压縮期间对具有错误的分组的数目进行计数， 并且如果具有错误的分组的数目大于参考值(或阈值)，贝IJPDCP确定 存在安全性问题，并且执行安全性失败的恢复处理。为此，接收侧PDCP 使用用于在报头解压縮期间对CRC错误分组的数目进行计数的变量 (或计数器)，并且在分组中无论何时发生错误都使该变量的值增加。 此后，当该变量达到预定参考值(阈值)时，PDCP确定安全性配置有 问题。同时，可以通过在RB设置中接收侧RRC (即，eNB RRC)向传 送侧RRC(g卩，UERRC)通知该参考值，并且然后通过传送侧RRC(UE RRC)向传送侧PDCP (即，UEPDCP)通知该参考值。该参考值可以预先被确定为特定值并且根据RB具有不同的值。无论何时在分组处发 生错误(例如，如果间断地发生错误)，用于对分组的错误进行计数 的变量(或计数器)的值都可以增加，或仅当在分组处不断地发生错 误时才可以增加。图8是示出根据本发明的实施例的相对于用户平面RB由接收侧 PDCP确定安全性失败的处理的框图。现在将详细描述在U平面RB情况 下确定安全性失败的处理。S20:接收侧PDCP接收来自较低层(即，RLC)的PDU1 PDU20 的PDCP PDU。S21:接收侧PDCP移除所接收到的PDU的报头，并且将它们递送 到解密单元。S22:接收侧PDCP的解密单元对已移除报头的PDU执行解密。如 果在PDU1处发生了安全性失败，即，如果发生了HFN去同步，则没有 对PDU1和所有其他后续PDU (即，PDU2 PDU20)正确地进行解密。S23:然而，接收侧PDCP没有认识到分组(即，PDU1 PDU20) 没有被正确地解密的事实，并且将它们递送到报头解压縮单元。S24:报头解压縮单元对所接收到的分组执行报头解压縮，但是它 们所有都具有错误。可以基于报头的CRC值来确定所生成的错误。S25:接收侧PDCP对在报头解压縮期间已经发生错误的分组的数 目进行计数。如果所计数的错误的分组的数目达到(即，大于)预定 义参考值(即，可以例如是20的阈值)，则接收侧PDCP确定安全性配 置有错误。艮口，在如图8所示的实施例中，首先，当接收侧PDCP对所接收到 的分组执行报头解压缩时，它基于报头的CRC值确定错误。其次，接 收侧PDCP对具有错误的分组的数目进行计数。第三，如果错误的分组 的数目达到了参考值，则接收侧PDCP确定已经发生了安全性失败。一 旦确定了安全性失败，接收侧PDCP很快执行恢复安全性失败的处理，以便防止可能的进一步数据丢失和无线资源浪费。该恢复处理可以被 执行，以便例如接收侧RRC层通知终端该安全性失败的错误，使得终
端可以切断它到该网络的连接，并且再次从开始建立RRC连接。替代 地，RRC层可以相对于在终端(UE)和网络之间的特定RB而重新建立 RB或再次设置安全性配置。
首先，用于确定在C平面RB情况下的安全性失败的条件将描述如下。
在C平面RB的情况下，没有执行报头解压縮，而是替代地，执行 完整性验证。因此，应当基于与U平面RB的基础不同的基础来确定安 全性失败。在执行完整性验证期间，将包括在PDU中的MAC-I值和由接 收侧PDCP本身生成的XMAC-I值相比较。如果这两个值不同，则确定 完整性验证失败，并且丢弃由接收侧PDCP接收到的分组。因此，在本 发明中，相对于C平面RB，如果在执行完整性验证期间超过特定数目 的分组具有错误，则将它确定为安全性失败，并且执行恢复该安全性 失败的处理。为此，在执行完整性验证期间，接收侧PDCP对错误的数 目进行计数，即，其中包括在PDU中的MAC-I值和由接收侧PDU本身生 成的XMAC-I不同的情况的数目。换句话说，接收侧PDCP使用用于对 具有不同值(包括在PDU中的MAC-I值和由接收侧PDCP本身生成的 XMAC-I值)的对应分组的数目进行计数的变量(计数器)。也就是， 无论何时在分组处发生错误，接收侧PDCP都使变量的值增加，并且当 变量达到预定参考值(阈值)时，接收侧PDCP确定安全性配置有问题。 同时，可以通过在RB设置中接收侧RRC (即，eNBRRC)向传送侧RRC (即，UERRC)通知该参考值，并且然后通过传送侧RRC (UERRC) 向传送侧PDCP (即，UEPDCP)通知该参考值。该参考值可以预先被 确定为特定值并且根据RB具有不同的值。无论何时在分组处发生错误 (例如，如果间断地发生错误)，用于对分组的错误进行计数的变量 (或计数器)的值都可以增加，或仅当在分组处不断地发生错误时才 可以增加。图9是示出根据本发明的实施例的相对于控制平面RB由接收侧
PDCP确定安全性失败的处理的框图。现在将详细描述相对于C平面RB
的确定安全性失败的处理。
S30:接收侧PDCP接收来自较低层(即，RLC)的PDU1 PDU20 的PDCP PDU。
S31:接收侧PDCP移除所接收到的PDU的报头，并且将它们递送 到解密单元。
S32:接收侧PDCP对已移除报头的PDU执行解密。如果在PDU1处 发生了安全性失败，即，如果发生了HFN去同步，则没有对PDU1和所 有其他后续PDU (即，PDU2 PDU20)正确地进行解密。
S33:然而，接收侧PDCP没有认识到分组(即，PDU1 PDU20) 没有被正确地解密的事实，并且将它们递送到完整性验证单元。
S34:完整性验证单元对所接收到的分组(即，PDU1 PDU20) 执行完整性验证，但是它们所有都具有错误。可以通过将包括在PDU 中的MAC-I值和由接收侧PDCP本身生成的XMAC-I值相比较来确定所 生成的错误。
S35:接收侧PDCP对在完整性验证期间已经发生错误的分组的数 目进行计数。如果所计数的错误的分组的数目达到预定义参考值(可 以例如是20)，则接收侧PDCP确定安全性配置有错误。
图9中的实施例示出了在解密处理期间发生了错误的情况。但是， 实际上，在完整性验证处理期间也可能发生错误。在这种情况下，紧 接着的处理过程与上述相同。例如，如果对所有分组成功地执行了解 密，但是PDU l由于错误的完整性验证参数而具有错误，所有的后续分 组将具有错误。因此，在任何情况下，都在完整性验证期间对错误的 分组的数目进行计数以确定是否已经发生安全性失败。
当接收侧PDCP确定安全性失败时，接收侧PDCP很快地执行恢复安全性失败的处理，以便防止可能的进一步数据丢失和无线资源的浪 费。恢复处理可以被执行，以便例如接收侧RRC层向终端通知该安全 性失败的错误，使得终端能够切断它到网络的连接，并且再次从开始
建立RRC连接。替代地，RRC层可以相对于在终端(UE)和网络之间 的特定RB而重新建立RB或再次设置安全性配置。
可以通过软件、硬件或它们的结合来实现到此所描述的方法。例 如，根据本发明的方法可以存储在存储介质(例如，移动终端的内部 存储器、闪存、硬盘等)中，并且可以通过在可以由处理器(例如， 移动终端的内部微处理器)执行的软件程序中的代码或命令语言来实 现。
因此描述了本发明，将显而易见的是，可以以很多方式来改变本 发明。不应当认为这样的变化背离本发明的范围，并且如将对本领域 技术人员显而易见的所有这样的修改意在被包括在随附权利要求的范 围之内。
权利要求
1.一种用于检测与在移动通信系统中的安全性有关的错误的方法，所述方法包括(A)对一个或多个接收到的分组当中的具有错误的分组的数目进行计数；(B)将所计数的具有错误的分组的数目与参考值相比较；以及(C)如果所计数的具有错误的分组的数目达到所述参考值，则确定安全性失败。
2. 根据权利要求l所述的方法，其中，所述步骤(A)包括 接收由传送侧传送的至少一个分组；移除所接收至I」的分组的报头； 对已移除报头的分组执行解码；通过执行从已解码的分组中恢复压缩的报头的处理或执行完整性 验证处理来确定所述分组的安全性失败的错误；以及如果存在已确定具有安全性失败的错误的分组，则使计数器增加。
3. 根据权利要求l所述的方法，其中，所述分组是用户平面的数 据或控制平面的数据。
4. 根据权利要求l所述的方法，进一步包括(D) 如果所计数的具有错误的分组的数目达到所述参考值以致被 确定为所述安全性失败，则执行安全性配置的恢复处理。
5. 根据权利要求4所述的方法，其中，所述恢复处理包括 执行PDCP层的重新设置过程。
6. 根据权利要求4所述的方法，其中，所述恢复处理包括 通知RRC层。
7. 根据权利要求6所述的方法，其中，所述RRC层重新建立RB(无 线承载)，重新建立RRC连接或针对特定RB重新设置安全性配置。
8. 根据权利要求l所述的方法，其中，所述错误的分组是连续的。
9. 根据权利要求l所述的方法，所述步骤(A)在PDCP (分组数 据汇聚协议)层的报头解压縮处理期间或在所述PDCP层的完整性验证 处理期间执行。
10. 根据权利要求1所述的方法，其中，所述参考值根据RB而不同。
11. 一种用于检测与在移动通信系统中的安全性有关的错误的方法，所述方法包括接收至少一个分组；对所述至少一个接收到的分组执行完整性验证或报头解压縮；在执行所述完整性验证或报头解压縮期间检査所述至少一个接收 到的分组是否具有错误；如果检查到所述至少一个接收到的分组具有错误，则向RRC层报 告所生成的错误；以及一旦接收到所生成的错误，则由所述RRC层执行重新建立。
12. 根据权利要求ll所述的方法，其中，所述重新建立包括RB重 新建立和PDCP层的重新建立中的至少一个。
13. 根据权利要求ll所述的方法，其中，所述重新建立是RRC连接的重新建立。
14. 根据权利要求ll所述的方法，其中，所述完整性验证使用 XMAC-I，并且所述报头解压縮使用上下文。
15.根据权利要求12所述的方法，其中，所述PDCP层的重新建 立是指重新设置所述PDCP层。
全文摘要
公开了一种用于在是一种移动通信系统的LTE(长期演进)系统的PDCP层处检测安全性错误的方法和装置。定义了用于确定安全性失败的条件。接收侧PDCP通过使用特定条件(即，用于确定安全性失败的条件)确定是否已经发生HFN去同步，即，安全性失败。如果确定已经发生了安全性失败，则接收侧PDCP通知RRC重新建立RB或执行PDCP RESET处理，以重新设置传送侧和接收侧的安全性配置。
文档编号H04L1/00GK101675618SQ200880014193
公开日2010年3月17日 申请日期2008年8月4日 优先权日2007年8月10日
发明者千成德, 朴成埈, 李承俊, 李英大 申请人:Lg电子株式会社