[发明专利]用于在蜂窝通信系统中管理安全重配置的方法和设备

说明书

技术领域

本发明总体上涉及电信系统，更具体地涉及对这种系统中的安全重配置的管理。

背景技术

对于所有的电信系统，存在各种各样的重配置过程。基于要重配置的参数的特性，可以将这些过程分成两个主要组，即软重配置和物理重配置。物理重配置处理物理特性的重配置，诸如无线承载重配置、传送信道重配置、物理信道重配置。软重配置处理非物理的重配置，诸如安全参数重配置。针对3GPP规范的典型场景，这两类重配置的处理有些不同，并且因此各自存在不同的问题。

本公开将关注软重配置，特别是与3GPP规范TS 25.331V8.7.0节8.1.12.4b[1]有关的安全重配置。改进的一个方面涉及由于在安全重配置期间的小区重选过程而导致的网络与用户终端(诸如移动电话)之间的安全配置的失配造成呼叫掉话的情形。

对于处于所谓的CELL_FACH状态或模式下的尝试建立多RAB语音呼叫的已连接3G用户，如果“小区更新(Cell-Update)”小区重选过程与“安全模式”过程同时发生，则会出现呼叫掉话。为了更加清楚，CELL_FACH状态或模式是操作的无线资源控制已连接模式或状态之一。因此，对于处于CELL_FACH状态下的用户设备，可应用下述情况：

●无专用物理信道分配给该UE。

●UE在下行链路中连续监视FACH。

●向UE分配上行链路中的默认的公共或共享传送信道(如RACH)，其中根据针对该公共或共享传送信道的接入过程，UE任何时间都可以使用该公共或共享传送信道。

●根据UE上一次进行小区更新所在的小区，UTRAN在小区级别上知道UE的位置。

应该注意，安全模式过程包括协商参与方(例如用户设备和网络节点)要用于通信的加密和完整性保护方案。双方(例如，用户终端和网络)之间的安全配置的失配或不一致将最终导致呼叫掉话，因为双方不能够彼此通信。

在UE移动期间，下述两种这样的情形是可能的：

1)小区更新过程期间的安全重配置，即，刚好在从UE向网络发送小区更新消息之后，在用户设备(UE)中接收到来自网络的安全模式命令。

2)安全重配置期间的小区更新，即在安全模式过程仍在进行时，从UE发送小区更新消息。

现有技术，如3GPP规范[1][2][3]中规定的技术，描述了用户设备UE或移动设备和网络应该如何处理这两种情况；然而，存在进一步降低由于3GPP规范限制造成的呼叫掉话风险的改进空间。

通常，所有上述问题与在主要由于小区更新小区重选而中止进行中的安全模式过程时安全(加密/完整性)设置的不一致或失配有关。如果UE和无线网络控制器(RNC)都中止安全重配置或者都没有中止，则网络解决方案能够容易地处理这种情况。然而，由于在小区更新和安全模式过程之间出现的不同的争用条件，UE可能中止重配置但是RNC没有中止，以及反之。结果是完整性保护(和/或加密)不一致导致呼叫掉话。

参考图1，将描述从UE视角观察的已知安全模式过程。在标为“A”的时间跨度内，根据3GPP规范[1]，清楚地知道：如果需要发送小区更新，则UE应该中止进行中的安全模式过程。该小区更新可以由下述情形中的任一种触发：

a)重选到新小区

b)重选进入服务区域

c)定期小区更新

d)向网络通知UE故障(“物理信道故障”或“RLC不能恢复的错误”)

对于本公开，将利用由于重选到新小区造成的用户设备中止进行中的安全重配置过程的情况。

当来到标为“B”的时间跨度上时，3GPP规范在UE安全配置行为方面有点不清楚并且存在限制。如果在安全过程期间发送“小区更新”(CellUpdate)消息，在“安全模式完成”(securityModeComplete)之后，但在接收L2ACK之前，则如上所述，UE应该中止进行中的安全模式过程[1]以及对完整性参数COUNT-I进行特殊处理。通过针对RNC的声明[2]给出了一些其他模糊指导，在[2]中叙述了网络(NW)应该意识到UE“可以”中止安全过程。

然而，此时中止UE中的安全过程不是优选的，因为UE刚刚向RNC应答(在安全模式完成消息中)已经执行安全重配置，尽管直到从RNC接收到针对“安全模式完成”的L2ACK为止，才会在UE中完全应用该安全重配置(即，这是[1]规定的现有技术中的灰色区域限制)。