用于在蜂窩通信系統(tǒng)中管理安全重配置的方法和設備的制造方法
【專利說明】用于在蜂窩通信系統(tǒng)中管理安全重配置的方法和設備
[0001 ]本申請是申請?zhí)枮?01080062442.9(“用于在蜂窩通信系統(tǒng)中管理安全重配置的方法和設備”)的中國專利申請的分案申請。
技術領域
[0002]本發(fā)明總體上涉及電信系統(tǒng)，更具體地涉及對這種系統(tǒng)中的安全重配置的管理。
【背景技術】
[0003]對于所有的電信系統(tǒng)，存在各種各樣的重配置過程?；谝嘏渲玫膮?shù)的特性，可以將這些過程分成兩個主要組，即軟重配置和物理重配置。物理重配置處理物理特性的重配置，諸如無線承載重配置、傳送信道重配置、物理信道重配置。軟重配置處理非物理的重配置，諸如安全參數(shù)重配置。針對3GPP規(guī)范的典型場景，這兩類重配置的處理有些不同，并且因此各自存在不同的問題。
[0004]本公開將關注軟重配置，特別是與3GPP規(guī)范TS 25.331V8.7.0節(jié)8.1.12.4b[ 1 ]有關的安全重配置。改進的一個方面涉及由于在安全重配置期間的小區(qū)重選過程而導致的網(wǎng)絡與用戶終端(諸如移動電話)之間的安全配置的失配造成呼叫掉話的情形。
[0005]對于處于所謂的CELL_FACH狀態(tài)或模式下的嘗試建立多RAB語音呼叫的已連接3G用戶，如果“小區(qū)更新(Cell-Update)”小區(qū)重選過程與“安全模式”過程同時發(fā)生，則會出現(xiàn)呼叫掉話。為了更加清楚，CELL_FACH狀態(tài)或模式是操作的無線資源控制已連接模式或狀態(tài)之一。因此，對于處于CELL_FACH狀態(tài)下的用戶設備，可應用下述情況:
[0006]?無專用物理信道分配給該UE。
[0007]籲UE在下行鏈路中連續(xù)監(jiān)視FACH。
[0008]?向UE分配上行鏈路中的默認的公共或共享傳送信道(如RACH)，其中根據(jù)針對該公共或共享傳送信道的接入過程，UE任何時間都可以使用該公共或共享傳送信道。
[0009]?根據(jù)UE上一次進行小區(qū)更新所在的小區(qū)，UTRAN在小區(qū)級別上知道UE的位置。
[0010]應該注意，安全模式過程包括協(xié)商參與方(例如用戶設備和網(wǎng)絡節(jié)點)要用于通信的加密和完整性保護方案。雙方(例如，用戶終端和網(wǎng)絡)之間的安全配置的失配或不一致將最終導致呼叫掉話，因為雙方不能夠彼此通信。
[0011 ]在UE移動期間，下述兩種這樣的情形是可能的:
[0012]1)小區(qū)更新過程期間的安全重配置，S卩，剛好在從UE向網(wǎng)絡發(fā)送小區(qū)更新消息之后，在用戶設備(UE)中接收到來自網(wǎng)絡的安全模式命令。
[0013]2)安全重配置期間的小區(qū)更新，即在安全模式過程仍在進行時，從UE發(fā)送小區(qū)更新消息。
[0014]現(xiàn)有技術，如3GPP規(guī)范[1][2][3]中規(guī)定的技術，描述了用戶設備UE或移動設備和網(wǎng)絡應該如何處理這兩種情況;然而，存在進一步降低由于3GPP規(guī)范限制造成的呼叫掉話風險的改進空間。
[0015]通常，所有上述問題與在主要由于小區(qū)更新小區(qū)重選而中止進行中的安全模式過程時安全(加密/完整性)設置的不一致或失配有關。如果UE和無線網(wǎng)絡控制器(RNC)都中止安全重配置或者都沒有中止，則網(wǎng)絡解決方案能夠容易地處理這種情況。然而，由于在小區(qū)更新和安全模式過程之間出現(xiàn)的不同的爭用條件，UE可能中止重配置但是RNC沒有中止，以及反之。結(jié)果是完整性保護(和/或加密)不一致導致呼叫掉話。
[0016]參考圖1，將描述從UE視角觀察的已知安全模式過程。在標為“A”的時間跨度內(nèi)，根據(jù)3GPP規(guī)范[1]，清楚地知道:如果需要發(fā)送小區(qū)更新，則UE應該中止進行中的安全模式過程。該小區(qū)更新可以由下述情形中的任一種觸發(fā):
[0017]a)重選到新小區(qū)
[0018]b)重選進入服務區(qū)域
[0019]c)定期小區(qū)更新
[0020]d)向網(wǎng)絡通知UE故障(“物理信道故障”或“RLC不能恢復的錯誤”)
[0021]對于本公開，將利用由于重選到新小區(qū)造成的用戶設備中止進行中的安全重配置過程的情況。
[0022]當來到標為“B”的時間跨度上時，3GPP規(guī)范在UE安全配置行為方面有點不清楚并且存在限制。如果在安全過程期間發(fā)送“小區(qū)更新”(CellUpdate)消息，在“安全模式完成”(securityModeComplete)之后，但在接收L2ACK之前，則如上所述，UE應該中止進行中的安全模式過程[1]以及對完整性參數(shù)C0UNT-1進行特殊處理。通過針對RNC的聲明[2]給出了一些其他模糊指導，在[2]中敘述了網(wǎng)絡(NW)應該意識到UE “可以”中止安全過程。
[0023]然而，此時中止UE中的安全過程不是優(yōu)選的，因為UE剛剛向RNC應答(在安全模式完成消息中)已經(jīng)執(zhí)行安全重配置，盡管直到從RNC接收到針對“安全模式完成”的L2ACK為止，才會在UE中完全應用該安全重配置(S卩，這是[1]規(guī)定的現(xiàn)有技術中的灰色區(qū)域限制)。
[0024]如果UE在RNC已經(jīng)接收到“安全模式完成”之后中止安全重配置，則RNC將應用新的安全重配置。因此，存在安全失配，導致呼叫掉話(可以從實況網(wǎng)絡分析來證明)。呼叫掉話是由于下述事實:此時UE和網(wǎng)絡正在使用不同的安全配置且不能夠通信。

