JP2012508493A - 基地局間インタフェースの確立 - Google Patents

Abstract

同一のあるいは異なる無線アクセスネットワーク内に配置されている１対の基地局との間のピアツーピアＩＰＳｅｃセキュリティアソシエーションを確立する方法である。これらの基地局は、それぞれが事前に確立されているＩＰＳｅｃセキュリティアソシエーションを使用して、コアネットワークの同一のあるいは異なるセキュリティゲートウェイ群を介してコアネットワークと通信する。この方法は、事前に確立されているＩＰＳｅｃセキュリティアソシエーションを使用して、１対の基地局との間で、ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージとを交換することを含んでいる。
【選択図】 なし

Description

本発明は、無線通信ネットワークに関するものである。より詳しくは、制限するものでなく、本発明は、同一の無線アクセスネットワークあるいは異なる無線アクセスネットワーク内の基地局との間のインタフェースを確立するシステム及び方法に向けられている。

３ＧＰＰリリース８で導入されている、ロングタームエボリューション（ＬＴＥ）技術は、移動無線通信における次なる大きな進歩である。これは、より豊かなユーザ体験を与え、かつより厳しい用途でさえもサポートすることになる。この用途には、インタラクティブＴＶ、ユーザ生成ビデオ群、高度なゲーム、及びプロフェッショナルサービスがある。ＬＴＥは、高度アンテナ技術を伴うＯＦＤＭ（直交周波数分割多重）無線アクセス技術を使用する。

ＬＴＥに加えて、３ＧＰＰは、システムアーキテクチャエボリューション（ＳＡＥ）の試みの一部として、均一のＩＰベースネットワークアーキテクチャを規定している。ＬＴＥ／ＳＡＥアーキテクチャ及び概念の目的及び設計は、任意のＩＰベースのサービスの大規模市場での使用を効率的にサポートすることである。このアーキテクチャは、既存のＧＳＭ／ＷＣＤＭＡコアと無線アクセスネットワークに基づき、かつそれから進化することで、簡略化操作及び平滑で費用効果がある配備を容易にしている。

ＬＴＥ／ＳＡＥアーキテクチャは、操業費用と設備投資を削減する。この新規で、安定したアーキテクチャは、例えば、２つのノードのタイプ（基地局とゲートウェイ）だけが、データ量の大幅な増加に対応するために容量を変倍しなければならないことを意味する。加えて、３ＧＰＰと３ＧＰＰ２は、ＣＤＭＡとＬＴＥ／ＳＡＥ間の相互作用を最適化することに同意している。ＣＤＭＡオペレータは、自身のネットワークをＬＴＥ−ＳＡＥへ進化させることができるであろうし、また、大規模な経済利益と全体的なチップセット規模の恩恵を受けることができるであろう。

ＬＴＥ／ＳＡＥのアーキテクチャが図１に示される。ここでは、無線アクセスネットワークにおけるトラフィックタイプのノード（ｅノードＢ）だけが、ＳＡＥコアネットワーク（ＳＡＥ ＣＮ）における２つのタイプのノード、即ち、制御シグナリングを扱うモビリティ管理エンティティ（ＭＭＥ）、ユーザデータを扱うＳＡＥゲートウェイ（ＳＡＥ−ＧＷ）とともに存在している。ＳＡＥ−ＧＷは動作名であり、２つの異なる部分、即ち、サービングゲートウェイ（在圏ゲートウェイ）とＰＤＮゲートウェイを構成する。これらは、例えば、３ＧＰＰ ＴＳ２３．４０１で定義されている。これらのノードのすべては、ＩＰネットワークによって相互に接続されている。

これらのタイプのノード間には、３つの主要なプロトコルとインタフェース（図１に示される）が存在する。これらは、ｅノードＢとＭＭＥとの間のＳ１−ＭＭＥ、ｅノードＢとＳＡＥ−ＧＷとの間（あるいは、より正確には、ｅノードＢとサービングゲートウェイとの間）のＳ１−Ｕ、及びｅノードＢとの間のＸ２である。これらのインタフェースで使用される対応のプロトコルは、Ｓ１ＡＰ（Ｓ１アプリケーションプロトコル）、ＧＴＰ−Ｕ（ＧＰＲＳトンネリングプロトコルユーザプレーン）、及びＸ２ＡＰ（Ｘ２アプリケーションプロトコル）である。これらのプロトコルとインタフェースのすべてがＩＰベースである。加えて、ネットワークは、上述のインタフェースの一部である他のノード群を含むことができ、これには、例えば、ホームｅノードＢ（ＨｅＮＢ）とネットワーク内の残りのノード群との間のホームｅノードＢゲートウェイ（ＨｅＮＢ ＧＷ）がある。

オペレータにとって、ＬＴＥ ＲＡＮとＳＡＥ ＣＮとを接続するための共通の状況は、ある一定のサービスレベル協定（ＳＬＡ）、例えば、インターネットサービスプロバイダからの特定の帯域幅とＱｏＳサポートを伴う、トランスポート容量の貸出を含んでいる。この借り受けのトランスポート容量は非セキュアなもの（un-secure：安全でないもの）として取り扱われる。これは、トラフィックが、他のユーザのトラフィックと混ざる可能性があり、また、例えば、インターネットの一部を経由する可能性があるからである。我々は、コアネットワークノード群がセキュア化（安全な）イントラネット（いわゆる、信頼済ドメイン）に配置されているものと想定している。ｅノードＢとＳＡＥ ＣＮとの間でセキュア化通信を提供するために、セキュリティゲートウェイ（ＳＥＧＷ）が、インターネットとイントラネットとの間のインタフェースに導入される。ＩＰＳｅｃトンネル群は、ＳＥＧＷ群を介してコアネットワークイントラネットに向けてｅノードＢ群を接続するために使用される。

図２は、ｅノードＢ群（インターネット内）が、ＳＥＧＷ群に向けてのＩＰＳｅｃトンネル群を使用してＳＡＥ ＣＮに接続されているいくつかの例を示している。Ｓ１−ＭＭＥとＳ１−Ｕは、ＩＰｓｅｃトンネル群を介して確立される。２つのｅノードＢとの間のＸ２インタフェースは、ｅノードＢ群が同一のあるいは異なるＳＥＧＷ（群）に接続されているかどうかに依存して、１つあるいは２つのＳＥＧＷ（群）を通じて横断し得ることが示されている。

貸出のトランスポート容量の値付けに影響を与える要素がいくつか存在する。これらには、例えば、帯域幅、サービス品質（ＱｏＳ）、及び提供されるパブリックＩＰアドレスの数がある。パブリックＩＰアドレスに対する要件を最小化するために、ｅノードＢは、ネットワークアドレス変換（ＮＡＴ）を有するファイヤウォールの配下に配置することができる。ＮＡＴは、通常、ＩＳＰによって、公的に登録されているＩＰアドレス群のプールから１つのＩＰアドレスが割り当てられる。そして、プライベートＩＰアドレスとパブリックＩＰアドレスとの間で、ソース（パケット群を発信するための）と宛先（パケット群を着信するための）アドレス変換を実行する。ＮＡＴの使用は、ＮＡＴをバイパスし、かつｅノードＢ群にＳＥＧＷ群とイントラネット内のノード群と通信することを可能にするために、ＩＰＳｅｃセットアップが、例えば、以下の特性を伴うようになされても良いことを要求する。

・トンネルモード
・ＥＳＰ
・ＩＰｓｅｃ ＥＳＰ パケット群のＵＤＰカプセル化（ＲＦＣ３９４８）
・例えば、ＩＫＥｖ２シグナリングあるいはＤＨＣＰを介してＩＰｓｅｃトンネルの確立中のイントラネットＩＰアドレス割当
図３は、Ｘ２インタフェースの確立に関連して重要である、ｅノードＢトポロジー位置に対する様々な可能性を示している。これには、
１．イントラネット−ｅノードＢは、コアネットワークノード群といくつかの他のｅノードＢ群として、同一のセキュアドメイン（即ち、イントラネット）内に配置される。

２．ＮＡＴなしのインターネット−ｅノードＢは、セキュアドメイン外、即ち、インターネットに配置される。セキュアドメインにアクセスするために、ｅノードＢは、ＳＥＧＷに向けてのＩＰＳｅｃトンネルを確立することを必要とする。

３．ＮＡＴ付きインターネット−ｅノードＢは、セキュアドメイン外、即ち、インターネットに配置される。パブリックＩＰアドレスの量を節約するため（あるいはそれ以外の理由のため）に、ｅノードＢは、ＮＡＴの配下に配置される。この場合、ＩＰｓｅｃトンネルは、ｅノードＢとＳＥＧＷとの間でも必要とされる。

