專利名稱：檢測移動電信系統中的安全性錯誤的方法和移動電信設備的制作方法
技術領域：
本發明涉及一種在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電子株式會社