【發(fā)明內(nèi)容】

[0025]本發(fā)明涉及用于蜂窩通信系統(tǒng)中的改進的安全重配置管理的方法和設備。本發(fā)明的目的是降低由于小區(qū)更新過程造成的呼叫掉話風險。
[0026]在一種管理蜂窩通信系統(tǒng)的用戶設備中的安全重配置和小區(qū)更新過程的方法中，執(zhí)行下述過程。用戶設備從節(jié)點接收安全重配置請求，隨后發(fā)起和向節(jié)點確認所請求的安全重配置。在接收到節(jié)點應答之前的某個時間點，用戶設備檢測到小區(qū)更新觸發(fā)，并且響應于檢測到的小區(qū)更新觸發(fā)，中止已經(jīng)確認的安全重配置。隨后，用戶設備響應于中止的安全重配置，提供安全狀態(tài)指示，然后將小區(qū)更新消息和提供的安全狀態(tài)指示聯(lián)合發(fā)送給節(jié)點，其中所述提供的安全狀態(tài)指示通知:先前確認的安全重配置被中止。
[0027]通過這些特征，避免了蜂窩通信系統(tǒng)中的UE與節(jié)點之間的安全配置的失配。作為結(jié)果，降低了呼叫掉話率，并且提高了呼叫建立率。
[0028]根據(jù)本發(fā)明的另一方面，一種蜂窩通信系統(tǒng)中的用戶設備的實施例包括:用于檢測小區(qū)更新觸發(fā)事件的裝置；以及用于響應于檢測到的小區(qū)更新觸發(fā)事件而中止用戶設備中的任何進行中的安全重配置過程的裝置。另外，用戶設備包括:用于響應于中止的安全重配置而提供安全狀態(tài)指示的裝置；以及用于將小區(qū)更新消息和提供的安全狀態(tài)指示聯(lián)合發(fā)送給節(jié)點的裝置。
[0029]根據(jù)本發(fā)明的又一方面，一種管理根據(jù)本發(fā)明的蜂窩通信系統(tǒng)的節(jié)點中的安全重配置和小區(qū)更新過程的方法的實施例包括以下步驟:向用戶設備發(fā)送安全重配置請求；以及接收安全重配置確認。節(jié)點應答并執(zhí)行確認的安全重配置。隨后，節(jié)點聯(lián)合接收小區(qū)更新消息和安全狀態(tài)指示，其中所述安全狀態(tài)指示通知:所確認的安全重配置在用戶設備中被中止。最后，節(jié)點基于接收的安全狀態(tài)指示來管理所請求的安全重配置。
[0030]根據(jù)另外的方面，一種蜂窩通信系統(tǒng)中的節(jié)點的實施例包括:用于向用戶設備發(fā)送安全重配置請求的裝置；以及用于接收安全重配置確認的裝置。另外，節(jié)點包括用于應答并執(zhí)行確認的安全重配置的裝置，以及用于聯(lián)合接收小區(qū)更新消息和安全狀態(tài)指示的裝置，其中所述安全狀態(tài)指示通知:所確認的安全重配置在用戶設備中被中止。最后，節(jié)點包括用于基于接收的安全狀態(tài)指示來管理所請求的安全重配置的裝置。
[0031]此外，本發(fā)明有利地協(xié)調(diào)了小區(qū)更新和安全重配置過程，并且克服了已經(jīng)描述的3