２つのｅノードＢがインターネットに配置される場合に、これらの２つのｅノードＢとの間のＸ２接続を確立するための方法が２種類存在する。１つ目の方法は、ｅノードＢ群とＳＥＧＷ群との間に既に確立されているＩＰＳｅｃトンネル群を通じてトラフィックをルーティングすることである。この方法の利点は単純なことであり、これは、ｅノードＢ群とＳＥＧＷ群との間でもＩＰｓｅｃトンネル群が確立される場合のＳ１インタフェース群の初期セットアップ中にすべての必要な接続が既に確立されているからである。この方法の欠点は、Ｘ２データが少なくとも２つの暗号化／解読チェーンを通すことになり、かつＸ２インタフェースにおいて余計でかつ不必要な遅延を招き、かつＳＥＧＷにおいて余計な容量が必要とされることである。これは、モビリティあるいはパフォーマンスの観点から望ましくない。

少なくとも宛先ｅノードＢがＮＡＴの配下に配置されていない場合に適用できる第２の方法は、ｅノードＢ群との間の直接のＩＰｓｅｃトンネルを確立することである。この方法の利点は、Ｘ２データが、単一の１つの暗号化／解読チェーンのみを通すことになることである。この方法の欠点は、各Ｘ２接続に対して、ｅノードＢ群との間の証明が必要とされることである（即ち、他のｅノードＢを認証し、かつｅノードＢがＩＰｓｅｃトンネルを確立することを許容されているかを検証することである）、つまり、自動近隣リレーション（ＡＮＲ）がＸ２の確立に関与する場合にｅノードＢについて複雑な証明構造を要求する（これは、Ｘ２の確立は、より「アドホック」的な方法でなされることになり、かつ各ｅノードＢが、ラインタイム中に任意の潜在的な「近隣」を認証する機能を有することを必要とするからである）。

本発明の目的は、Ｘ２接続セットアップ中にｅノードＢ群との間での認証の必要性を最小化することである。また、２つの異なるｅノードＢ群との間で確立されるＸ２インタフェースで実行される暗号化及び解読の数を最小化することが要望される。本明細書で提示される方法は、既存のセキュアな子セキュリティアソシエーション（ＳＡ）におけるＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージを交換することによって、ｅノードＢ群を認証するために、あるいは既存のＩＫＥ＿ＳＡ上の専用のメッセージ群によって、ｅノードＢ群を証明するために、既存のセキュア化イントラネットトンネルをピギーバックする。初期の交換後は、ｅノードＢ群は、それらの直接のピアツーピア通信を開始することができる。

本発明の第１の態様に従えば、同一のあるいは異なる無線アクセスネットワーク内に配置されている１対の基地局との間のピアツーピアＩＰＳｅｃセキュリティアソシエーションを確立する方法が提供される。１対の基地局は、それぞれが事前に確立されているＩＰＳｅｃセキュリティアソシエーションを使用して、コアネットワークの同一のあるいは異なるセキュリティゲートウェイ群を介してコアネットワークと通信する。この方法は、前記事前に確立されているＩＰＳｅｃセキュリティアソシエーションを使用して、前記１対の基地局との間で、ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージとを交換することを有する。

このソリューションは、セキュリティゲートウェイ（群）に対するＩＰｓｅｃセキュア化通信チャネル群を介して、あるいはそれらのＩＰｓｅｃセキュア化通信チャネル群と関連付けられている子チャネル群を介して、一対の基地局との間でピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージとを送信することを含んでいても良い。

前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージとはそれぞれ、ＩＫＥメッセージであるＩＫＥ−ＳＡ−ＩＮＩＴリクエストメッセージとＩＫＥ−ＳＡ−ＩＮＩＴ応答メッセージであっても良い。

前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージの交換に続いて、この方法は、前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションを開始する前記１対の基地局の一方から該１対の基地局の他方へ、非セキュア化ＩＰネットワークを介してＩＫＥ＿ＡＵＴＨメッセージを送信することを含んでも良い。この方法は、前記ＩＫＥ＿ＡＵＴＨメッセージをＵＤＰカプセル化することを含んでも良い。

前記基地局の他方は、前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションに割り当てられるセキュリティパラメータインデックスのみを使用して、前記基地局の一方から受信するメッセージ群を、該基地局の一方と関連付けることができる。選択的には、前記基地局の他方は、前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションに割り当てられるセキュリティパラメータインデックスと前記基地局の一方のＩＰアドレスとを使用して、該基地局の一方から受信するメッセージ群を、該基地局の一方と関連付けることができ、また、前記基地局の一方のＩＰアドレスは、前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージの通知ペイロード内のＮＡＴ ＤＥＴＥＣＴＩＯＮ ＳＯＵＲＣＥ ＩＰとして、前記基地局の他方へ搬送される。

この方法は、前記１対の基地局との間で、前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージとを、前記１対の基地局それぞれとセキュリティのペア群との間に存在する前記事前に確立されているＩＰＳｅｃセキュリティアソシエーションの暗号化された子セキュリティアソシエーション群を介して交換することを含んでも良い。そして、前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションでセキュアにされたデータは、前記基地局それぞれと前記セキュリティゲートウェイのペア群との間での、ヌル暗号化による子セキュリティアソシエーション群を介して連続して送信されても良い。

この方法は、少なくとも前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージに、前記セキュリティゲートウェイ群の１つあるいはそれぞれを識別するフラグであって、前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションが前記基地局の他方のＩＰアドレスと関連付けられた、セキュリティポリシーデータベースに追加されるべきことを示すフラグを含めても良い。次に、前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションを使用して連続的に送信されるデータは、ペイロード暗号化あるいは解読を必要とすることなく前記セキュリティゲートウェイによって転送される。

この方法は、前記基地局の一方において、前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージを送信し、前記基地局の他方がネットワークアドレストランスレータであるＮＡＴの配下に配置されているか否かを判定し、その判定結果を使用して、どのようにして、前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションの確立を進めるかを判定しても良い。

本発明の特定の実施形態では、前記１対の基地局それぞれは、ＬＴＥベースの無線アクセスネットワーク内のｅノードＢであり、前記コアネットワークは、ＳＡＥベースのネットワークである。

この方法は、前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージの後に続くメッセージ群が、前記セキュリティゲートウェイ群を介してあるいはパブリックＩＰネットワークを介して交換されるべきかどうかを判定することを含んでも良い。この判定は、前記セキュリティゲートウェイ群を介して交換されるべきであると判定する場合、前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションを開始する前記基地局のパブリックＩＰアドレスを、前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージの通知ペイロード内のＮＡＴ ＤＥＴＥＣＴＩＯＮ ＳＯＵＲＣＥ ＩＰとして含めず、また、前記パブリックＩＰネットワークを介して交換されるべきであると判定する場合、前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションを開始する前記基地局のパブリックＩＰアドレスを、前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージの通知ペイロード内のＮＡＴ ＤＥＴＥＣＴＩＯＮ ＳＯＵＲＣＥ ＩＰとして含める。

本発明の第２の態様に従えば、無線アクセスネットワークに使用され、かつ事前に確立されているＩＰＳｅｃセキュリティアソシエーションを使用して、コアネットワークのセキュリティゲートウェイを介して前記コアネットワークと通信するように構成されている基地局が提供される。この基地局は、ピアとなる基地局とのピアツーピアセキュリティアソシエーションを確立するために、前記事前に確立されているＩＰＳｅｃセキュリティアソシエーションを使用して、前記ピアとなる基地局と、ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージとを交換するためのセキュリティ処理ユニットを備える。

前記セキュリティ処理ユニットは、前記ピアとなる基地局へ、前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージの交換に続いて、非セキュア化ＩＰネットワークを介してＩＫＥ＿ＡＵＴＨメッセージを送信するように構成されても良い。選択的には、前記セキュリティ処理ユニットは、前記ピアとなる基地局へ、前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージの交換に続いて、前記セキュリティゲートウェイ群を介してＩＫＥ＿ＡＵＴＨメッセージを送信するように構成されても良い。

この基地局は、更に、本発明の第１の態様に関して上述されるステップ群の方法を実現するための構成要素を更に備えても良い。例えば、この構成要素は、ＩＫＥ−ＡＵＴＨメッセーのＵＤＰカプセル化に対して提供されても良く、一方で、この構成要素は、ＩＫＥセキュリティアソシエーション開始リクエストメッセージの通知ペイロード内のＮＡＴ ＤＥＴＥＣＴＩＯＮ ＳＯＵＲＣＥ ＩＰとして、基地局のパブリックアドレスを含めることに対してあるいは含めないことに対して提供されても良い。含めないことに対して提供される構成要素は、更なる交換がパブリックＩＰネットワークを介して行われるべきかどうかをピアとなる基地局へ指示するために要求されても良い。

