(57)【要約】本発明は、移動通信システムであるＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システムのＰＤＣＰ層でセキュリティエラーを検出する方法及び装置に関する。本発明においては、セキュリティ失敗の判断条件を定義し、受信側ＰＤＣＰ層が特定の条件（すなわち、セキュリティ失敗の判断条件）を用いてＨＦＮ非同期化、すなわちセキュリティ失敗が発生したか否かを判断し、セキュリティ失敗が発生したと判断されると、これをＲＲＣ層に通知してＲＢ再設定又はＰＤＣＰリセット過程を行うことにより、送信側及び受信側のセキュリティ構成をリセットする。
2010533415.tif 000002
【特許請求の範囲】
【請求項１】
（Ａ）受信した少なくとも１つのパケットからエラー発生パケットの数をカウントするステップと、
（Ｂ）前記カウントしたエラー発生パケットの数と基準値とを比較するステップと、
（Ｃ）前記カウントしたエラー発生パケットの数が前記基準値に達すると、セキュリティ失敗であると判断するステップと
を含むことを特徴とする移動通信システムにおけるセキュリティ関連エラー検出方法。
【請求項２】
前記ステップ（Ａ）は、
送信側により送信された少なくとも１つのパケットを受信するステップと、
前記受信したパケットのヘッダを除去するステップと、
前記ヘッダが除去されたパケットに対して復号化を行うステップと、
前記復号化されたパケットに対して圧縮されたヘッダの復元を行う過程、又は完全性確認過程を行うことにより、前記パケットのセキュリティ失敗のエラーを判断するステップと、
前記セキュリティ失敗のエラーがあると判断されたパケットがある場合、カウンタを増加させるステップと
を含むことを特徴とする請求項１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
【請求項３】
前記パケットが、ユーザプレーンのデータ、又は制御プレーンのデータであることを特徴とする請求項１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
【請求項４】
（Ｄ）前記カウントしたエラー発生パケットの数が前記基準値に達し、セキュリティ失敗であると判断されると、セキュリティ構成の復旧過程を行うステップをさらに含むことを特徴とする請求項１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
【請求項５】
前記復旧過程が、ＰＤＣＰ層のリセット手順を行う過程を含むことを特徴とする請求項４に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
【請求項６】
前記復旧過程が、ＲＲＣ層に通知する過程を含むことを特徴とする請求項４に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
【請求項７】
前記ＲＲＣ層が、ＲＢを再設定するか、ＲＲＣ接続を再設定するか、又は特定のＲＢに関してセキュリティ構成をリセットすることを特徴とする請求項６に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
【請求項８】
前記エラー発生パケットが連続していることを特徴とする請求項１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
【請求項９】
前記ステップ（Ａ）が、ＰＤＣＰ層のヘッダ復元過程、又は前記ＰＤＣＰ層の完全性確認過程で行われることを特徴とする請求項１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
【請求項１０】
前記基準値がＲＢによって異なる値であることを特徴とする請求項１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
【請求項１１】
少なくとも１つのパケットを受信するステップと、
前記受信した少なくとも１つのパケットに対して完全性確認又はヘッダ復元を行うステップと、
前記完全性確認又は前記ヘッダ復元時、前記受信した少なくとも１つのパケットにエラーが発生したか否かを確認するステップと、
前記受信した少なくとも１つのパケットにエラーが発生したことが確認されると、前記エラーの発生をＲＲＣ層に報告するステップと、
前記ＲＲＣ層が前記エラー発生報告を受信して再設定を行うステップと
を含むことを特徴とする移動通信システムにおけるセキュリティ関連エラー検出方法。
【請求項１２】
前記再設定が、ＲＢの再設定とＰＤＣＰ層の再設定の少なくとも一方を含むことを特徴とする請求項１１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
【請求項１３】
前記再設定が、ＲＲＣ接続の再設定であることを特徴とする請求項１１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
【請求項１４】
前記完全性確認はＸＭＡＣ−Ｉを利用し、前記ヘッダ復元はコンテクストを利用することを特徴とする請求項１１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
【請求項１５】
前記ＰＤＣＰ層の再設定が、前記ＰＤＣＰ層のリセットであることを特徴とする請求項１２に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システムのＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）層で使用されるセキュリティアルゴリズムに発生したセキュリティエラーを検出する方法及び装置に関する。
【背景技術】
【０００２】
図１は、従来の移動通信システムであるＬＴＥシステムのネットワーク構造を示す図である。ＬＴＥシステムは、既存のＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）システムから進化したシステムであり、３ＧＰＰで基礎的な標準化作業を行っている。
【０００３】
ＬＴＥネットワークは、大きくＥ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ  ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）とＣＮ（Ｃｏｒｅ  Ｎｅｔｗｏｒｋ）とに区分される。Ｅ−ＵＴＲＡＮは、端末（又は、Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ；  ＵＥ）と、基地局（Ｅｖｏｌｖｅｄ  ＮｏｄｅＢ；  ｅＮＢ）と、ネットワークのエンドに位置して外部ネットワークに接続するアクセスゲートウェイ（Ａｃｃｅｓｓ  Ｇａｔｅｗａｙ；  ａＧＷ）とから構成される。ａＧＷは、ユーザトラフィック処理を担当する部分と制御トラフィック処理を担当する部分とに分けられる。この場合、新しいユーザトラフィック処理のためのａＧＷと制御トラフィック処理のためのａＧＷ間では、新しいインタフェースを使用して通信することもできる。１つのｅＮＢには１つ以上のセルが存在する。ｅＮＢ間ではユーザトラフィック又は制御トラフィックの送信のためのインタフェースを使用することもできる。ＣＮは、ａＧＷとその他のＵＥのユーザ登録などのためのノードなどとから構成することもできる。Ｅ−ＵＴＲＡＮとＣＮとを区分するためのインタフェースを使用することもできる。
【０００４】
図２は、３ＧＰＰ無線アクセスネットワーク規格に準拠したＵＥとＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルの制御プレーン（Ｃ−ｐｌａｎｅ）の構造を示す図である。図３は、３ＧＰＰ無線アクセスネットワーク規格に準拠したＵＥとＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルのユーザプレーン（Ｕ−ｐｌａｎｅ）の構造を示す図である。
【０００５】
以下、図２及び図３を参照して、ＵＥとＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルの構造を説明する。
【０００６】
無線インタフェースプロトコルは、水平的には、物理層、データリンク層、及びネットワーク層からなり、垂直的には、データ情報の送信のためのユーザプレーン、及び制御信号の送信のための制御プレーンからなる。図２及び図３のプロトコル層は、通信システムでよく知られている開放型システム間相互接続（Ｏｐｅｎ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ；  ＯＳＩ）参照モデルの下位３層に基づいて、Ｌ１（第１層）、Ｌ２（第２層）、Ｌ３（第３層）に区分される。このような無線プロトコル層は、ＵＥとＥ−ＵＴＲＡＮに対で存在し、無線区間のデータ送信を担当する。
【０００７】
以下、図２の無線プロトコルの制御プレーン及び図３の無線プロトコルのユーザプレーンの各層を説明する。
【０００８】
第１層である物理（Ｐｈｙｓｉｃａｌ；  ＰＨＹ）層は、物理チャネルを利用して上位層に情報送信サービス（Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｒａｎｓｆｅｒ  Ｓｅｒｖｉｃｅ）を提供する。ＰＨＹ層は、上位の媒体アクセス制御（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ；  ＭＡＣ）層とトランスポートチャネルを介して接続されており、このトランスポートチャネルを介してＭＡＣ層とＰＨＹ層間のデータの移動が行われる。ここで、トランスポートチャネルは、チャネルが共有されるか否かによって、大きく専用トランスポートチャネルと共通トランスポートチャネルとに分けられる。また、異なるＰＨＹ層間、すなわち送信側ＰＨＹ層と受信側ＰＨＹ層間では、無線リソースを利用した物理チャネルを介してデータの移動が行われる。
【０００９】
第２層には様々な層が存在する。まず、ＭＡＣ層は、様々な論理チャネルを様々なトランスポートチャネルにマッピングする役割を果たし、様々な論理チャネルを１つのトランスポートチャネルにマッピングする論理チャネル多重化の役割も果たす。ＭＡＣ層は、上位層であるＲＬＣ層と論理チャネルを介して接続されており、この論理チャネルは、送信される情報の種類によって、大きく制御プレーンの情報を送信する制御チャネルとユーザプレーンの情報を送信するトラフィックチャネルとに分けられる。
【００１０】
第２層のＲＬＣ層は、上位層から受信したデータを分割（ｓｅｇｍｅｎｔ）及び連結（ｃｏｎｃａｔｅｎａｔｅ）して、下位層における無線区間のデータ送信に適するようにデータサイズを調節する役割を果たす。また、各無線ベアラ（Ｒａｄｉｏ  Ｂｅａｒｅｒ；  ＲＢ）が要求する様々なＱｏＳを保証するために、透過モード（Ｔｒａｎｓｐａｒｅｎｔ  Ｍｏｄｅ；  ＴＭ）、非応答モード（Ｕｎ−ａｃｋｎｏｗｌｅｄｇｅｄ  Ｍｏｄｅ；  ＵＭ）、及び応答モード（Ａｃｋｎｏｗｌｅｄｇｅｄ  Ｍｏｄｅ；  ＡＭ）の３つの動作モードを提供する。特に、ＡＭモードで動作するＲＬＣ層（以下、ＡＭ  ＲＬＣ層という）は、信頼性のあるデータ送信のために、自動再送要求（Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  Ｒｅｑｕｅｓｔ；  ＡＲＱ）機能を利用した再送機能を実行する。
【００１１】
第２層のＰＤＣＰ層は、ＩＰｖ４（ＩＰ  ｖｅｒｓｉｏｎ  ４）やＩＰｖ６（ＩＰ  ｖｅｒｓｉｏｎ  ６）などのＩＰパケットを帯域幅の小さい無線区間で効率的に送信するために、相対的にサイズが大きくて不要な制御情報を含むＩＰパケットのヘッダサイズを小さくするヘッダ圧縮機能を実行する。これは、データのヘッダ部分で必ず必要な情報のみを送信させることにより、無線区間の送信効率を向上させる役割を果たす。
【００１２】
第３層の最上位に位置するＲＲＣ層は、制御プレーンでのみ定義され、無線ベアラ（ＲＢ）の設定、再設定、及び解除に関連して論理チャネル、トランスポートチャネル、及び物理チャネルの制御を担当する。ここで、ＲＢとは、ＵＥとＵＴＲＡＮ間のデータ送信のために無線プロトコルの第１層及び第２層により提供される論理パスを意味し、一般に、ＲＢの設定とは、特定のサービスを提供するために必要な無線プロトコル層及びチャネルの特性を規定し、それぞれの具体的なパラメータ及び動作方法を設定する過程を意味する。
【００１３】
以下、ＰＤＣＰ層について具体的に説明する。ＰＤＣＰ層は、上位にはＲＲＣ層又はユーザアプリケーションと接続され、下位にはＲＬＣ層と接続されている。図４において、左側は送信側ＰＤＣＰエンティティの機能的構造を示し、右側は受信側ＰＤＣＰエンティティの機能的構造を示す。左の送信側構造は、ＰＤＣＰ層が上位エンティティからＰＤＣＰ  ＳＤＵを受信した場合に前記ＰＤＣＰ  ＳＤＵに適用する動作を示し、右の受信側構造は、ＰＤＣＰ層が下位エンティティからＰＤＣＰ  ＰＤＵを受信した場合に前記ＰＤＣＰ  ＰＤＵに適用する動作を示す。
【００１４】
ＰＤＣＰはユーザプレーンと制御プレーンの両方に使用されるが、ＰＤＣＰの一部機能は使用されるプレーンに応じて選択的に適用される。すなわち、図４に示すように、ヘッダ圧縮機能はユーザプレーンのデータにのみ適用され、完全性保護（ｉｎｔｅｇｒｉｔｙ  ｐｒｏｔｅｃｔｉｏｎ）機能は制御プレーンのデータにのみ適用される。
【００１５】
以下、図４の左の送信側ＰＤＣＰエンティティにより行われるデータ処理過程を説明する。
【００１６】
Ｓ１：ＰＤＣＰ層は、受信したＰＤＣＰ  ＳＤＵにシーケンス番号を割り当てる。
【００１７】
Ｓ２：設定されたＲＢがユーザプレーンのＲＢである場合、前記ＰＤＣＰ層は、前記ＰＤＣＰ  ＳＤＵに対してヘッダ圧縮を行う。
【００１８】
Ｓ３：前記設定されたＲＢが制御プレーンのＲＢである場合、前記ＰＤＣＰ層は、前記ＰＤＣＰ  ＳＤＵに対して完全性保護動作を行う。
【００１９】
Ｓ４：前記ＰＤＣＰ層は、ステップＳ２又はステップＳ３の結果として生成されたデータブロックに対して暗号化（ｃｉｐｈｅｒｉｎｇ）を行う。
【００２０】
Ｓ５：前記ＰＤＣＰ層は、前記暗号化されたデータブロックに適切なヘッダを付加してＰＤＣＰ  ＰＤＵを構成し、前記構成されたＰＤＣＰ  ＰＤＵをＲＬＣ層に送信する。
【００２１】
以下、図４の右の受信側ＰＤＣＰエンティティにより行われるデータ処理過程を説明する。
【００２２】
Ｓ６：前記ＰＤＣＰ層は、受信した前記ＰＤＣＰ  ＰＤＵのヘッダを除去する。
【００２３】
Ｓ７：前記ＰＤＣＰ層は、前記ヘッダが除去されたＰＤＣＰ  ＰＤＵに対して復号化（ｄｅｃｉｐｈｅｒｉｎｇ）を行う。
【００２４】
Ｓ８：前記設定されたＲＢがユーザプレーンのＲＢである場合、前記ＰＤＣＰ層は、前記復号化されたＰＤＣＰ  ＰＤＵに対してヘッダ復元（ｈｅａｄｅｒ  ｄｅｃｏｍｐｒｅｓｓｉｏｎ）を行う。
【００２５】
Ｓ９：前記設定されたＲＢが制御プレーンのＲＢである場合、前記ＰＤＣＰ層は、前記復号化されたＰＤＣＰ  ＰＤＵに対して完全性確認（ｉｎｔｅｇｒｉｔｙ  ｖｅｒｉｆｉｃａｔｉｏｎ）動作を行う。
【００２６】
Ｓ１０：前記ＰＤＣＰ層は、ステップＳ８又はステップＳ９により受信したデータブロック、すなわちＰＤＣＰ  ＳＤＵを上位層に送信する。前記設定されたＲＢがユーザプレーンのＲＢである場合、前記ＰＤＣＰ層は、必要に応じて、並び替え（ｒｅｏｒｄｅｒｉｎｇ）を行った後に前記ＰＤＣＰ  ＳＤＵを上位層に送信する。
【００２７】
以下、前記ＰＤＣＰ層により行われるヘッダ圧縮について説明する。ヘッダ圧縮は、同一のパケットストリームに属するＩＰパケットのＩＰヘッダはほとんどの部分が変わらないという事実に基づいてヘッダのサイズを小さくするもので、変わらないフィールドは前記送信側の圧縮機（ｃｏｍｐｒｅｓｓｏｒ）と前記受信側の復元機（ｄｅｃｏｍｐｒｅｓｓｏｒ）にコンテクストの形態で保存しておき、コンテクストが形成された後は、変わるフィールドのみを送信することにより、ＩＰヘッダのオーバーヘッドを減らす。ヘッダ圧縮の初期段階では、前記復元機に該当パケットストリームに関するコンテクストを形成するために、前記圧縮機はフルヘッダ（ｆｕｌｌ  ｈｅａｄｅｒ）パケットを送信するため、ヘッダ圧縮による利得がないが、前記復元機にコンテクストが形成された後は、前記圧縮機は圧縮ヘッダパケットのみを送信するため、その利得が大きくなる。
【００２８】
ＬＴＥシステムで用いられる代表的なヘッダ圧縮方式であるＲＯＨＣ（Ｒｏｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）は、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）／ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）などのリアルタイムパケットのヘッダ情報を減らすのに用いられる。ここで、ＲＴＰ／ＵＤＰ／ＩＰパケットとは、上位層からのデータがＲＴＰ、ＵＤＰ、及びＩＰにより関連ヘッダが付加されたパケットを意味し、データがインターネットを介して送信先に送信されて復旧されるのに必要な様々なヘッダ情報を含む。一般に、ＲＴＰ／ＵＤＰ／ＩＰパケットのヘッダサイズは、ＩＰｖ４の場合は４０ｂｙｔｅであり、ＩＰｖ６の場合は６０ｂｙｔｅであるが、ＲＯＨＣを用いてヘッダを圧縮した場合、ヘッダが４０ｂｙｔｅ又は６０ｂｙｔｅから１〜３ｂｙｔｅに減るので、その利得は大きい。
【００２９】
図５は、ＲＯＨＣにより生成されるパケットのヘッダサイズの変化を示す図である。特に、図５は、一般的なＲＴＰ／ＵＤＰ／ＩＰパケットのヘッダサイズの変化、並びにＲＯＨＣの適用によるヘッダサイズの変化を示す。パケットストリームを最初に送信する際は、前記送信側の圧縮機と前記受信側の復元機のどちらにもコンテクストが形成されていないため、コンテクストの形成のためにフルヘッダを送信する。ある程度のフルヘッダが送信されるとコンテクストが形成され、従って、その後は圧縮ヘッダを送信することができる。ところが、途中でパケット損失などの理由でコンテクストが損傷することがあるため、適切な間隔でフルヘッダを送信する必要もある。一般に、フルヘッダは、コンテクストを形成する追加情報を含むため、通常のヘッダ（ｎｏｒｍａｌ  ｈｅａｄｅｒ）より若干大きい。
【００３０】
次に、前記ＰＤＣＰ層により行われるセキュリティ機能について説明する。前述のように、セキュリティには暗号化と完全性保護の２つの機能があるが、どちらの機能もパケット毎に変わるコードを生成し、これを利用して元のデータの暗号化又は完全性検査を行う。
【００３１】
前記パケット毎に変わるコードは、各ＰＤＣＰ  ＰＤＵのヘッダに追加されるＰＤＣＰ  ＳＮ（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）を用いて生成するが、そのコード生成因子の１つがＣＯＵＮＴである。前記ＣＯＵＮＴは、３２ｂｉｔの長さを有し、この中で、下位ビット（Ｌｅａｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔ；  ＬＳＢ）はＰＤＣＰ  ＳＮから構成され、残りの上位ビット（Ｍｏｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔ；  ＭＳＢ）はＨＦＮ（Ｈｙｐｅｒ  Ｆｒａｍｅ  Ｎｕｍｂｅｒ）から構成される。ＰＤＣＰ  ＳＮの長さは、５、７、又は１２ｂｉｔであって、ＲＢ毎に異なるため、ＨＦＮの長さも異なり、それぞれ２７、２５、又は２０ｂｉｔである。
【００３２】
暗号化は図６に示すような方法で行う。送信側は、元のデータに対してパケット毎に変わるコード、すなわちＭＡＳＫをかけることにより、暗号化されたデータを生成する。ここで、ＭＡＳＫをかけるとは、元のデータとＭＡＳＫに対してビット別のＸＯＲ演算を行うことを意味する。このようにして暗号化されたデータを受信した受信側は、前記暗号化されたデータに再びＭＡＳＫをかけて復号化する。ここで、ＭＡＳＫは、３２ｂｉｔであり、様々な入力因子から生成されるが、特に、パケット毎に異なる値を生成するために、ＰＤＣＰ  ＰＤＵ毎に変わるＰＤＣＰ  ＳＮを用いてＣＯＵＮＴを生成し、その生成したＣＯＵＮＴをＭＡＳＫ生成入力因子の１つとして使用する。ＭＡＳＫ生成入力因子は、ＣＯＵＮＴの他に、該当ＲＢのＩＤ値である「Ｂｅａｒｅｒ」、上り又は下りの値を有する「Ｄｉｒｅｃｔｉｏｎ」、ＲＢ設定時に端末とネットワークにより交換される「ＣＫ（Ｃｉｐｈｅｒｉｎｇ  Ｋｅｙ）」などがある。
【００３３】
また、完全性保護は図７に示すような方法で行う。完全性保護過程においては、暗号化過程と同様に、ＰＤＣＰ  ＳＮを用いた「ＣＯＵＮＴ」、ＲＢのＩＤ値である「Ｂｅａｒｅｒ」、上り又は下りの値を有する「Ｄｉｒｅｃｔｉｏｎ」、ＲＢ設定時に端末とネットワークにより交換される「ＩＫ（Ｉｎｔｅｇｒｉｔｙ  Ｐｒｏｔｅｃｔｉｏｎ  Ｋｅｙ）」などを利用して、コード、すなわち「ＭＡＣ−Ｉ（Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ−Ｉｎｔｅｇｒｉｔｙ）」を生成する。ここで、図６の暗号化過程と異なる点は、生成された「ＭＡＣ−Ｉ」を元のデータとＸＯＲ演算するのではなく、図７に示すように、生成された「ＭＡＣ−Ｉ」をＰＤＣＰ  ＰＤＵに付加することである。受信側は、前記「ＭＡＣ−Ｉ」が付加されたＰＤＣＰ  ＰＤＵを受信すると、送信側で使用したのと同じ入力因子を用いてＸＭＡＣ−Ｉを生成し、前記ＸＭＡＣ−Ｉと前記ＰＤＣＰ  ＰＤＵに付加されているＭＡＣ−Ｉとを比較する。２つの値（すなわち、ＸＭＡＣ−Ｉの値とＰＤＣＰ  ＰＤＵに付加されているＭＡＣ−Ｉの値）が同一であればデータが完全であると判断し、２つの値が異なればデータが途中で変わったと判断する。
【００３４】
何らかの理由で送信側及び受信側のＭＡＳＫ又はＭＡＣ−Ｉが変わり、暗号化又は完全性保護にエラーが発生することがある。ＭＡＳＫ又はＭＡＣ−Ｉが変わる最も大きな理由としては、ＣＯＵＮＴのＭＳＢであるＨＦＮの変化が挙げられるが、これは多数のＰＤＣＰ  ＳＤＵが損失した場合に発生する。その理由は、ＣＯＵＮＴのＭＳＢはＨＦＮであり、ＣＯＵＮＴのＬＳＢはＰＤＣＰ  ＳＮであるが、ＰＤＣＰ  ＳＮが最大値に達すると、これは再び０に戻り、ＭＳＢであるＨＦＮは１増加するからである。つまり、ＰＤＣＰ  ＳＮスペースがラップアラウンドする程度にＰＤＣＰ  ＳＤＵが損失すると、ＨＦＮの非同期化（ｄｅ−ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）が発生する。他の理由として、下位層でＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｏｄｅ）検査によっても発見できないエラーが発生することがあるが、その場合、ＰＤＣＰ  ＳＮ値が有効範囲から外れるとＨＦＮ非同期化が発生することがある。
【００３５】
このようにＨＦＮ非同期化が発生すると、セキュリティに失敗する。従って、受信側がデータを受信しても元のデータを復元できないため、受信側は受信したデータを廃棄し続けるという問題が発生する。
【００３６】
このような問題の発生について、ユーザプレーンのＲＢの場合と制御プレーンのＲＢの場合とに分けて説明する。
【００３７】
第一に、ユーザプレーンのＲＢの場合は、受信したＰＤＣＰ  ＰＤＵを復号化した後にヘッダ復元を行うが、このとき誤ったＭＡＳＫで復号化すると、ヘッダ復元過程でエラーが発生し続け、従って、受信側は受信したＰＤＣＰ  ＰＤＵを廃棄し続けるという問題が発生する。
【００３８】
第二に、制御プレーンのＲＢの場合は、受信したＰＤＣＰ  ＰＤＵを復号化した後に完全性確認を行うが、このとき誤ったＭＡＳＫで復号化するか、又は誤ったＸＭＡＣ−Ｉと比較すると、完全性確認過程でエラーが発生し続け、従って、受信側は受信したＰＤＣＰ  ＰＤＵを廃棄し続けるという問題が発生する。
【００３９】
このような問題は、現在ＰＤＣＰにはＨＦＮ非同期化を検出する機能がないことに起因する。従って、一度ＨＦＮ非同期化が発生すると、これを復旧することができず、その後に受信したＰＤＵには全てエラーが発生し、これらを廃棄し続けることになる。
【発明の概要】
【課題を解決するための手段】
【００４０】
そこで、本発明の目的は、受信側ＰＤＣＰが特定の条件を用いてＨＦＮ非同期化、すなわちセキュリティ失敗（ｓｅｃｕｒｉｔｙ  ｆａｉｌｕｒｅ）が発生したか否かを判断し、ＨＦＮ非同期化が発生した場合、これをＲＲＣに通知してＲＢを再設定するか、又はＰＤＣＰリセット過程を用いて送信側もしくは受信側のセキュリティ構成（ｓｅｃｕｒｉｔｙ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）をリセットすることにある。
【００４１】
上記の目的を達成するために、本発明は、（Ａ）受信した少なくとも１つのパケットからエラー発生パケットの数をカウントするステップと、（Ｂ）前記カウントしたエラー発生パケットの数と基準値とを比較するステップと、（Ｃ）前記カウントしたエラー発生パケットの数が前記基準値に達すると、セキュリティ失敗であると判断するステップとを含むことを特徴とする移動通信システムにおけるセキュリティ関連エラー検出方法を提供する。
【００４２】
前記ステップ（Ａ）は、送信側により送信された少なくとも１つのパケットを受信するステップと、前記受信したパケットのヘッダを除去するステップと、前記ヘッダが除去されたパケットに対して復号化を行うステップと、前記復号化されたパケットに対して圧縮されたヘッダの復元を行う過程、又は完全性確認過程を行うことにより、前記パケットのセキュリティ失敗のエラーを判断するステップと、前記セキュリティ失敗のエラーがあると判断されたパケットがある場合、カウンタを増加させるステップとを含むようにしてもよい。
【００４３】
前記パケットは、ユーザプレーンのデータ、又は制御プレーンのデータであってもよい。
【００４４】
前記移動通信システムにおけるセキュリティ関連エラー検出方法は、（Ｄ）前記カウントしたエラー発生パケットの数が前記基準値に達し、セキュリティ失敗であると判断されると、セキュリティ構成の復旧過程を行うステップをさらに含むようにしてもよい。
【００４５】
前記復旧過程は、ＰＤＣＰ層のリセット手順を行う過程を含むようにしてもよい。
【００４６】
前記復旧過程は、ＲＲＣ層に通知する過程を含むようにしてもよい。
【００４７】
前記ＲＲＣ層は、ＲＢを再設定するか、ＲＲＣ接続を再設定するか、又は特定のＲＢに関してセキュリティ構成をリセットするようにしてもよい。
【００４８】
前記ステップ（Ａ）は、ＰＤＣＰ層のヘッダ復元過程、又は前記ＰＤＣＰ層の完全性確認過程で行われるようにしてもよい。
【００４９】
前記基準値は、ＲＢによって異なる値であってもよい。
【００５０】
また、上記の目的を達成するために、本発明は、少なくとも１つのパケットを受信するステップと、前記受信した少なくとも１つのパケットに対して完全性確認又はヘッダ復元を行うステップと、前記完全性確認又は前記ヘッダ復元時、前記受信した少なくとも１つのパケットにエラーが発生したか否かを確認するステップと、前記受信した少なくとも１つのパケットにエラーが発生したことが確認されると、前記エラーの発生をＲＲＣ層に報告するステップと、前記ＲＲＣ層が前記エラー発生報告を受信して再設定を行うステップとを含むことを特徴とする移動通信システムにおけるセキュリティ関連エラー検出方法を提供する。
【００５１】
前記再設定は、ＲＢの再設定とＰＤＣＰ層の再設定の少なくとも一方を含むようにしてもよい。
【００５２】
前記再設定は、ＲＲＣ接続の再設定であってもよい。
【００５３】
前記完全性確認はＸＭＡＣ−Ｉを利用し、前記ヘッダ復元はコンテクストを利用するようにしてもよい。
【００５４】
前記ＰＤＣＰ層の再設定は、前記ＰＤＣＰ層のリセットであってもよい。
【００５５】
本発明は、受信側ＰＤＣＰ層でセキュリティ失敗が発生した場合にこれを効果的に検出する方法を提供することにより、さらなるデータ損失とそれによる無線リソースの浪費を防止することができる。
【図面の簡単な説明】
【００５６】
【図１】従来の移動通信システムであるＬＴＥシステムのネットワーク構造を示す図である。
【図２】３ＧＰＰ無線アクセスネットワーク規格に準拠した端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルの制御プレーンの構造を示す図である。
【図３】３ＧＰＰ無線アクセスネットワーク規格に準拠した端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルのユーザプレーンの構造を示す図である。
【図４】ＰＤＣＰ層の機能的構造を示す図である。
【図５】ＲＯＨＣにより生成されるパケットのヘッダサイズの変化を示す図である。
【図６】暗号化方法を示す図である。
【図７】完全性保護方法を示す図である。
【図８】本発明の一実施形態によってユーザプレーンのＲＢに関してセキュリティ失敗を判断する過程を示すブロック図である。
【図９】本発明の一実施形態によって制御プレーンのＲＢに関してセキュリティ失敗を判断する過程を示すブロック図である。
【発明を実施するための形態】
【００５７】
本発明は、移動通信システム、とりわけＵＭＴＳから進化したＥ−ＵＭＴＳ（Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）に適用される。しかし、本発明は、これに限定されるものではなく、本発明の技術的思想を適用できる全ての通信システム及び通信プロトコルに適用することができる。
【００５８】
本発明は、様々な変更が可能であり、様々な実施形態を有するが、特定の実施形態を図面に示して詳細な説明で詳細に説明する。しかし、これは本発明を特定の実施形態に限定するものではなく、本発明の思想及び技術範囲に含まれる全ての変更、均等物乃至代替物を含むものと理解されるべきである。
【００５９】
「第１」、「第２」などのように序数を含む用語は様々な構成要素を説明するために使用されるが、前記構成要素は前記用語により限定されるものではない。前記用語は１つの構成要素を他の構成要素と区別する目的でのみ使用される。例えば、本発明の権利範囲から外れない限り、第１構成要素は第２構成要素と命名してもよく、同様に、第２構成要素は第１構成要素と命名してもよい。「及び／又は」という用語は、複数の関連記載項目の組み合わせ又は複数の関連記載項目のいずれか１つの項目を含む。
【００６０】
ある構成要素が他の構成要素に「連結」又は「接続」されていると言及された場合は、前記他の構成要素に直接的に連結又は接続されていることもあり、中間にさらに他の構成要素が存在することもある。それに対して、ある構成要素が他の構成要素に「直接連結」又は「直接接続」されていると言及された場合は、中間にさらに他の構成要素が存在しないと理解すべきである。
【００６１】
本出願で使用された用語は、単に特定の実施形態を説明するために使用されたもので、本発明を限定するものではない。単数の表現は、文脈上明らかに他の意味を表すものでない限り、複数の表現を含む。本出願において、「含む」や「有する」などの用語は、明細書上に記載された特徴、数字、段階、動作、構成要素、部品、又はこれらの組み合わせが存在することを指定しようとするもので、１つ又はそれ以上の他の特徴、数字、段階、動作、構成要素、部品、又はこれらの組み合わせの存在や付加可能性を予め排除するものではないと理解されるべきである。
【００６２】
別途定義されない限り、技術的な用語や科学的な用語を含めてここで使用される全ての用語は、本発明の属する技術の分野における通常の知識を有する者に一般的に理解される意味と同一の意味を有する。一般的に使用される辞書に定義されているような用語は、関連技術の文脈上の意味と一致する意味を有するものと解釈されるべきであり、本出願で明らかに定義しない限り、理想的であるか又は過度に形式的な意味で解釈されるべきではない。
【００６３】
以下、添付図面を参照して本発明の好ましい実施形態を詳細に説明し、図面番号に関係なく同一又は対応する構成要素には同一の参照番号を付し、これに関する重複説明は省略する。
【００６４】
本発明で使用する用語を説明すると次の通りである。
【００６５】
セキュリティ失敗とは、送信側又は受信側のＭＡＳＫ（ユーザプレーンの場合）又はＭＡＣ−Ｉ（制御プレーンの場合）が変わり、暗号化又は完全性保護にエラーが発生し、結果的にＨＦＮ非同期化をもたらすことをいう。
【００６６】
セキュリティ構成とは、暗号化及び完全性保護をいい、ここで、暗号化はユーザプレーンのパケット（データ）に対して行われ、完全性保護は制御プレーンのパケット（データ）に対して行われる。
【００６７】
本発明は、現在ＰＤＣＰにはＨＦＮ非同期化を検出する機能がない点に着目したものである。この点に着目して、本発明は、一旦ＨＦＮ非同期化が発生すると、これを復旧することができず、その後に受信側が受信したＰＤＵの全てにエラーが発生し、受信側は受信したＰＤＵを廃棄し続けるという問題に取り組む。
【００６８】
そこで、本発明の基本概念は、１）セキュリティ失敗の判断条件を定義し、２）受信側ＰＤＣＰが特定の条件（すなわち、セキュリティ失敗の判断条件）を用いてＨＦＮ非同期化、すなわちセキュリティ失敗が発生したか否かを判断し、２）セキュリティ失敗が発生したと判断されると、これをＲＲＣに通知してＲＢ再設定又はＰＤＣＰリセット過程を行うことにより、４）送信側及び受信側のセキュリティ構成をリセットするというものである。
【００６９】
以下、本発明によるセキュリティ失敗の判断条件をより詳細に説明する。
【００７０】
セキュリティ失敗の判断条件は、該当ＲＢがユーザプレーンのＲＢであるか、制御プレーンのＲＢであるかによって異なる。
【００７１】
まず、ユーザプレーンのＲＢの場合におけるセキュリティ失敗の判断条件を説明する。
【００７２】
受信側は復号化されたデータに対してヘッダ復元を行うが、復号化が正しく行われていないと、ヘッダ復元時にＣＲＣエラーが発生してヘッダ復元に失敗する。従って、ヘッダ復元に失敗したパケットの数がＨＦＮ非同期化の根拠となる。すなわち、ＰＤＣＰは、ユーザプレーンのＲＢに関して、ヘッダ復元中にエラーが発生したパケットの数をカウントし、そのエラー発生パケットの数が基準値（又は、閾値）より大きいと、セキュリティに問題が発生したと判断し、セキュリティ失敗の復旧過程を行う。このために、受信側ＰＤＣＰは、ヘッダ復元中にエラー、例えばＣＲＣエラーが発生したパケットの数をカウントする変数（又は、カウンタ）を設け、パケットにエラーが発生する度に前記変数の値を増加させる。その後、前記変数が予め定められた基準値（閾値）に達すると、セキュリティ構成に問題が発生したと判断する。一方、前記基準値は、ＲＢ設定時に受信側ＲＲＣ（すなわち、ｅＮＢ  ＲＲＣ）が送信側ＲＲＣ（すなわち、ＵＥ  ＲＲＣ）に通知し、さらに送信側ＲＲＣ（ＵＥ  ＲＲＣ）が送信側ＰＤＣＰ（すなわち、ＵＥ  ＰＤＣＰ）に通知することもできる。また、前記基準値は、特定の値に予め定めておいてもよく、ＲＢによって異なる値を有するようにしてもよい。さらに、前記パケットのエラーをカウントする変数（又は、カウンタ）の値は、パケットにエラーが発生する度に（例えば、不連続的にエラーが発生した場合）増加させてもよく、パケットに連続的にエラーが発生した場合にのみ増加させてもよい。
【００７３】
図８は、本発明の一実施形態によって受信側ＰＤＣＰがユーザプレーンのＲＢに関してセキュリティ失敗を判断する過程を示すブロック図である。以下、ユーザプレーンのＲＢの場合におけるセキュリティ失敗を判断する過程をより詳細に説明する。
【００７４】
Ｓ２０：受信側ＰＤＣＰは、ＰＤＵ１〜ＰＤＵ２０のＰＤＣＰ  ＰＤＵを下位層、すなわちＲＬＣから受信する。
【００７５】
Ｓ２１：前記受信側ＰＤＣＰは、前記受信したＰＤＵからヘッダを除去して復号化ユニットに送信する。
【００７６】
Ｓ２２：前記受信側ＰＤＣＰの復号化ユニットは、前記ヘッダが除去されたＰＤＵに対して復号化を行う。ここで、ＰＤＵ１にセキュリティ失敗、すなわちＨＦＮ非同期化が発生した場合、ＰＤＵ１及びその後の全てのＰＤＵ（すなわち、ＰＤＵ２〜ＰＤＵ２０）において復号化が正しく行われない。
【００７７】
Ｓ２３：しかしながら、前記受信側ＰＤＣＰは、前記パケット（すなわち、ＰＤＵ１〜ＰＤＵ２０）が正しく復号化されていないことを認知できず、これらをヘッダ復元ユニットに送信する。
【００７８】
Ｓ２４：前記ヘッダ復元ユニットは、受信したパケットに対してヘッダ復元を行うが、全てにエラーが発生する。エラーの発生はヘッダのＣＲＣ値から判断することができる。
【００７９】
Ｓ２５：前記受信側ＰＤＣＰは、前記ヘッダ復元時にエラーが発生したパケットの数をカウントする。そのカウントしたエラー発生パケットの数が予め定められた基準値（すなわち、閾値、この値は例えば、２０）に達すると（すなわち、より大きくなると）、前記受信側ＰＤＣＰは、セキュリティ構成にエラーが発生したと判断する。
【００８０】
つまり、図８の実施形態において、受信側ＰＤＣＰは、第一に、受信したパケットのヘッダ復元時にヘッダのＣＲＣ値からエラーを判断し、第二に、ヘッダ復元時にエラーが発生したパケットの数をカウントし、第三に、そのエラー発生パケットの数が基準値に達すると、セキュリティ失敗が発生したと判断する。受信側ＰＤＣＰは、セキュリティ失敗が発生したと判断すると、これを迅速に復旧してさらなるデータ損失と無線リソースの浪費を防止するために、セキュリティ失敗の復旧過程を行う。前記復旧過程は、例えば受信側ＲＲＣ層がセキュリティ失敗のエラーを端末に通知し、端末がネットワークとの接続を切断して再び最初からＲＲＣ接続を設定するようにしてもよい。あるいは、ＲＲＣ層がＲＢを再設定するか、又は端末（ＵＥ）とネットワーク間の特定のＲＢに関してセキュリティ構成を再設定するようにしてもよい。
【００８１】
次に、制御プレーンのＲＢの場合におけるセキュリティ失敗の判断条件を説明する。
【００８２】
制御プレーンのＲＢの場合、ヘッダ復元が行われず、その代わりに完全性確認が行われる。従って、ユーザプレーンのＲＢとは異なる基準でセキュリティ失敗を判断しなければならない。完全性確認時には、ＰＤＵに含まれるＭＡＣ−Ｉの値と受信側ＰＤＣＰが独自に生成したＸＭＡＣ−Ｉの値とを比較するが、これら２つの値が異なると、完全性確認に失敗したと判断し、受信側ＰＤＣＰが受信したパケットを廃棄する。従って、本発明においては、制御プレーンのＲＢに関しては、完全性確認で所定数以上のパケットにエラーが発生すると、セキュリティ失敗であると判断し、セキュリティ失敗の復旧過程を行う。このために、受信側ＰＤＣＰは、完全性確認でエラーが発生した数、すなわちＰＤＵに含まれるＭＡＣ−Ｉの値と受信側ＰＤＣＰが独自に生成したＸＭＡＣ−Ｉの値とが異なる場合の数をカウントする。つまり、受信側ＰＤＣＰは、異なる値（ＰＤＵに含まれるＭＡＣ−Ｉの値と受信側ＰＤＣＰが独自に生成したＸＭＡＣ−Ｉの値）を有する該当パケットの数をカウントする変数（カウンタ）を用いて、パケットにエラーが発生する度に前記変数の値を増加させ、前記変数が予め定められた基準値（閾値）に達すると、セキュリティ構成に問題が発生したと判断する。一方、前記基準値は、ＲＢ設定時に受信側ＲＲＣ（すなわち、ｅＮＢ  ＲＲＣ）が送信側ＲＲＣ（すなわち、ＵＥ  ＲＲＣ）に通知し、さらに送信側ＲＲＣ（ＵＥ  ＲＲＣ）が送信側ＰＤＣＰ（すなわち、ＵＥ  ＰＤＣＰ）に通知することもできる。また、前記基準値は、特定の値に予め定めておいてもよく、ＲＢによって異なる値を有するようにしてもよい。さらに、前記パケットのエラーをカウントする変数（又は、カウンタ）の値は、パケットにエラーが発生する度に（例えば、不連続的にエラーが発生した場合）増加させてもよく、パケットに連続的にエラーが発生した場合にのみ増加させてもよい。
【００８３】
図９は、本発明の一実施形態によって受信側ＰＤＣＰが制御プレーンのＲＢに関してセキュリティ失敗を判断する過程を示すブロック図である。以下、制御プレーンのＲＢの場合における受信側ＰＤＣＰがセキュリティ失敗を判断する過程をより詳細に説明する。
【００８４】
Ｓ３０：受信側ＰＤＣＰは、ＰＤＵ１〜ＰＤＵ２０のＰＤＣＰ  ＰＤＵを下位層、すなわちＲＬＣから受信する。
【００８５】
Ｓ３１：前記受信側ＰＤＣＰは、前記受信したＰＤＵからヘッダを除去して復号化ユニットに送信する。
【００８６】
Ｓ３２：前記受信側ＰＤＣＰは、前記ヘッダが除去されたＰＤＵに対して復号化を行う。ここで、ＰＤＵ１にセキュリティ失敗、すなわちＨＦＮ非同期化が発生した場合、ＰＤＵ１及びその後の全てのＰＤＵ（すなわち、ＰＤＵ２〜ＰＤＵ２０）において復号化が正しく行われない。
【００８７】
Ｓ３３：しかしながら、前記受信側ＰＤＣＰは、前記パケット（すなわち、ＰＤＵ１〜ＰＤＵ２０）が正しく復号化されていないことを認知できず、これらを完全性確認ユニットに送信する。
【００８８】
Ｓ３４：前記完全性確認ユニットは、受信したパケット（すなわち、ＰＤＵ１〜ＰＤＵ２０）に対して完全性確認を行うが、全てにエラーが発生する。エラーの発生は、前記ＰＤＵに含まれるＭＡＣ−Ｉの値と前記受信側ＰＤＣＰが独自に生成したＸＭＡＣ−Ｉの値とを比較することで判断することができる。
【００８９】
Ｓ３５：前記受信側ＰＤＣＰは、前記完全性確認時にエラーが発生したパケットの数をカウントする。そのカウントしたエラー発生パケットの数が予め定められた基準値（例えば、２０）に達すると、前記受信側ＰＤＣＰは、セキュリティ構成にエラーが発生したと判断する。
【００９０】
図９の実施形態は復号化過程でエラーが発生した場合を示す。ところが、実際には、完全性確認過程でもエラーが発生することがあるが、この場合も、その後の処理過程は前述と同様である。例えば、復号化には全て成功したが、完全性確認パラメータが誤っており、ＰＤＵ１にエラーが発生した場合、その後の全てのパケットにもエラーが発生するので、いずれの場合でも、完全性確認でエラーが発生したパケットの数をカウントして、セキュリティ失敗が発生したか否かを判断する。
【００９１】
受信側ＰＤＣＰは、セキュリティ失敗が発生したと判断すると、これを迅速に復旧してさらなるデータ損失と無線リソースの浪費を防止するために、セキュリティ失敗の復旧過程を行う。前記復旧過程は、例えば受信側ＲＲＣ層がセキュリティ失敗のエラーを端末に通知し、端末がネットワークとの接続を切断して再び最初からＲＲＣ接続を設定するようにしてもよい。あるいは、ＲＲＣ層がＲＢを再設定するか、又は端末（ＵＥ）とネットワーク間の特定のＲＢに関してセキュリティ構成を再設定するようにしてもよい。
【００９２】
以上説明した本発明による方法は、ソフトウェア、ハードウェア、又はこれらの組み合わせで実現することができる。例えば、本発明による方法は、記憶媒体（例えば、移動端末機の内部メモリ、フラッシュメモリ、ハードディスクなど）に保存することができ、プロセッサ（例えば、移動端末機内部のマイクロプロセッサ）により実行されるソフトウェアプログラム内にコード又はコマンドで実現することができる。
【００９３】
前述した本発明が様々な面で変形可能であることは明らかである。その変形は本発明の範囲から外れるものとみなされず、当該技術分野における通常の知識を有する者に明らかな全ての変形が添付の請求の範囲に含まれる。
【図２】
2010533415.tif 000003
【図３】
2010533415.tif 000004
【図１】
2010533415.tif 000005
【図４】
2010533415.tif 000006
【図５】
2010533415.tif 000007
【図６】
2010533415.tif 000008
【図７】
2010533415.tif 000009
【図８】
2010533415.tif 000010
【図９】
2010533415.tif 000011
【手続補正書】
【提出日】平成22年1月12日(2010.1.12)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システムのＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）層で使用されるセキュリティアルゴリズムにおいてセキュリティエラーを検出する方法及び装置に関する。
【背景技術】
【０００２】
図１は、従来の移動通信システムであるＬＴＥシステムのネットワーク構造を示す図である。ＬＴＥシステムは、既存のＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）システムから進化したシステムであり、３ＧＰＰで基礎的な標準化作業を行っている。
【０００３】
ＬＴＥネットワークは、大きくＥ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ  ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）とＣＮ（Ｃｏｒｅ  Ｎｅｔｗｏｒｋ）とに区分される。Ｅ−ＵＭＴＳは、端末（又は、Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ；  ＵＥ）と、基地局（Ｅｖｏｌｖｅｄ  ＮｏｄｅＢ；  ｅＮＢ）と、ネットワークのエンドに位置して外部ネットワークに接続するアクセスゲートウェイ（Ａｃｃｅｓｓ  Ｇａｔｅｗａｙ；  ａＧＷ）とから構成される。ａＧＷは、ユーザトラフィック処理を担当する部分と制御トラフィック処理を担当する部分とに分けられる。この場合、新しいユーザトラフィック処理のためのａＧＷと制御トラフィック処理のためのａＧＷ間では、新しいインタフェースを使用して通信することもできる。１つのｅＮＢには１つ以上のセルが存在する。ｅＮＢ間ではユーザトラフィック又は制御トラフィックの送信のためのインタフェースを使用することもできる。ＣＮは、ａＧＷとその他のＵＥのユーザ登録などのためのノードなどとから構成することもできる。Ｅ−ＵＴＲＡＮとＣＮとを区分するためのインタフェースを使用することもできる。
【０００４】
図２は、３ＧＰＰ無線アクセスネットワーク規格に準拠したＵＥとＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルの制御プレーン（Ｃ−ｐｌａｎｅ）の構造を示す図である。図３は、３ＧＰＰ無線アクセスネットワーク規格に準拠したＵＥとＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルのユーザプレーン（Ｕ−ｐｌａｎｅ）の構造を示す図である。
【０００５】
以下、図２及び図３を参照して、ＵＥとＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルの構造を説明する。
【０００６】
無線インタフェースプロトコルは、水平的には、物理層、データリンク層、及びネットワーク層からなり、垂直的には、データ情報の送信のためのユーザプレーン、及び制御信号の送信のための制御プレーンからなる。図２及び図３のプロトコル層は、通信システムでよく知られている開放型システム間相互接続（Ｏｐｅｎ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ；  ＯＳＩ）参照モデルの下位３層に基づいて、Ｌ１（第１層）、Ｌ２（第２層）、Ｌ３（第３層）に区分される。このような無線プロトコル層は、ＵＥとＥ−ＵＴＲＡＮに対で存在し、無線区間のデータ送信を担当する。
【０００７】
以下、図２の無線プロトコルの制御プレーン及び図３の無線プロトコルのユーザプレーンの各層を説明する。
【０００８】
第１層である物理（Ｐｈｙｓｉｃａｌ；  ＰＨＹ）層は、物理チャネルを利用して上位層に情報送信サービス（Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｒａｎｓｆｅｒ  Ｓｅｒｖｉｃｅ）を提供する。ＰＨＹ層は、上位の媒体アクセス制御（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ；  ＭＡＣ）層とトランスポートチャネルを介して接続されており、このトランスポートチャネルを介してＭＡＣ層とＰＨＹ層間のデータの移動が行われる。ここで、トランスポートチャネルは、チャネルが共有されるか否かによって、大きく専用トランスポートチャネルと共通トランスポートチャネルとに分けられる。また、異なるＰＨＹ層間、すなわち送信側ＰＨＹ層と受信側ＰＨＹ層間では、無線リソースを利用した物理チャネルを介してデータの移動が行われる。
【０００９】
第２層には様々な層が存在する。まず、ＭＡＣ層は、様々な論理チャネルを様々なトランスポートチャネルにマッピングする役割を果たし、様々な論理チャネルを１つのトランスポートチャネルにマッピングする論理チャネル多重化の役割も果たす。ＭＡＣ層は、上位層であるＲＬＣ層と論理チャネルを介して接続されており、この論理チャネルは、送信される情報の種類によって、大きく制御プレーンの情報を送信する制御チャネルとユーザプレーンの情報を送信するトラフィックチャネルとに分けられる。
【００１０】
第２層のＲＬＣ層は、上位層から受信したデータを分割（ｓｅｇｍｅｎｔ）及び連結（ｃｏｎｃａｔｅｎａｔｅ）して、下位層における無線区間のデータ送信に適するようにデータサイズを調節する役割を果たす。また、各無線ベアラ（Ｒａｄｉｏ  Ｂｅａｒｅｒ；  ＲＢ）が要求する様々なＱｏＳを保証するために、透過モード（Ｔｒａｎｓｐａｒｅｎｔ  Ｍｏｄｅ；  ＴＭ）、非応答モード（Ｕｎ−ａｃｋｎｏｗｌｅｄｇｅｄ  Ｍｏｄｅ；  ＵＭ）、及び応答モード（Ａｃｋｎｏｗｌｅｄｇｅｄ  Ｍｏｄｅ；  ＡＭ）の３つの動作モードを提供する。特に、ＡＭモードで動作するＲＬＣ層（以下、ＡＭ  ＲＬＣ層という）は、信頼性のあるデータ送信のために、自動再送要求（Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  Ｒｅｑｕｅｓｔ；  ＡＲＱ）機能を利用した再送機能を実行する。
【００１１】
第２層のＰＤＣＰ層は、ＩＰｖ４（ＩＰ  ｖｅｒｓｉｏｎ  ４）やＩＰｖ６（ＩＰ  ｖｅｒｓｉｏｎ  ６）などのＩＰパケットを狭帯域幅の無線区間で効率的に送信するために、相対的にサイズが大きくて不要な制御情報を含むＩＰパケットのヘッダサイズを小さくするヘッダ圧縮機能を実行する。これは、データのヘッダ部分で必ず必要な情報のみを送信させることにより、無線区間の送信効率を向上させる役割を果たす。
【００１２】
第３層の最下上位に位置するＲＲＣ層は、制御プレーンでのみ定義され、無線ベアラ（ＲＢ）の設定、再設定、及び解除に関連して論理チャネル、トランスポートチャネル、及び物理チャネルの制御を担当する。ここで、ＲＢとは、ＵＥとＵＴＲＡＮ間のデータ送信のために無線プロトコルの第１層及び第２層により提供される論理パスを意味し、一般に、ＲＢの構成とは、特定のサービスを提供するために必要な無線プロトコル層及びチャネルの特性を規定し、それぞれの具体的なパラメータ及び動作方法を設定する過程を意味する。
【００１３】
以下、ＰＤＣＰ層について具体的に説明する。ＰＤＣＰ層は、上位にはＲＲＣ層又はユーザアプリケーションと接続され、下位にはＲＬＣ層と接続されている。図４において、左側は送信側ＰＤＣＰエンティティの機能的構造を示し、右側は受信側ＰＤＣＰエンティティの機能的構造を示す。左の送信側構造は、ＰＤＣＰ層が上位エンティティからＰＤＣＰ  ＳＤＵを受信した場合に前記ＰＤＣＰ  ＳＤＵに適用する動作を示し、右の受信側構造は、ＰＤＣＰ層が下位エンティティからＰＤＣＰ  ＰＤＵを受信した場合に前記ＰＤＣＰ  ＰＤＵに適用する動作を示す。
【００１４】
ＰＤＣＰはユーザプレーンと制御プレーンの両方に使用されるが、ＰＤＣＰの一部機能は使用されるプレーンに応じて選択的に適用される。すなわち、図４に示すように、ヘッダ圧縮機能はユーザプレーンのデータにのみ適用され、完全性保護（ｉｎｔｅｇｒｉｔｙ  ｐｒｏｔｅｃｔｉｏｎ）機能は制御プレーンのデータにのみ適用される。
【００１５】
以下、図４の左の送信側ＰＤＣＰエンティティにより行われるデータ処理過程を説明する。
【００１６】
Ｓ１：ＰＤＣＰ層は、受信したＰＤＣＰ  ＳＤＵにシーケンス番号を割り当てる。
【００１７】
Ｓ２：設定されたＲＢがユーザプレーンのＲＢである場合、前記ＰＤＣＰ層は、前記ＰＤＣＰ  ＳＤＵに対してヘッダ圧縮を行う。
【００１８】
Ｓ３：前記設定されたＲＢが制御プレーンのＲＢである場合、前記ＰＤＣＰ層は、前記ＰＤＣＰ  ＳＤＵに対して完全性保護動作を行う。
【００１９】
Ｓ４：前記ＰＤＣＰ層は、ステップＳ２又はステップＳ３の結果として生成されたデータブロックに対して暗号化（ｃｉｐｈｅｒｉｎｇ）を行う。
【００２０】
Ｓ５：前記ＰＤＣＰ層は、前記暗号化されたデータブロックに適切なヘッダを付加してＰＤＣＰ  ＰＤＵを構成し、前記構成されたＰＤＣＰ  ＰＤＵをＲＬＣ層に送信する。
【００２１】
以下、図４の右の受信側ＰＤＣＰエンティティにより行われるデータ処理過程を説明する。
【００２２】
Ｓ６：前記ＰＤＣＰ層は、受信した前記ＰＤＣＰ  ＰＤＵのヘッダを除去する。
【００２３】
Ｓ７：前記ＰＤＣＰ層は、前記ヘッダが除去されたＰＤＣＰ  ＰＤＵに対して復号化（ｄｅｃｉｐｈｅｒｉｎｇ）を行う。
【００２４】
Ｓ８：前記設定されたＲＢが制御プレーンのＲＢである場合、前記ＰＤＣＰ層は、前記復号化されたＰＤＣＰ  ＰＤＵに対して完全性確認（ｉｎｔｅｇｒｉｔｙ  ｖｅｒｉｆｉｃａｔｉｏｎ）動作を行う。
【００２５】
Ｓ９：前記設定されたＲＢがユーザプレーンのＲＢである場合、前記ＰＤＣＰ層は、前記復号化されたＰＤＣＰ  ＰＤＵに対してヘッダ復元（ｈｅａｄｅｒ  ｄｅｃｏｍｐｒｅｓｓｉｏｎ）を行う。
【００２６】
Ｓ１０：前記ＰＤＣＰ層は、ステップＳ８又はステップＳ９により受信したデータブロック、すなわちＰＤＣＰ  ＳＤＵを上位層に送信する。前記設定されたＲＢがユーザプレーンのＲＢである場合、前記ＰＤＣＰ層は、必要に応じて、並び替え（ｒｅｏｒｄｅｒｉｎｇ）を行った後に前記ＰＤＣＰ  ＳＤＵを上位層に送信する。
【００２７】
以下、前記ＰＤＣＰ層により行われるヘッダ圧縮について説明する。ヘッダ圧縮は、同一のパケットストリームに属するＩＰパケットのＩＰヘッダはほとんどの部分が変わらないという事実に基づいてヘッダのサイズを小さくするもので、変わらないフィールドは前記送信側の圧縮機（ｃｏｍｐｒｅｓｓｏｒ）と前記受信側の復元機（ｄｅｃｏｍｐｒｅｓｓｏｒ）にコンテクストの形態で保存しておき、コンテクストが形成された後は、変わるフィールドのみを送信することにより、ＩＰヘッダのオーバーヘッドを減らす。ヘッダ圧縮の初期段階では、前記復元機に該当パケットストリームに関するコンテクストを形成するために、前記圧縮機はフルヘッダ（ｆｕｌｌ  ｈｅａｄｅｒ）パケットを送信するため、ヘッダ圧縮による利得がないが、前記復元機にコンテクストが形成された後は、前記圧縮機は圧縮ヘッダパケットのみを送信するため、その利得が大きくなる。
【００２８】
ＬＴＥシステムで用いられる代表的なヘッダ圧縮方式であるＲＯＨＣ（Ｒｏｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）は、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）／ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）などのリアルタイムパケットのヘッダ情報を減らすのに用いられる。ここで、ＲＴＰ／ＵＤＰ／ＩＰパケットとは、上位層からのデータがＲＴＰ、ＵＤＰ、及びＩＰにより関連ヘッダが付加されたパケットを意味し、データがインターネットを介して送信先に送信されて復旧されるのに必要な様々なヘッダ情報を含む。一般に、ＲＴＰ／ＵＤＰ／ＩＰパケットのヘッダサイズは、ＩＰｖ４の場合は４０ｂｙｔｅであり、ＩＰｖ６の場合は６０ｂｙｔｅであるが、ＲＯＨＣを用いてヘッダを圧縮した場合、ヘッダが４０ｂｙｔｅ又は６０ｂｙｔｅから１〜３ｂｙｔｅに減るので、その利得は大きい。
【００２９】
図５は、ＲＯＨＣにより生成されるパケットのヘッダサイズの変化を示す図である。特に、図５は、一般的なＲＴＰ／ＵＤＰ／ＩＰパケットのヘッダサイズの変化、並びにＲＯＨＣの適用によるヘッダサイズの変化を示す。パケットストリームを最初に送信する際は、前記送信側の圧縮機と前記受信側の復元機のどちらにもコンテクストが形成されていないため、コンテクストの形成のためにフルヘッダを送信する。ある程度のフルヘッダが送信されるとコンテクストが形成され、従って、その後は圧縮ヘッダを送信することができる。ところが、途中でパケット損失などの理由でコンテクストが損傷することがあるため、適切な間隔でフルヘッダを送信する必要もある。一般に、フルヘッダは、コンテクストを形成する追加情報を含むため、通常のヘッダ（ｎｏｒｍａｌ  ｈｅａｄｅｒ）より若干大きい。
【００３０】
次に、前記ＰＤＣＰ層により行われるセキュリティ機能について説明する。前述のように、セキュリティには暗号化と完全性保護の２つの機能があるが、どちらの機能もパケット毎に変わるコードを生成し、これを利用して元のデータの暗号化又は完全性検査を行う。
【００３１】
前記パケット毎に変わるコードは、各ＰＤＣＰ  ＰＤＵのヘッダに追加されるＰＤＣＰ  ＳＮ（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）を用いて生成するが、そのコード生成因子の１つがＣＯＵＮＴである。前記ＣＯＵＮＴは、３２ｂｉｔの長さを有し、この中で、下位ビット（Ｌｅａｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔ；  ＬＳＢ）はＰＤＣＰ  ＳＮから構成され、残りの上位ビット（Ｍｏｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔ；  ＭＳＢ）はＨＦＮ（Ｈｙｐｅｒ  Ｆｒａｍｅ  Ｎｕｍｂｅｒ）から構成される。ＰＤＣＰ  ＳＮの長さは、５、７、又は１２ｂｉｔであって、ＲＢ毎に異なるため、ＨＦＮの長さも異なり、それぞれ２７、２５、又は２０ｂｉｔである。
【００３２】
暗号化は図６に示すような方法で行う。送信側は、元のデータに対してパケット毎に変わるコード、すなわちＭＡＳＫをかけることにより、暗号化されたデータを生成する。ここで、ＭＡＳＫをかけるとは、元のデータとＭＡＳＫに対してビット別のＸＯＲ演算を行うことを意味する。このようにして暗号化されたデータを受信した受信側は、前記暗号化されたデータに再びＭＡＳＫをかけて復号化する。ここで、ＭＡＳＫは、３２ｂｉｔであり、様々な入力因子から生成されるが、特に、パケット毎に異なる値を生成するために、ＰＤＣＰ  ＰＤＵ毎に変わるＰＤＣＰ  ＳＮを用いてＣＯＵＮＴを生成し、その生成したＣＯＵＮＴをＭＡＳＫ生成入力因子の１つとして使用する。ＭＡＳＫ生成入力因子は、ＣＯＵＮＴの他に、該当ＲＢのＩＤ値である「Ｂｅａｒｅｒ」、上り又は下りの値を有する「Ｄｉｒｅｃｔｉｏｎ」、ＲＢ設定時に端末とネットワークにより交換される「ＣＫ（Ｃｉｐｈｅｒｉｎｇ  Ｋｅｙ）」などがある。
【００３３】
また、完全性保護は図７に示すような方法で行う。完全性保護過程においては、暗号化過程と同様に、ＰＤＣＰ  ＳＮを用いた「ＣＯＵＮＴ」、ＲＢのＩＤ値である「Ｂｅａｒｅｒ」、上り又は下りの値を有する「Ｄｉｒｅｃｔｉｏｎ」、ＲＢ設定時に端末とネットワークにより交換される「ＩＫ（Ｉｎｔｅｇｒｉｔｙ  Ｐｒｏｔｅｃｔｉｏｎ  Ｋｅｙ）」などを利用して、コード、すなわち「ＭＡＣ−Ｉ（Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ−Ｉｎｔｅｇｒｉｔｙ）」を生成する。ここで、図６の暗号化過程と異なる点は、生成された「ＭＡＣ−Ｉ」を元のデータとＸＯＲ演算するのではなく、図７に示すように、生成された「ＭＡＣ−Ｉ」をＰＤＣＰ  ＰＤＵに付加することである。受信側は、前記「ＭＡＣ−Ｉ」が付加されたＰＤＣＰ  ＰＤＵを受信すると、送信側で使用したのと同じ入力因子を用いてＸＭＡＣ−Ｉを生成し、前記ＸＭＡＣ−Ｉと前記ＰＤＣＰ  ＰＤＵに付加されているＭＡＣ−Ｉとを比較する。２つの値（すなわち、ＸＭＡＣ−Ｉの値とＰＤＣＰ  ＰＤＵに付加されているＭＡＣ−Ｉの値）が同一であればデータが完全であると判断し、２つの値が異なればデータが途中で変わったと判断する。
【００３４】
何らかの理由で送信側及び受信側のＭＡＳＫ又はＭＡＣ−Ｉが変わり、暗号化又は完全性保護にエラーが発生することがある。ＭＡＳＫ又はＭＡＣ−Ｉが変わる最も大きな理由としては、ＣＯＵＮＴのＭＳＢであるＨＦＮの変化が挙げられるが、これは多数のＰＤＣＰ  ＳＤＵが損失した場合に発生する。その理由は、ＣＯＵＮＴのＭＳＢはＨＦＮであり、ＣＯＵＮＴのＬＳＢはＰＤＣＰ  ＳＮであるが、ＰＤＣＰ  ＳＮが最大値に達すると、これは再び０に戻り、ＭＳＢであるＨＦＮは１増加するからである。つまり、ＰＤＣＰ  ＳＮスペースがラップアラウンドする程度にＰＤＣＰ  ＳＤＵが損失すると、ＨＦＮの非同期化（ｄｅ−ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）が発生する。他の理由として、下位層でＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｏｄｅ）検査によっても発見できないエラーが発生することがあるが、その場合、ＰＤＣＰ  ＳＮ値が有効範囲から外れるとＨＦＮ非同期化が発生することがある。
【００３５】
このようにＨＦＮ非同期化が発生すると、セキュリティに失敗する。従って、受信側がデータを受信しても元のデータを復元できないため、受信側は受信したデータを廃棄し続けるという問題が発生する。
【００３６】
このような問題の発生について、ユーザプレーンのＲＢの場合と制御プレーンのＲＢの場合とに分けて説明する。
【００３７】
第一に、ユーザプレーンのＲＢの場合は、受信したＰＤＣＰ  ＰＤＵを復号化した後にヘッダ復元を行うが、このとき誤ったＭＡＳＫで復号化すると、ヘッダ復元過程でエラーが発生し続け、従って、受信側は受信したＰＤＣＰ  ＰＤＵを廃棄し続けるという問題が発生する。
【００３８】
第二に、制御プレーンのＲＢの場合は、受信したＰＤＣＰ  ＰＤＵを復号化した後に完全性確認を行うが、このとき誤ったＭＡＳＫで復号化するか、又は誤ったＸＭＡＣ−Ｉと比較すると、完全性確認過程でエラーが発生し続け、従って、受信側は受信したＰＤＣＰ  ＰＤＵを廃棄し続けるという問題が発生する。
【００３９】
このような問題は、現在ＰＤＣＰにはＨＦＮ非同期化を検出する機能がないことに起因する。従って、一度ＨＦＮ非同期化が発生すると、これを復旧することができず、その後に受信したＰＤＵには全てエラーが発生し、これらを廃棄し続けることになる。
【発明の概要】
【課題を解決するための手段】
【００４０】
そこで、本発明の目的は、受信側ＰＤＣＰが特定の条件を用いてＨＦＮ非同期化、すなわちセキュリティ失敗（ｓｅｃｕｒｉｔｙ  ｆａｉｌｕｒｅ）が発生したか否かを判断し、ＨＦＮ非同期化が発生した場合、これをＲＲＣに通知してＲＢを再設定するか、又はＰＤＣＰリセット過程を用いて送信側もしくは受信側のセキュリティ構成（ｓｅｃｕｒｉｔｙ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）をリセットすることにある。
【００４１】
上記の目的を達成するために、本発明は、（Ａ）受信した少なくとも１つのパケットからエラー発生パケットの数をカウントするステップと、（Ｂ）前記カウントしたエラー発生パケットの数と基準値とを比較するステップと、（Ｃ）前記カウントしたエラー発生パケットの数が前記基準値に達すると、セキュリティ失敗であると判断するステップとを含むことを特徴とする移動通信システムにおけるセキュリティ関連エラー検出方法を提供する。
【００４２】
前記ステップ（Ａ）は、送信側により送信された少なくとも１つのパケットを受信するステップと、前記受信した少なくとも１つのパケットのヘッダを除去するステップと、前記ヘッダが除去された少なくとも１つのパケットを復号化するステップと、圧縮されたヘッダを復号する過程、又は前記少なくとも１つの復号されたパケットに対して完全性確認過程を行うことにより、前記受信した少なくとも１つのパケットのセキュリティ失敗のエラーを判断するステップと、前記セキュリティ失敗エラーであると判断されたパケットがある場合、カウント値を増加させるステップとを含むようにしてもよい。
【００４３】
前記少なくとも１つのパケットは、ユーザプレーンのデータ、又は制御プレーンのデータであってもよい。
【００４４】
前記移動通信システムにおけるセキュリティ関連エラー検出方法は、（Ｄ）前記カウントしたエラーパケットの数が前記基準値に達し、セキュリティ失敗であると判断されると、セキュリティ構成の復旧過程を行うステップをさらに含むようにしてもよい。
【００４５】
前記復旧過程は、ＰＤＣＰ層のリセット手順を行う過程を含むようにしてもよい。
【００４６】
前記復旧過程は、ＲＲＣ層に通知する過程を含むようにしてもよい。
【００４７】
前記ＲＲＣ層は、ＲＢを再設定するか、ＲＲＣ接続を再設定するか、又は特定のＲＢに関してセキュリティ構成をリセットするようにしてもよい。
【００４８】
前記ステップ（Ａ）は、ＰＤＣＰ層のヘッダ復元過程、又は前記ＰＤＣＰ層の完全性確認過程で行われるようにしてもよい。
【００４９】
前記基準値は、ＲＢによって異なる値であってもよい。
【００５０】
また、上記の目的を達成するために、本発明は、少なくとも１つのパケットを受信するステップと、前記受信した少なくとも１つのパケットに対して完全性確認又はヘッダ復元を行うステップと、前記完全性確認又は前記ヘッダ復元中に、前記受信した少なくとも１つのパケットにエラーが発生したか否かを確認するステップと、前記受信した少なくとも１つのパケットにエラーが発生したことが確認されると、前記確認されたエラーをＲＲＣ層に報告するステップと、前記ＲＲＣ層が前記確認されたエラー報告を受信して再設定を行うステップとを含むことを特徴とする移動通信システムにおけるセキュリティ関連エラー検出方法を提供する。
【００５１】
前記再設定は、ＲＢの再設定とＰＤＣＰ層の再設定の少なくとも一方を含むようにしてもよい。
【００５２】
前記再設定は、ＲＲＣ接続の再設定であってもよい。
【００５３】
前記完全性確認はＸＭＡＣ−Ｉを利用し、前記ヘッダ復元はコンテクストを利用するようにしてもよい。
【００５４】
前記ＰＤＣＰ層の再設定は、前記ＰＤＣＰ層のリセットであってもよい。
【００５５】
本発明は、受信側ＰＤＣＰ層でセキュリティ失敗が発生した場合にこれを効果的に検出する方法を提供することにより、さらなるデータ損失とそれによる無線リソースの浪費を防止することができる。
（項目１）
（Ａ）受信した少なくとも１つのパケットからエラー発生パケットの数をカウントするステップと、
（Ｂ）前記カウントしたエラー発生パケットの数と基準値とを比較するステップと、
（Ｃ）前記カウントしたエラー発生パケットの数が前記基準値に達すると、セキュリティ失敗であると判断するステップと
を含むことを特徴とする移動通信システムにおけるセキュリティ関連エラー検出方法。
（項目２）
前記ステップ（Ａ）は、
送信側により送信された少なくとも１つのパケットを受信するステップと、
前記受信したパケットのヘッダを除去するステップと、
前記ヘッダが除去されたパケットに対して復号化を行うステップと、
前記復号化されたパケットに対して圧縮されたヘッダの復元を行う過程、又は完全性確認過程を行うことにより、前記パケットのセキュリティ失敗のエラーを判断するステップと、
前記セキュリティ失敗のエラーがあると判断されたパケットがある場合、カウンタを増加させるステップと
を含むことを特徴とする項目１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
（項目３）
前記パケットが、ユーザプレーンのデータ、又は制御プレーンのデータであることを特徴とする項目１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
（項目４）
（Ｄ）前記カウントしたエラー発生パケットの数が前記基準値に達し、セキュリティ失敗であると判断されると、セキュリティ構成の復旧過程を行うステップをさらに含むことを特徴とする項目１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
（項目５）
前記復旧過程が、ＰＤＣＰ層のリセット手順を行う過程を含むことを特徴とする項目４に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
（項目６）
前記復旧過程が、ＲＲＣ層に通知する過程を含むことを特徴とする項目４に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
（項目７）
前記ＲＲＣ層が、ＲＢを再設定するか、ＲＲＣ接続を再設定するか、又は特定のＲＢに関してセキュリティ構成をリセットすることを特徴とする項目６に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
（項目８）
前記エラー発生パケットが連続していることを特徴とする項目１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
（項目９）
前記ステップ（Ａ）が、ＰＤＣＰ層のヘッダ復元過程、又は前記ＰＤＣＰ層の完全性確認過程で行われることを特徴とする項目１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
（項目１０）
前記基準値がＲＢによって異なる値であることを特徴とする項目１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
（項目１１）
少なくとも１つのパケットを受信するステップと、
前記受信した少なくとも１つのパケットに対して完全性確認又はヘッダ復元を行うステップと、
前記完全性確認又は前記ヘッダ復元時、前記受信した少なくとも１つのパケットにエラーが発生したか否かを確認するステップと、
前記受信した少なくとも１つのパケットにエラーが発生したことが確認されると、前記エラーの発生をＲＲＣ層に報告するステップと、
前記ＲＲＣ層が前記エラー発生報告を受信して再設定を行うステップと
を含むことを特徴とする移動通信システムにおけるセキュリティ関連エラー検出方法。
（項目１２）
前記再設定が、ＲＢの再設定とＰＤＣＰ層の再設定の少なくとも一方を含むことを特徴とする項目１１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
（項目１３）
前記再設定が、ＲＲＣ接続の再設定であることを特徴とする項目１１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
（項目１４）
前記完全性確認はＸＭＡＣ−Ｉを利用し、前記ヘッダ復元はコンテクストを利用することを特徴とする項目１１に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
（項目１５）
前記ＰＤＣＰ層の再設定が、前記ＰＤＣＰ層のリセットであることを特徴とする項目１２に記載の移動通信システムにおけるセキュリティ関連エラー検出方法。
【図面の簡単な説明】
【００５６】
【図１】従来の移動通信システムであるＬＴＥシステムのネットワーク構造を示す図である。
【図２】３ＧＰＰ無線アクセスネットワーク規格に準拠した端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルの制御プレーンの構造を示す図である。
【図３】３ＧＰＰ無線アクセスネットワーク規格に準拠した端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルのユーザプレーンの構造を示す図である。
【図４】ＰＤＣＰ層の機能的構造を示す図である。
【図５】ＲＯＨＣにより生成されるパケットのヘッダサイズの変化を示す図である。
【図６】暗号化方法を示す図である。
【図７】完全性保護方法を示す図である。
【図８】本発明の一実施形態によってユーザプレーンのＲＢに関してセキュリティ失敗を判断する過程を示すブロック図である。
【図９】本発明の一実施形態によって制御プレーンのＲＢに関してセキュリティ失敗を判断する過程を示すブロック図である。
【発明を実施するための形態】
【００５７】
本発明は、移動通信システム、とりわけＵＭＴＳから進化したＥ−ＵＭＴＳ（Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）に適用される。しかし、本発明は、これに限定されるものではなく、本発明の技術的思想を適用できる全ての通信システム及び通信プロトコルに適用することができる。
【００５８】
本発明は、様々な変更が可能であり、様々な実施形態を有するが、特定の実施形態を図面に示して詳細な説明で詳細に説明する。しかし、これは本発明を特定の実施形態に限定するものではなく、本発明の思想及び技術範囲に含まれる全ての変更、均等物乃至代替物を含むものと理解されるべきである。
【００５９】
「第１」、「第２」などのように序数を含む用語は様々な構成要素を説明するために使用されるが、前記構成要素は前記用語により限定されるものではない。前記用語は１つの構成要素を他の構成要素と区別する目的でのみ使用される。例えば、本発明の権利範囲から外れない限り、第１構成要素は第２構成要素と命名してもよく、同様に、第２構成要素は第１構成要素と命名してもよい。「及び／又は」という用語は、複数の関連記載項目の組み合わせ又は複数の関連記載項目のいずれか１つの項目を含む。
【００６０】
ある構成要素が他の構成要素に「連結」又は「接続」されていると言及された場合は、前記他の構成要素に直接的に連結又は接続されていることもあり、中間にさらに他の構成要素が存在することもある。それに対して、ある構成要素が他の構成要素に「直接連結」又は「直接接続」されていると言及された場合は、中間にさらに他の構成要素が存在しないと理解すべきである。
【００６１】
本出願で使用された用語は、単に特定の実施形態を説明するために使用されたもので、本発明を限定するものではない。単数の表現は、文脈上明らかに他の意味を表すものでない限り、複数の表現を含む。本出願において、「含む」や「有する」などの用語は、明細書上に記載された特徴、数字、段階、動作、構成要素、部品、又はこれらの組み合わせが存在することを指定しようとするもので、１つ又はそれ以上の他の特徴、数字、段階、動作、構成要素、部品、又はこれらの組み合わせの存在や付加可能性を予め排除するものではないと理解されるべきである。
【００６２】
別途定義されない限り、技術的な用語や科学的な用語を含めてここで使用される全ての用語は、本発明の属する技術の分野における通常の知識を有する者に一般的に理解される意味と同一の意味を有する。一般的に使用される辞書に定義されているような用語は、関連技術の文脈上の意味と一致する意味を有するものと解釈されるべきであり、本出願で明らかに定義しない限り、理想的であるか又は過度に形式的な意味で解釈されるべきではない。
【００６３】
以下、添付図面を参照して本発明の好ましい実施形態を詳細に説明し、図面番号に関係なく同一又は対応する構成要素には同一の参照番号を付し、これに関する重複説明は省略する。
【００６４】
本発明で使用する用語を説明すると次の通りである。
【００６５】
セキュリティ失敗とは、送信側又は受信側のＭＡＳＫ（ユーザプレーンの場合）又はＭＡＣ−Ｉ（制御プレーンの場合）が変わり、暗号化又は完全性保護にエラーが発生し、結果的にＨＦＮ非同期化をもたらすことをいう。
【００６６】
セキュリティ構成とは、暗号化及び完全性保護をいい、ここで、暗号化はユーザプレーンのパケット（データ）に対して行われ、完全性保護は制御プレーンのパケット（データ）に対して行われる。
【００６７】
本発明は、現在ＰＤＣＰ層にはＨＦＮ非同期化を検出する機能がない点に着目したものである。この点に着目して、本発明は、一旦ＨＦＮ非同期化が発生すると、これを復旧することができず、その後に受信側が受信したＰＤＵの全てにエラーが発生し、受信側は受信したＰＤＵを廃棄し続けるという問題に取り組む。
【００６８】
そこで、本発明の基本概念は、１）セキュリティ失敗の判断条件を定義し、２）受信側ＰＤＣＰエンティティが特定の条件（すなわち、セキュリティ失敗の判断条件）を用いてＨＦＮ非同期化、すなわちセキュリティ失敗が発生したか否かを判断し、３）セキュリティ失敗が発生したと判断されると、前記受信側ＰＤＣＰエンティティがこれをＲＲＣに通知してＲＢ再設定又はＰＤＣＰリセット過程を行うことにより、４）送信側及び受信側のセキュリティ構成をリセットするというものである。
【００６９】
以下、本発明によるセキュリティ失敗の判断条件をより詳細に説明する。
【００７０】
セキュリティ失敗の判断条件は、該当ＲＢがユーザプレーンのＲＢであるか、制御プレーンのＲＢであるかによって異なる。
【００７１】
まず、ユーザプレーンのＲＢの場合におけるセキュリティ失敗の判断条件を説明する。
【００７２】
受信側は復号化されたデータに対してヘッダ復元を行うが、復号化が正しく行われていないと、ヘッダ復元時にＣＲＣエラーが発生してヘッダ復元に失敗する。従って、ヘッダ復元に失敗したパケットの数がＨＦＮ非同期化の根拠となる。すなわち、ＰＤＣＰ層は、ユーザプレーンのＲＢに関して、ヘッダ復元中にエラーが発生したパケットの数をカウントし、そのエラー発生パケットの数が基準値（又は、閾値）より大きいと、セキュリティに問題が発生したと判断し、セキュリティ失敗の復旧過程を行う。このために、受信側ＰＤＣＰ層は、ヘッダ復元中にエラー、例えばＣＲＣエラーが発生したパケットの数をカウントする変数（又は、カウンタ）を設け、パケットにエラーが発生する度に前記変数の値を増加させる。その後、前記変数が予め定められた基準値（閾値）に達すると、セキュリティ構成に問題が発生したと判断する。一方、前記基準値は、ＲＢ設定時に受信側ＲＲＣ層（すなわち、ｅＮＢ  ＲＲＣ層）が送信側ＲＲＣ層（すなわち、ＵＥ  ＲＲＣ層）に通知し、さらに送信側ＲＲＣ層（ＵＥ  ＲＲＣ層）が送信側ＰＤＣＰ層（すなわち、ＵＥ  ＰＤＣＰ層）に通知することもできる。また、前記基準値は、特定の値に予め定めておいてもよく、ＲＢによって異なる値を有するようにしてもよい。さらに、前記パケットのエラーをカウントする変数（又は、カウンタ）の値は、パケットにエラーが発生する度に（例えば、不連続的にエラーが発生した場合）増加させてもよく、パケットに連続的にエラーが発生した場合にのみ増加させてもよい。
【００７３】
図８は、本発明の一実施形態によって受信側ＰＤＣＰエンティティがユーザプレーンのＲＢに関してセキュリティ失敗を判断する過程を示すブロック図である。以下、ユーザプレーンのＲＢの場合におけるセキュリティ失敗を判断する過程をより詳細に説明する。
【００７４】
Ｓ２０：受信側ＰＤＣＰエンティティは、ＰＤＵ１〜ＰＤＵ２０のＰＤＣＰ  ＰＤＵを下位層、すなわちＲＬＣから受信する。
【００７５】
Ｓ２１：前記受信側ＰＤＣＰエンティティは、前記受信したＰＤＵからヘッダを除去して復号化ユニットに送信する。
【００７６】
Ｓ２２：前記受信側ＰＤＣＰエンティティの復号化ユニットは、前記ヘッダが除去されたＰＤＵに対して復号化を行う。ここで、ＰＤＵ１にセキュリティ失敗、すなわちＨＦＮ非同期化が発生した場合、ＰＤＵ１及びその後の全てのＰＤＵ（すなわち、ＰＤＵ２〜ＰＤＵ２０）において復号化が正しく行われない。
【００７７】
Ｓ２３：しかしながら、前記受信側ＰＤＣＰエンティティは、前記パケット（すなわち、ＰＤＵ１〜ＰＤＵ２０）が正しく復号化されていないことを認知できず、これらをヘッダ復元ユニットに送信する。
【００７８】
Ｓ２４：前記ヘッダ復元ユニットは、受信したパケットに対してヘッダ復元を行うが、全てにエラーを確認（識別）する。エラーの発生確認はヘッダのＣＲＣ値から判断することができる。
【００７９】
Ｓ２５：前記受信側ＰＤＣＰエンティティは、前記ヘッダ復元時にエラーが発生したパケットの数をカウントする。そのカウントしたエラー発生パケットの数が予め定められた基準値（すなわち、閾値、この値は例えば、２０）に達すると（すなわち、より大きくなると）、前記受信側ＰＤＣＰエンティティは、セキュリティ構成にエラーが発生したと判断する。
【００８０】
つまり、図８の実施形態において、受信側ＰＤＣＰエンティティは、第一に、受信したパケットのヘッダ復元時にヘッダのＣＲＣ値からエラーを判断し、第二に、ヘッダ復元時にエラーが発生したパケットの数をカウントし、第三に、そのエラー発生パケットの数が基準値に達すると、セキュリティ失敗が発生したと判断する。受信側ＰＤＣＰエンティティは、セキュリティ失敗が発生したと判断すると、これを迅速に復旧してさらなるデータ損失と無線リソースの浪費を防止するために、セキュリティ失敗の復旧過程を行う。前記復旧過程は、例えば受信側ＲＲＣ層がセキュリティ失敗のエラーを端末に通知し、端末がネットワークとの接続を切断して再び最初からＲＲＣ接続を設定するようにしてもよい。あるいは、ＲＲＣ層がＲＢを再設定するか、又は端末（ＵＥ）とネットワーク間の特定のＲＢに関してセキュリティ構成を再設定するようにしてもよい。
【００８１】
次に、制御プレーンのＲＢの場合におけるセキュリティ失敗の判断条件を説明する。
【００８２】
制御プレーンのＲＢの場合、ヘッダ復元が行われず、その代わりに完全性確認が行われる。従って、ユーザプレーンのＲＢとは異なる基準でセキュリティ失敗を判断しなければならない。完全性確認時には、ＰＤＵに含まれるＭＡＣ−Ｉの値と受信側ＰＤＣＰエンティティが独自に生成したＸＭＡＣ−Ｉの値とを比較するが、これら２つの値が異なると、完全性確認に失敗したと判断し、受信側ＰＤＣＰエンティティが受信したパケットを廃棄する。従って、本発明においては、制御プレーンのＲＢに関しては、完全性確認で所定数以上のパケットにエラーが発生すると、セキュリティ失敗であると判断し、セキュリティ失敗の復旧過程を行う。このために、受信側ＰＤＣＰエンティティは、完全性確認でエラーが発生した数、すなわちＰＤＵに含まれるＭＡＣ−Ｉの値と受信側ＰＤＣＰエンティティが独自に生成したＸＭＡＣ−Ｉの値とが異なる場合の数をカウントする。つまり、受信側ＰＤＣＰエンティティは、異なる値（ＰＤＵに含まれるＭＡＣ−Ｉの値と受信側ＰＤＣＰエンティティが独自に生成したＸＭＡＣ−Ｉの値）を有する該当パケットの数をカウントする変数（カウンタ）を用いて、パケットにエラーが発生する度に前記変数の値を増加させ、前記変数が予め定められた基準値（閾値）に達すると、セキュリティ構成に問題が発生したと判断する。一方、前記基準値は、ＲＢ設定時に受信側ＲＲＣ層（すなわち、ｅＮＢ  ＲＲＣ層）が送信側ＲＲＣ層（すなわち、ＵＥ  ＲＲＣ層）に通知し、さらに送信側ＲＲＣ層（ＵＥ  ＲＲＣ層）が送信側ＰＤＣＰエンティティ（すなわち、ＵＥ  ＰＤＣＰエンティティ）に通知することもできる。また、前記基準値は、特定の値に予め定めておいてもよく、ＲＢによって異なる値を有するようにしてもよい。さらに、前記パケットのエラーをカウントする変数（又は、カウンタ）の値は、パケットにエラーが発生する度に（例えば、不連続的にエラーが発生した場合）増加させてもよく、パケットに連続的にエラーが発生した場合にのみ増加させてもよい。
【００８３】
図９は、本発明の一実施形態によって受信側ＰＤＣＰエンティティが制御プレーンのＲＢに関してセキュリティ失敗を判断する過程を示すブロック図である。以下、制御プレーンのＲＢの場合における受信側ＰＤＣＰエンティティがセキュリティ失敗を判断する過程をより詳細に説明する。
【００８４】
Ｓ３０：受信側ＰＤＣＰエンティティは、ＰＤＵ１〜ＰＤＵ２０のＰＤＣＰ  ＰＤＵを下位層、すなわちＲＬＣ層から受信する。
【００８５】
Ｓ３１：前記受信側ＰＤＣＰエンティティは、前記受信したＰＤＵからヘッダを除去して復号化ユニットに送信する。
【００８６】
Ｓ３２：前記受信側ＰＤＣＰエンティティは、前記ヘッダが除去されたＰＤＵに対して復号化を行う。ここで、ＰＤＵ１にセキュリティ失敗、すなわちＨＦＮ非同期化が発生した場合、ＰＤＵ１及びその後の全てのＰＤＵ（すなわち、ＰＤＵ２〜ＰＤＵ２０）において復号化が正しく行われない。
【００８７】
Ｓ３３：しかしながら、前記受信側ＰＤＣＰエンティティは、前記パケット（すなわち、ＰＤＵ１〜ＰＤＵ２０）が正しく復号化されていないことを認知できず、これらを完全性確認ユニットに送信する。
【００８８】
Ｓ３４：前記完全性確認ユニットは、受信したパケット（すなわち、ＰＤＵ１〜ＰＤＵ２０）に対して完全性確認を行うが、全てにエラーを確認（識別）する。エラーの発生確認は、前記ＰＤＵに含まれるＭＡＣ−Ｉの値と前記受信側ＰＤＣＰエンティティが独自に生成したＸＭＡＣ−Ｉの値とを比較することで判断することができる。
【００８９】
Ｓ３５：前記受信側ＰＤＣＰエンティティは、前記完全性確認時にエラーが発生したパケットの数をカウントする。そのカウントしたエラー発生パケットの数が予め定められた基準値（例えば、２０）に達すると、前記受信側ＰＤＣＰエンティティは、セキュリティ構成にエラーが発生したと判断する。
【００９０】
図９の実施形態は復号化過程でエラーが発生した場合を示す。ところが、実際には、完全性確認過程でもエラーが発生することがあるが、この場合も、その後の処理過程は前述と同様である。例えば、復号化には全て成功したが、完全性確認パラメータが誤っており、ＰＤＵ１にエラーが発生した場合、その後の全てのパケットにもエラーが発生するので、いずれの場合でも、完全性確認でエラーが発生したパケットの数をカウントして、セキュリティ失敗が発生したか否かを判断する。
【００９１】
受信側ＰＤＣＰエンティティは、セキュリティ失敗が発生したと判断すると、これを迅速に復旧してさらなるデータ損失と無線リソースの浪費を防止するために、セキュリティ失敗の復旧過程を行う。前記復旧過程は、例えば受信側ＲＲＣ層がセキュリティ失敗のエラーを端末に通知し、端末がネットワークとの接続を切断して再び最初からＲＲＣ接続を設定するようにしてもよい。あるいは、ＲＲＣ層がＲＢを再設定するか、又は端末（ＵＥ）とネットワーク間の特定のＲＢに関してセキュリティ構成を再設定するようにしてもよい。
【００９２】
以上説明した本発明による方法は、ソフトウェア、ハードウェア、又はこれらの組み合わせで実現することができる。例えば、本発明による方法は、記憶媒体（例えば、移動端末機の内部メモリ、フラッシュメモリ、ハードディスクなど）に保存することができ、プロセッサ（例えば、移動端末機内部のマイクロプロセッサ）により実行されるソフトウェアプログラム内にコード又はコマンドで実現することができる。
【００９３】
前述した本発明が様々な面で変形可能であることは明らかである。その変形は本発明の範囲から外れるものとみなされず、当該技術分野における通常の知識を有する者に明らかな全ての変形が添付の請求の範囲に含まれる。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
（Ａ）受信側ＰＤＣＰ（ｐａｃｋｅｔ  ｄａｔａ  ｃｏｎｖｅｒｇｅｎｃｅ  ｐｒｏｔｏｃｏｌ）層において少なくとも１つのデータユニットを受信するステップと、
（Ｂ）前記ＰＤＣＰ層において前記少なくとも１つのデータユニットに対して完全性確認（ｉｎｔｅｇｒｉｔｙ  ｖｅｒｉｆｉｃａｔｉｏｎ）を行うステップと、
（Ｃ）前記完全性確認を行いながら、前記少なくとも１つのデータユニットに対してセキュリティ失敗（ｓｅｃｕｒｉｔｙ  ｆａｉｌｕｒｅ）が存在するか否かを確認するステップと、
（Ｄ）前記少なくとも１つのデータユニットにセキュリティ失敗が存在する場合に、受信側ＲＲＣ（ｒａｄｉｏ  ｒｅｓｏｕｒｃｅ  ｃｏｎｔｒｏｌ）層にセキュリティ失敗を報告するステップと
を含むことを特徴とする移動通信システムにおけるセキュリティ失敗報告方法。
【請求項２】
前記ＲＲＣ層が前記セキュリティ失敗の報告を受信すると再設定（ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔ）手順を行うステップをさらに含むことを特徴とする請求項１に記載の移動通信システムにおけるセキュリティ失敗報告方法。
【請求項３】
前記再設定手順が、
ＲＢ（ｒａｄｉｏ  ｂｅａｒｅｒ）の再設定、ＲＲＣ接続の再設定、特定ＲＢに関するセキュリティ構成（ｓｅｃｕｒｉｔｙ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）のリセット、及びＰＤＣＰ層の再設定の少なくとも１つを含むことを特徴とする請求項２に記載の移動通信システムにおけるセキュリティ失敗報告方法。
【請求項４】
前記ＰＤＣＰ層の再設定ステップが、
前記ＰＤＣＰ層をリセットするステップを含むことを特徴とする請求項３に記載の移動通信システムにおけるセキュリティ失敗報告方法。
【請求項５】
前記ステップ（Ｃ）は、
受信した少なくとも１つのデータユニットのうちエラー発生データユニットの数をカウントするステップと、
前記カウントしたエラー発生データユニットの数を基準値と比較するステップと、
前記カウントしたエラー発生データユニットの数が前記基準値に達するとセキュリティ失敗であると判断するステップと
を含むことを特徴とする請求項１に記載の移動通信システムにおけるセキュリティ失敗報告方法。
【請求項６】
前記受信した少なくとも１つのデータユニットのうちエラー発生データユニットの数をカウントするステップは、
前記受信した少なくとも１つのデータユニットからヘッダを除去するステップと、
前記ヘッダを除去したデータユニットを復号化するステップと、
エラー発生データユニットが存在する場合はエラーデータユニットの数を示すカウント値を増加させるステップとを含み、
前記カウント値は、前記セキュリティ失敗が存在するか否かを判断するために前記基準値と比較されることを特徴とする請求項５に記載の移動通信システムにおけるセキュリティ失敗報告方法。
【請求項７】
前記カウントしたエラー発生データユニットの数が前記基準値に達すると、セキュリティ構成復旧過程を行うステップをさらに含むことを特徴とする請求項５に記載の移動通信システムにおけるセキュリティ失敗報告方法。
【請求項８】
前記セキュリティ構成復旧過程が、
前記ＰＤＣＰ層のリセット手順を行うステップを含むことを特徴とする請求項７に記載の移動通信システムにおけるセキュリティ失敗報告方法。
【請求項９】
前記少なくとも１つのデータユニットに対して前記セキュリティ失敗が存在することが確認されると、前記少なくとも１つのデータユニットを廃棄（ｄｉｓｃａｒｄ）するステップをさらに含むことを特徴とする請求項１に記載の移動通信システムにおけるセキュリティ失敗報告方法。
【請求項１０】
前記エラー発生データユニットが連続していることを特徴とする請求項５に記載の移動通信システムにおけるセキュリティ失敗報告方法。
【請求項１１】
前記基準値がＲＢによって異なることを特徴とする請求項５に記載の移動通信システムにおけるセキュリティ失敗報告方法。
【請求項１２】
前記エラー発生データユニットは、
前記受信した少なくとも１つのデータユニットのＭＡＣ−Ｉ（ｍｅｓｓａｇｅ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｃｏｄｅ−ｉｎｔｅｇｒｉｔｙ）値が、前記ＰＤＣＰ層が生成したＸＭＡＣ−Ｉ（ｅｘｐｅｃｔｅｄ  ｍｅｓｓａｇｅ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｃｏｄｅ−ｉｎｔｅｇｒｉｔｙ）値と異なる場合に決定されることを特徴とする請求項５に記載の移動通信システムにおけるセキュリティ失敗報告方法。
【請求項１３】
前記少なくとも１つのデータユニットが制御プレーン（ｃｏｎｔｒｏｌ  ｐｌａｎｅ）データを含むことを特徴とする請求項５に記載の移動通信システムにおけるセキュリティ失敗報告方法。
【請求項１４】
受信した少なくとも１つのデータユニットのヘッダを除去するヘッダ除去モジュールと、
前記ヘッダが除去された少なくとも１つのデータユニットを復号化する復号化モジュールと、
前記少なくとも１つのデータユニットに対して完全性確認を行い、前記完全性確認を行いながら、前記少なくとも１つのデータユニットに対してセキュリティ失敗が存在するか否かを確認する完全性確認モジュールとを含み、
前記完全性確認モジュールが前記少なくとも１つのデータユニットに対してセキュリティ失敗を確認すると、前記セキュリティ失敗は受信側（ｒｅｃｅｉｖｅｒ）のＲＲＣ層に報告されることを特徴とする移動通信システムにおける受信側ＰＤＣＰエンティティ。
【請求項１５】
前記セキュリティ失敗の報告を受信する前記ＲＲＣ層において再設定を行う再設定モジュールをさらに含むことを特徴とする請求項１４に記載の移動通信システムにおける受信側ＰＤＣＰエンティティ。
【請求項１６】
前記少なくとも１つのデータユニットは、
前記完全性確認モジュールが前記少なくとも１つのデータユニットに対して前記セキュリティ失敗を確認すると、廃棄されることを特徴とする請求項１４に記載の移動通信システムにおける受信側ＰＤＣＰエンティティ。
【国際調査報告】
2010533415.tif 000012
2010533415.tif 000013