專利名稱：檢測移動電信系統(tǒng)中的安全性錯誤的方法和移動電信設(shè)備的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種在LTE (長期演進(jìn))系統(tǒng)的PDCP層使用的用于檢 測安全性算法中生成的安全性錯誤的方法和設(shè)備。
背景技術(shù)：
圖1是LTE(長期演進(jìn))系統(tǒng)、相關(guān)技術(shù)移動通信系統(tǒng)的網(wǎng)絡(luò)結(jié)構(gòu)。 對于從現(xiàn)有UMTS系統(tǒng)演進(jìn)而來的LTE系統(tǒng)，在3GPP中正在進(jìn)行基本標(biāo) 準(zhǔn)化。
LTE網(wǎng)絡(luò)可以被分成E-UTRAN (演進(jìn)UMTS地面無線接入網(wǎng)絡(luò)) 和CN (核心網(wǎng)絡(luò))。E-UTRAN包括終端(或UE (用戶設(shè)備))、基 站(eNB (演進(jìn)節(jié)點B))以及接入網(wǎng)關(guān)(aGW)。接入網(wǎng)關(guān)可以被分 成處理用戶業(yè)務(wù)的部分以及處理控制業(yè)務(wù)的部分。在這種情況下，處 理用戶業(yè)務(wù)的接入網(wǎng)關(guān)部分以及處理控制業(yè)務(wù)的接入網(wǎng)關(guān)部分可以通 過使用新的接口相互通信。 一個或多個小區(qū)可以存在于單個eNB中。在 eNB之間可以使用用于傳送用戶業(yè)務(wù)或控制業(yè)務(wù)的接口。 CN可以包括 用于UE的用戶注冊的接入網(wǎng)關(guān)和節(jié)點等。可以使用用于區(qū)分E-UTRAN 和CN的接口。
圖2示出了基于3GPP無線接入網(wǎng)絡(luò)標(biāo)準(zhǔn)在UE和E-UTRAN之間的 無線接口協(xié)議的控制平面(C-平面)的示例性結(jié)構(gòu)。圖3示出了基于3GPP 無線接入網(wǎng)絡(luò)標(biāo)準(zhǔn)在UE和E-UTRAN之間的無線接口協(xié)議的用戶平面 (U-平面)的示例性結(jié)構(gòu)。
現(xiàn)在將參考圖2和3描述在UE和E-UTRAN之間的無線接口協(xié)議的結(jié)構(gòu)。
5無線接口協(xié)議具有包括物理層、數(shù)據(jù)鏈路層以及網(wǎng)絡(luò)層的水平層，
并且具有垂直平面，該垂直平面包括用于傳送數(shù)據(jù)信息的用戶平面(u-
平面)和用于傳送控制信號的控制平面(C-平面)。可以基于在通信 系統(tǒng)中廣泛公知的開放式系統(tǒng)互聯(lián)(OSI)標(biāo)準(zhǔn)模型的三個較低層將圖
2和3中的協(xié)議層分類為第一層(Ll)、第二層(L2)和第三層(L3)。 無線協(xié)議層在UE和E-UTRAN之間成對存在，并且處理在無線接口中的 數(shù)據(jù)傳輸。
現(xiàn)在將如下描述圖2的無線協(xié)議控制平面的層以及圖3的無線協(xié)議 用戶平面的層。
物理層即第一層通過使用物理信道向上層提供信息傳遞服務(wù)。物 理層經(jīng)由傳輸信道連接到被稱為媒體接入控制(MAC)層的上層。經(jīng) 由傳輸信道在MAC層和物理層之間傳遞數(shù)據(jù)。根據(jù)信道是否是共享的， 將傳輸信道分成專用傳輸信道和公共信道。在不同物理層之間，即在 傳送側(cè)(發(fā)送方)的物理層和在接收側(cè)(接收方)的物理層之間，經(jīng) 由物理信道傳遞數(shù)據(jù)。
第二層包括各種層。首先，媒體接入控制(MAC)層用于將各種 邏輯信道映射到各種傳輸信道，并且通過將若干邏輯信道映射到單個 傳輸信道而執(zhí)行邏輯信道復(fù)用。MAC層通過邏輯信道連接到被稱為無 線鏈路控制(RLC)層的上層。根據(jù)所傳送的信息的類型將邏輯信道分 成用于傳送控制平面的信息的控制信道和用于傳送用戶平面的信息的 業(yè)務(wù)信道。
RLC (無線資源控制)層即第二層將從上層接收到的數(shù)據(jù)分段或 接續(xù)(concatenate)，以調(diào)節(jié)數(shù)據(jù)大小以便較低層適于將數(shù)據(jù)傳送到無 線接口。另外，為了確保每個無線承載RB需要的各種QoS， RLC層提 供三種操作模式TM (透明模式)、UM (未應(yīng)答模式)和AM (應(yīng)答模式)。特別地，以AM操作的RLC層(下文中被稱為"AMRLC層") 通過用于可靠數(shù)據(jù)傳送的自動重復(fù)和請求(ARQ)功能來執(zhí)行重新傳 送功能。
第二層的分組數(shù)據(jù)匯聚協(xié)議(PDCP)層執(zhí)行用于減小IP分組的報 頭的大小的被稱為報頭壓縮的功能，以便在具有較小帶寬的無線接口 中有效地傳送諸如IPv4或IPv6的IP分組，上述IP分組的報頭相對大并且 包括不必要的控制信息。報頭壓縮通過允許數(shù)據(jù)的報頭部分僅傳送必 要信息而提高了在無線接口之間的傳送效率。
位于第三層的最上部分處的RRC層僅定義在控制平面中，并且與 無線承載(RB)的配置、重新配置和釋放或取消有關(guān)地控制邏輯信道、 傳送信道和物理信道。這里，RB指的是由無線協(xié)議的第一和第二層提 供的用于在UE和UTRAN之間的數(shù)據(jù)傳送的邏輯路徑。通常，RB的設(shè) 置(配置)指的是規(guī)定用于提供特定數(shù)據(jù)服務(wù)所需要的無線協(xié)議層和 信道的特性以及設(shè)置各自的詳細(xì)參數(shù)和操作方法的過程。
下文中，現(xiàn)在將詳細(xì)描述PDCP層。PDCP層向上與RRC層或用戶 應(yīng)用連接，并且向下與RLC層連接。在圖4中，左側(cè)示出了傳送PDCP 實體的功能的結(jié)構(gòu)，并且右側(cè)示出了接收PDCP實體的功能的結(jié)構(gòu)。左 面的傳送側(cè)結(jié)構(gòu)示出了當(dāng)PDCP層從上面的實體接收PDCP SDU時應(yīng)用 于PDCP SDU的操作，并且右面的接收側(cè)結(jié)構(gòu)示出了當(dāng)PDCP層從下面 的實體接收PDCP PDU時應(yīng)用于PDCP PDU的操作。
PDCP用于用戶平面和控制平面兩者，并且根據(jù)所使用的平面而選 擇性地應(yīng)用PDCP的一些功能。S卩，如圖4所示，報頭壓縮功能僅應(yīng)用 于用戶平面的數(shù)據(jù)，而完整性保護(hù)功能僅應(yīng)用于控制平面的數(shù)據(jù)。
現(xiàn)在將描述由在圖4的左側(cè)的傳送PDCP實體執(zhí)行的數(shù)據(jù)處理過程。Sl: PDCP層將序列號指配到所接收到的PDCP SDU。
S2:如果所建立的RB是用戶平面的RF，貝(JPDCP層對PDCP SDU
執(zhí)行報頭壓縮。
S3:如果所建立的RB是控制平面的RB，貝UPDCP層對PDCP SDU
執(zhí)行完整性保護(hù)操作。
S4: PDCP層對根據(jù)步驟S2或S3的結(jié)果生成的數(shù)據(jù)塊執(zhí)行加密。S5: PDCP層通過將正確的報頭附加到所加密的數(shù)據(jù)塊來配置
PDCP PDU，并且將所配置的PDCP PDU遞送到RLC層。
現(xiàn)在將描述由在圖4的右側(cè)的接收PDCP實體執(zhí)行的數(shù)據(jù)處理過程。
S6: PDCP層移除所接收到的PDCPPDU的報頭。S7: PDCP層對移除報頭的PDCPPDU執(zhí)行解密。S8:如果所建立的RB是用戶平面的RB，貝ljPDCP層對所解密的
PDCP PDU執(zhí)行報頭解壓縮。
S9:如果所建立的RB是控制平面的RB，貝ljPDCP層對所解密的
PDCP PDU執(zhí)行完整性驗證操作。
S10: PDCP層將已經(jīng)通過步驟S8或S9接收到的數(shù)據(jù)塊(即，PDCP
SDU)遞送到上層。如果所建立的RB是用戶平面的RB，貝ijPDCP層在
必要時執(zhí)行重新排序，并且將所述數(shù)據(jù)塊遞送到上層。
現(xiàn)在將描述由PDCP層執(zhí)行的報頭壓縮。報頭壓縮基于以下事實減小報頭的大小屬于相同分組流的每個IP分組的IP報頭大部分沒有改變。以上下文的形式將未改變的字段存儲在傳送側(cè)的壓縮器中以及接收側(cè)的解壓縮器中，并且當(dāng)形成了上下文時，僅傳送改變的字段以由此減小IP報頭的開銷。在報頭壓縮的初始階段，壓縮器傳送完整報頭分組以形成相對于相應(yīng)的分組流的上下文，因此報頭壓縮沒有增益。但是，當(dāng)在解壓縮器中形成上下文之后，壓縮器可以僅傳送壓縮的報頭分組，所以它的增益顯著增加。
ROHC (魯棒報頭壓縮)是在LTE系統(tǒng)中使用的典型的報頭壓縮方案，它用于減少諸如RTP (實時傳輸協(xié)議)/UDP (用戶數(shù)據(jù)報協(xié)議)/IP(網(wǎng)際協(xié)議)的實時分組的報頭信息。這里，RTP/UDP/IP分組指的是具有相關(guān)報頭的分組，該相關(guān)報頭已經(jīng)作為從上層穿過RTP、 UDP和IP的數(shù)據(jù)而被添加。它包括經(jīng)由因特網(wǎng)向目的地傳遞數(shù)據(jù)并恢復(fù)數(shù)據(jù)所需的各種報頭信息。通常，對于RTP/UDP/IP分組的報頭大小，IPv4 (IP版本4)具有40字節(jié)的報頭大小，并且IPv6具有60字節(jié)的報頭大小。當(dāng)通過使用ROHC壓縮了報頭時，40或60字節(jié)的報頭減少成1至3字節(jié)的報頭，從而獲得了顯著增益。
圖5示出了根據(jù)ROHC形成的分組的報頭大小的改變。具體地，圖5相比較地示出了 一般RTP/UDP/IP分組的報頭大小的改變以及應(yīng)用了ROHC的報頭大小的改變。當(dāng)首先傳送分組流時，因為在傳送側(cè)的壓縮器中以及在接收側(cè)的解壓縮器中尚未形成上下文，所以傳送完整報頭以形成上下文。當(dāng)在一定程度上傳送了完整報頭時，形成了上下文，并且因此可以傳送壓縮的報頭。在這個方面中，由于分組中途丟失等造成可能損壞上下文，所以需要以適當(dāng)?shù)拈g隔傳送完整報頭。通常，完整報頭包括用于形成上下文的附加信息，所以它稍微大于正常報頭。
現(xiàn)在將描述由PDCP層執(zhí)行的安全性功能。如上所述，安全性包括加密和完整性保護(hù)兩個功能。在這兩個功能中，生成了對于每個分組變化的代碼，利用該代碼加密原始數(shù)據(jù)或檢査其完整性。
通過使用添加到每個PDCP PDU的報頭的PDCP SN(序列號)來生成對于每個分組變化的代碼，并且代碼生成因子中的一個是COUNT(計數(shù))。該COUNT具有32位的長度，它的最低有效位(LSB)包括PDCPSN，并且其他剩余最高有效位(MSB)包括HFN (超幀號)。PDCP SN的長度是5、 7或12位，即對于每個RB不同，所以HFN的長度對于每種
9情況不同，為27、 25或20位。
以圖6所示的方式來執(zhí)行加密。傳送側(cè)通過在原始數(shù)據(jù)上覆蓋對于每個分組改變的代碼，即，MASK(掩碼)，來生成加密的數(shù)據(jù)。這里，MASK的覆蓋指的是對原始數(shù)據(jù)執(zhí)行XOR(異或)并且逐位執(zhí)行MASK。當(dāng)接收到因而加密的數(shù)據(jù)時，接收側(cè)再次在已加密的數(shù)據(jù)上覆蓋MASK以將它解密。這里，MASK具有32位的長度，并且根據(jù)各種輸入因子來生成。特別地，為了對于每個分組生成不同的值，通過使用對每個PDCPPDU不同的PDCP序列號來生成COUNT ，并且所生成的COUNT被用作MASK生成輸入因子中的一個。除了COUNT之外，MASK生成輸入因子包括是對應(yīng)的RB的ID值的"承載"、具有向上或向下值的"方向"、在建立RB期間由終端和網(wǎng)絡(luò)交換的"CK (加密密鑰)"等等。
另外，以如圖7所示的方式執(zhí)行完整性保護(hù)。類似于加密處理，在完整性保護(hù)處理中，通過使用利用PDCPSN的"COUNT"、是RB的ID值的"承載"、具有向上或向下值的"方向"、在建立RB期間由終端和網(wǎng)絡(luò)交換的"IK(完整性保護(hù)密鑰)"等等來生成代碼，g卩，"MAC-I(消息認(rèn)證代碼完整性)"。這里，如圖7所示，與如圖6所示的加密處理的不同之處在于，所生成的"MAC-I"沒有與原始數(shù)據(jù)XOR，而是附連到PDCP PDU。當(dāng)接收側(cè)接收到附連到PDCP PDU的MAC-I時，它通過使用與在傳送側(cè)使用的輸入因子相同的輸入因子而生成XMAC-I，并且將它與附連到PDCP PDU的MAC-I相比較，如果這兩個值(即，XMAC-I和附連到PDCP PDU的MAC-I)相同，則確定數(shù)據(jù)具有完整性，然而如果這兩個值不同，則確定數(shù)據(jù)中途已經(jīng)被改變。
由于 一 些原因，傳送側(cè)和接收側(cè)的MASK或MAC-I可能被改變以致在加密或完整性保護(hù)中出錯。MASK或MAC-I被改變的主要原因是因為HFN，即COUNT的MSB，被改變了。這在丟失了許多PDCP SDU時發(fā)生。原因是因為COUNT的MSB是HFN并且COUNT的LSB是SN，并且如果PDCPSN達(dá)到了最大值，則它返回零(0)并且增加一個HFN，即MSB。艮P，如果PDCP SDU丟失了多達(dá)環(huán)繞(wrap around) PDCP SN
的空間，則發(fā)生HFN的去同步。由于另一個原因，可能存在即使在較低層的CRC (循環(huán)冗余碼)檢驗也無法發(fā)現(xiàn)的錯誤，并且在這種情況下，如果PDCP SN值沒有在有效范圍內(nèi)，則可能發(fā)生HFN去同步。
當(dāng)發(fā)生HFN去同步時，安全性就失敗。因此，盡管接收側(cè)接收到數(shù)據(jù)，但是它無法恢復(fù)原始數(shù)據(jù)，造成接收側(cè)不斷地丟棄接收到的數(shù)據(jù)的問題。
由于發(fā)生了該問題，所以將分別描述用戶平面的RB和控制平面的RB。
首先，在用戶平面的RB的情況下，接收到的PDCP PDU被解密并且經(jīng)歷報頭解壓縮。此時，如果利用錯誤的MASK解密PDCPPDU，則在報頭壓縮處理中不斷出現(xiàn)錯誤，所以接收側(cè)不斷丟棄所接收到的PDCP PDU。
其次，在控制平面的RB的情況下，接收到的PDCP PDU被解密并且經(jīng)歷完整性驗證。如果利用錯誤的MASK解密PDCP PDU或?qū)DCPPDU與錯誤的XMAC-I相比較，則在完整性驗證處理中不斷出現(xiàn)錯誤，所以接收側(cè)不斷丟棄所接收到的PDCP PDU。
因為當(dāng)前沒有提供檢測HFN去同步的功能，所以出現(xiàn)了該問題。結(jié)果， 一旦發(fā)生了HFN去同步，則它無法恢復(fù)，并且自此所接收到的PDU具有錯誤并且因此不斷地被丟棄。