本発明の第３の態様に従えば、無線アクセスネットワーク内の１つ以上の基地局をコアネットワークとセキュアに接続するためのセキュリティゲートウェイが提供される。このセキュリティゲートウェイは、前記無線アクセスネットワーク内の第１の基地局と前記コアネットワークとの間で交換されるトラフィックをセキュアにするために、第１のセキュリティアソシエーションを確立するためのセキュリティ処理ユニットを備える。また、前記第１の基地局と前記ピアとなる基地局との間で交換される、ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージを処理するために、前記第１のセキュリティアソシエーションを使用するためのメッセージ処理ユニットが提供される。前記メッセージ交換は、前記第１の基地局と前記ピアとなる基地局との間でピアツーピアセキュリティアソシエーションの確立をもたらす。前記メッセージ処理ユニットは、更に、前記ピアツーピアセキュリティアソシエーションに対するセキュリティパラメータインデックスを、ローカルのセキュリティパラメータインデックスデータベースへ、前記第１の基地局と前記ピアとなる基地局との一方の宛先に向けて転送される前記セキュリティパラメータインデックスにパケット群を照合させるためのメッセージ処理命令とともに追加するように構成されている。

本発明の第４の態様に従えば、同一のあるいは異なる無線アクセスネットワーク内に配置されている１対の基地局として、その内の少なくとも一方がセキュリティゲートウェイを介してコアネットワークに接続されている前記基地局との間のピアツーピアＩＰＳｅｃセキュリティアソシエーションの確立を実現する方法が提供される。この方法は、セキュリティゲートウェイにおいて、前記無線アクセスネットワーク内の第１の基地局と前記コアネットワークとの間で交換されるトラフィックをセキュアにするために、第１のセキュリティアソシエーションを確立することを有する。この第１のセキュリティアソシエーションは、前記第１の基地局とピアとなる基地局との間で交換される、ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージを処理するために使用され、前記メッセージ交換は、前記第１の基地局と前記ピアとなる基地局との間でピアツーピアセキュリティアソシエーションの確立をもたらす。前記ピアツーピアセキュリティアソシエーションに対するセキュリティパラメータインデックスが、ローカルのセキュリティパラメータインデックスデータベースへ、前記第１の基地局と前記ピアとなる基地局との一方の宛先に向けて転送される前記セキュリティパラメータインデックスにパケット群を照合させるためのメッセージ処理命令とともに追加される。

ＬＴＥ／ＳＡＥネットワークのアーキテクチャのブロック図である。 ＳＥＧＷ群に向けてのＩＰＳｅｃトンネル群を使用して、インターネット内のｅノードＢ群がＳＡＥ ＣＮノード群に接続されている例を示すブロック図である。 Ｘ２インタフェースの確立に関連して重要であるｅノードＢトポロジー位置に対する様々な可能性を示すブロック図である。 ピアツーピアトンネルをセットアップするための方法の実施形態を示すシーケンス図である。 本発明の実施形態に従うＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージに対するパケット構造を示す図である。 ピアツーピアトンネルをセットアップするための方法の別の実施形態を示すシーケンス図である。 ｅノードＢ群間のＩＫＥｖ２交換の例と、例としてＩＫＥ＿ＳＡ＿ＩＮＩＴ交換を使用して、子ＳＡ確立後のＩＰＳｅｃメッセージ群を示すシーケンス図である。 ＩＰＳｅｃを使用して、２つのＳＥＧＷとの間の接続を示すブロック図である。 例としてＰ２Ｐ＿ＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージを採用する、ネットワークのノード群との間のＩＫＥ Ｐ２Ｐ交換を示すシーケンス図である。 ソースｅノードＢが宛先ｅノードＢへＩＰパケットを送信したい場合に実行される手順を示すシーケンス図である。 ２つのｅノードＢとの間で確立されるエンドツーエンドセキュアチャネルを示すブロック図である。 基地局とセキュリティゲートウェイを示す図である。

本明細書で記載される方法及び装置は、特に、ＬＴＥ／ＳＡＥに関するものであるが、他の場合にも適用することができる。つまり、この記載は、ＬＴＥ／ＳＡＥネットワークにおけるｅノードＢ群（改良ユニバーサル地上無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）ノードＢ群）に関係し、かつｅノードＢ群との間のＸ２インタフェースをどのようにして確立できるかに関係する一方で、同様の方法が、他のタイプの基地局群とインタフェース群とにも適用することができる。例えば、これらは、Ｅ−ＵＴＲＡＮホームｅノードＢ群（ＨｅＮＢ）、ＵＴＲＡＮにおけるｌｕｒインタフェース、及びＵＴＲＡＮホームノードＢ群（ＨＮＢ）にも適用することができる。現在の３ＧＰＰで策定中の仮説は、Ｘ２はＨｅＮＢ群を介在するハンドオーバに対して使用されないとしているが、これは、介在するＸインタフェースを有する他のＨｅＮＢ機能群を除外するものではない。将来、Ｘ２がＨｅＮＢ群を介在するハンドオーバに対して導入されることになる可能性を除外することはない。

Ｘ２インタフェースの確立に対する３つの方法をここで提示する。

１．非セキュアドメイン内のｅノードＢにおけるピアツーピアＸ２セットアップ
この方法の前提条件は、ソースｅノードＢと宛先ｅノードＢ群の両方が、非セキュアドメインあるいはドメイン群に配置され、かつＩＰｓｅｃトンネル（＝通常ＳＡ）がＳＥＧＷとｅノードＢとの間で確立されなければならないことである。例えば、ＩＰｓｅｃトンネルは、ｅノードＢとコアネットワークとの間のＳ１インタフェースに対して確立されている。このソースｅノードＢは、少なくとも以下の情報も有することになる。

１．ソースｅノードＢのトポロジー位置
２．宛先ｅノードＢのトポロジー位置
３．宛先ｅノードＢに対するイントラネットＩＰアドレス
４．宛先ｅノードＢに対するインターネットＩＰアドレス
この情報は、ソースｅノードＢにおいて事前構成設定される、あるいはいくつかのネットワークサーバからダウンロードされる、あるいは任意のいくつかの異なるシグナリングプロトコル（例えば、Ｓ１ベースのハンドオーバシグナリング）を使用して宛先ｅノードＢから取得される。

この方法は、ｅノードＢ群の少なくとも１つがＮＡＴの配下にない場合に適用する。ここでは、ソースｅノードＢはＮＡＴの配下にあるが、宛先ｅノードＢはＮＡＴの配下にないと想定する。

ピアツーピアトンネルをセットアップするための方法が、図４のシーケンス図で示され、かつこれは、以下のステップ群を備える。

１．ソースｅノードＢは、ＮＡＴの配下に配置されるソースｅノードＢで、宛先ｅノードＢへのＸ２接続を確立しようとする。この段階で、ソースｅノードＢは、自身と宛先ｅノードＢとの両方に対するトポロジー位置を知っている。宛先ｅノードＢに対するイントラネットアドレスとインターネットアドレスが取得される。ＳＥＧＷ群とｅノードＢ群との間の通常ＳＡ群が、例えば、Ｓ１接続の初期化中に確立される。

２．ＩＫＥ＿ＳＡ＿ＩＮＩＴリクエストが、ＮＡＴを通過させるために、ＵＤＰカプセル化を使用してソースｅノードＢから送信される。このメッセージは、内部ＩＰパケットヘッダ内のソースアドレス（Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ）と宛先アドレス（Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ）とするｅノードＢイントラネットＩＰアドレス（Ｉｎｔｒａｎｅｔ ＩＰ ａｄｄｒｅｓｓ）群、即ち、ＩＰソースアドレスとしてのソースｅノードＢイントラネットＩＰアドレスとＩＰ宛先アドレスとしての宛先ｅノードＢイントラネットＩＰアドレスとを伴って、上述のステップ１（かつ、既にＮＡＴをバイパスしている）で確立されるＳＡを通じて送信されることになる。ソースＳＥＧＷは、ＵＤＰカプセル化ヘッダを取り除き、そして、受信したパケットを認証し、かつ解読することになる。これは、カプセル化パケットを、通常のイントラネットＩＰパケットとして取り扱うことになる。

３．このＩＫＥ＿ＳＡ＿ＩＮＩＴリクエストメッセージは、ＳＥＧＷ群との間の通常のＩＰルーティングを使用して、ソースＳＥＧＷから宛先ＳＥＧＷへ転送されることになる。宛先ＳＥＧＷは、このパケットを通常のイントラネットＩＰパケットとして取り扱うことになる。

４．ＩＫＥ＿ＳＡ＿ＩＮＩＴリクエストは、宛先ｅノードＢへ送信される。このメッセージは、宛先側のＳＥＧＷと宛先ｅノードＢとの間で、上述のステップ１で確立されるＳＡを通じて転送されることになる。ＵＤＰカプセル化は要求されない。これは、宛先ｅノードＢは、ＮＡＴの配下でないからである。

５．ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答は、宛先ｅノードＢから宛先側のＳＥＧＷに向けて送信される。このメッセージは、上述のステップ１で確立されるＳＡを通じて、内部ＩＰパケットヘッダにおけるソースアドレス（Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ）と宛先アドレス（Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ）とするイントラネットＩＰアドレス（Ｉｎｔｒａｎｅｔ ＩＰ Ａｄｄｒｅｓｓ）を用いて送信される。このＩＫＥ＿ＳＡ＿ＩＮＩＴ応答では、ＣＥＲＴＲＥＱパラメータに対する必要性はない。これは、ＩＫＥ＿ＳＡ＿ＩＮＩＴは、セキュア化チャネルを介して送信され、かつソースｅノードＢは「信頼された」ものとして取り扱われるからである。宛先側のＳＥＧＷは、ＥＳＰを取り除き、かつ応答を認証し、解読することになる。これは、応答パケットを通常のイントラネットＩＰパケットとして取り扱うことになる。宛先ｅノードＢがＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信した後、宛先ｅノードＢは、ピアからの更なるＩＫＥシグナリングを受信するための適切なポートをオープンすることになる。

６．ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答メッセージは、ＳＥＧＷとの間の通常のＩＰルーティングを使用して、宛先ＳＥＧＷからソースＳＥＧＷへ転送されることになる。ソースＳＥＧＷは、このパケットを通常のイントラネットＩＰパケットとして取り扱うことになる。

７．ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答は、ソース側のＳＥＧＷからソースｅノードＢへと送信される。このメッセージは、上述のステップ１で確立されるＳＡを通じて、ＵＤＰカプセル化を使用して送信されることになる。この時点で、ソースｅノードＢと宛先ｅノードＢとの両方は、ＩＫＥ ＳＰＩに関連付けられている共有のシークレットを所有している。

８．ソースｅノードＢは、ＩＫＥ＿ＡＵＴＨメッセージを、直接、インターネットを通じて、宛先ｅノードＢへ、ｅノードＢソースアドレス（Ｓｏｒｕｃｅ Ａｄｄｒｅｓｓ）とｅノードＢ宛先アドレス（Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ）とするインターネットＩＰアドレス（Ｉｎｔｅｒｎｅｔ ＩＰ Ａｄｄｒｅｓｓ）で、かつＵＤＰカプセル化を使用して送信することになる。これは、ソースｅノードＢが、宛先ｅノードＢがＮＡＴを持たないインターネット内に配置されていて、かつ宛先ｅノードＢにおけるＩＰｓｅｃ用のＵＤＰポートがオープンされていることを知っているから可能となる。この方法から予見されるセキュリティ問題はない。これは、ＩＫＥ＿ＡＵＴＨメッセージが、ＩＫＥ ＳＰＩフィールドによって識別され、かつメッセージが、ＩＫＥ＿ＳＡ＿ＩＮＩＴ交換（第２ドメインで行われる）によって生成される初期キーを使用して暗号化されるからである。

ここで、この方法は、宛先ｅノードＢにおけるＩＫＥｖ２の実装における緩和を要求する場合があり、そうすることで、ＳＰＩは、ソースＩＰアドレス、宛先ＩＰアドレス及びＳＰＩの３つに代えて、ＩＰｓｅｃＳＡの単独の識別子となることに注意された（ネゴシエーションフェーズ中に送信されるＩＫＥメッセージ群は、ソースｅノードＢイントラネットアドレスと宛先ｅノードＢイントラネットアドレスのみを含んでいて、かつインターネットＩＰアドレスを含んでいない）。代替のソリューションは、ソースｅノードＢに対するものとなり、これは、含んでいるＮＡＴ＿ＤＥＴＥＣＴＩＯＮ＿ＳＯＵＲＣＥ＿ＩＰを伴う通知ペイロードを、ＩＫＡ＿ＳＡ＿ＩＮＩＴ（上述のステップ２）に含めることである。ＮＡＴ検出ペイロードのソースＩＰの値は、ソースｅノードＢのインターネットＩＰアドレスとなる。宛先ｅノードＢは、次に、ＩＫＥ＿ＡＵＴＨとその前方が、インターネットＩＰアドレスを介して送信され、かつ適切なポートをオープンすることになることが通知されることになる。

［また、ソースｅノードＢもＮＡＴがないインターネットに配置される場合、ＩＫＥ＿ＡＵＴＨメッセージを、ＵＤＰカプセル化を伴ってあるいは伴わずに送信することができる。］
９．宛先ｅノードＢは、リファレンスとしてＩＫＥ ＳＰＩフィールドを使用して、ＩＫＥ＿ＡＵＴＨメッセージを解読し、かつ認証することになる。解読と認証が成功した後、宛先ｅノードＢは、ソースｅノードＢのインターネットＩＰアドレス（かつＵＤＰカプセル化の場合はポートアドレスと）を記憶することになる。ＵＤＰカプセル化ＩＫＥ＿ＡＵＴＨの受信は、ソースｅノードＢに向けてのＵＤＰカプセル化を使用することを開始するための、宛先ｅノードＢに対するトリガーとなる。

１０．宛先ｅノードＢは、ＩＫＥ＿ＡＵＴＨメッセージを、インターネットを介して、ソースｅノードＢへ応答することになる。続いて、ソースｅノードＢと宛先ｅノードＢとの間のすべてのＩＰＳｅｃ通信は、インターネットを介して送信されることになる。ソースｅノードＢは、宛先ｅノードＢ（前者はＮＡＴの配下に配置されていると想定する）に向けて送信されるメッセージ群のＵＤＰカプセル化を継続することになる。同一の方法で、宛先ｅノードＢは、ソースｅノードＢに向けて送信されるメッセージ群のＵＤＰカプセル化を継続することになる。

上述の方法は、宛先ｅノードＢがＮＡＴファイヤウォールの配下に配置されない場合にのみ動作することになる。そのような場合でなく、逆に、ソースｅノードＢはＮＡＴの配下にはなく、一方で、宛先ｅノードＢはＮＡＴの配下となる場合、宛先ｅノードＢは、ソースｅノードＢによって送信される任意のＩＫＥ＿ＡＵＴＨメッセージを受信することができなくなる。この問題を回避するために、宛先ｅノードＢは代わりにＩＫＥｖ２交換を開始することができる。

上述のステップ４を考慮して、宛先ｅノードＢが、自身がＮＡＴの配下でインターネットに配置されていることを検出する場合、宛先ｅノードＢは、ＩＫＥ＿ＳＡ＿ＩＮＩＴ信号を拒否し、かつＩＫＥ＿ＳＡ＿ＩＮＩＴから取得されるイントラネットＩＰアドレスを使用してソースｅノードＢのインターネットＩＰアドレスのルックアップを実行することになる。このルックアップは、リバースＤＮＳを採用することができる、即ち、ドメイン名（ＰＴＲレコード）に加えて、宛先ノードは、イントラネットＩＰアドレスのような別のレコードを取得することができる。宛先ｅノードＢが、ソースｅノードＢに対して登録されているインターネットＩＰアドレスを一旦取得すると、宛先ｅノードＢは、ソースｅノードＢに向けて同一のシーケンスを開始する。即ち、ＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージの送信等を開始する。この方法の利点は、ＩＫＥｖ２交換の特別な取り扱いを必要としないことである。図５は、ＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージに対するパケット構造群を示していて、ここでは、メッセージは、ソースｅノードＢと宛先ｅノードＢとの間で転送される。

宛先ｅノードＢが、自身がＮＡＴの配下でインターネットに配置されていることを検出する場合に対する代替のソリューションは、含まれているＮＡＴ＿ＤＥＴＣＴＩＯＮ＿ＳＯＵＲＣＥ＿ＩＰに伴う通知ペイロードを、ソースｅノードＢがＩＫＥ＿ＳＡ＿ＩＮＩＴ（上述のステップ２）に含めることを要求する。ＮＡＴ検出ペイロード内のソースＩＰの値は、ソースｅノードＢのインターネットＩＰアドレスとなる。宛先ｅノードＢは自身がＮＡＴの配下にあることを知っているので、宛先ｅノードＢは、ＩＫＥ＿ＳＡ＿ＩＮＩＴ信号を拒否して、ＮＡＴ検出ペイロードから取得されるソースｅノードＢのインターネットＩＰアドレスを記憶し、そして、再度、ソースｅノードＢに向けてのＩＫＥ＿ＳＡ＿ＩＮＩＴの送信で開始するシーケンスと同一のシーケンスを開始することになる。この方法の利点は、外部のＩＰアドレスルックアップが要求されないことである。この方法に関連するシグナリングフローは、図６で示される。

２．ＮＡＴ配下の非セキュアドメイン内のｅノードＢにおけるＸ２セットアップ用ＩＰｓｅｃにおけるＩＰｓｅｃ
上述の第１の方法とは異なり、この第２の方法は、ＮＡＴの配下に２つのｅノードＢの両方が配置されている場合に適用することができる。また、２つのｅノードＢの内の一方あるいは両方がＮＡＴの配下に配置されていない場合にも適用することができる。以下の説明のために、ここでは、どちらのｅノードＢもＮＡＴの配下にないと想定することにする。