發(fā)明內(nèi)容
因此，本發(fā)明的目的是允許接收側(cè)PDCP通過使用特定條件來確定是否發(fā)生HFN去同步，即，安全性失敗，并且如果發(fā)生了HFN去同步，則通過使用PDCP RESET處理來通知RRC重新建立RB或重新設(shè)置傳送側(cè)或接收側(cè)的安全性配置。
為了實現(xiàn)以上目的，提供了一種用于檢測與在移動通信系統(tǒng)中的 安全性有關(guān)的錯誤的方法，包括(A)對一個或多個接收到的分組當(dāng) 中的具有錯誤的分組的數(shù)目進(jìn)行計數(shù)；(B)將所計數(shù)的具有錯誤的分 組數(shù)目與參考值相比較；以及(C)如果所計數(shù)的具有錯誤的分組的數(shù) 目達(dá)到了所述參考值，則確定安全性失敗。
步驟(A)可以包括接收由傳送側(cè)傳送的至少一個分組；移除所 接收到的分組的報頭；對巳移除報頭的分組執(zhí)行解碼；通過執(zhí)行從已 解碼的分組中恢復(fù)壓縮的報頭的處理或執(zhí)行完整性驗證處理來確定所 述分組的安全性失敗的錯誤；以及如果存在已確定具有安全性失敗的 錯誤的分組，則使計數(shù)器增加。
所述分組可以是用戶平面的數(shù)據(jù)或控制平面的數(shù)據(jù)。
所述方法可以進(jìn)一步包括(D)如果所計數(shù)的具有錯誤的分組的 數(shù)目達(dá)到了所述參考值以致被確定為安全性失敗，則執(zhí)行安全性配置 的恢復(fù)處理。
所述恢復(fù)處理可以包括PDCP層的重新設(shè)置過程的執(zhí)行。
所述恢復(fù)處理可以包括通知RRC層。
所述RRC層可以重新建立RB (無線承載)，重新建立RRC連接或 針對特定RB重新設(shè)置安全性配置。
步驟(A)是在PDCP (分組數(shù)據(jù)匯聚協(xié)議)層的報頭解壓縮處理 中或在PDCP層的完整性驗證處理中執(zhí)行。所述參考值可以根據(jù)RB而不同。
為了實現(xiàn)以上目的，還提供了一種用于檢測與在移動通信系統(tǒng)中 的安全性有關(guān)的錯誤的方法，包括接收至少一個分組；對所述至少 一個接收到的分組執(zhí)行完整性驗證或報頭解壓縮；在執(zhí)行所述完整性 驗證或報頭解壓縮期間檢査所述至少一個接收到的分組是否具有錯 誤；如果檢查到所述至少一個接收到的分組具有錯誤，則向RRC層報 告所生成的錯誤；以及一旦接收到所生成的錯誤，則由所述RRC層執(zhí) 行重新建立。
所述重新建立可以包括RB重新建立和PDCP層的重新建立中的至
少一個。
所述重新建立可以是RRC連接的重新建立。
所述完整性驗證可以使用XMAC-I，并且所述報頭解壓縮可以使用 上下文。
所述PDCP層的重新建立可以是所述PDCP層的RESET (重新設(shè) 置)。
本發(fā)明提供了用于當(dāng)在接收側(cè)的PDCP層處發(fā)生了安全性失敗時 有效地檢測該安全性失敗的方法，所以可以防止任何進(jìn)一步的數(shù)據(jù)丟 失以及所引起的無線資源的浪費(fèi)。