この方法の前提条件は、各ＳＥＧＷとｅノードＢとの間で、ＩＫＥ ＳＡが確立されなければならないことである。このようなＩＫＥ ＳＡは、Ｓ１通信に対して確立されることになる。このソースｅノードＢは、少なくとも以下の情報を有することになる。

１．ソースｅノードＢのトポロジー位置
２．宛先ｅノードＢのトポロジー位置
３．宛先ｅノードＢに対するイントラネットＩＰアドレス
インターネットに接続されるｅノードＢは、ｅノードＢとＳＥＧＷとの間で確立されているＩＰｓｅｃトンネル上、即ち、Ｓ１通信に対して確立されているＩＰｓｅｃトンネル上での認証を伴わず、かつヌル（ｎｕｌｌ）暗号化（ＥＮＣＲ＿ＮＵＬＬ）を伴って、追加の子ＳＡ（つまり、これは、通常の子ＳＡが、ｅノードＢとコアネットワークとの間でデータを搬送するために確立されている）を確立すべきである。この新規のｅノードＢとＳＥＧＷとの間の子ＳＡは、Ｘ２インタフェースに対して使用されることになり、かつ、例えば、Ｓ１インタフェースに対するＩＰｓｅｃトンネルの初期の作成時間で既に確立することができる。インターネットに接続されるｅノードＢは、更に、ｅノードＢとＳＥＧＷとの間の通常の子ＳＡについて、即ち、ＥＳＰペイロードについてのＩＫＥ接続試行を受信するための準備をすべきである。

ソースｅノードＢが、宛先ｅノードＢとのＸ２接続を確立することを必要とし、かつソースｅノードＢが２つのｅノードＢの両方がインターネットに接続されていることを知っている場合、ソースｅノードＢは、新規の標準的なＩＫＥ ＳＡと、ｅノードＢとＳＥＧＷとの間の通常の子ＳＡを通じて、宛先ｅノードＢに向けての子ＳＡを確立することになる。これらのＳＡ群は、ｅノードＢ群との間でエンドツーエンドで確立され、かつ子ＳＡは、トランスポートモードあるいはトンネルモードで、ＩＰＳｅｃＡＨあるいはＩＰＳｅｃＥＳＰのどちらかで確立することができる。ＥＳＰトランスポートモードの使用は、送信されるパケット群のオーバヘッドを減少させることになる。

図７はｅノードＢ間のＩＫＥｖ２交換と、例としてＩＫＥ＿ＳＡ＿ＩＮＩＴ交換を使用して子ＳＡ確立が実行された後のＩＰｓｅｃメッセージ群を示している。フローにおけるステップ群は以下のようになる。

１．暗号化と認証を伴う通常の子ＳＡ群と、暗号化を伴わない（かつ、認証を伴わない）別個の子ＳＡ群とは、ＳＥＧＷとｅノードＢ群との間で確立される。即ち、１つの通常の子ＳＡと１つの「別個」の子ＳＡとは、ソースｅノードＢとソースＳＥＧＷとの間で確立され、また、もう一方のペア（対）の子ＳＡ群は、宛先ｅノードＢと宛先ＳＥＧＷとの間で確立される。専用のトラフィックセレクタイニシエータ／レスポンダ（ＴＳｉとＴＳｒ）値は、これらのＳＡ群がピアツーピアＩＰｓｅｃデータトランスポート、即ち、Ｘ２インタフェース／接続確立及びｅノードＢ間の他の関連するトラフィックに対して使用されることを特定するために、別個の子ＳＡ群に対して使用される。Ｘ２インタフェース／接続確立と他の関連するトラフィックは、ＥＳＰプロトコル（エンドツーエンド）を使用して行われる。この専用ＴＳｉとＴＳｒは、例えば、エンドエンドＩＫＥｖ２シグナリング、及びエンドツーエンドＥＳＰプロトコルの少なくとも一方に対するＵＤＰポート５００と４５００を示すことができる。これらの通常の子ＳＡ群と別個のＳＡ群とは、Ｓ１インタフェースに対するＩＰＳｅｃトンネルの初期作成時点で既に確立されていると想定する。

ｅノードＢ群が互いに任意の認証を実行する必要がないことを強調することも重要である。これは、ＳＥＧＷが、例えば、Ｓ１インタフェースに対する初期ＩＰＳｅｃトンネル（即ち、ＩＫＥ ＳＡ、通常のＳＡと別個のＳＡ）の確立時にｅノードＢの認証を既に実行しているからである。加えて、異なるＳＥＧＷが対象のネットワーク内の同一のオペレータに属していて、かつこれらのＳＥＧＷは互いに信頼しているものと想定する。

２．ＩＫＥ＿ＳＡ＿ＩＮＩＴリクエストは、ソースｅノードＢから送信される。このメッセージは、上述のステップ１で確立される通常の子ＳＡを通じて送信される。ソースＳＥＧＷは、そのパケットを任意の他のＩＰパケットとしてみなす。

３．ＩＫＥ＿ＳＡ＿ＩＮＩＴリクエストメッセージは、これらのＳＥＧＷ群との間の通常のＩＰルーティングを使用して、ソースＳＥＧＷから宛先ＳＥＧＷへ転送されることになる。この宛先ＳＥＧＷは、このパケットを任意の他のＩＰパケットとしてみなす。

４．ＩＫＥ＿ＳＡ＿ＩＮＩＴリクエストは、宛先ｅノードＢへ送信される。このメッセージは、上述のステップ１で確立される通常の子ＳＡを通じて送信されることになる。

５．ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答は、宛先ｅノードＢから送信される。このメッセージは、ステップ１で確立される通常の子ＳＡを通じて送信されることになる。宛先ＳＥＧＷは、このパケットを任意の通常のＩＰパケットとして処理する。

６．ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答メッセージは、これらのＳＥＧＷ群との間の通常のＩＰルーティングを使用して、宛先ＳＥＧＷからソースＳＥＧＷへ転送されることになる。ソースＳＥＧＷは、このパケットを任意の通常のＩＰパケットとしてみなす。

７．ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答は、ソースｅノードＢへ送信される。このメッセージは、上述のステップ１で確立される通常のＳＡを通じて送信されることになる。

ここで、ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答メッセージはＣＥＲＴＲＥＱパラメータを含まないことは明らかであろう。

一旦、ソースｅノードＢがＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を受信すると、ソースｅノードＢは、別個の子ＳＡを介して、ＩＫＥ＿ＡＵＴＨメッセージと、他のピアツーピアＩＫＥ ＳＡメッセージ、及びＩＰｓｅｃピアツーピアデータを送信することができる。

この時点で、エンドツーエンドＩＫＥ ＳＡは、ｅノードＢ群との間で共有されるシークレットに基づいて、また、ＳＥＧＷ群を介して、ソースｅノードＢと宛先ｅノードＢとの間に存在する。これは、ｅノードＢ群が、ＳＥＧＷ群を介してＩＫＥ＿ＡＵＴＨを含む暗号化ＩＫＥ ＳＡパケット群を交換できることを意味する。続いて、ＩＫＥ＿ＡＵＴＨが交換される場合、Ｘ２データは、確立されたエンドツーエンド子ＳＡを介して送信することができる。

このソリューションの利点は、新規の拡張したメカニズムあるいはデータベースノード群を、ＳＥＧＷ内にあるいはイントラネット内に導入する必要がないことである。潜在的な欠点は、ＳＥＧＷ群が図８に示されるようにＩＰＳｅｃを使用して接続される場合に、それらのＳＥＧＷ群との間で、追加の暗号化及び解読が回避不能な場合があることである。しかしながら、この特定の場合の欠点は、暗号化を伴わない別個の子ＳＡが、いくつかの予め定義されたＴＳｉとＴＳｒを使用して、すべてのＳＥＧＷ群との間で作成される場合には回避できる。ここで、この予め定義されたＴＳｉとＴＳｒは、例えば、図７に関連してステップ１で記載される同様のＴＳｉ及びＴＳｒを使用して、一意にＸ２インタフェースを識別する。

欠点としては、追加のヘッダ（及びそして、更なるプロトコルオーバヘッダ）が導入されることがあり、これは、新規のＩＰＳｅｃ ＳＡがＩＰＳｅｃトンネル内で実現されるからである。

パフォーマンスの観点からは、Ｘ２通信に対して使用されるＳＡにおいて認証が使用されないことが適切である。しかしながら、これは、正しい宛先ｅノードＢイントラネットアドレスを有する（イントラネットアドレスは、別個の非暗号化ＳＡにおいて傍受され得る）ＩＰＳｅｃパケット群が、ソースｅノードＢとソースＳＥＧＷとの間での非暗号化ＳＡに投入される可能性があるということによって生じ得る若干のセキュリティリスクを招く可能性がある。このリスクは、許可されているＩＰアドレス群／ポート群についてフィルタを通すアクセス制御リスト群（ＡＣＬ群）のようなファイヤウォール機能によって、あるいは認証を使用する（かつ、結果とする処理ペナルティを受け付ける）ことによって軽減することができる。

上述の第１の方法及び第２の方法の両方が宛先ｅノードＢで利用可能である場合、適用される方法をノードに通知するためのメカニズムが要求される場合がある。宛先ｅノードＢでのＩＰｓｅｃの実行を簡略にするために、このようなメカニズムは、通知ペイロードＮＡＴ＿ＤＥＴＥＣＴＩＯＮ＿ＳＯＵＲＣＥ＿ＩＰがＩＫＥ＿ＳＡ＿ＩＮＩＴリクエストメッセージに含まれるかをチェックするｅノードＢを介在させることができる。そのような場合、インターネットを介在する第１の方法が使用され、そうでなければ、ＩＰｓｅｃＸ２セットアップ方法におけるＩＰｓｅｃが使用されることになる。

３．基地局間インタフェース確立
第２の方法と同様に、ここから説明する第３の方法は、２つのｅノードＢの一方あるいは両方がＮＡＴの配下に配置されている、あるいはどちらも配置されていないかどうかに関わらず適用することができる。以下の説明のために、ｅノードＢはどちらもＮＡＴの配下に配置されていないと想定する。この例は、ソースｅノードＢと宛先ｅノードＢがそれぞれ異なるＳＥＧＷに接続されていると想定するが、原理は、ｅノードＢの両方が同一のＳＥＧＷに接続されている場合にも適用することができる。

この方法は、Ｘ２インタフェースに対して必要とされる処理時間及び処理能力を向上させるために、ｅノードＢ群に対するＳＥＧＷ群を介するＩＰＳｅｃトンネル群の転送に依存する。ＩＫＥｖ２における新規のメッセージタイプ群が、通常のＩＫＥｖ２交換とピアツーピアＩＫＥｖ２交換との間を区別するために導入される。パラメータＴＳｉとＴＳｒは、新規のメッセージタイプ群とともに、ピア間でＩＫＥｖ２交換メッセージを転送するためにＳＥＧＷ群によって使用される。このＳＰＩは、ＩＰＳｅｃ ＳＡを識別するためだけではなく、ピア間でのＩＰＳｅｃパケット群をルーティングするために、ＳＥＧＷによって使用される。

この方法の前提条件は、ＳＥＧＷとｅノードＢとの間でＩＫＥ ＳＡが確立されなければならないことである。例えば、このＩＫＥ ＳＡは、Ｓ１インタフェースに対して確立され得る。ソースｅノードＢは、少なくとも以下の情報を有することになる。

１．ソースｅノードＢのトポロジー位置（即ち、ソースｅノードＢは、非セキュアドメイン内に配置される）
２．宛先ｅノードＢのトポロジー位置（即ち、宛先ｅノードＢは非セキュアドメイン内に配置される）
３．宛先ｅノードＢに対するイントラネットＩＰアドレス
以下の情報は、ソースｅノードＢに対してオプションであり、また、後続のステップ中に取得することができる。

４．ＳＥＧＷインターネットＩＰアドレスに関連付けられている宛先ｅノードＢ
５．ＳＥＧＷイントラネットＩＰアドレスに関連付けられている宛先ｅノードＢ
新規の交換タイプ群のセットが、ｅノードＢ群との間でピアツーピアセキュリティアソシエーションを作成することを可能にするために作成される。これらのＰ２Ｐ ＩＫＥｖ２交換タイプ群は、通常のＩＫＥｖ２交換タイプ群に類似している：
・Ｐ２Ｐ＿ＩＫＥ＿ＳＡ＿ＩＮＩＴ
・Ｐ２Ｐ＿ＩＫＥ＿ＡＵＴＨ
・Ｐ２Ｐ＿ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ
・Ｐ２ＰＪＮＦＯＲＭＡＴＩＯＮＡＬ
ソースｅノードＢが宛先ｅノードＢとのＸ２接続を確立することを必要とする場合（これに対する様々なトリガー群は３ＧＰＰで良く知られている）、ソースｅノードＢはノード群との間でＩＫＥ Ｐ２Ｐ交換を開始することになる。各交換メッセージは、例として、Ｐ２Ｐ＿ＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージ交換を採用する、図９に示される手順に従って、ネットワークを通じて送信されることになる。この図示のステップ群は以下のようになる。

１．通常のＩＫＥ ＳＡは、ソースｅノードＢとソースＳＥＧＷとの間で、また、宛先ｅノードＢと宛先ＳＥＧＷとの間で確立されている。例えば、これらのＩＫＥ ＳＡ群は、ｅノードＢ群とＭＭＥ群との間のＳ１−ＭＭＥインタフェース群に対して確立され得る。

ソースｅノードＢは、少なくとも以下の情報を取得する。：
・ソースｅノードＢトポロジー位置
・宛先ｅノードＢトポロジー位置
・宛先ｅノードＢイントラネットＩＰアドレス
ソースｅノードＢは、以下のオプションの情報も取得することができる。：
・ソースｅノードＢに関連付けられているＳＥＧＷのイントラネットＩＰアドレス
・ソースｅノードＢに関連付けられているＳＥＧＷのインターネットＩＰアドレス
・宛先ｅノードＢに関連付けられているＳＥＧＷのイントラネットＩＰアドレス
・宛先ｅノードＢに関連付けられているＳＥＧＷのインターネットＩＰアドレス
２．ソースｅノードＢは、通常のＩＫＥ ＳＡを介して、Ｐ２Ｐ交換タイプメッセージを宛先ｅノードＢへ送信することになる。ピアツーピア接続は、タイプパラメータ群Ｐ２ＰＳＡ（ｅノードＢ群との間のセキュリティアソシエーション；この場合、ｅノードＢ群との間のＩＫＥ ＳＡを識別する）、トラフィックセレクタ−イニシエータ（ＴＳｉ）＝ソースｅノードＢイントラネットＩＰアドレス、及びトラフィックセレクタ−レスポンダ（ＴＳｒ）＝宛先ｅノードＢイントラネットＩＰアドレスを交換することによって識別される。

Ｐ２Ｐ＿ＩＫＥ＿ＳＡ＿ＩＮＩＴに対して、パラメータＴＳｉとＴＳｒは、ソースｅノードＢで利用可能である場合に、以下の情報も含むことになる：ソースｅノードＢと宛先ｅノードＢの両方に対する関連するＳＥＧＷインターネットＩＰアドレス及びイントラネットＩＰアドレス。これは、トラフィックセレクタインスタンス群において専用のＴＳタイプを有することによって可能となる。

３．ソースＳＥＧＷがこれらのＰ２Ｐ交換タイプメッセージ群を受信する場合、通常の交換タイプ群のようなソースｅノードＢに対してこのリクエストに応答する代わりに、メッセージをまず解読することになる。宛先ｅノードＢに対して関連するＳＥＧＷインターネットＩＰアドレスとイントラネットＩＰアドレスを含むＰ２Ｐ＿ＩＫＥ＿ＳＡ＿ＩＮＩＴの場合においては、ソースＳＥＧＷは、宛先ｅノードＢイントラネットＩＰアドレスをキーとして使用して、宛先ｅノードＢイントラネットＩＰアドレス、宛先ＳＥＧＷイントラネットＩＰアドレス、及び宛先ＳＥＧＷインターネットＩＰアドレスを登録することになる。［そうでなければ、ソースＳＥＧＷは、宛先ｅノードＢのイントラネットアドレスをキーとして使用して、いくつかのデータベースからこの情報をリクエストして、そして、上述の関連するＳＥＧＷアドレス群を登録することができる。］このセッションに関連する他のＰ２Ｐメッセージ群に対して、ソースＳＥＧＷは、ＴＳｒをキーとして使用して、宛先ＳＥＧＷの宛先イントラネットＩＰアドレスと宛先インターネットＩＰアドレスとをルックアップすることになる。

４．ソースＳＥＧＷは、Ｐ２Ｐ交換タイプメッセージを、宛先ｅノードＢが接続されている宛先ＳＥＧＷに転送することになる（即ち、Ｐ２Ｐ＿ＩＫＥ＿ＳＡ＿ＩＮＩＴからの宛先ＳＥＧＷ ＩＰアドレス群（インターネットあるいはイントラネット）の１つを使用して）。宛先ｅノードＢにメッセージを直接転送しない理由は、宛先ＳＥＧＷが、ユーザデータを転送するためにＰ２Ｐ ＳＡについての知識を持つ必要があるからである。宛先ＳＥＧＷのインターネットＩＰアドレスを使用することができる、これは、Ｐ２Ｐ交換タイプメッセージ群がエンドツーエンドで暗号化されるからである。しかしながら、インターネットの使用は、ｅノードＢ群への外部からの攻撃に対する潜在的なリスクを高める可能性がある。但し、この部分は、宛先ＳＥＧＷのイントラネットＩＰアドレスを使用することによって実行することもできる。