圖l示出了長期演進(jìn)(LTE)、相關(guān)技術(shù)移動通信系統(tǒng)的網(wǎng)絡(luò)結(jié)構(gòu)； 圖2示出了基于3GPP無線接入網(wǎng)絡(luò)標(biāo)準(zhǔn)的在終端和演進(jìn)UMTS地 面無線接入網(wǎng)絡(luò)(UTRAN)之間的無線接口協(xié)議的控制平面的架構(gòu)； 圖3示出了基于3GPP無線接入網(wǎng)絡(luò)標(biāo)準(zhǔn)的在終端和演進(jìn)UMTS地面無線接入網(wǎng)絡(luò)(UTRAN)之間的無線接口協(xié)議的用戶平面的架構(gòu)； 圖4示出了PDCP層的功能結(jié)構(gòu)；
圖5示出了根據(jù)R0HC形成的分組的報頭大小的改變；
圖6示出了加密方法； 圖7示出了完整性保護(hù)方法；
圖8是示出根據(jù)本發(fā)明的實施例的相對于用戶平面RB確定安全性 失敗的處理的框圖；以及
圖9是示出根據(jù)本發(fā)明的實施例的相對于控制平面RB確定安全性 失敗的處理的框圖。
具體實施例方式
本發(fā)明應(yīng)用于移動電信系統(tǒng)，并且更具體地，應(yīng)用于已經(jīng)從UMTS 演進(jìn)的演進(jìn)通用移動電信系統(tǒng)(E-UMTS)。然而，不限于此，本發(fā)明 還可以應(yīng)用于可應(yīng)用本發(fā)明的技術(shù)特征的任何移動電信系統(tǒng)和通信協(xié) 議。
本發(fā)明可以可變地修改，并且可以具有各種實施例，特定的實施 例將在附圖中圖示并被詳細(xì)地描述。然而，應(yīng)當(dāng)理解，下面的本發(fā)明 的示例性描述并不意在將本發(fā)明限制成本發(fā)明的特定形式，而是本發(fā) 明意在覆蓋包括在本發(fā)明的精神和范圍中的所有的修改、類似物和替 代。
盡管諸如"第一"和"第二"等的術(shù)語可以用于描述各種組件， 但是這樣的組件不一定限于以上術(shù)語。以上術(shù)語僅用于將一個組件與 另一個組件相區(qū)分。例如，第一組件可以被稱為第二組件，而不背離 本發(fā)明的權(quán)利范圍，并且類似地第二組件可以被稱為第一組件。術(shù)語 "和/或"既涵蓋所公開的多個相關(guān)項的組合又涵蓋來自所公開的多個 相關(guān)項的任何項。
當(dāng)組件被描述成"連接"到或"接入"另一個組件時，這可以意指它直接連接到或接入另一組件，但是應(yīng)當(dāng)理解之間可以存在另一組 件。另一方面，當(dāng)組件被描述成"直接連接"到或"直接接入"另一 組件時，應(yīng)當(dāng)理解之間沒有其他組件。
在本申請中使用的術(shù)語僅用于描述特定實施例，并且并不意在限 制本發(fā)明。單數(shù)使用的表達(dá)涵蓋復(fù)數(shù)的表達(dá)，除非它在上下文中具有 明確不同的含義。在本申請中，應(yīng)當(dāng)理解，諸如"包括"、"具有" 等的術(shù)語意在指示存在在說明書中公開的特征、數(shù)目、操作、動作、 組件、部分或其組合，并且并不意在排除可以存在或可以添加一個或 多個其他特征、數(shù)目、操作、動作、組件、部分或其組合的可能性。
除非另外定義，在此使用的所有術(shù)語，包括技術(shù)或科學(xué)術(shù)語，具 有與本發(fā)明所屬領(lǐng)域的普通技術(shù)人員通常理解的含義相同的含義。諸 如在通常使用的詞典中定義的此類術(shù)語應(yīng)當(dāng)被解釋成具有與在相關(guān)領(lǐng) 域中的上下文含義相同的含義，并且不應(yīng)當(dāng)被解釋成具有理想或過度 正式的含義，除非在本申請中明確地定義。
下面將參考附圖詳細(xì)描述本發(fā)明的實施例，在附圖中，相同或相 對應(yīng)的那些組件被賦予了相同的附圖標(biāo)記，而不管附圖的編號，并且 省略了冗余的解釋。
將描述如下在本發(fā)明中使用的術(shù)語。
安全性失敗指的是傳送側(cè)或接收側(cè)的MASK (在U-平面的情況下) 或MAC-I (在C平面的情況下)被改變以致在加密或完整性保護(hù)中出錯 從而導(dǎo)致HFN去同步的現(xiàn)象。
安全性配置指的是加密和完整性保護(hù)，并且在 對用戶平面的分 組(數(shù)據(jù))執(zhí)行加密并對控制平面的分組(數(shù)據(jù))執(zhí)行完整性保護(hù)。本發(fā)明基于當(dāng)前PDCP沒有提供用于檢測HFN去同步的功能的這
樣的認(rèn)識。因此，本發(fā)明解決了以下問題 一旦發(fā)生HFN去同步則它 無法恢復(fù)，所以由接收側(cè)接收到的所有PDU具有錯誤，并且因此，接 收側(cè)不斷地丟棄所接收到的P D U 。
本發(fā)明的基本概念是l)定義了用于確定安全性失敗的條件；2) 接收側(cè)PDCP通過使用特定條件(即，用于確定安全性失敗的條件)來 確定是否已經(jīng)發(fā)生HFN去同步，g卩，安全性失??；3)如果確定已經(jīng)發(fā) 生了安全性失敗，則接收側(cè)PDCP通知RRC重新建立RB或執(zhí)行PDCP RESET處理；4)從而重新設(shè)置傳送側(cè)和接收側(cè)的安全性配置。
現(xiàn)在將詳細(xì)描述根據(jù)本發(fā)明的安全性失敗的確定條件。
安全性失敗的確定條件根據(jù)對應(yīng)的RB屬于用戶平面還是控制平 面而不同。
首先，現(xiàn)在將描述在U平面RB情況下安全性失敗的確定條件。
接收側(cè)對解密的數(shù)據(jù)執(zhí)行報頭解壓縮。如果沒有正確地執(zhí)行解密， 則在報頭解壓縮期間發(fā)生CRC錯誤，這導(dǎo)致報頭解壓縮失敗。因此， 報頭解壓縮失敗的分組的數(shù)目充當(dāng)HFN去同步的根據(jù)。g卩，PDCP在相 對于U平面RB的報頭解壓縮期間對具有錯誤的分組的數(shù)目進(jìn)行計數(shù)， 并且如果具有錯誤的分組的數(shù)目大于參考值(或閾值)，貝IJPDCP確定 存在安全性問題，并且執(zhí)行安全性失敗的恢復(fù)處理。為此，接收側(cè)PDCP 使用用于在報頭解壓縮期間對CRC錯誤分組的數(shù)目進(jìn)行計數(shù)的變量 (或計數(shù)器)，并且在分組中無論何時發(fā)生錯誤都使該變量的值增加。 此后，當(dāng)該變量達(dá)到預(yù)定參考值(閾值)時，PDCP確定安全性配置有 問題。同時，可以通過在RB設(shè)置中接收側(cè)RRC (即，eNB RRC)向傳 送側(cè)RRC(g卩，UERRC)通知該參考值，并且然后通過傳送側(cè)RRC(UE RRC)向傳送側(cè)PDCP (即，UEPDCP)通知該參考值。該參考值可以預(yù)先被確定為特定值并且根據(jù)RB具有不同的值。無論何時在分組處發(fā) 生錯誤(例如，如果間斷地發(fā)生錯誤)，用于對分組的錯誤進(jìn)行計數(shù) 的變量(或計數(shù)器)的值都可以增加，或僅當(dāng)在分組處不斷地發(fā)生錯 誤時才可以增加。圖8是示出根據(jù)本發(fā)明的實施例的相對于用戶平面RB由接收側(cè) PDCP確定安全性失敗的處理的框圖?，F(xiàn)在將詳細(xì)描述在U平面RB情況 下確定安全性失敗的處理。S20:接收側(cè)PDCP接收來自較低層(即，RLC)的PDU1 PDU20 的PDCP PDU。S21:接收側(cè)PDCP移除所接收到的PDU的報頭，并且將它們遞送 到解密單元。S22:接收側(cè)PDCP的解密單元對已移除報頭的PDU執(zhí)行解密。如 果在PDU1處發(fā)生了安全性失敗，即，如果發(fā)生了HFN去同步，則沒有 對PDU1和所有其他后續(xù)PDU (即，PDU2 PDU20)正確地進(jìn)行解密。S23:然而，接收側(cè)PDCP沒有認(rèn)識到分組(即，PDU1 PDU20) 沒有被正確地解密的事實，并且將它們遞送到報頭解壓縮單元。S24:報頭解壓縮單元對所接收到的分組執(zhí)行報頭解壓縮，但是它 們所有都具有錯誤?？梢曰趫箢^的CRC值來確定所生成的錯誤。S25:接收側(cè)PDCP對在報頭解壓縮期間已經(jīng)發(fā)生錯誤的分組的數(shù) 目進(jìn)行計數(shù)。如果所計數(shù)的錯誤的分組的數(shù)目達(dá)到(即，大于)預(yù)定 義參考值(即，可以例如是20的閾值)，則接收側(cè)PDCP確定安全性配 置有錯誤。艮口，在如圖8所示的實施例中，首先，當(dāng)接收側(cè)PDCP對所接收到 的分組執(zhí)行報頭解壓縮時，它基于報頭的CRC值確定錯誤。其次，接 收側(cè)PDCP對具有錯誤的分組的數(shù)目進(jìn)行計數(shù)。第三，如果錯誤的分組 的數(shù)目達(dá)到了參考值，則接收側(cè)PDCP確定已經(jīng)發(fā)生了安全性失敗。一 旦確定了安全性失敗，接收側(cè)PDCP很快執(zhí)行恢復(fù)安全性失敗的處理，以便防止可能的進(jìn)一步數(shù)據(jù)丟失和無線資源浪費(fèi)。該恢復(fù)處理可以被 執(zhí)行，以便例如接收側(cè)RRC層通知終端該安全性失敗的錯誤，使得終
端可以切斷它到該網(wǎng)絡(luò)的連接，并且再次從開始建立RRC連接。替代 地，RRC層可以相對于在終端(UE)和網(wǎng)絡(luò)之間的特定RB而重新建立 RB或再次設(shè)置安全性配置。
首先，用于確定在C平面RB情況下的安全性失敗的條件將描述如下。
在C平面RB的情況下，沒有執(zhí)行報頭解壓縮，而是替代地，執(zhí)行 完整性驗證。因此，應(yīng)當(dāng)基于與U平面RB的基礎(chǔ)不同的基礎(chǔ)來確定安 全性失敗。在執(zhí)行完整性驗證期間，將包括在PDU中的MAC-I值和由接 收側(cè)PDCP本身生成的XMAC-I值相比較。如果這兩個值不同，則確定 完整性驗證失敗，并且丟棄由接收側(cè)PDCP接收到的分組。因此，在本 發(fā)明中，相對于C平面RB，如果在執(zhí)行完整性驗證期間超過特定數(shù)目 的分組具有錯誤，則將它確定為安全性失敗，并且執(zhí)行恢復(fù)該安全性 失敗的處理。為此，在執(zhí)行完整性驗證期間，接收側(cè)PDCP對錯誤的數(shù) 目進(jìn)行計數(shù)，即，其中包括在PDU中的MAC-I值和由接收側(cè)PDU本身生 成的XMAC-I不同的情況的數(shù)目。換句話說，接收側(cè)PDCP使用用于對 具有不同值(包括在PDU中的MAC-I值和由接收側(cè)PDCP本身生成的 XMAC-I值)的對應(yīng)分組的數(shù)目進(jìn)行計數(shù)的變量(計數(shù)器)。也就是， 無論何時在分組處發(fā)生錯誤，接收側(cè)PDCP都使變量的值增加，并且當(dāng) 變量達(dá)到預(yù)定參考值(閾值)時，接收側(cè)PDCP確定安全性配置有問題。 同時，可以通過在RB設(shè)置中接收側(cè)RRC (即，eNBRRC)向傳送側(cè)RRC (即，UERRC)通知該參考值，并且然后通過傳送側(cè)RRC (UERRC) 向傳送側(cè)PDCP (即，UEPDCP)通知該參考值。該參考值可以預(yù)先被 確定為特定值并且根據(jù)RB具有不同的值。無論何時在分組處發(fā)生錯誤 (例如，如果間斷地發(fā)生錯誤)，用于對分組的錯誤進(jìn)行計數(shù)的變量 (或計數(shù)器)的值都可以增加，或僅當(dāng)在分組處不斷地發(fā)生錯誤時才 可以增加。圖9是示出根據(jù)本發(fā)明的實施例的相對于控制平面RB由接收側(cè)
PDCP確定安全性失敗的處理的框圖。現(xiàn)在將詳細(xì)描述相對于C平面RB
的確定安全性失敗的處理。
S30:接收側(cè)PDCP接收來自較低層(即，RLC)的PDU1 PDU20 的PDCP PDU。
S31:接收側(cè)PDCP移除所接收到的PDU的報頭，并且將它們遞送 到解密單元。
S32:接收側(cè)PDCP對已移除報頭的PDU執(zhí)行解密。如果在PDU1處 發(fā)生了安全性失敗，即，如果發(fā)生了HFN去同步，則沒有對PDU1和所 有其他后續(xù)PDU (即，PDU2 PDU20)正確地進(jìn)行解密。
S33:然而，接收側(cè)PDCP沒有認(rèn)識到分組(即，PDU1 PDU20) 沒有被正確地解密的事實，并且將它們遞送到完整性驗證單元。
S34:完整性驗證單元對所接收到的分組(即，PDU1 PDU20) 執(zhí)行完整性驗證，但是它們所有都具有錯誤?？梢酝ㄟ^將包括在PDU 中的MAC-I值和由接收側(cè)PDCP本身生成的XMAC-I值相比較來確定所 生成的錯誤。
S35:接收側(cè)PDCP對在完整性驗證期間已經(jīng)發(fā)生錯誤的分組的數(shù) 目進(jìn)行計數(shù)。如果所計數(shù)的錯誤的分組的數(shù)目達(dá)到預(yù)定義參考值(可 以例如是20)，則接收側(cè)PDCP確定安全性配置有錯誤。
圖9中的實施例示出了在解密處理期間發(fā)生了錯誤的情況。但是， 實際上，在完整性驗證處理期間也可能發(fā)生錯誤。在這種情況下，緊 接著的處理過程與上述相同。例如，如果對所有分組成功地執(zhí)行了解 密，但是PDU l由于錯誤的完整性驗證參數(shù)而具有錯誤，所有的后續(xù)分 組將具有錯誤。因此，在任何情況下，都在完整性驗證期間對錯誤的 分組的數(shù)目進(jìn)行計數(shù)以確定是否已經(jīng)發(fā)生安全性失敗。
當(dāng)接收側(cè)PDCP確定安全性失敗時，接收側(cè)PDCP很快地執(zhí)行恢復(fù)安全性失敗的處理，以便防止可能的進(jìn)一步數(shù)據(jù)丟失和無線資源的浪 費(fèi)?；謴?fù)處理可以被執(zhí)行，以便例如接收側(cè)RRC層向終端通知該安全 性失敗的錯誤，使得終端能夠切斷它到網(wǎng)絡(luò)的連接，并且再次從開始
建立RRC連接。替代地，RRC層可以相對于在終端(UE)和網(wǎng)絡(luò)之間 的特定RB而重新建立RB或再次設(shè)置安全性配置。
可以通過軟件、硬件或它們的結(jié)合來實現(xiàn)到此所描述的方法。例 如，根據(jù)本發(fā)明的方法可以存儲在存儲介質(zhì)(例如，移動終端的內(nèi)部 存儲器、閃存、硬盤等)中，并且可以通過在可以由處理器(例如， 移動終端的內(nèi)部微處理器)執(zhí)行的軟件程序中的代碼或命令語言來實 現(xiàn)。
因此描述了本發(fā)明，將顯而易見的是，可以以很多方式來改變本 發(fā)明。不應(yīng)當(dāng)認(rèn)為這樣的變化背離本發(fā)明的范圍，并且如將對本領(lǐng)域 技術(shù)人員顯而易見的所有這樣的修改意在被包括在隨附權(quán)利要求的范 圍之內(nèi)。
權(quán)利要求
1.一種用于檢測與在移動通信系統(tǒng)中的安全性有關(guān)的錯誤的方法，所述方法包括(A)對一個或多個接收到的分組當(dāng)中的具有錯誤的分組的數(shù)目進(jìn)行計數(shù)；(B)將所計數(shù)的具有錯誤的分組的數(shù)目與參考值相比較；以及(C)如果所計數(shù)的具有錯誤的分組的數(shù)目達(dá)到所述參考值，則確定安全性失敗。
2. 根據(jù)權(quán)利要求l所述的方法，其中，所述步驟(A)包括 接收由傳送側(cè)傳送的至少一個分組；移除所接收至I」的分組的報頭； 對已移除報頭的分組執(zhí)行解碼；通過執(zhí)行從已解碼的分組中恢復(fù)壓縮的報頭的處理或執(zhí)行完整性 驗證處理來確定所述分組的安全性失敗的錯誤；以及如果存在已確定具有安全性失敗的錯誤的分組，則使計數(shù)器增加。
3. 根據(jù)權(quán)利要求l所述的方法，其中，所述分組是用戶平面的數(shù) 據(jù)或控制平面的數(shù)據(jù)。
4. 根據(jù)權(quán)利要求l所述的方法，進(jìn)一步包括(D) 如果所計數(shù)的具有錯誤的分組的數(shù)目達(dá)到所述參考值以致被 確定為所述安全性失敗，則執(zhí)行安全性配置的恢復(fù)處理。
5. 根據(jù)權(quán)利要求4所述的方法，其中，所述恢復(fù)處理包括 執(zhí)行PDCP層的重新設(shè)置過程。
6. 根據(jù)權(quán)利要求4所述的方法，其中，所述恢復(fù)處理包括 通知RRC層。
7. 根據(jù)權(quán)利要求6所述的方法，其中，所述RRC層重新建立RB(無 線承載)，重新建立RRC連接或針對特定RB重新設(shè)置安全性配置。
8. 根據(jù)權(quán)利要求l所述的方法，其中，所述錯誤的分組是連續(xù)的。
9. 根據(jù)權(quán)利要求l所述的方法，所述步驟(A)在PDCP (分組數(shù) 據(jù)匯聚協(xié)議)層的報頭解壓縮處理期間或在所述PDCP層的完整性驗證 處理期間執(zhí)行。
10. 根據(jù)權(quán)利要求1所述的方法，其中，所述參考值根據(jù)RB而不同。
11. 一種用于檢測與在移動通信系統(tǒng)中的安全性有關(guān)的錯誤的方法，所述方法包括接收至少一個分組；對所述至少一個接收到的分組執(zhí)行完整性驗證或報頭解壓縮；在執(zhí)行所述完整性驗證或報頭解壓縮期間檢査所述至少一個接收 到的分組是否具有錯誤；如果檢查到所述至少一個接收到的分組具有錯誤，則向RRC層報 告所生成的錯誤；以及一旦接收到所生成的錯誤，則由所述RRC層執(zhí)行重新建立。
12. 根據(jù)權(quán)利要求ll所述的方法，其中，所述重新建立包括RB重 新建立和PDCP層的重新建立中的至少一個。
13. 根據(jù)權(quán)利要求ll所述的方法，其中，所述重新建立是RRC連接的重新建立。
14. 根據(jù)權(quán)利要求ll所述的方法，其中，所述完整性驗證使用 XMAC-I，并且所述報頭解壓縮使用上下文。
15.根據(jù)權(quán)利要求12所述的方法，其中，所述PDCP層的重新建 立是指重新設(shè)置所述PDCP層。
全文摘要
公開了一種用于在是一種移動通信系統(tǒng)的LTE(長期演進(jìn))系統(tǒng)的PDCP層處檢測安全性錯誤的方法和裝置。定義了用于確定安全性失敗的條件。接收側(cè)PDCP通過使用特定條件(即，用于確定安全性失敗的條件)確定是否已經(jīng)發(fā)生HFN去同步，即，安全性失敗。如果確定已經(jīng)發(fā)生了安全性失敗，則接收側(cè)PDCP通知RRC重新建立RB或執(zhí)行PDCP RESET處理，以重新設(shè)置傳送側(cè)和接收側(cè)的安全性配置。
文檔編號H04L1/00GK101675618SQ200880014193
公開日2010年3月17日 申請日期2008年8月4日 優(yōu)先權(quán)日2007年8月10日
發(fā)明者千成德, 樸成埈, 李承俊, 李英大 申請人:Lg電子株式會社