５．宛先ＳＥＧＷがこのＰ２Ｐ交換タイプメッセージを受信すると、宛先ＳＥＧＷは、受信したメッセージ内のＴＳｒに基づいて、宛先ｅノードＢに向けての正しいＩＫＷ ＳＡを検出するためのルックアップをまず実行することになる。次に、宛先ＳＥＧＷは、自身のＳＡルーティングテーブル内の宛先ｅノードＢとＰ２Ｐ ＳＡとを関連付けることになる。

６．宛先ＳＥＧＷは、通常のＩＫＥ ＳＡを使用して、このメッセージを宛先ｅノードＢへ転送することになる。

７．宛先ｅノードＢは、通常のＩＫＥ ＳＡを使用して、Ｐ２Ｐ交換タイプメッセージ群（宛先ＳＥＧＷに対する）に応答することになる。

Ｐ２Ｐ＿ＩＫＥ＿ＳＡ＿ＩＮＩＴの場合において、宛先ｅノードＢがソースｅノードＢの知識を持っていない場合、宛先ｅノードＢは、次のステップで、ソースｅノードＢに対するイントラネットＩＰアドレス、及びソースｅノードＢに対する関連するＳＥＧＷインターネットＩＰアドレスとイントラネットＩＰアドレスとを登録することになる。

８．このステップは、上述のステップ３と同様である。

９．このステップは、上述のステップ４と同様である。

１０．このステップは、上述のステップ５と同様である。

１１．このステップは、上述のステップ６と同様である。

初期のＰ２Ｐ ＩＫＥ交換の後、Ｐ２Ｐ ＩＫＥ ＳＡとＰ２Ｐ子ＳＡとは、ｅノードＢ群との間で確立される。ソースｅノードＢはＩＰパケットを宛先ｅノードＢへ送信したい場合、図１０に示されるような、以下の手順が実行されることになる。

１．ソースｅノードＢは、宛先ｅノードＢに向けて新規に確立されるＰ２Ｐ子ＳＡに設定されるセキュリティパラメータインデックス（ＳＰＩ）を有するＩＰＳｅｃパケットをソースＳＥＧＷへ送信することになる。

２．ソースＳＥＧＷがこのＩＰＳｅｃパケットを受信する場合、ソースＳＥＧＷは、ＳＰＩフィールドを使用してそのパケットを識別することができる。このパケットは、次に、宛先ＳＥＧＷへ転送されることになる。これは、インターネットを介して実行することができる（ＳＥＧＷとの間のＩＰＳｅｃトンネル群によって結果的に生じる追加の暗号化及び解読を回避するため）。別の可能性としては、Ｘ２インタフェース群に対するＳＥＧＷとの間で確立されるＮＵＬＬ暗号化を伴う追加のＩＰＳｅｃトンネル群を通じるイントラネットを使用するトラフィックの転送が介在する。

３．宛先ＳＥＧＷがこのＩＰＳｅｃパケット（ＳＩＰフィールドによって識別される）を受信すると、宛先ＳＥＧＷはそのパケットを宛先ｅノードＢへ転送することになる。

シークレットが、ソースｅノードＢと宛先ｅノードＢとの間で共有されるので、ネットワーク内の任意の他のパーティに対しては、その内容（ＳＥＧＷ群を含む）を抽出することは不可能になる。図１１は、ｅノードＢ群との間で確立されるエンドツーエンドセキュアチャネルを示している。

このソリューションの利点は、１つの暗号化／解読がｅノード群との間で保証でき、かつヘッダのオーバヘッドを最適化でき、かつイントラネットＩＰアドレス群がデータメッセージ上で可視化されることがないことである。このソリューションの欠点は、拡張されたソリューションを、ｅノードＢとＳＥＧＷとの両方で実現しなければならないことである。

図１２は、基地局（ＢＳ）１とセキュリティゲートウェイ（ＳＥＧＷ）２を示していて、これらは、ＢＳ１とピアＢＳ（不図示）との間のエンドツーエンドセキュリティアソシエーションの確立を容易にするように構成されている。図示のＢＳは、セキュリティ処理ユニット３を備え、これは、ＳＥＧＷ２のセキュリティ処理ユニット４との初期セキュリティアソシエーションを確立する。これの主な目的は、ＢＳにコアネットワークとセキュアに通信することを可能にするためである。ＳＥＧＷ２は、更に、ＢＳ群との間でＩＫＥ開始メッセージ群を中継するためのＩＫＥメッセージ処理ユニット５を備える。

Ｐ２Ｐ ＩＫＥ交換タイプ群に対する詳細メッセージフォーマットを以下にリストする。使用される略語は、ＲＦＣ４３０６でも使用されており、プレフィックス「Ｐ２Ｐ」は修正パラメータ群を示している。

・Ｐ２Ｐ＿ＩＫＥ＿ＳＡ＿ＩＮＩＴ
ＳＥＧＷとｅノードＢ間
HDR, SK {P2PSAi1, KEi, Ni, TSi, TSr} →
← HDR, SK {P2PSAr1 , KEr, Nr, TSi, TSr}
ＳＥＧＷ間
HDR, P2PSAi1, KEi, Ni, TSi, TSr →
← HDR, P2PSAr1, KEr, Nr, TSi, TSr
・Ｐ２Ｐ＿ＩＫＥ＿ＡＵＴＨ
ＳＥＧＷとｅノードＢ間
HDR, SK { P2PSAi2, TSi, TSr, P2PSK {IDi, [CERT,] [CERTREQ,]
[P2PIDr,] AUTH, P2PTSi, P2PTSr }} →
← HDR, SK { P2PSAr2, TSi, TSr, P2PSK {IDr, [CERT,] AUTH, P2PTSi,
P2PTSr }}
ＳＥＧＷ間
HDR, P2PSAi2, TSi, TSr, P2PSK {IDi, [CERT,] [CERTREQ,] [P2PIDr,]
AUTH, P2PTSi, P2PTSr } →
← HDR, P2PSAr2, TSi, TSr, P2PSK {IDr, [CERT,] AUTH, P2PTSi,
P2PTSr }
・Ｐ２Ｐ＿ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ
ＳＥＧＷとｅノードＢ間
HDR, SK { [P2PN], P2PSA, TSi, TSr, P2PSK { Ni, [KEi,] [P2PTSi,
P2PTSr] }} →
← HDR, SK { P2PSA, TSi, TSr, P2PSK { Nr, [KEr,] [P2PTSi, P2PTSr] }}
ＳＥＧＷ間
HDR, [P2PN], P2PSA, TSi, TSr, P2PSK { Ni, [KEi,] [P2PTSi, P2PTSr] } →
← HDR, P2PSA, TSi, TSr, P2PSK { Nr, [KEr,] [P2PTSi, P2PTSr] }
・Ｐ２Ｐ＿ＩＮＦＯＲＭＡＴＩＯＮＡＬ
ＳＥＧＷとｅノードＢ間
HDR, SK { TSi, TSr, [P2PN], [P2PD], P2PSK { [CP,] ...}} →
← HDR, SK { TSi, TSr, [P2PN], [P2PD], P2PSK { [CP,] ...}}
ＳＥＧＷ間
HDR, TSi, TSr, [P2PN], [P2PD], P2PSK { [CP,] ...} →
← HDR, TSi, TSr, [P2PN], [P2PD], P2PSK { [CP,] ...}
パラメータ群ＴＳｉとＴＳｒはこれらのメッセージのすべてに導入されることに注意されたい。これらの２つのパラメータは、ピアツーピア接続の識別のために使用される。

ピアツーピアＩＫＥ交換は、通常のＩＫＥ交換と同一の方法で実現される。この交換は、以下の方法で実行される（ＲＦＣ４３０６と比較して）。

・Ｐ２Ｐ初期交換（P2P Initial exchange）
P2P_IKE_SA_INIT →
← P2P_IKE_SA_INIT
P2P_IKE_AUTH →
← P2P_IKE_AUTH
・Ｐ２Ｐ作成 子ＳＡ交換（P2P Create child SA exchange）
P2P_CREATE_CHILD_SA →
← P2P_CREATE_CHILD_SA
・Ｐ２Ｐ情報交換（P2P Informational exchange）
P2P_INFORMATIONAL →
← P2P_INFORMATIONAL
Ｐ２Ｐ ＩＫＥ ＳＡは、通常のＩＫＥ ＳＡによって作成されるので、ＩＫＥ ＳＡが解除される場合、Ｐ２Ｐ ＩＫＥ ＳＡ（及び自身の関連するＰ２Ｐ子ＳＡ）も解除されることになる。

本明細書で記載されるＸ２インタフェースを確立するための方法は、ｅノードＢ群との間のＸ２インタフェース上の不必要な暗号化と解読を解消することができ、これによって、処理時間と処理能力の両方が向上する。また、この方法は、ｅノードＢ群との間の信頼のあるＸ２接続群を確立するために必要とされる複雑な認証構造の複雑度を削減する。

記載の方法群の配下にある原理は、非セキュアドメイン内の２つのノード群で接続が必要とされる、ＬＴＥ以外の技術に対しても適用できる。この原理は、非セキュアドメイン内に配置される２つのクライアントが、ピアツーピア接続を確立する必要がある場合における、企業ＩＰネットワーク群に対しても適用できる。

本発明の実施形態は図面と上述の説明によって示されているが、本発明は開示の実施形態に限定されるものではなく、本発明の範囲から逸脱しない範囲での、いくつかの再構成、変形及び置換を行うことができることが理解されるべきである。

Claims (17)

1. 同一のあるいは異なる無線アクセスネットワーク内に配置されている１対の基地局として、それぞれが事前に確立されているＩＰＳｅｃセキュリティアソシエーションを使用して、コアネットワークの同一のあるいは異なるセキュリティゲートウェイ群を介して前記コアネットワークと通信する前記基地局との間のピアツーピアＩＰＳｅｃセキュリティアソシエーションを確立する方法であって、
   前記事前に確立されているＩＰＳｅｃセキュリティアソシエーションを使用して、前記１対の基地局との間で、ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージとを交換する
   ことを特徴とする方法。
2. 前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージはそれぞれ、ＩＫＥメッセージにおけるＩＫＥ−ＳＡ−ＩＮＩＴリクエストメッセージとＩＫＥ−ＳＡ−ＩＮＩＴ応答メッセージである
   ことを特徴とする請求項１に記載の方法。
3. 前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージの交換に続いて、
   前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションを開始する前記１対の基地局の一方から該１対の基地局の他方へ、非セキュア化ＩＰネットワークを介してＩＫＥ＿ＡＵＴＨメッセージを送信する
   ことを特徴とする請求項１または２に記載の方法。
4. 前記ＩＫＥ−ＳＡ−ＩＮＩＴ応答メッセージを送信する前記基地局の一方において、該メッセージの送信に際して、前記基地局の他方から更なるメッセージ群を受信するための適切なポートをオープンする
   ことを特徴とする請求項３に記載の方法。
5. 前記ＩＫＥ＿ＡＵＴＨメッセージをＵＤＰカプセル化する
   ことを特徴とする請求項３または４に記載の方法。
6. 前記基地局の他方は、前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションに割り当てられるセキュリティパラメータインデックスのみを使用して、前記基地局の一方から受信するメッセージ群を、該基地局の一方と関連付ける
   ことを特徴とする請求項３乃至５のいずれか１項に記載の方法。
7. 前記基地局の他方は、前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションに割り当てられるセキュリティパラメータインデックスと前記基地局の一方のＩＰアドレスとを使用して、該基地局の一方から受信するメッセージ群を、該基地局の一方と関連付け、
   前記基地局の一方のＩＰアドレスは、前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージの通知ペイロード内のＮＡＴ ＤＥＴＥＣＴＩＯＮ ＳＯＵＲＣＥ ＩＰとして、前記基地局の他方へ搬送される
   ことを特徴とする請求項３乃至５のいずれか１項に記載の方法。
8. 前記１対の基地局との間で、前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージとを、前記１対の基地局それぞれとセキュリティのペア群との間に存在する前記事前に確立されているＩＰＳｅｃセキュリティアソシエーションの暗号化された子セキュリティアソシエーション群を介して交換し、
   前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションでセキュアにされたデータは、前記基地局それぞれと前記セキュリティゲートウェイのペア群との間での、ヌル暗号化による子セキュリティアソシエーション群を介して連続して送信される
   ことを特徴とする請求項１または２に記載の方法。
9. 少なくとも前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージに、前記セキュリティゲートウェイ群の１つあるいはそれぞれを識別するフラグであって、前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションが前記基地局の他方のＩＰアドレスと関連付けられた、セキュリティポリシーデータベースに追加されるべきことを示すフラグを含め、
   前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションを使用して連続して送信されるデータは、ペイロード暗号化あるいは解読を必要とすることなくセキュリティゲートウェイによって転送される
   ことを特徴とする請求項１または２に記載の方法。
10. 前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージを送信する前記基地局の一方において、前記基地局の他方がネットワークアドレストランスレータであるＮＡＴの配下に配置されているか否かを判定し、その判定結果を使用して、どのようにして、前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションの確立を進めるかを判定する
    ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
11. 前記１対の基地局それぞれは、ＬＴＥベースの無線アクセスネットワーク内のｅノードＢであり、
    前記コアネットワークは、ＳＡＥベースのネットワークである
    ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
12. 前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージの後に続くメッセージ群が、前記セキュリティゲートウェイ群を介してあるいはパブリックＩＰネットワークを介して交換されるべきかどうかを判定し、
    前記セキュリティゲートウェイ群を介して交換されるべきであると判定される場合、前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションを開始する前記基地局のパブリックＩＰアドレスを、前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージの通知ペイロード内のＮＡＴ ＤＥＴＥＣＴＩＯＮ ＳＯＵＲＣＥ ＩＰとして含めず、
    前記パブリックＩＰネットワークを介して交換されるべきであると判定される場合、前記ピアツーピアＩＰＳｅｃセキュリティアソシエーションを開始する前記基地局のパブリックＩＰアドレスを、前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージの通知ペイロード内のＮＡＴ ＤＥＴＥＣＴＩＯＮ ＳＯＵＲＣＥ ＩＰとして含める
    ことを特徴とする請求項１に記載の方法。
13. 無線アクセスネットワークに使用され、かつ事前に確立されているＩＰＳｅｃセキュリティアソシエーションを使用して、コアネットワークのセキュリティゲートウェイを介して前記コアネットワークと通信するように構成されている基地局であって、
    ピアとなる基地局とのピアツーピアセキュリティアソシエーションを確立するために、前記事前に確立されているＩＰＳｅｃセキュリティアソシエーションを使用して、前記ピアとなる基地局と、ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージとを交換するためのセキュリティ処理ユニットを備える
    ことを特徴とする基地局。
14. 前記セキュリティ処理ユニットは、前記ピアとなる基地局へ、前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージの交換に続いて、非セキュア化ＩＰネットワークを介してＩＫＥ＿ＡＵＴＨメッセージを送信するように構成されている
    ことを特徴とする請求項１３に記載の基地局。
15. 前記セキュリティ処理ユニットは、前記ピアとなる基地局へ、前記ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージの交換に続いて、前記セキュリティゲートウェイ群を介してＩＫＥ＿ＡＵＴＨメッセージを送信するように構成されている
    ことを特徴とする請求項１３に記載の基地局。
16. 無線アクセスネットワーク内の１つ以上の基地局をコアネットワークとセキュアに接続するためのセキュリティゲートウェイであって、
    前記無線アクセスネットワーク内の第１の基地局と前記コアネットワークとの間で交換されるトラフィックをセキュアにするために、第１のセキュリティアソシエーションを確立するためのセキュリティ処理ユニットと、
    前記第１の基地局とピアとなる基地局との間で交換される、ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージを処理するために、前記第１のセキュリティアソシエーションを使用するためのメッセージ処理ユニットとを備え、
    前記メッセージ交換は、前記第１の基地局と前記ピアとなる基地局との間でピアツーピアセキュリティアソシエーションの確立をもたらし、
    前記メッセージ処理ユニットは、前記ピアツーピアセキュリティアソシエーションに対するセキュリティパラメータインデックスを、ローカルのセキュリティパラメータインデックスデータベースへ、前記第１の基地局と前記ピアとなる基地局との一方の宛先に向けて転送される前記セキュリティパラメータインデックスにパケット群を照合させるためのメッセージ処理命令とともに追加する
    ことを特徴とするセキュリティゲートウェイ。
17. 同一のあるいは異なる無線アクセスネットワーク内に配置されている１対の基地局として、その内の少なくとも一方がセキュリティゲートウェイを介してコアネットワークに接続されている前記１対の基地局との間のピアツーピアＩＰＳｅｃセキュリティアソシエーションの確立を実現する方法であって、
    前記無線アクセスネットワーク内の第１の基地局と前記コアネットワークとの間で交換されるトラフィックをセキュアにするために、第１のセキュリティアソシエーションを確立し、
    前記第１の基地局とピアとなる基地局との間で交換される、ピアツーピアＩＫＥセキュリティアソシエーション開始リクエストメッセージと開始応答メッセージを処理するために、前記第１のセキュリティアソシエーションを使用し、かつ前記メッセージ交換により、前記第１の基地局と前記ピアとなる基地局との間でピアツーピアセキュリティアソシエーションの確立をもたらし、
    前記ピアツーピアセキュリティアソシエーションに対するセキュリティパラメータインデックスを、ローカルのセキュリティパラメータインデックスデータベースへ、前記第１の基地局と前記ピアとなる基地局との一方の宛先に向けて転送される前記セキュリティパラメータインデックスにパケット群を照合させるためのメッセージ処理命令とともに追加する
    ことを特徴とする方法。

Images