通信システムは、インターネットプロトコル(IP)ベースのネットワークへとますます進化している。当該通信システムは相互接続された多くのネットワークから成り、当該ネットワーク内において、音声及びデータはある端末から別の端末へと断片状いわゆるパケット状で送信される。各IPパケットは各ルータによって接続のない状態であて先へルーティングされる。したがってパケットは、IPヘッダ及びペイロード情報によって構成されているともに、中でも当該ヘッダには送信元及びあて先IPアドレスが含まれる。
拡張性の理由から、IPネットワークは階層的なアドレス構造を用いている。それゆえにIPアドレスは、対応する端末を特定するだけでなく、この端末についての位置情報を含んでいる。ルーティングプロトコルによって提供される追加情報によって、ネットワーク内の各ルータは特定のあて先にあてられた次のルータを識別できる。
ある端末の電源が入ると、端末はアクセスネットワークのIPアドレスプレフィクスに基づいたIPアドレスを設定する。端末が移動性のある、いわゆるモバイルノード(MN:Mobile Node)であり、異なるIPプレフィクスアドレスを備えたサブネット間を移動した場合には、当該端末は階層的なアドレス構造を理由に、自身のIPアドレスを位相的に正確なアドレスへと変更しなければならない。しかしながら、TCP(Transmission Control Protocol:伝送制御プロトコル)接続を始めとする上位レイヤにおける接続は通信中のノードのIPアドレス(ならびにポート)によって規定されているので、移動等の理由からノードのうち1つが自身のIPアドレスを変更した場合には、アクティブなIPセッションへの接続が切断されることになる。
モバイルIPv6
MIPv6とも呼ばれるモバイルIPv6(D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6”, IETF RFC 3775, June 2004, available at http://www.ietf.orgより入手可能)は、モバイルノードが、上位レイヤならびにアプリケーションに対してトランスペアレントな態様で、すなわち上位レイヤでの接続が切断されることなく、サブネット間を移動するIPベースの移動体プロトコルである。すなわちモバイルノードは、IPv6インターネットネットワークの内部を移動している間にも、依然として到達可能である。MIPv6の主な原理は、モバイルノードはインターネット内における位相的な位置にかかわらずホームアドレス(HoA:Home Address)によって常に特定され、一方、モバイルノードの気付アドレス(CoA:Care of Address)はモバイルノードの現在の位相的位置に関する情報を提供することである。
より詳細には、1個のモバイルノードは2個のIPアドレス:気付アドレスならびにホームアドレスを構成してきた。モバイルノードの上位レイヤは、以降コレスポンデントノード(CN:Correspondent Node)と呼ばれる通信パートナー(あて先端末)との通信のためにホームアドレスを用いる。このアドレスは変化せず、モバイルノードの識別のための目的を果たす。位相的にホームアドレスは、モバイルノードのホームネットワークに属する。対照的に、気付アドレスはサブネット変更をきたすすべての移動ごとに変化し、ルーティングインフラストラクチャのためのロケータとして用いられる。位相的には、CoAはモバイルノードが現在訪問しているネットワークに属する。ホームリンク上に位置している一組のホームエージェント(HA:Home Agent)のうち1つは、モバイルノードのホームアドレスへのモバイルノードの気付アドレスのマッピングを保持するとともに、モバイルノードのための着信トラフィックを自身の現在位置に向けてリダイレクトする。1つのホームエージェントではなく一組のホームエージェントを配置する理由は、冗長ならびにロードバランシングでありうる。
現在、モバイルIPv6は2つの動作のモード:双方向トンネリング(図1)ならびに経路最適化(図2)を定義している。双方向トンネリングを用いる場合は、コレスポンデントノード101によって送信されモバイルノード102のホームアドレスへとあてられたデータパケットは、ホームネットワーク110内のホームエージェント111によってインターセプトされ、外部のネットワーク120にアンカされたモバイルノード102の気付アドレスへと向けてトンネリングされる。モバイルノード102によって送信されたデータパケットは、ホームエージェント111へリバーストンネリングされ、ホームエージェントはパケットのデカプセル化を行うとともに、それらパケットをコレスポンデントノード101へ送信する。リバーストンネリングは、パケットが、モバイルノードを始点としホームエージェントを終点とする追加的な(「通常の」トンネルを補完する)リバーストンネルを介して、モバイルノードによって送信されることを意味する。
MIPv6でのこの動作のためには、ホームエージェント111のみが、モバイルノード102の現在位置(すなわち、気付アドレス)を通知される。したがって、モバイルノードはバインディングアップデート(BU:Binding Update)メッセージをホームエージェントへ送信する。これらメッセージは、IPsecのセキュリティアソシエーション上において送信、ひいては認証され、完全性が保護される。MNがHAとのIPsecのアソシエーションを持つためには、MNはアプリオリにブートストラップを行う必要がある。ブートストラップは、少なくとも下記情報を取得する処理である:ホームアドレス、ホームエージェントアドレス、ならびに、ホームエージェントとのセキュリティアソシエーション。この情報は、MNがCoAをホームエージェントに登録する前に必要である。この処理は、MNとHAとの間には数回の往復が必要なので、数秒間持続しうる。
欠点は、モバイルノードがホームネットワークから遠く離れており、コレスポンデントノードがモバイルノードに近い場合には、通信経路が不要に長くなり、非効率なルーティングならびに高いパケット遅延をきたすことである。
経路最適化モード(図2を参照)は、コレスポンデントノードとモバイルノードとの間の直接パスを活用することによって、双方向トンネリングモードの非効率性を防止することができる。経路最適化を用いる際には、モバイルノードは、バインディングアップデートメッセージをコレスポンデントノードへ送信し、次いでコレスポンデントノードは、データパケットをモバイルノードへ直接送信できる(タイプ2ルーティングヘッダは、モバイルノードのホームアドレスあてのパケットを、モバイルノードの気付アドレスへの直接パス上で送信するのに用いられる)。当然のことながら、コレスポンデントノードはモバイルIPv6経路最適化サポートを実装しなければならない。
より具体的には、経路最適化を行うために、モバイルノードとコレスポンデントノードは、モビリティヘッダプロトコルの一部であるシグナリングメッセージを交換する。当該モビリティヘッダは、バインディングの作成と管理に関連した全メッセージング内にあるモバイルノード、コレスポンデントノード、ならびに、ホームエージェントによって用いられる拡張ヘッダである。経路最適化に関して、4つのメッセージタイプが、モビリティヘッダプロトコル中に規定されている。
図3は、MIPv6におけるROのために実行されるシグナリングフローを図示する。コレスポンデントノードへ送信されたバインディングアップデートの保護は、モバイルノードとコレスポンデントノードとの間におけるセキュリティアソシエーションの設定も、もしくは、認証インフラストラクチャの存在も必要としない。代わりに、リターンルータビリティ(RR:Return Rtoutablity)処理と呼ばれる方法が、正しいモバイルノードがメッセージを送信していることを確実にするのに用いられる。
リターンルータビリティ処理は、モバイルノードが実際には、自身のホームアドレスと同様に自身が主張する気付アドレスにおいてアドレス可能であることの一定の合理的な保証を、コレスポンデントノードが取得するのを可能にする。この保証によってのみ、コレスポンデントノードはモバイルノードからバインディングアップデートを受け取ることができ、次いでモバイルノードは、コレスポンデントノードに対して、モバイルノードのデータトラフィックを自身が主張する気付アドレスへと向けるよう指示する。
これは、2個の主張するアドレスにあてられたパケットがモバイルノードへルーティングされるか否かを試験することによって、行われる。モバイルノードは、コレスポンデントノードが当該アドレスへ送信する所定のデータ(「キーゲントークン」)を自身が受信した証拠を、自身が提供できる場合にのみ試験に合格することができる。これらデータは、モバイルノードによってバインディング管理キーに組み合わされる。バインディングアップデートメッセージのコレスポンデントノードに対する完全性ならびに認証は、バインディング管理キーを用いることによって保護されている。
MNは2個のメッセージをCNへ送信するが、それぞれ異なる経路上で送信する。一方のメッセージであるホームテスト開始(HoTi:Home Test init)メッセージが、MIPのIP−in−IPトンネル上でHA(図3には図示されない)へ送信され、HAは今度はメッセージをCNへ転送する。モバイルノードはホームテスト開始メッセージをコレスポンデントノードへ(ホームエージェントを介して)送信して、ホームキーゲントークンを取得する。図3から明らかなように、メッセージは、CNが後に返さなければならないホーム開始クッキーを含み、MNのホームアドレスをCNへ搬送する。気付キーゲントークンを取得するために、他方のメッセージ−気付テスト開始(CoTi:Care-of-Test init)−が直接CNへ送信される。CoTiメッセージはMNの現在の気付アドレスをCNへ通知するとともに、気付開始クッキーを含んでいる。CNもMIPv6を用いる場合は、HoTi及びCoTiメッセージは、CNのHAを介してCNへ送信される.
HoTi及びCoTiメッセージを受信した後に、CNは2個のメッセージを再び異なるルート上でMNへ返信する。ホーム試験(HoT:Home Test)メッセージは、HoTiメッセージに応答して、MNのHoA、すなわちHAへ送信される。HAは次いでMIPv6トンネル上でメッセージをMNへ転送する。したがって、気付テスト(CoT:Care-of-Test)メッセージが直接MNへ送信される。両メッセージHoT及びCoTは、「ホームキーゲントークン」及び「気付キーゲントークン」をそれぞれ、過去のHoTi及びCoTiメッセージからそれぞれ受信したホーム開始クッキー及び気付開始クッキーとともに含んでいる。両トークンとも、CNの現在アクティブな秘密キー、ノンス、及び、(それぞれ)ホーム又は気付アドレスに基づいている。
HoT及びCoTメッセージがMNに到達した後に、MNはキーゲントークンを用い、HoT及びCoTメッセージとともに受信したトークンからバインディング管理キーを生成する。モバイルノードはバインディング管理キーを作成した後、検証可能なバインディングアップデートをコレスポンデントノードへ供給することができる。CNはバインディングアップデートメッセージを受信した後、自身のバインディングキャッシュをMNのHoAならびにCoAのバインディングで更新できる。バインディングアップデートメッセージはバインディング受信確認メッセージによって受信確認される。HoTi−HoT及びCoTi−CoTメッセージの交換は、CNにより、あらかじめ取り決められたセキュリティアソシエーションを用いずにHoA−CoAの対応付けを検証するために用いられる。
このように、MIPv6は、CN内におけるMNのHoAとCoAの対応付けを可能にすることによって、CNとMNとの間における経路の最適化を可能にし、その結果、CNはMNと直接通信することができる。
プロキシMIPv6
モバイルIPは、モビリティ関連のシグナリングがホスト(又はクライアント)とHAとの間にあるので、ホストベース(又はクライアントベース)のモビリティ管理として分類される。それゆえに当該IPは時には、クライアントモバイルIP(CMIP)と呼ばれる。別のアプローチは、限定された地理上領域内のIPモビリティ管理をターゲットとしており、ネットワークによって管理されているので、MNに対してトランスペアレントである。このアプローチはネットワークベースのローカルなIPモビリティと呼ばれる。
ネットワークベースモビリティの1つの主な特徴は、アクセスネットワークエンティティが、MNの移動を検知し、MNの現在位置に関する情報を交換するよう適切に設定されていることであり、その結果、MNはモビリティ処理に関与する必要はない。
したがって、無線インタフェース上におけるモビリティ関連のシグナリングが回避される。ネットワークベースのモビリティ管理の他の利点は、MIPv6のカプセル化が必要ないため無線上でのパケットオーバーヘッドがより少ないこと、ならびに、簡素なIPノード(すなわち非MIP可能ノード)のためのモビリティサポートである。インターネット技術タスクフォース(IETF:Internet Engineering Task Force)機関は、モバイルIPプロトコルに基づくローカルなモビリティ管理のためのかかるアプローチに取り組んでいる。ネットワークエンティティはMNに代わってプロキシの役割を果たしているので、当該プロトコルはプロキシモバイルIP(PMIP:proxy mobile IP)と呼ばれる。PMIPv6と呼ばれるIPv6の変形、ならびに、PMIPv4と呼ばれるIPv4の変形がある。本発明の実施の形態のほとんどは、PMIPv6を、ネットワークベースのモビリティ管理のためのプロトコルと想定しているが、本発明はPMIPv6に限定されない。本発明は、PMIPv4を始めとする他のネットワークベースのモビリティ管理プロトコルにも適用可能である。
ネットワークの、制限され、位相的にローカルな部分の内部にある任意のIPv6ホストに対して、ホストの参加を必要とせずに、モビリティサポートを提供するために、プロキシモバイルIP(PMIP:proxy mobile IP)は、モバイルアクセスゲートウェイ(MAG:Mobile Access Gateway)と呼ばれる、自身のアクセスリンクに接続されたモバイルノードのためのモビリティ関連のシグナリングを管理するネットワーク内でのプロキシモビリティエージェントである、新規の論理エンティティを導入する。MAGは、モバイルノードのリンクへの接続の追跡、ならびに、モバイルノードのローカルモビリティアンカのシグナリングに責任を負うエンティティである。MAGは通常、アクセスルータ(AR:Access Router)と同位置に配置されており、モバイルノードに代わってモバイルIPv6シグナリングメッセージを実行、例えば、MNに代わってBUメッセージを送信できる。これらBUメッセージにはフラグが付けられており、その結果、当該メッセージはプロキシBU(PBU)メッセージとして識別できる。さらにPBUメッセージは、ネットワークアクセス識別子(NAI:Network Access Identifier)オプション、ホームプレフィクスオプション、ならびに、タイムスタンプオプションを含んでもよい。NAIオプションは「username@realm」の形式を持ち、MNを特定するのに用いられるNAIを含んでいる。ホームプレフィクスオプションはHoA又はMNのホームプレフィクスを含んでいる。いわゆる「MNごとのプレフィクスアドレス指定モデル」では、すべてのMNは固有のホームプレフィクスを持ち、MNのグローバルIPアドレス(1つまたは複数)はこのプレフィクスに基づいて構成されている。HoAの代わりに固有のホームプレフィクスがPBUメッセージ中に用いることができる。タイムスタンプオプションは、MAGがPBUを送信した時間を含んでおり、PBUメッセージの鮮度を特定するのにHAによって用いられる。PBUメッセージのシーケンス番号値はHAによって無視される。
ローカルモビリティアンカ(LMA:Local Mobility Anchor)は、プロキシモバイルIPv6ドメイン内のモバイルノードのためのホームエージェントである。LMAは、モバイルノードのホームプレフィクスのための位相的アンカポイントであるとともに、モバイルノードの到達可能性の状態を管理するエンティティである。LMAが、モバイルIPv6ベース仕様に規定されるホームエージェントの機能的な能力を有し、プロキシモバイルIPv6をサポートするために要求される付加的な能力を有することを理解することは重要である。
MNは新規MAGに接続する際に、EAPフレームワーク、ならびに、EAP−AKA等のEAP方法を用いて、ネットワークに認証する。MAGは典型的にはパススルー認証者としての役割を果たし、EAPパケットをMNに関連したAAAサーバ/インフラストラクチャへ転送する。MNはNAIを識別子として用いる。ネットワーク認証が成功した場合は、MAGはMNのホームプレフィクスを含むMNのプロファイルをAAAサーバから取得する。次いでMAGは、PBUをHAへ送信し、MNにホームプレフィクスを通知する。MNはARに対して認証した後に、IP設定を開始する。すなわちMNはリンクローカル(LL:link-local)なIPアドレスを設定し、近隣要請(NS:Neighbour Solicitation)メッセージを、確認されるべきLLアドレスの要請ノードマルチキャストアドレスへ送信することによって、LLアドレスのための重複アドレス検知(DAD:Duplicate Address Detection)を行う。当該処理に成功した場合は、MNは、対応するマルチキャストアドレスを介して、ルータ要請(RS:Router Solicitation)メッセージを全ルータへ送信し、ルータ アドバタイズメント(RA:Router Advertisement)の受信を待つ。AR/MAGは、MNのホームプレフィクスを含むユニキャストRAによって応答する。
グローバルIPアドレスを設定した後は、MNはIPに到達可能であり、自身がPMIPドメインの内部を移動する限り、IPアドレスを用いることができる。初期登録処理中におけるPMIPv6のための例示的なシグナリングフローを上記のように図4に示す。
図5は例示的な一シナリオを示しており、ここでは、2個のモバイルノードMN1及びMN2が、訪問ネットワーク(VN:visited network)内に位置しており、互いの間で通信セッションを開始することを望んでいる。MIPv6トンネルが、モバイルノードMN1/MN2と、ホームネットワークHN1、HN2内の対応する各ホームエージェントHA1/HA2との間に存在する。図示目的のため、MN1とHA1との間、ならびに、MN2とHA2との間の各MIPv6トンネルは図5から省略されている。
両方のVNにおいて、PMIPv6サービスがMNに提供されている。すなわち、MN1はVN1の内部を移動しながら、同一の気付アドレス(CoA:Care-of-Address)を保持する。MN1はMAG1に接続されており、VN1内にあるLMAで登録されている。同様に、MN2はMAG2に接続されており、VN2内にあるLMA2で登録されている。再び、MAG1とLMA1との間、ならびに、MAG2とLMA2との間のPMIPv6トンネルは、概略を見やすくするため、図5には示されていない。
MN1とMN2との間のデータパスはホームネットワーク(図5中実線)を横断するので、データパケットの端末相互間の遅延は重大である。MN1がMIPv6の経路最適化を行った場合は、結果として生じたデータパスは、LMA1(VN1内)からHA2(HN2)へと、さらにはVN2内にあるLMA2/MAGへと横断する点線となるであろう。その理由は、MN2からのデータパケットは、LMA1でアンカされているMNのCoAへ直接送信されるからである。別の最適化は、MN2もMIPv6−ROを行う場合に、LMA1(VN1内)とLMA2(VN2内)との間を直接経由する、いずれのHN、すなわちHN1、HN2も横断しない破線で示されたデータパスをきたすであろう。
記載したシナリオは、第3世代移動体通信システムの標準化プロジェクト(3GPP:3rd Generation Partnership Project)において標準化されたシステム構成エボルーション(SAE:System Architecture Evolution)の作業項目にマッピングすることができる。SAEの術語を用いると、各インタフェースMN1−HA1ならびにMN2−HA2はS2cインタフェースと記述することができる。
別の例示シナリオを図6に示す。このシナリオではMN1に関して変更はない。MN1をHN1内のHA1にMIPv6を用いて接続し、PMIPv6は訪問ネットワークVN1内にあるMN1に提供されている。しかしながら図5とは異なり、MN2はPMIPv6を介して、訪問ネットワークVN2からホームネットワークHN2へ接続され、MN2にMIPv6は用いられない。PMIPトンネルは、VN2内のMAG2とHN2内のLMA2との間でセットアップされるが、しかしながらこれは図示目的のために省略される。
かかるシナリオがあるので、PMIPv6サービスがHN2とVN2の両方のMN2に提供されるが、このことは、MN2が、HN2とVN2との間を移動しながら同一のIPアドレスを保持することを意味する。ROがない場合のデータパスが実線で示される。破線は、MN1がMIPv6のROを行うであろう場合のデータパスを示す。当然のことながら、MN2はMIPv6の経路最適化を行うことはできない。
図5及び6から明らかなように、モバイルノードMN1及びMN2の間のデータパスは、それぞれのMIPv6のROが両方のMNによって実行された後であってさえも、最適ではない。同様の問題は、MN2が固定されている場合、すなわちMN2がモビリティ管理サービスを持たない時を始めとする他の各シナリオにも存在する。
したがって、従来の上記の問題に鑑みて、本発明の1つの目的は、互いに通信中であり、それぞれのアクセスゲートウェイを介して異なるネットワークに接続されている2個のモバイルノードの間においてより短いデータパスを提供することである。
本発明のより具体的な目的は、各アクセスゲートウェイに対し、それらの間により短いデータパスを確立するために必要な情報を提供する方法である。
上記の目的のうち少なくとも1つの目的は独立請求項の主題によって解決される。本発明の有利な実施の形態は従属請求項の各主題である。
モバイルノードの2個のホームネットワークを経由するデータパスを用いる代わりに、ノード間におけるセッションを開始する際に、2個のアクセスゲートウェイを経由するデータパスが確立される。しかしながら、それを行うためには、2個のMAGは、接続しているモバイルノードから来るデータパケットを正確に転送できるよう、互いのことを把握している必要がある。以下において、本発明によるいくつかのアプローチが記載される。
本発明の1つの実施の形態によると、各モバイルノードに対し、自身が接続しているアクセスゲートウェイ(以下、MAGと称する)を通知するべく、SIPシグナリングが最初に用いられる。引き続いて、2個のモバイルノードのそれぞれによって経路最適化処理が開始され、この経路最適化処理によって、各MNはネットワークへの接続に際して経由しているアクセスゲートウェイを、他方のモバイルノードへ通知する。例えば、MN1の経路最適化は、MAG1のID又はIPアドレスに関する情報をMN2に提供するであろうし、逆もまた同じである。さらに各MAGは、他方のMAGのID又はIPアドレスを把握するべく、MNから来るパケットを傍受する能力を備えている。例えば、MAG1は、MN1から来るパケットを、当該パケットからMAG2のIDを抽出するために傍受する能力がある。都合よく、上述の経路最適化処理中には、経路最適化を開始するMNの位置依存性アドレス(以下CoAと称する)もまた、他方のMAGのIDとともに、他方のMNへと提供される。したがってMAGは、接続しているMNから受信した、他方のMAGへのより短いデータパスを確立するのに十分な情報を備えるデータパケットを傍受した時に、他方のMNのCoAについてもまた把握する。
本発明の別の実施の形態によると、SIPシグナリングが再び用いられる。しかしながら今回は、各MNには、自身のアクセスゲートウェイと、相手側のMNのアクセスゲートウェイが通知される。すなわち、MN2はMAG1のIDとMAG2のIDを把握するようになり、その逆もまた生じる。各MAGは適切な情報を得るために、各MNからの前記情報を含むメッセージをインターセプトし、これによって、他方のMNのアクセスゲートウェイを把握する。都合よく、各MNは、他方のMNがパケットを読み取り可能な正しいパケット形式でデータパケットを送信できるように、他方のMNに対する経路最適化処理を開始する。さらに都合よく、MAG1のIDおよびMAG2のIDによってセッションをセットアップしている間に各MNは、同一のSIPシグナリング処理中に他方のMNの気付アドレスも通知される。次いで各MAGは、MNからのメッセージをインターセプトする際には、他方のMNのCoAも把握するであろう。このようにして各MAGは、MN間におけるより短いデータパスをセットアップするのに必要な情報を有する。
本発明のさらに別の実施の形態によると、SIPシグナリングが、MNのそれぞれの管理サーバに対して必要な情報を通知するのに用いられ、当該管理サーバは、前記情報を各MNが接続しているアクセスゲートウェイへ転送する。より詳細には、SIPシグナリング中に各MNの管理サーバには、他方のMNのMAGのID/IPアドレスが通知される。例えば、MN1の管理サーバはMAG2のIDを、それに対応してMN2のIDも把握するようになる。次いで各管理サーバは、他のMAGのIDをMAGへ通知する適切なメッセージを、各MAGへ送信することができる。都合よく、各MNは、他方のMNがパケットを読み取り可能な正しいパケット形式でデータパケットを送信できるように、他方のMNに対する経路最適化処理を開始する。さらに都合よく、セッションをセットアップしている間に各管理サーバは、同一のSIPシグナリング処理中である各セッション管理サーバによって、他方のMNの位置依存性アドレスが通知される。とりわけMN1の管理サーバは、MN1のセッション管理サーバから、MAG2のIDについて、ならびに、MN2の位置依存性アドレスについて把握するであろう。次いで、各MAGは対応する管理サーバから、他方のMAGのIDとともに他方のMNの位置依存性アドレスを受信するであろう。
異なる実施態様によると、相手側のMAGのIDならびにIPアドレスを推論するために、2個のMN又は2個のMAGのうちそれぞれ1つ等、異なるエンティティによって、ドメイン名解決処理ならびにドメイン名リバース解決処理が用いられる。前記処理を行った後に、MAGのIDならびにIPアドレスがアクセスゲートウェイ間におけるデータパスを確立するのに用いられる。
ここで一実施態様を参照すると、第1のMNは自身のアドレスのIPプレフィクスと関連付けられたドメイン名を推論し、ドメイン名はネットワークによって通告されたプレフィクスに属する。前記推論したドメイン名は次いで第2のMNへ転送され、第2のMNはその後メッセージを第2アクセスゲートウェイを介して第1のMNへ送信し、その結果、第2アクセスゲートウェイは推論したドメイン名を含む前記メッセージをインターセプトできるようになる。前記メッセージをインターセプトすることによって、第2アクセスゲートウェイはドメイン名について把握し、前記ドメイン名に属するIPアドレスを解消しうる。次いで第2アクセスゲートウェイは、解消したIPアドレスに属するエンティティに対する経路最適化処理を開始する。解消したIPアドレスに属するエンティティがすでに第1アクセスゲートウェイではない場合は、経路最適化処理のためのメッセージは、前記エンティティによって、第1アクセスゲートウェイへ転送される。第1アクセスゲートウェイは、経路最適化処理のためのメッセージを受信した後ただちに、それに応じて前記第2アクセスゲートウェイに応答する。経路最適化のためのメッセージを第1アクセスゲートウェイへ転送することによって、たとえドメイン名から推論したIPアドレスが第1アクセスゲートウェイと関連付けられていない場合であっても、結局のところ、両方のアクセスゲートウェイの間に結果として生じたデータパスが確立される。
本発明の他の実施態様によると、第1のMNが自身のCoAのプレフィクスを直接第2のMNへ送信し、第2のMNは今度は前記CoA−プレフィクスを含むメッセージを、自身を接続する第2アクセスゲートウェイを介して送信する。第2アクセスゲートウェイは次いで、第1のMNのCoAプレフィクスを把握するために前記メッセージを受ける。前の実施態様と同様、まず必要なことは、前記ドメイン名、ひいてはネットワーク内のプレフィクスをアンカするエンティティに属するIPアドレスを決定する前に、CoA−プレフィクスと関連付けられたドメイン名を、第2アクセスゲートウェイにより推論することである。代替的には第2アクセスゲートウェイは、CoA−プレフィクスに対応するネットワークドメイン内にある適切なサーバに連絡し、第1アクセスゲートウェイのIPアドレスを依頼してもよい。都合よく、前記適切なサーバは、管理サーバ(AAA(認証、許可及びアカウンティング)サーバ等)でありうる。
再び、第2アクセスゲートウェイは次いで、決定したIPアドレスに属するエンティティに対する経路最適化処理を開始する。解消したIPアドレスに属するエンティティがすでに第1アクセスゲートウェイでない場合は、経路最適化処理のためのメッセージは、前記エンティティによって、第1アクセスゲートウェイへ転送される。第1アクセスゲートウェイは、経路最適化処理のためのメッセージを受信した後ただちに、それに応じて前記第2アクセスゲートウェイに応答する。
さらに別の実施態様によると、第1のMNは通常の経路最適化を行い、その間に第2のMNは第1のMNのCoAを把握する。例えば第2アクセスゲートウェイは、第1のMNのCoAの受信を通常通り受信確認した時に、前記受信確認メッセージを受け、第1のMNのCoAを把握する。次いで、前と同じく、MNのCoAからドメイン名が推論され、引き続いて、前記ドメイン名に属するIPアドレスが決定される。次いで経路最適化処理は、第2アクセスゲートウェイによってあて先としての決定したIPアドレスに対して開始される。このことは、当該エンティティによる前記決定したIPアドレスに対する前記経路最適化のためのメッセージを第1アクセスゲートウェイへ転送することを含みうる。
代替的には、第2アクセスゲートウェイは、第1のMNのCoAのプレフィクスと関連付けられたサーバに対し、第1アクセスゲートウェイのIPアドレスを依頼してもよい。
他の実施態様によると、第1及び第2のMNは互いのホームアドレスを把握している。第2のMNが、例えば第1のMNのホームアドレスを含むメッセージを送信することによって、第2アクセスゲートウェイは第1のMNのホームアドレスを把握することができる。次いで第2アクセスゲートウェイは、第1アクセスゲートウェイのアドレスを依頼するために、第1のMNのホームアドレスのIPプレフィクスに対応する適切な管理サーバに連絡してもよい。
上記には、各アクセスゲートウェイが、それらの間のより短いデータパスを確立できるように、互いの識別情報及び/又はアドレスを把握することを可能にするいくつかの方法を記載してきた。図7に示すように、両方のMAGが互いを把握しているので、両者は他方のMNあてのデータパケットを、相手側のMAGへ直接リダイレクトできる。
本発明の1つの実施の形態は、第1ネットワークにモバイルノードを接続している第1アクセスゲートウェイに、第2ネットワークにコレスポンデントノードを接続している第2アクセスゲートウェイの識別情報を通知する方法を提供する。当該コレスポンデントノードには、当該モバイルノードと当該コレスポンデントノードとの間におけるセッションイニシエーションのためのメッセージを用いることによって、当該第2アクセスゲートウェイの識別情報が通知される。さらに当該モバイルノードには、当該モバイルノードによって当該コレスポンデントノードに対して開始された第1の経路最適化処理のメッセージを用いて、当該第2アクセスゲートウェイの識別情報が通知される。次いで当該第1アクセスゲートウェイは、当該第2アクセスゲートウェイの識別情報を含むメッセージであって、当該モバイルノードから当該コレスポンデントノードへ送信されたメッセージから、当該第2アクセスゲートウェイの識別情報を抽出する。
本発明の有利な実施の形態によると、当該モバイルノードには、当該モバイルノードと当該コレスポンデントノードとの間におけるセッションイニシエーションのためのメッセージを用いることによって、当該第1アクセスゲートウェイの識別情報が通知される。当該コレスポンデントノードには次いで、当該モバイルノードによって当該コレスポンデントノードに対して開始された第2の経路最適化処理のメッセージを用いることによって、当該第1アクセスゲートウェイの識別情報が通知される。当該第2アクセスゲートウェイは、当該第1アクセスゲートウェイの識別情報を含むメッセージであって、当該コレスポンデントノードから当該モバイルノードへ送信された他のメッセージから、当該第1アクセスゲートウェイの識別情報を抽出する。
本発明の別の実施の形態では、当該第2アクセスゲートウェイの識別情報を含むメッセージであって、当該モバイルノードから当該コレスポンデントノードへ送信された当該メッセージは、当該第2の経路最適化処理の一部である。
本発明の実施の形態に詳細に記載された態様を参照すると、当該第1及び第2アクセスゲートウェイの当該抽出された識別情報を用いて、当該第2/第1アクセスゲートウェイ内において当該モバイル/コレスポンデントノードあてのデータパケットを当該第1/第2アクセスゲートウェイへルーティングすることによって、当該第1及び第2アクセスゲートウェイの間におけるデータパスが確立される。
本発明の1つの実施の形態は、コレスポンデントノードとデータパケットを交換するモバイルノードを提供する。当該モバイルノードは第1アクセスゲートウェイによって第1ネットワークに接続されており、当該コレスポンデントノードは第2アクセスゲートウェイによって第2ネットワークに接続されている。当該モバイルノードの受信器は、当該モバイルノードと当該コレスポンデントノードとの間におけるセッションイニシエーションのための、当該第1アクセスゲートウェイの識別情報を含むメッセージを受信する。当該モバイルノードの送信器は、当該第1アクセスゲートウェイの識別情報を含むメッセージであって、第1の経路最適化処理のメッセージを、当該コレスポンデントノードへ送信する。当該受信器は、当該第2アクセスゲートウェイの識別情報を含むメッセージであって、第2の経路最適化処理のメッセージを、当該コレスポンデントノードから受信する。当該送信器はさらに、当該第2アクセスゲートウェイの識別情報を含むメッセージを、当該第1アクセスゲートウェイを介して、当該コレスポンデントノードへ送信する。
本発明の1つの実施の形態は、第2ネットワークにコレスポンデントノードを接続している第2アクセスゲートウェイへのデータパスを確立するために、第1ネットワークにモバイルノードを接続しているアクセスゲートウェイを提供する。当該アクセスゲートウェイの受信器は、当該第2アクセスゲートウェイの識別情報を含むメッセージであって、当該モバイルノードから当該コレスポンデントノードあてのメッセージをインターセプトする。当該アクセスゲートウェイの処理装置は、当該モバイルノードからの当該受信されたメッセージから、当該第2アクセスゲートウェイの識別情報を抽出する。当該処理装置はさらに、当該第2アクセスゲートウェイの当該抽出された識別情報に基づいて、当該第2アクセスゲートウェイへのデータパスを確立する。当該アクセスゲートウェイの送信器は次いで、当該モバイルノードから受信され当該コレスポンデントノードあてのデータパケットを、当該第2アクセスゲートウェイへ転送する。
本発明の1つの実施の形態は、モバイルノードとコレスポンデントノードとの間における通信セッションを確立するためのセッション管理サーバを提供する。当該モバイルノードは第1アクセスゲートウェイによって第1ネットワークに接続されており、当該コレスポンデントノードは第2アクセスゲートウェイによって第2ネットワークに接続されている。当該セッション管理サーバの受信器は、当該モバイルノードからセッションイニシエーションメッセージを受信する。当該セッション管理サーバの送信器は、当該モバイルノードと関連付けられたサーバから当該第1アクセスゲートウェイの識別情報を依頼する。当該セッション管理サーバの処理装置は、当該第1アクセスゲートウェイの識別情報を当該セッションイニシエーションメッセージに挿入する。当該送信器はさらに、当該セッションイニシエーションメッセージを当該コレスポンデントノードへ転送する。
本発明の他の実施の形態は、第1ネットワークにモバイルノードを接続している第1アクセスゲートウェイに、第2ネットワークにコレスポンデントノードを接続している第2アクセスゲートウェイの識別情報を通知する方法を提供する。当該モバイルノードには、当該モバイルノードと当該コレスポンデントノードとの間におけるセッションイニシエーションのためのメッセージを用いることによって、当該第1及び第2アクセスゲートウェイの識別情報が通知される。当該第1アクセスゲートウェイは、当該モバイルノードが開始した第1の経路最適化処理のために当該モバイルノードから当該コレスポンデントノードへと当該第1アクセスゲートウェイを介して送信されたメッセージから、当該第2アクセスゲートウェイの識別情報を抽出する。
本発明の有利な実施の形態によると、当該コレスポンデントノードには、当該モバイルノードと当該コレスポンデントノードとの間における当該セッションイニシエーションのためのメッセージを用いることによって、当該第1及び第2アクセスゲートウェイの識別情報が通知される。当該第2アクセスゲートウェイは、当該コレスポンデントノードが開始した第2の経路最適化処理のために当該コレスポンデントノードから当該モバイルノードへと第2アクセスゲートウェイを介して送信されたメッセージから、当該第1アクセスゲートウェイの識別情報を抽出する。
本発明の他の有利な実施の形態では、当該第1及び第2アクセスゲートウェイの当該抽出された識別情報を用いて、当該第2/第1アクセスゲートウェイ内において当該モバイル/コレスポンデントノードあてのデータパケットを当該第1/第2アクセスゲートウェイへルーティングすることによって、当該第1及び第2アクセスゲートウェイの間におけるデータパスが確立される。
本発明の他の実施の形態は、コレスポンデントノードとデータパケットを交換するモバイルノードをさらに提供する。当該モバイルノードは第1アクセスゲートウェイによって第1ネットワークに接続されており、当該コレスポンデントノードは第2アクセスゲートウェイによって第2ネットワークに接続されている。当該モバイルノードの受信器は、当該モバイルノードと当該コレスポンデントノードとの間におけるセッションイニシエーションのための、当該第1及び第2アクセスゲートウェイの識別情報を含むメッセージを受信する。当該モバイルノードの送信器は、当該第2アクセスゲートウェイの識別情報を含むメッセージを、当該第1アクセスゲートウェイを介して当該コレスポンデントノードへ送信する。
本発明の他の実施の形態は、第2ネットワークにコレスポンデントノードを接続している第2アクセスゲートウェイへのデータパスを確立するために、第1ネットワークにモバイルノードを接続しているアクセスゲートウェイをさらに提供する。当該アクセスゲートウェイの受信器は、当該第2アクセスゲートウェイの識別情報を含むメッセージであって、当該モバイルノードから当該コレスポンデントノードあてのメッセージをインターセプトする。当該アクセスゲートウェイの処理装置は、当該モバイルノードからの当該受信されたメッセージから、当該第2アクセスゲートウェイの識別情報を抽出する。当該処理装置はさらに、当該第2アクセスゲートウェイの当該抽出された識別情報に基づいて、当該第2アクセスゲートウェイへのデータパスを確立する。アクセスゲートウェイの送信器は、当該モバイルノードから受信され当該コレスポンデントノードあてのデータパケットを、当該第2アクセスゲートウェイへ転送する。
本発明の他の実施の形態は、モバイルノードとコレスポンデントノードとの間における通信セッションを確立するためのセッション管理サーバを提供する。当該モバイルノードは第1アクセスゲートウェイによって第1ネットワークに接続されており、及び、当該コレスポンデントノードは第2アクセスゲートウェイによって第2ネットワークに接続されている。当該セッション管理サーバの受信器は、当該モバイルノードからセッションイニシエーションメッセージを受信する。当該セッション管理サーバの送信器は、当該モバイル/コレスポンデントノードと関連付けられたサーバから当該第1/第2アクセスゲートウェイの識別情報を依頼する。当該セッション管理サーバの処理装置は、当該第1/第2アクセスゲートウェイの識別情報を当該セッションイニシエーションメッセージに挿入する。さらに当該送信器は、当該セッションイニシエーションメッセージを当該コレスポンデントノードへ転送する。
本発明のさらに別の実施の形態は、第1ネットワークにモバイルノードを接続している第1アクセスゲートウェイに、第2ネットワークにコレスポンデントノードを接続している第2アクセスゲートウェイの識別情報を通知する方法を提供する。当該モバイルノードの第1管理サーバには、当該モバイルノードと当該コレスポンデントノードとの間におけるセッションイニシエーションのためのメッセージを用いることによって、当該第2アクセスゲートウェイの識別情報が通知される。次いで、当該第1管理サーバは、当該第1アクセスゲートウェイに当該第2アクセスゲートウェイの識別情報を通知する。
他の有利な実施の形態によると、当該コレスポンデントノードの第2管理サーバには、当該モバイルノードと当該コレスポンデントノードとの間における当該セッションイニシエーションのためのメッセージを用いることによって、当該第1アクセスゲートウェイの識別情報が通知される。次いで当該第2管理サーバは、当該第2アクセスゲートウェイに当該第2アクセスゲートウェイの識別情報を通知する。
本発明のさらに別の実施の形態は、第2ネットワークにコレスポンデントノードを接続している第2アクセスゲートウェイへのデータパスを確立するために、第1ネットワークにモバイルノードを接続しているアクセスゲートウェイをさらに提供する。当該アクセスゲートウェイの受信器は、当該第2アクセスゲートウェイの識別情報を含むメッセージを当該モバイルノードの管理サーバから受信する。次いで当該アクセスゲートウェイの処理装置は、当該管理サーバからの当該受信されたメッセージから、当該第2アクセスゲートウェイの識別情報を抽出する。当該処理装置はさらに、当該第2アクセスゲートウェイの当該抽出された識別情報に基づいて、当該第2アクセスゲートウェイへのデータパスを確立する。当該アクセスゲートウェイの送信器は、当該モバイルノードから受信され当該コレスポンデントノードあてのデータパケットを、当該第2アクセスゲートウェイへ転送する。
本発明のさらに別の実施の形態は、モバイルノードとコレスポンデントノードとの間における通信セッションを確立するためのセッション管理サーバをさらに提供する。当該モバイルノードは第1アクセスゲートウェイによって第1ネットワークに接続されており、当該コレスポンデントノードは第2アクセスゲートウェイによって第2ネットワークに接続されている。当該セッション管理サーバの受信器は、当該モバイルノードからセッションイニシエーションメッセージを受信する。当該セッション管理サーバの送信器は、当該モバイルノードの管理サーバから当該第1アクセスゲートウェイの識別情報を依頼する。当該セッション管理サーバの処理装置は、当該第1アクセスゲートウェイの識別情報を、当該セッションイニシエーションメッセージに挿入する。次いで当該送信器は、当該第1アクセスゲートウェイの当該挿入された識別情報を含む当該セッションイニシエーションメッセージを、当該コレスポンデントノードへ転送する。さらに当該受信器は、当該第2アクセスゲートウェイの識別情報を含む第2のイニシエーションメッセージを、当該コレスポンデントノードの第2セッション管理サーバから受信する。当該送信器は、当該第2アクセスゲートウェイの識別情報を含むメッセージを当該管理サーバへ送信する。
本発明のさらに別の実施の形態は、第1アクセスゲートウェイによって第1ネットワークに接続されたモバイルノードを管理するための管理サーバを提供する。当該モバイルノードは、第2アクセスゲートウェイによって第2ネットワークに接続されたコレスポンデントノードとの通信セッションを確立する。当該管理サーバの受信器は、当該第2アクセスゲートウェイの識別情報を含むメッセージを、当該モバイルノードのセッション管理サーバから受信する、。次いで、当該管理サーバの送信器は、当該第2アクセスゲートウェイの識別情報を含むメッセージを、第1アクセスゲートウェイへ送信する。
本発明のさらに別の実施の形態によると、モバイルノードはこのモバイルノードに接続されているアクセスゲートウェイの識別情報を取得する。当該モバイルノードは、他方のモバイルノード(コレスポンデントノード)に当該アクセスゲートウェイの識別情報を通知するためのメッセージを送信する。このメッセージは他方のモバイルノードの識別情報に付加され、このモバイルノードのアクセスゲートウェイによってインターセプトされる。このモバイルノードのアクセスゲートウェイは、他方のモバイルノードの識別情報を、このメッセージから抽出することによって把握し、モバイルノード間におけるRO処理のための準備を開始する。
定義
以下において、本文書中に高頻度に用いられる2、3の術語の定義をする。
モバイルノードは通信ネットワーク内にある物理的なエンティティである。ある1個のノードが数個の機能エンティティを持ちうる。機能エンティティとは、所定の一組の機能を、ノード又は当該ネットワークの他の機能エンティティに、実装及び/又は提供するソフトウェア又はハードウェアモジュールのことをいう。各ノードは、ノードを、ノードが通信可能な通信施設、もしくは媒体に接続する、1個又は複数のインタフェースを持ちうる。同様にネットワークエンティティは、機能エンティティを、他の機能エンティティ又はコレスポンデントノードと通信可能な通信施設、もしくは媒体に接続している論理インタフェースを持ちうる。
セッション管理サーバは、MNと関連付けられたエンティティであり、他のCNとの通信セッションを確立する際にMNの助けとなる。セッションイニシエーションプロトコル(SIP:Session Initiation Protocol)を用いる際には、セッション管理サーバは、SIP−レジストラ又はSIP−プロキシとなり得る。
管理サーバはMNと関連付けられたエンティティであり、MNと接続される認証、許可及びアカウンティングの問題を管理する。通常今日の各システムでは、このタスクはAAAサーバによって実行される。
本発明を通して、術語「MAG−ID」(アクセスゲートウェイの識別)が用いられている。MAGのIPアドレスの代わりにMAGのIDをMNに対して通知する1つの理由は、MNは、ネットワークエンティティのIPアドレスを把握するべきではないからである。このことは、エンドノードがサービス妨害(DoS:Denial of Service)攻撃をネットワークインフラストラクチャに対して行うのを回避するために、大部分のネットワーク事業者により要求されている。エンドノードがMAG−IDのみを知っていて、MAGのIPアドレスを解消できない場合に、前記要件が達成される。MAG−IDは例えば、ドメイン名システム(DNS:Domain Name System)ツリー階層内にあるノードの位置を規定する明確なドメイン名である、完全に記述したドメイン名(FQDN:Fully Qualified Domain Name)であってもよい。MAG1のためのFQDNの一例は「mag1.operatorXYZ.com」である。対応するIPアドレスに対するMAGのFQDNの解消がセキュアDNSに基づいている場合は、認証されたエンティティのみがDNSサーバに連絡し、MAGのFQDNを自身のIPアドレスへ解消することができる。MAG及びLMAといったネットワークエンティティとは異なり、エンドノードは通常、MAG−IDを自身のIPアドレスへ解消することは認証されない。しかしながら、反対にネットワーク事業者によっていかなる要件も設定されていない場合には、MAGのIPアドレスはMAG−IDとしても用いられうる。
上記の技術分野のセクションで提供された説明は、本明細書中に記載された特定の例示的な実施の形態をよりよく理解するためのものであり、本発明を移動体通信ネットワーク内における処理ならびに機能の記載された特定の実装に限定するものとして理解されるべきではない。それにもかかわらず、本明細書中に提案された改良は、技術分野のセクション中に記載されたアーキテクチャ/システム内に容易に適用されうるとともに、本発明のいくつかの実施の形態においても、これらアーキテクチャ/システムの標準的な処理ならびに改良された処理を活用している。同様に、以下の段落では本発明の様々な実施の形態を記載する。本発明は都合よく、3GPP通信システムを始めとする様々な移動体通信システムとの接続に例えば用いられうるが、本発明はこの特定の例示的な通信ネットワーク内での使用に限定されないことに留意するべきである。
図5及び6から明らかなように、LMA(LMA1及びLMA2)を介した、もしくは、HA(HA1及びHA2)を介したデータパスは迂回路であり、このため、MN間における通信の端末相互間の遅延が大幅に増大している。図7は、図4に提示したシナリオと同一の設定を示しているが、MN1からMN2へのMAG1及びMAG2を経由した、及びその逆向きの、より短いデータパスを示している。
図8は、図7に示すようなより短いデータパスを達成するためにMAGに適切な情報を提供するための、本発明の第1の実施の形態のシグナリング図を示す。最初の2個のメッセージ、「invite」及び「ringing」は、例えば後述するセッションイニシエーション処理(下記のSIPシグナリングの見出しを参照)に基づいた2個のMN、すなわちMN1とMN2との間におけるセッションイニシエーションに属している。この例示的なシナリオでは、当該セッションはMN1が「invite」メッセージをMN2へ送信することによって開始される。図8には示されないが、MNが他の通信パートナーとの通信セッションを確立する際にMNの助けとなるべく、専用のセッション管理サーバがネットワーク内に提供されている。さらに、前記セッション管理サーバは、ある特定のMNが接続されるMAGを把握済である。このようにして、MAG2−IDは、MNが受信する前に、VN1内のMNと関連付けられたセッション管理サーバによって、inviteメッセージに挿入される。inviteメッセージに応答して、MN2により、ringingメッセージがMN1へ返送される。同様に、MAG1のIDが、MN2が前記メッセージを受信する前に、VN2のセッション管理サーバによって、ringingメッセージに挿入される。
inviteメッセージは、MN2がMN1に対して経路最適化処理を開始するためのトリガも含んでおり、経路最適化処理のメッセージのうち少なくとも1つのメッセージは、(inviteメッセージとともに受信した)MAG2のIDをMN2のCoAとともにさらに含むよう、拡張されている。したがって、別の経路最適化がMN1によってMN2に対して開始され、当該経路最適化はMN2に対して、(ringingメッセージとともに受信した)MAG1のIDならびにMN1のCoAに関する情報を提供する。
都合よく、MN1からMN2へ送信された上述のルート最適化処理の1個のメッセージは、MN1により、MAG2のIDならびにMN2のCoAを付けて拡張される。前記メッセージは次いで、MAG1によりインターセプトされ、MAG1はMAG2のIDとMN2のCoAの両方を把握し、前記メッセージをMN2へ転送する。このようにしてMN2はMAG1のIDならびにMN1のCoAについて把握する。MAG1がMAG1のIDならびにMN1のCoAを把握するために、MN2は前記情報を含むメッセージをMN1へ送信する。MAG2は、必要な情報を把握するために前記メッセージをインターセプトすることのみが必要であり、次いで、メッセージを自身のあて先へ転送する。
同様に、両MAG、すなわちMAG1、MAG2は、他方のMAGならびに他方のMNに関する必要な識別情報を所有する。このようにして、MAG1とMAG2との間のトンネルを双方向に確立することができ、ひいては当該トンネルを介してデータパケットを転送する。
とりわけ、MAG1内でのルーティングエントリは、MAG1に対し、MN2のCoAあてのデータパケットを直接MAG2へ、さらにMAG2からMN2へ転送するよう促すであろう。同様に、MAG2内でのルーティングエントリは、MAG2に対し、MN1のCoAあてのデータパケットを直接MAG1へ、さらにMAG1からMN1へ転送するよう促すであろう。
両MAG間の一方向トンネルも同様に可能であることにも留意するべきである。したがって、上記の情報交換は完全に実行されるべきものではない。むしろ、2個のMAGのうち一方に対し、他方のMAGのIDならびに他方のMNのCoAアドレスを通知するために必要なステップのみが、実行されるものとする。当業者は、追加の明示的な助言なしに上記の情報交換を前記目的に適応させることができる。
MAG間におけるトンネルを確立するための上記の原理は、比較的一般的であり、実際の実装にとって重要な様々な論点を無視している。例えば、トンネル確立はセキュアではない。通常は、MN間において用いられるデータパスをリダイレクトする際には、最初に、リダイレクトが本当に適正であることを確実にするべく、2個のエンティティの間にセキュリティアソシエーションを確立することが必要である。トンネル確立を保護するためのMAG間のあらかじめ取り決められたセキュリティアソシエーションも可能であるが、ネットワークアーキテクチャに依存しており、実世界のすべての場合に実行可能ではない。
MIPv6によると、経路最適化処理においてリターンルータビリティ処理が実行され、モバイルノードが自身のホームアドレスならびに自身が主張する気付アドレスにおいて、実際にアドレス指定可能なことへの、一定の合理的な保証を取得する。この保証があって初めて、コレスポンデントノードはモバイルノードからバインディングアップデートを受け取ることができ、モバイルノードは次いで、コレスポンデントノードに対し、モバイルノードあてのデータトラフィックを自身が主張する気付アドレスへと向けるよう指示する。
2個のMAG間におけるセキュアなデータパスを達成するために、MIPv6のRO処理と類似した経路最適化処理が、2つの側の間において実行されうる。したがって、はっきり区別される3つのケースがありうる。
1.経路最適化がMN1とMAG2との間で実行される。このケースでは、ROはMN1によって開始され、MAG2とMN1は経路最適化されたデータパスの終点である。例えば、MIPv6のRO処理が経路最適化に用いられる場合には、MAG2はMIPv6のRO中においてMN2の役割を果たす。
2.経路最適化がMAG1とMN2との間で実行される。このケースでは、MN1に代わってMAG1が経路最適化をMN2に対して開始する。経路最適化されたデータパスの終点はMAG1(MN1の代わり)ならびにMN2である。例えば、MIPv6のRO処理が経路最適化のために用いられる場合は、MAG1はMIPv6のRO中においてMN1の役割を行う。
3.経路最適化がMAG1とMAG2との間で実行される。このケースでは、MAG1は経路最適化をMAG2に対して開始し、両MAG間における経路が最適化されたパスが確立される。例えば、MIPv6のROが経路最適化に用いられる場合には、MIPv6のRO中において、MAG1がMN1の役割を行いMAG2がMN2の役割を行う。
図5及び6のシナリオと類似した他のシナリオも同様に可能である。例えば、ノードのうち1つをホームネットワーク内に配置することができ、当該ノードはPMIPモビリティ管理を用いてもよい。別の例は、ノードが固定されていて(又はIPモビリティサービスがノードに提供されていない)、インターネット内の任意の場所に位置しているシナリオにかかわる。固定ノードの場合には、経路最適化は上記のケース1又は2にしたがって実行することができる。それにもかかわらず、あるMAGがMNのために利用可能な場合には、経路最適化は好適にはMAG間において実行される。したがって、当業者は記載された原理を他の2つのケースにも同様に実装する知識を持つものの、下記に提示する各実施の形態は上記のケース3に焦点を当てている。
本発明の各実施の形態は上記ケースのすべてに適用可能である。
結果として、2個のMAG間にトンネルを確立するためには、MIPv6と類似した経路最適化処理を行うことが常に必要であろうと想定される。このため、下記において術語「PMIP経路最適化(RO:roue optimization)」とは、2個のMAG間におけるトンネルのセキュアな確立のことをいう。
さらに、MAG間にトンネルを確立することが認められているか否かを、最初に判定することが必要かもしれない。前記情報は、MNのAAAサーバを始めとする、各MNと関連付けられた適切なサーバから依頼されてもよい。あるいは前記情報はMNから取得したシグナリングを介して検索され、当該MNは当該情報をAAAサーバから取得した。さらに各MNは、経路最適化をセットアップするべき関連したモバイルノードを把握している必要がある。
繰り返し既述したとおり、上記ケースにおいて記載した経路最適化を行おうと試みた際に遭遇する問題の1つは、経路最適化を行う各エンティティが互いを把握している必要があることである。例えばケース3において、各経路最適化中にメッセージを正確に宛てるために、MAG1はMAG2に関する情報を持つ必要があり、その逆も同様である。
図8による上記処理は、図10に示す特定の例示的シナリオを考慮すると、さらに詳細に説明されるであろう。しかしながら、最初は、本発明の様々な実施の形態において広範に用いられるセッションイニシエーションプロトコルを、図9を参照しながら提示し、簡潔に論じる。
セッションイニシエーションプロトコル(SIP)
多くの場合、通信セッションの確立にはアプリケーション層上におけるシグナリングを必要とする。(例:VoIPアプリケーションによって)この目的のために用いられる人気の高いプロトコルは、セッションイニシエーションプロトコル(SIP:Session Initiation Protocol)である。MNとコレスポンデントノード(MN2)との間のSIPを用いたセッション確立シグナリングの例を図9に示す。明確さのために、この例は簡略化したシグナリングのフローを示す。例えば、IPマルチメディアをモバイルユーザに送るためのアーキテクチャのフレームワークであるIPマルチメディアサブシステム(IMS:IP Multimedia Subsystem)が用いられる場合、リソース確保、課金などを理由としてより多数のシグナリングメッセージが送信される。
SIPは新規のインフラストラクチャエンティティを規定する。各SIPノードは、自身が登録され、通常SIPシグナリングメッセージを送/受信するSIPレジストラ又はプロキシサーバをすでに割り当ている。CNとのセッションを確立するために、MNはinviteメッセージを自身のSIPプロキシサーバへ送信する。inviteメッセージは、セッションのためのメディアの種類、トランスポートプロトコル、アドレスならびにポートを始めとする記述を含んでいる。inviteメッセージは、コレスポンデントノードのSIPの統一資源識別子(URI:Unified Resource Identifier)も含まなければならない。SIPのURIは例えば「Bob@domain.com」でありうる。この記述は通常、セッション記述プロトコル(SDP:Session Description Protocol)によって搬送される。SIPにおいてSDPはオファー/アンサーモデルに従っているが、このことは、一方のノードがメディアの種類、コード等を提供(オファー)し、他方のノードがオファーを受け取るか又は拒絶することを意味している。SDPのオファーならびにアンサーは様々なSIPメッセージに添付することができる。
MNのSIPプロキシサーバは、SIPのURIならびにDNSを用いることによってCNのSIPプロキシサーバを発見し、inviteメッセージをCNのSIPプロキシへ送信する。CNのSIPプロキシは、CNによって送信されたより早期の登録メッセージからCNのアドレスを把握し、SIP inviteメッセージをCNへ転送する。このメッセージの受信は、例えば着信音によって、CNのユーザへの通知をトリガする。同時にCNは、通知(ringingメッセージ)をMNへ返信し、当該通知は2個のSIPプロキシサーバ上のリバース経路上をルーティングされる。CNのユーザが電話を受けた時、CNは、再び2個のSIPプロキシサーバを介して、OK inviteメッセージ(SDP回答)をMNへ返信する。SDP回答は、CNアドレスも含んでおり、任意の応答メッセージ、例えば(図9の例の場合のように)ringing又はOK inviteメッセージに添付することができる。さらに、SIPヘッダの連絡先フィールドは、送信者のエンドポイントであるCNのアドレスを含んでもよい。
いずれにせよ、ひとたびOK inviteメッセージが受信されると、エンドポイントの各アドレスが把握され、MNはデータのCNへの、及びその反対の、直接的な送信を、プロキシを経由することなく開始することができる。
ここで図10の本発明の実施の形態を参照すると、PMIPv6仕様によると、PMIPドメインに接続されるMNは、PMIPサービスの利用可能性を把握していない。すなわちMNは、MAGならびにLMAの存在を把握していない。本発明の様々な実施の形態は、各MNがアプリケーション層シグナリング(SIP等)を介してMAGの存在を把握する方法を提案している。本発明において、AAAサーバは、MNが接続されるPMIPエンティティ(MAGならびにLMA)を把握していると想定される。この想定は、図4において実行されたPMIPv6接続処理に基づいている。
図10の実施の形態の様々なステップには、その理解を促進するために番号が付けられている。
(1)最初のステップは完全なSIPシグナリングを説明しており、実際は下記により明らかにされる様々なサブステップから成る。最初に、MN1はMN2との例えば音声又はビデオ通話を開始することを希望している。MN1はこのようにしてSIPシグナリングを開始し、SIP inviteメッセージを自身のSIPサーバ(SIPpr1と呼ばれるHN1内のSIPプロキシサーバ)へ送信する。SIPpr1は、AAA1サーバに対して、PMIPサービスがMN1に提供されるか、ならびに、PMIPのRO(両MAG間におけるトンネルの確立)が許容されるか否かを検証する。AAA1の回答が肯定的である場合は、SIPpr1は、MN1のPMIPのRO能力に関する情報を、拡張SIP inviteメッセージに(例えば、特別なフラグを用いて)含める。SIPpr1はHN2内のMN2のSIPサーバ(SIPpr2)を解消し、拡張SIP inviteメッセージを自身へ転送する。拡張SIP inviteメッセージの受信時に、SIPpr2はHN2内のAAA2サーバに連絡して、MN2に対して、MN2にPMIPサービスが提供されるか否か、いずれが責任あるMAGであるか、ならびに、PMIPのROが許可されるか否かを検証する。AAA2は、PMIPサービスがVN2内のMN2に提供されることと、MN2がHN2に対してMIPv6を用いていることを把握しており、かつ、PMIPのROがMN2に対して許容されていると想定するので、AAA2サーバはかかる情報をSIPpr2に伝える。連続して、SIPpr2はMIP/PMIPに関連した情報をSIP inviteメッセージに含め、MN2へ転送する。
このMIP/PMIPに関連した情報は、1)MN2がMIPv6のROを行うためのトリガ、2)PMIPのROが許容されること、ならびに3)MAG2のIDをMN2に通知することを含みうる。MN2はinviteメッセージに対し、ringingメッセージによって応答する。ringingメッセージがSIPpr2に到達すると、SIPpr2はMN2に関するPMIPのRO許容情報を含んでおり、その結果最終的には、AAA1又はSIPpr1は、PMIPのROをMN1に対して許容するか否かを把握するために、PMIPのROがMN2のために許容されるか否かを把握している。次にSIPpr2は、ringingメッセージをSIPpr1へ転送する。SIPpr1はHN1内のAAA1サーバに連絡し、AAA1サーバは、MN1が接続されるMAG1のIDをSIPpr1へ通知する。SIPpr1は、下記の情報1)2)3)を含むringingメッセージをMN1へ転送する:1)MN1がMIPv6のROを行うためのトリガ2)PMIPのROが許容されること、3)MAG1のIDをMN1に通知することを。このステップ(1)の結果は、MN1がMAG1のIDを把握し、MN2がMAG2のIDを把握することである。
(2)ringingメッセージ中のトリガに応答して、MN1はMN2に対するMIPv6のRR処理を開始する。代替的にはMN2が(対応するトリガを最初に受信するので)MIPv6のRR/RO処理を開始する最初のMNとなる可能性もある。しかしながら、図10の例示的な実施の形態の残り部分では、MN1がMIPv6のRR/RO処理を、MN2がそれを行う前に開始すると想定する。MIPv6のRR処理の完了後に、MN1は、MAG1のIDを含む拡張BUをMN2へ送信する。BUメッセージの受信時には、MN2はMN1のCoA、ならびに、MN1が接続されるMAG1のIDを把握する。MN2は拡張BCE内に、MN1_HoAとMN1_CoAとの間のバインディングとともに、MAG1のIDを格納してもよい。
(3)inviteメッセージに応答して、MN2はMN1に対するMIPv6のRO処理を行う。MN2はMAG1のIDを格納済であるので(ステップ(2)を参照)、MN2は、都合よくMN1のCoAとMAG1のIDも含めることによって、拡張CoTiメッセージをMN1へ送信する。セキュリティの理由で有利なことから、前のステップ(2)によるMN1からのBUを介して等の信頼された交換を用いて、MAG1のIDが受信される場合にのみ、MN2はMAG1のIDをCoTiメッセージに含めてもよい。
(4)MN2からのCoTiメッセージはHA2に向けてMIPv6トンネリングされず、HA1を経由してMN1へと向かうので、MAG2は、MN1のCoAとMAG1との関係を把握するために、CoTiメッセージをインターセプトならびに傍受してもよい。MAG2とMN2とは同一のリンク上にあり、ひいては侵入者が存在しないので、MAG2はこの情報を信頼してもよい。前記関係は後に、MN1のCoAあてのパケットをPMIPトンネル上でMAG1へと向けてトンネリングするために用いられる。CoTiメッセージを傍受する同一の処理が、MAG1が、MN2のCoAとMAG2との関係を把握するために用いられる。前記目的のためにMN1は、前記情報を含む、特別な専用のメッセージ、例えばCoTiメッセージを1個のみ送信する。MAG1が、MN2のCoAならびにMAG2を含む拡張CoTiメッセージを検知する場合には、MAG1は、連続的なPMIPのROトンネリングのために、当該関係を作成及び格納する。CoTiメッセージはMN2によって受信されるが、同一のMN1に対して成功したMIPv6のRO処理がしばらく前に実行済であるので、MN2は当該メッセージを無視する。MN内のタイマは、前記無視処理を、MIPv6のRO処理後の合理的期間に限定してもよい。
(5)MAG1又はMAG2が、対応するMNがMAGに接続されていることを検知した後に、MAG1及び/又はMAG2は、相手側のMAGへと向かうPMIPトンネルを確立するための処理を開始することができる。すなわち、MN1とMN2との間のセッションのために、トンネルがMAG1とMAG2との間に確立される。2個のMAG間におけるPMIPトンネルを確立する厳密な処理はさまざまであってよく、MIPv6のRO処理の適応であってもよいが、MN間の代わりに、MAG間において実行されてもよい。いかなる場合においても、PMIPトンネルが確立された後に、MAGは、MAG2内におけるMN1のCoAとMAG1との間の関係等、パケットのあて先アドレスと相手側のMAGとの関係にしたがって、パケットを転送する。
上述のステップによると、各MAGはトンネルを確立するために必要な情報を備えている。さらに、各MNはそれぞれがMIPv6のRO処理を行うことによって、対応するMNが当該データパケットを受信及び解読するために適切な形式でデータパケットを送信する。MIPv6のRO処理が実行されない時には、MNによって送信されたデータパケットは、MNとそのHAとの間のMIPv6トンネルによって、カプセル化及び暗号化される。このような場合には、相手側のMAGはデータパケットがCNあてか否かを判定できなかった。その理由は、カプセル化によってデータパケットをHAアドレスへ宛てており、内部パケットは暗号化を理由としてMAGによって解読できないからである。同様に、たとえデータパケットがCNへ向けてリダイレクトされても、対応するセキュリティアソシエーションがMNとそのHAとの間で確立されるので、CNは内部パケットを解読できない。
本発明の別の実施の形態を図11を参照しながら図示及び記載する。図10に示す解法とは異なり、SIPシグナリングが、MNに対し、自身のMAGのIDだけでなく、相手側のMAGのIDも通知するのに用いられる。例えば、SIPpr2からMN2へ送信されたSIPのInvメッセージが、MAG1のID(図10による実施の形態と同様のMAG2のID、MIPv6のRO及びPMIPの許容のためのトリガは別として)を追加的に搬送するために拡張される。したがって、MN1へのSIP Ringメッセージは(MAG1のID、MIPv6のRO及びPMIPの許容のためのトリガとともに)MAG2のIDを追加的に搬送する。このようにして、MNには、自身及び相手側のMAGのIDが通知される。図11中のステップの詳細な説明は下記のとおりである。
(1)MN1は、SIP inviteメッセージを自身のSIPサーバ(HN1内のSIPpr1)へ送信することによってSIPシグナリングを開始する。SIPpr1はinviteメッセージ中に封入されたMN2のURIを解消し、ひいてはSIPpr2サーバを発見する。
(2)MN1ならびにMAG1がPMIPのROのために許容される場合には、SIPpr1はAAA1サーバに対して検証する。それらが許容される場合は、SIPpr1は、AAA1サーバから受信したMAG1のIDならびにMN1のIPアドレス(例:MN1のCoA)をinviteメッセージに含め、メッセージをSIPpr2へ転送する。MN1のIPアドレス(CoA)が自身のAAAサーバ内で利用可能か否かは、ネットワークアーキテクチャに依存しうる。MN1がMIPv6を使用している(本シナリオにおいて想定される)場合には、MN1のIPアドレスを検索するために考えられる方法はHAに問い合わせることである。
(3)SIPpr1は、MAG1のIDならびにMN1のCoAを含む拡張SIP inviteメッセージを、SIPpr2へ転送する。
(4)SIPpr2はPMIPのROに関連した情報がinviteメッセージに含まれていることを認識し、AAA2サーバに対して、PMIPサービスがMN2に提供されるか否か、ならびに、PMIPのROがMN2のために許容されるか否かを検証する。回答が肯定的である場合は、SIPpr2は、自身がinviteメッセージ中のPMIPのROに関連した情報をMN2へ転送することができることを把握し、MAG2のIDに関する情報も保持する。
(5)SIPpr2は、PMIPのROに関連した情報(すなわち、MAG1のID、MAG2のID、MIPv6のROのトリガ、PMIP許容情報)を含む拡張SIP inviteメッセージをMN2へ転送するが、MN1のCoAが追加的に含められる。MAG2がMN1のCoA→MAG1のIDの関係を確立することができるよう、MN2はいずれのノードがMAG1に接続されているかをMAG2へ通知する必要があるので、MN1のCoAが必要であり、これは以下に説明される。本実施の形態では、MN1のCoAはPMIPのROに関連した追加情報としてみなされる。
(6)拡張SIP inviteメッセージを受信した後に、MN2は、MN1に対してMIPv6のROの実行を開始してもよい。MN2は、拡張CoTiメッセージに、PMIPのROに関連した情報、すなわち、SIP inviteメッセージとともに受信したMAG1のIDならびにMN1のCoAを含める。本発明の本実施の形態によると、HoTi、HoT、CoT、BUならびにBAを始めとするMIPv6のRO処理の他のメッセージは、変更する必要はない。MN2はさらに、拡張SIP inviteメッセージに対して、SIP ringingメッセージによって応答し、当該SIP ringingメッセージはMN1に戻るよう転送される。しかしながら、より明確に示すために、MN2の応答ならびに追加のSIPシグナリングは、図中に示されない。ringingメッセージはSIPpr2ならびにSIPpr1によってMN1へ送信される。前の実施の形態と同様に、ringingメッセージがSIPpr2に到達した時に、SIPpr2はPMIPのRO許容情報を含め、MAG2のIDならびにMAG2のCoAを含む当該情報をSIPpr1へ転送する。SIPpr1はHN1内のAAA1サーバに連絡し、AAA1サーバは、MN1が接続されるMAG1のIDをSIPpr1に通知する。
こうして、MN1によって受信されたringingメッセージは、MAG2のID、MN2のCoAならびにMAG1のIDを、MN1がMIPv6のROを行うためのトリガとともに含む。したがってMN1は、MN2に対するMIPv6のRO処理も開始し、前記観点において、MAG2のIDならびにMN2のCoAを含むMN2あての拡張CoTiメッセージをMAG1を介して送信する。
(7)前の実施の形態のステップ(4)と同様に、MN2からの拡張CoTiメッセージはHA2へ向けてMIPv6トンネリングされないが、MN1のHoAに直接送信するので、MAG2はMN1のCoAとMAG1との関係を把握するためにCoTiメッセージを傍受してもよい。同様に、自身のMIPv6のRO処理中にMN1から送信された拡張CoTiメッセージは、MAG1によってインターセプトすることができ、MAG1はMN2のCoAならびにMAG2のIDを、それらの間の関係を把握するために抽出する。
(8)MAG2及びMAG1は、それらの間におけるプロキシROトンネルを設定するためのPMIPのRO処理を開始してもよい。
本発明の別の実施の形態を図12に示し、下記に詳細に説明する。MAG1のIDはMAG2にAAAシグナリングを介して通知される。このように、本実施の形態の図10及び11中の前の実施の形態との主な違いは、各MAGのIDはBU、CoTiのような拡張されたMIPv6のROメッセージ中ではもはや搬送されないことである。さらに、対応するMNのIPアドレスは、AAAインフラストラクチャのエンティティから来るメッセージ中でMAGのIDとして搬送される。
(1)MN1は、SIP inviteメッセージを自身のSIPサーバ(HN1内のSIPpr1)へ送信することによって、SIPシグナリングを開始する。SIPpr1は封入されたMN2のURIを解消し、これによってSIPpr2サーバを発見する。
(2)SIPpr1は、AAA1サーバに対して、PMIPがMN1に提供されるか否か、ならびに、MN1のためにPMIPのROが許容されるか否かを検証する。回答が肯定的である場合は、AAA1サーバは、かかる情報はMNのネットワークへと通知される必要があるので、MAG1−IDならびにMN1のIPアドレス(例えば、MN1がMIPv6を用いる際のCoA、又は、PMIPv6を用いる際にMN1に割り当てられたPMIPv6のIPアドレス)をSIPpr1へ送信する。SIPpr1は、AAA1からこのPMIPのROに関連した情報を取得した後に、当該情報を拡張SIP inviteメッセージに含め、メッセージをSIPpr2へ転送する。SIPpr2は、拡張SIP inviteメッセージからPMIPのROに関連した情報を抽出することによって、拡張SIP inviteメッセージを標準的なinviteメッセージへと修正する。引き続いて、SIPpr2はAAA2サーバと通信し、AAA2サーバに対し、MN1のための抽出されたPMIPのROに関連した情報(例:MAG1のIDならびにMN1のCoA)を提供する。
(3)SIPpr2は、MN2内でMIPv6のRO処理をトリガするよう修正されたSIP inviteメッセージをMN2へ送信する。
(4)AAA2サーバがPMIPのROに関連した情報(例:MAG1及びMN1のIPアドレス)をSIPpr2から取得した後に、AAA2サーバはMN2がMAGに接続されているか否か、ならびに、PMIPのROがMN2のために許容されるか否かを検証する。これが当てはまる場合は、AAA2サーバは、MAG2にMAG1−IDならびにMNのCoAを通知するトリガメッセージを生成し、MAG2へ送信する。トリガメッセージに基づいて、MAG2はMN1_CoAとMAG1との関係を把握する。
(5)SIP inviteメッセージ中のトリガに応答して、MN2はRR処理を開始して、MN1に対するMIPv6のROを行う。
また、SIP inviteメッセージに応答して、MN2は、拡張SIP inviteメッセージに対して、SIP ringingメッセージによって応答し、当該SIP ringingメッセージはMN1に戻るよう転送される。しかしながら、より明確に示すためにここでも、MN2の応答及び追加のSIPシグナリングは図12には示されない。ringingメッセージはSIPpr2ならびにSIPpr1を介してMN1へ送信される。途中でSIPpr2は、MAG2のIDならびにMN2のCoAを始めとするPMIPのRO許容情報を含めて、ringingメッセージをSIPpr1へ転送する。SIPpr1は前記情報(MAG2のIDならびにMN2のCoA)を抽出し、前記情報をAAA2サーバへ送信する。ringingメッセージは、MN1内でのMIPv6のRO処理をトリガするべくSIPpr1によって修正され、ひいては、修正され、MN1へ送信される。AAA1サーバはMAG1がMN1に属することを把握しているので、MAG2のIDならびにMN2のCoAを含むトリガメッセージがMAG1へ送信される。このようにして、MAG1はMAG2のIDとMN2のCoAとの関係を把握する。
(6)AAA2サーバからのトリガメッセージに基づいて、MAG2はMAG1へ向かうプロキシトンネルを設定するためのPMIPのRO処理を開始する。その結果により、MAG2は、MN1_CoAあてのデータパケットをプロキシROトンネル上でMAG1へ転送するための、MN1_CoA→MAG1の関係を含むバインディングキャッシュエントリを作成する。同様に、AAA1サーバからのトリガメッセージに応答して、MAG1は、MAG2へと向かうトンネルを確立するために別のPMIPのRO処理を開始する。再び、バインディングキャッシュエントリは、MN2_CoAあてのデータパケットを確立されたトンネル上でMAG2へ転送するために、MN2_CoA→MAG2の関係を反映して、MAG1内に規定される。
図12と同様に上記の記載で省略したことは、それぞれのMNは、(MN2のための)SIP inviteメッセージ、(MN1のための)SIP ringingメッセージそれぞれによってトリガされた、MIPv6のRO処理を行うべきであることである。それを行うにあたり、データパケットは、通信パートナーが受信したデータパケットを処理できるように適切な形式で送信される。
図10に示す実施の形態に用いられたMIPv6処理を説明するために、詳細なシグナル図を図13に示す。この図より、MNならびにMAGにとって必要な変更が同様に理解できる。MN1のHA1とMN2のHA2との間の太い黒線はMIPv6トンネルを示し、MAG1のLMA1とMAG2のLMA2との間の太い灰色線は、PMIPv6トンネルを示す。BU及びCoTiメッセージ中の太いイタリック体文字は、それらメッセージ中に搬送された(例えば、メッセージオプションとしてコード化できる)新規の情報を示す。
まず最初に、第一列に示すように、データパケットは、MIP及びPMIPトンネル上でホームネットワークを介して送信される。図10に関連して既述したように、SIPシグナリングが実行され、このシグナリングによって2個のMNのそれぞれが、自身のMAGエンティティのIDを把握するようになる。すなわち、MN1はMAG1のIDを把握し、MN2はMAG2のIDを把握する(このことは図13には示されない)。受信したSIP ringingメッセージ中の対応するトリガに応答して、MN1は、HoTi及びCoTiメッセージをMN2へ送信することによってMIPv6のRO処理を開始する。MN1のHoTi及びMN2の対応するHoT応答の経路は同一であるので、図中において双方向矢印が示される。CoTiメッセージは直接MN2のHoAへ、したがって直接HA2へ送信され、LMA1ならびにHA1には最初に送信されない。CoTは同一の経路上で返信される。RR処理に成功した後に、MN1は、SIP ringingメッセージから把握したMAG1のIDを含め、拡張BUをMN2へ送信する。MN2はBUメッセージを受信した後ただちに、MN1_HoA→MN1_CoAの関係を格納するBCEを作成し、BCEをMAG1のIDで拡張する。
MN2がRR処理を開始する際に、MN2は、前に受信した拡張BUメッセージから把握したMAG1のIDならびにMN1のCoAを含む拡張CoTiメッセージをMN1へ送信する。MAG2は、MN2によって送信されたメッセージを傍受し、拡張CoTiメッセージを検知した際は、MAG2はMN1_CoA→MAG1の関係を抽出する。その後は2つのオプションが可能である。
1)MAG2は、修正された標準的なCoTiをさらにMN1へ送信する前に、MN1のCoAならびにMAG1のIDの付いた拡張子を削除することによって、CoTiを修正してもよい、又は
2)MAG2は拡張CoTiメッセージを修正せず、受信時には、MN1は単に拡張子を無視する。
図13は第2のケースを示す。ここでは、MN1のCoAならびにMAG1−IDを含む拡張子は、MN1で受信された時には、依然として拡張CoTiメッセージ中にある。MIPv6のRR処理を終了した後ただちに、MN2は、MN1に対する拡張BU中に、SIP inviteから把握したMAG2のIDを通常のMN2のCoAとともに含む。MN2の場合と同様に、MN1は、MN2_HoA→MN2_CoAの関係ならびにMAG2−IDを格納する拡張BCEを作成する。
MAG2がMN1のCoAとMAG1−IDとの関係を把握するとすぐに、MAG1へと向かうPMIPのROトンネルの確立を開始することができる。代替的には、図13に示されたように、MN1が自身のMIPのRO処理が終了すると、MAG2はPMIPのROトンネル確立も開始しうる。同様に、MN2から受信したMN1のCoAあてのデータパケットが、MAG2によって前記PMIPのROトンネルを介してMAG1へ転送される。
MN1からMN2へと追加的な拡張CoTi(RO処理の一部ではなく、この一個のメッセージのみ)を送信する処理はオプションであるので、灰色の影付きである。前記処理の目標は、MAG1に対し、MN2_CoA→MAG2の関係を通知することである。しかしながらこの通知は、MN1/MAG1がより短いデータパスを持つべくMAG2へと向かうトンネルを確立したい場合にのみ必要である。前記の場合には、MAG2からMAG1への一方向トンネルのみがセットアップされる。
代替的には、MAG2のIDならびにMN2のCoAに関する情報は、上記のようにMAG2によって開始されたPMIPのRO処理中にMAG2からMAG1へ伝達されうる。
この後者の場合は、当業者は、追加の助言がなくても対応するメッセージを適応させることができるので、より詳細には論じない。
ここで第1の代替例を参照すると、MN1はMN2のCoAならびにMAG2のIDを含む拡張CoTiメッセージをMN2へ送信してもよい。MAG1は前記拡張CoTiメッセージをMN1からインターセプトし、MN2のCoAならびにMAG2のIDに関する情報を抽出する。次いで、MAG1はCoTiメッセージをさらにHN2へ転送してもよく、CoTiメッセージは次いでHN2からMN2へと向けてトンネリングされる。MN2は、同一のCoAを持つ同一のMN1からBUを受信した後間もなく、CoTiメッセージを受信した場合は、MN2は、メッセージを破棄し、CoTメッセージによって回答しないことを決定することができる。MN2は、タイマ等によって制御された所定時間、前記方法で作用することができる。
まだ記述していないが、MAG−ID自体は、MAG1とMAG2との間のデータトンネルを確立するために用いることはできない。むしろ、MAGのIPアドレスが必要とされる。前記目的のため、MAG2ならびにMAG1は、相手側のMAGのIDを把握した後に、セキュアDNS処理を行って相手側のMAGのIPアドレスを解消する。例えば、MAG1はMAG2のIDのためのDNS解消を行い、ひいてはMAG2のIPアドレスを判定する。
その後、MAG1は、MAG2に対するPMIPのRO処理を行うこと等によって、MAG2へと向かうトンネルの確立を開始してもよい。2個のMAG間におけるトンネルはすでに確立可能であるものの、MNがデータパケットを相手側のMNのCoAへ送信することを開始した後に、すなわち、MIPv6のRO処理の後に、データ転送処理が始まる。
図13によると、MAG間におけるトンネル確立処理は、MIPv6のROがMN1ならびにMN2によって完了した後に開始される。しかしながら、MAGのそれぞれは、相手側の情報(他方のMNのCoAならびに他方のMAGのID)を把握するとすぐに、他方のMAGへと向かうトンネルの確立を開始することができる。
都合よく、PMIPのRO処理は、MIPv6のRRが2個の通信パートナーの間でセキュリティアソシエーションを確立しているMIPv6のRO処理と類似して、PMIPのRO処理の前に両方のMAGが互いを把握及び信頼する必要がないよう設計することができる。
図13を参照すると、図10の実施の形態によるシグナリング図が記載されており、当該図では、両方のモバイルノードはそれらのホームネットワークとの間でMIPv6を用いている。しかしながら、図6のシナリオと同様、単に一方のMNがMIPv6を使用しており、他方のMNが使用していない場合には、本発明の他の実施の形態が適用される。図14は、MN2がMIPv6を使用していない場合の詳細なフローチャートを示す。この図は2つのサブケースを含む。第1のサブケースでは、MN2はモビリティサービスのないインターネット内のIPノードであり、下記の第2のサブケースでは、MN2はPMIPv6モビリティサービスを使用している。
第一列は、経路最適化が実行されないであろう場合におけるデータパケットのトンネリングを示す。再び、前に図示したSIPシグナリングは図14から省略された。要するに、SIPシグナリングは、MNに、自身が接続されるMAGに関する情報を提供するのに用いられる。すなわち、MN2はSIP inviteメッセージを介してMAG2−IDを把握し、MN1はSIP ringingメッセージを介してMAG1−IDを把握する。MN1は、CoTi/CoT及びHoTi/HoTメッセージをMN2と交換することによって、MIPv6のROを開始する。MN1は、SIP inviteメッセージから把握したMAG1のIDに関する情報を持つので、MN1は、MAG1のIDをMN2へ送信される拡張BUに添付する。MN2は、拡張BUメッセージを受信した後に、MN1_HoA→MN1_CoAの関係を格納し、さらにMAG1のIDを格納する拡張BCEを作成する。
MN2がPMIPv6サービスを使用していない(すなわち、MN2が固定されているか、又は、いずれのモビリティ管理も用いられていない)場合には、いくつかのオプションが可能である。
MN2は、標準的な未修正BAをMN1へ返信する(図14には示されない)。この場合には、MAG1はMN2から何も把握せず、MAG1とMN2との間にトンネルを確立することができないか、又は、MN2は、MN1へ、モバイルノードの役割のためのMIPv6スタックがアクティブでない旨の情報を含む拡張BAを送信する(図14中のオプション1として示される)。MAG1はMN1へのBAメッセージを傍受し、拡張BAの検知時に、MN2がMIPv6を使用していないことを把握する。このことは、MAGが存在しておらず、MN2はMIPv6のRO処理のためのいかなるBUも送信しないので、MN2はMAGのIDを通知しないことを意味する。MAG1は、BAメッセージを傍受することによって、MN2のIPアドレスも把握し、MN2とのトンネルを確立しうる。
MN2がPMIPサービスを使用中であり(図6のシナリオを参照)、(SIPシグナリング等から)自身のMAG2のIDを把握する場合には、MN2は、この情報を相手側のMN1/MAG1へ通信することを望むかもしれない。MN2はMIPv6を使用中でないので、MN2は、図10と関連して上述したように、拡張BU中にあるこの情報を送信することができない。したがって代わりにMN2は、MAG2のIDに関する情報、ならびに、追加的にMIPv6がMN2内で利用不可能なことに関する情報を含む拡張BAを、MN1へ送信してもよい。BAメッセージのソースアドレスは、MN2のIPアドレスを示す。さらに、MN1のCoAがBAのあて先アドレスフィールドにすでに含まれているので、MAG2がMN1のCoAとMAG1−IDとの関係を把握するためには、拡張BAメッセージはさらに、MAG1のIDを追加的に含みうる。MAG1−IDならびにMNのCoAは、MN1によって開始されたMIPv6のRO処理の拡張BUを介して、MN2内において把握されている。MAG2は拡張BAメッセージを傍受し、また、拡張BAメッセージがMN1へと向かう方向にMAG2によって転送される前にMAG2がかかるメッセージを検知する場合には、MAG2はMN1のCoAならびにMAG1−IDに関する情報を抽出する。実装に応じて、MAG2はこうしてMAG1へと向かうPMIPトンネルの確立を開始することができ、その結果、MN2からMAG2で受信したMN1のCoAあてのデータパケットが、直接MAG1へ転送される。
MAG1は、MN1へのBAメッセージを傍受することができ、MN2内においてMIPv6が利用不可能なことに関する情報を含むMN1への拡張BAを検知した時は、MAG1はそれゆえMN2→MAG2の関係を把握する。代替的には、拡張BAメッセージはMAG1によって傍受されないが、別の専用のメッセージが、MN2→MAG2の関係をMAG1へ通知するために、MAG1へ送信される。専用のメッセージは、BAメッセージが自身の識別情報を含まないことを検知したMAG2からのメッセージであってもよい。
MAG1ならびにMN1の拡張BAの別の処理は、図13に記載されたMAG内の拡張CoTiの処理に類似している。すなわちMAG1は、このような標準的BAメッセージをMN1へ転送する前に、拡張BAメッセージ中のPMIPのROに関連した追加情報を削除するよう決定してもよい。代替的には、MAG1は拡張BAメッセージを修正することなく転送してもよく、MN1はPMIPのROに関連した追加情報を無視するであろう。MAG1がMN2→MAG2の関係を把握した後、MAG1は、MN2のIPアドレスあてのデータパケットをMAG1へと適切に転送するべくMAG1とのトンネルを確立する。
図10、11ならびに12に提示された本発明の様々な実施の形態の関係を明らかにするために、図17にフローチャートを示す。このフローチャートは、三つの例示的な実施の形態のそれぞれに対する上記の詳細な記載をまとめている。このフローチャートは、MN1からMN2へのSIPシグナリングをSIPサーバ内ならびにAAAサーバ内で必要とされるロジックとともに示している。MN2からMN1へのシグナリングは描かれていないが、SIP Ringメッセージに対してAAA1サーバによってなされる決定は、AAA2サーバによってなされる決定と類似している。このフローチャートは、MN1とMN2のいずれもPMIPを使用していないか、又は、PMIPのROが許容されていない場合には、SIPシグナリングメッセージは修正されないことを示す。
図10〜12に示す本発明の三つの実施の形態すべてにおいて、MN1ならびにMN2が自身のMIPv6のRO処理を完了し、パケットを相手側のMNのCoAへ送信するのを開始した後に、MAG間におけるプロキシROトンネルを通ったデータ転送が始まる。MN2がMIPv6のROを完了し、データパケットをMN1のCoAへ送信するのを開始した場合には、MAG2はパケットをプロキシROトンネルを介してMAG1へと向けてトンネリングする。その一方で、MN1がMIPv6のROをまだ実行していない場合には、MN1は依然としてデータパケットをMN2のHoAへ送信し、したがって、MAG1はパケットをLMA1へ転送中である。プロキシROトンネルを双方向に用いるために、両方のMNがMIPv6のROを実行済でなければならない。
それにもかかわらず、MAG1→MAG2であれ又はMAG2→MAG1であれ、MAG間において一方向トンネルのみを確立することも可能である。したがって当業者は、追加の助言なしにこのような一方向のトンネルを達成するべく、本発明の上述の原理を適応させるのに十分な知識を有している。
以下に、MAGが互いの存在を把握しうる方法に関して、異なる実施態様を記載する。本発明の前の実施の形態とは対照的に、この別の実施態様はアプリケーションサーバ、すなわち、SIPシグナリングを伴わない。したがって、修正されたMNは、MAGが互いの存在を見出す際に助けとなるために、協力する。これら実施態様のいくつかのオプションが下記に記載される。オプション1では、MN1は、自身のMAG1のIDを発見しMN2へとシグナリングするよう試み、MN2は情報をさらにMAG2へとシグナリングする。オプション2では、MN1は自身のIPプレフィクスをMN2へ通知し、MN2はプレフィクスをMAG2へ転送する。オプション3では、MN1は修正されないが、MN2はMN1のCoAをMAG2へシグナリングする。ここで重要なことは、MAG2が、MN1のCoAを介してMN1の訪問ネットワークを把握することである。オプション4では、MN1ならびにMN2は修正されず、MAG2は、(MN2によって送信された未修正CoTiメッセージから抽出された)MN1のHoAに基づいてMAG1を発見するよう試みる。オプションのそれぞれについて以下に詳細に説明する。
(オプション1):MN1は、自身のCoAのIPプレフィクス(例えばホームネットワークプレフィクス、すなわち、VN1のプレフィクス)に対するリバースDNS(ドメイン名システム)解決を行う。通常、リバースDNS(rDNS)解決は、ホスト名、又は、所定のIPアドレスと関連付けられたホストを判定する処理である。MAGのID解消の場合には、MNはMAGのIPアドレスを持っていないが、通告されたネットワークプレフィクス(PMIPv6サービスの場合にはホームネットワークプレフィクス、HNPであってもよい)を把握している。したがってMNは、ネットワークによって通告されたプレフィクスのためのrDNSを行う。DNSシステムは、あるIPプレフィクスからの完全に記述したドメイン名(FQDN:Fully-Qualified Domain Name)を解消できるように拡張される必要がある。rDNS処理の結果は1)LMA1のFQDN(PMIPが用いられる場合)又は 2)AR/MAGのFQDN(MIPv6が用いられる場合)(ARとMAGは同位置に配置されている)のいずれかである。
図15に示すように、解消されたFQDNはMN2へとシグナリングされる。このことは例えば、解消されたFQDNをMAGのIDとして、MN1のCoAをさらに含む拡張BU中に入れて、MN1からMN2へとシグナリングすることによって達成可能である。拡張BUは、MN1によってMN2に対して開始されたMIPv6のRO処理の一部となる。
しかしながら、代替的には、送信されたMAGのIDが自己決定されることを示す新規のオプションが、拡張BU中メッセージ中に規定されうる。このことは、このIDがLMA−ID又はAR/MAG−IDのいずれかであることを意味しうる。MN2は、受信したIDならびにMN1のCoAを、MN1への拡張CoTiメッセージに含める。MAG2は、拡張CoTiメッセージをインターセプトし、MN1によってシグナリングされたID(実際にはLMA1のID)ならびにMN1のCoAを把握する。このようにして、MAG2はセキュアDNSを行って把握したID、この例ではLMA1のIPアドレス、のIPアドレスを解消する。それゆえに、MAG2はMN1のCoAならびに解消したLMA1のIPアドレスを把握している。
以下に対しては、MAG2がMAG1とのトンネルを確立するために、通常のMIPv6のRO処理と類似した、プロキシMIPv6のRO処理が実行されると想定する。同様に、MAG2はMN1のCoAで拡張されたプロキシHoTi及びプロキシCoTiメッセージを、解消されたLMAのIPアドレスへ送信することによって、LMA1に対するプロキシRR処理を開始してもよい。正確なMAGを判定するためのメッセージに、MN1のCoAを挿入することが有利である。その理由は、プロキシHoTiは、ソースアドレスとしてのMAG2アドレスと、あて先アドレスとしてのLMA1アドレス(ならびに追加的にMN2のアドレス)のみを含んでおり、プロキシCoTiは、MAG2及びLMA1のアドレス(ならびに追加的にMN2のアドレス)を含んでいるからである。プロキシのRR処理を理由として、MN2のアドレスがさらに挿入される。このことは、MAGが、自身がMN2に代わってRR処理を行うことを相手側のエンティティに伝えることを意味する。こうして、LMA1は、当該メッセージ中に含まれる、MN1のCoAと関連付けられた相手側のMAGを把握しているので、LMA1はメッセージを正しいMAG(MAG1)へ転送することができる。次いでMAG1は、相手側のプロキシHoT及びCoTメッセージを送信することによって、MAG2へ返信応答する。
MAG2は、プロキシCoTメッセージを受信した時、前記プロキシCoTメッセージのソースアドレスを見ることによって、いずれがMAG1であるかを判定することができる。プロキシBUメッセージはこうして、直接MAG1へ送信することができ、2個のMAG、MAG1とMAG2との間にトンネルが確立される。
図15からは省略されているものの、MN2がMIPv6のRO処理を行うこともまた必要であり、その結果、MN2からMN1へ送信されたデータパケットは暗号化されず、MIPはHA2へと向けてトンネリングされる。例えば、MN2のためのMIPv6のRO処理は、MN1によって開始された図示するMIPv6のRO処理が実行される前に、実行される。
オプション1では、両方のエンドノード、MN1ならびにMN2、とも、修正されなければならない。
(オプション2):MN1がMAG1のID(通常、MNはリンクローカルなIPアドレスならびにレイヤ2のアドレスのみを把握しているが、グローバルIPアドレスは把握していない)を把握していない場合には、MN1は、MAG1によって受信され自身のCoAを設定するのに用いられたIPプレフィクスを、MN1によってMN2に対して開始されたMIPv6のRO処理の一部である、MN2へのBUに(MAG−ID又は特別な新規のオプションフィールドとして)含める。前と同様に、MN2もMN1に対するMIPv6のRO処理を実行済であると想定する。MN1はrDNSを行う必要はないが、MN1のCoAのIPプレフィクスをMN2へ送信するので、このオプション2はオプション1よりもより単純である。MN2は、取得したMN1のCoAのIPプレフィクスを拡張BCE中に格納し、MN1のCoAのIPプレフィクスをMAG1のIDとして、MN1への単一の拡張CoTiメッセージへと含める。MAG2は拡張CoTiメッセージをインターセプトし、MAG1のID(実際には、LMA1からのMN1のHNP又はARからの通常のIPプレフィクスのいずれか)を把握する。ここで、MAG2はMN1のCoAのIPプレフィクスを持っており、当該IPプレフィクスを通告したエンティティのIPアドレスを解消しなければならない。MAG2がIPアドレスを解消するための1つの可能性は、rDNS処理を行って、MN1のCoAのIPプレフィクスに対応するFQDNを見つけ出すことである。このさらなる処理が、上記のオプション1における処理に対応している。MAG2は、FQDNからLMA1のIPアドレスを解消し、LMA1に対するプロキシのRRを開始する(図15を参照)。次いで、メッセージはLMA1によって正しいMAG1へ転送され、ひいては、最終的にMAG1とMAG2との間におけるトンネルが確立される。
MAG2がMAG1のIPアドレスを判定するための他の可能性は、MN1のCoAのIPプレフィクスに対応する、ネットワークドメイン内のAAAサーバに連絡することであろう。AAAサーバは次いで、MAG1のIPアドレスをMAG2へと伝えることができる。
オプション2では、両方のエンドノード、MN1ならびにMN2、とも、修正されなければならない。
(オプション3):MN1はMN2に対するMIPv6のRO処理を開始し、RR処理の後に、MN2へ標準的なBUを送信する。すなわち、図16に示すように、MAG1のIDといったPMIPのROに関連した情報はBU中には含まれていない。ここで再び、MN2によってMN1に対して開始されたMIPv6のRO処理は、図16には示されないが、MN2が通信セッションのデータパケットを正しい、すなわち暗号化もトンネリングもされていない形式で送信することが必要である。MAG2がMN1のCoAを把握することができる方法には、2つの可能性がある。
1つの可能性によると、MN2は標準準拠のBAメッセージをMIPv6のRO処理の一部として、MN1へ返信する。MAG2はBAを傍受し、ひいては、BAメッセージのあて先アドレスフィールドからMN1のCoAを把握する。もう一方の可能性では、MIPv6のRO処理を終了した後に、MN2は、MN1のCoAをオプションとして1個の拡張CoTiメッセージに含める。MAG2は拡張CoTiメッセージを傍受し、ひいては、MN1のCoAを把握する。MAG2はMN1のCoAを把握した後に、MN1のCoAからIPプレフィクスを抽出することができ、次いで、IPプレフィクスからMAGのID/IPアドレスを推論する必要がある。前記目的のために、ここでも再び2つの主な代替例がある。MAG2がrDNS処理を行って相手側のFQDN、実際はLMA1のFQDN、を解消する。ひとたび、MAG2がLMA1のFQDNを持つと、MAG2は次いで、LMA1のFQDNに対してDNS処理を行うことによって、LMA1のIPアドレスを解消する。前のオプション1ならびに2と同様に、MAG2は次いで、MAG2とMAG1との間で最終的にトンネルを確立するために、LMA1に対するプロキシRR処理を開始する。
別の考えられる処理は、MAG2がMN1のCoAのIPプレフィクスを把握した後に、MN1のCoAのIPプレフィクスに対応するMN1の訪問ネットワークドメイン内のAAAサーバを発見することである。MAG2が訪問ドメイン内のAAAサーバから情報を検索することが許可される場合には、MAG2は、MN1が接続されているMAG1のIPアドレスを把握する。次いで、MIPv6のRO中に受信したMN1のCoA、ならびに、AAAサーバから検索したMAG1のIPアドレスを用いることによって、MAG2とMAG1との間のトンネルを確立することができる。
オプション3ではMN1は修正されない。しかしながら、MN2は修正されても(MN2がMN1のCoAを含む拡張CoTiメッセージを送信する場合)、又は、MN2は修正されなくても(MAG2が未修正のBAメッセージからMN1のCoTiを把握する場合)いずれでもよい。
(オプション4):MN1はMN2に対するMIPv6のRO処理を開始し、MIPv6のRO処理のRR部分を終了した後ただちに、標準的なBUをMN2へ送信する。すなわち、MAGのIDといったPMIPのROに関連した情報はBU中には含まれていない。MN2は、標準準拠のBAをMN1へ返信する。MN2はMN1に対するMIPv6のRO処理を行い、その一部として標準準拠のCoTiメッセージをMN1へ送信する。MAG2はCoTiメッセージを傍受し、MN1のHoA(CoTiメッセージのあて先アドレス)を把握する。MAG2は、MN1のHoAのIPプレフィクスに対応するIPドメイン内のAAAサーバの検索を開始する。MAG2がAAAサーバを見出すことに成功した場合には、図10より当該AAAサーバはAAA1であろう。次いでMAG2は、MN1に対するPMIPサービスの利用可能性、ならびに、MN2に対してPMIPのROを行う許可を、AAA1サーバに対して尋ねる。さらにMAG2は、MAG1のIPアドレスを把握することができる。MAG2は次いで、MAG1へと向かうプロキシROトンネルのセットアップを開始することができる。
同様に、MAG1はプロキシMIPv6のRO処理を行って、MAG1とMAG2との間のトンネルをセットアップすることもできる。とりわけ、MN1によって開始された上記MIPv6のRO処理中には、CoTiメッセージは、MN2のHoAをあて先アドレスフィールドから把握するために、MAG1によって傍受されてもよい。MAG2と同様に、MAG1はMN2のHoAのIPプレフィクスに対応するAAAサーバ(図10のAAA2)を探すのを開始する。MAG1はMAG2のIPアドレスをAAA2サーバから把握し、したがって、A2サーバへと向かうトンネルをセットアップすることができる。
オプション4では、両方のエンドノード、MN1ならびにMN2、とも修正されない。MAG1発見のための機能全般が、MAG2及びホームAAAサーバ内に実装されている。
実現の観点から、実装のために最も簡単なオプションは、処理全体がネットワークエンティティによって実行されることから、オプション3(とりわけMN2が修正されない場合)ならびにオプション4である。
前の記載では、MAGのIDが拡張BU又は(MNがMIPv6を使用していない場合に)拡張BAメッセージ中で実行されると想定されていた。しかしながら、他の変形例も同様に可能である。一変形例は、MAGのIDを二つの部分へと分割し、次いでRRメッセージ中に入れて搬送されることである。一方の部分は拡張HoTiメッセージ中に、もう一方の部分は、拡張CoTiメッセージ中に含めることができる。MAGのIDを二つの部分へと分割する目的は、経路上攻撃者がMAGのID(IPアドレス)を把握するのを防止することである。MN2が拡張HoTi及び拡張CoTiメッセージを受信した後に、MN2はMAG−IDを再構築することができる。
他の変形例は、末端ホストがMAG1のIPアドレスを把握することを認められているという想定に基づいている。MAGのIPアドレスは次いで、MAGのIDとして用いることができる。MNはBUメッセージ中の「交互気付アドレス」モビリティオプション(alt−CoA)を用いて、MAGのIPアドレスを搬送してもよい。BU中のAlt−CoAオプションは、MNがCoAをBUのソースアドレスとして使用できない場合に必要である。このような場合には、BUの受信器は、alt−CoAオプションからのIPアドレスを、ノードを送信するためのCoAとして用いる。alt−CoAオプションは本発明の目的のために、特別な方法で用いることができる。alt−CoAオプションはプロキシCoAを他の語のMAGのIPアドレスで搬送する。新規種類のオプションを類推的にalt−CoAオプションに指定することも可能であり、「プロキシCoA」(プロキシ−CoA)オプションと呼ばれる。
プロキシ−CoAはBU及びBAメッセージ両方のために指定されてもよい。
要約すると、本発明の実施の形態は、関与するエンティティに対する様々な変更を示唆している。しかしながら、以下の一覧は変更の一部分のみであり、限定するものとして理解されるべきではない。むしろ当業者は、上記に論じた例から下層システムを修正する方法を推論することができる。
・MNは、拡張SIP inviteメッセージを処理するよう変更されるべきである。さらに、MNは、MAGのIDをMAGのIPアドレスにする方法を実装してもよい。修正されたMIPv6のRR/ROメッセージの処理(送信ならびに受信)のために追加的な変更が必要である。
・MAGは、修正されたCoTiメッセージ、ならびに、オプション的に修正されたBAメッセージを傍受及び処理するよう修正されるべきである。さらに、プロキシRR及びプロキシRO処理のための手段も実装することができる。MAGは、MAGのIDをMAGのIPアドレスにするための手段も実装してもよい。
・SIPサーバは、MNがMAGのIDを発見する助けとなる手段を実装するべきである。すなわち、SIPサーバはAAAサーバと通信する能力があるべきである。さらにSIPサーバは、SIP inviteならびにRingメッセージ等、修正されたSIPメッセージを処理(生成、送信及び受信)する能力があるべきである。
・オプション的に、LMAは、MAGから来るプロキシRRメッセージを転送するために修正されてもよい。
次に、本発明のさらに別の異なる実施の形態を記載する。図13に示すように詳細なシーケンスによると、MAG2が拡張CoTiメッセージからMN1−CoAとMAG1−IDの関係を抽出済である時、又は、MN1がMIPのROトンネルの確立処理を完了した時などに、MAG1とMAG2との間のPMIPのROトンネルの確立を開始する。
しかしながら、より一般的な環境では、たとえMAG間においてPMIPのRO処理の完了に成功しても、MAGは互いを十分に信頼することができない。PMIPのRO処理は、たとえMAGが互いを認識しないか又はMAGが互いを信頼していない場合であっても実行することができる。しかしながら、実際のシステムでは、より良好なセキュリティのためにMAGが互いを信頼していることが好ましい。
さらに、一定の相互関係を持つMAG同士でさえも、それらの相互関係を確認するか、又は、有効(セキュア)なMAGとは何かを互いに示す必要があるかもしれない。MAGは、例えば、それぞれのエンティティを、それぞれの認証サーバを介して、それぞれのネットワークにて認証する必要があるか、又は、MAG間にローミングネットワークがある場合は、MAGはそれらの相互関係を確認する必要があるかもしれない。上記の認証処理と同様、ルーティング経路の設定、サービスの質(QoS:Quality of Service)のためのリソースの確認及び予約、ならびにアカウンティングといった様々な処理が、MAG間において実行される必要があるかもしれない。
このように、PMIPのROトンネルを確立し、次いで最適化されたルートを介して最終的に通信を開始するにはいくらかの時間がかかる。その理由は、MAG間におけるPMIPのRO処理は、いくつかの情報を(他のネットワーク内に位置する)他のノードから/他のノードへ/送信し/受信し、他の様々な処理を行うことを必要とするからである。
図13に示す詳細なシーケンスでは、オプションの処理(図13中の灰色の影付き)はMAG間における相互認証を支援してもよい。しかしながら、このオプションの処理は、MN1がMN2からの拡張BUメッセージを受信した後に行われ、MN1はMAG2−IDを拡張BUメッセージから抽出することができる。今回、MAG間におけるPMIPのRO処理が始まった時には、MAG間において信頼関係を確立(又は確認)するか、又は、他の様々な処理を行うのにいくらかの時間がかかる場合には、PMIPのROトンネル確立は遅延しうる。
オプションの処理(図13に灰色の影付き)では、MN1がCoTiメッセージ(拡張CoTiメッセージ)を再送信する処理は、MN1が、MN2_CoAとMAG2−IDの関係をMAG1に通知するのを許容することである。しかしながら、このメッセージは、ルートを最適化するためのCoTiメッセージとして冗長である。今回送信された拡張CoTiメッセージは、MN2によって破棄又は無視される。したがって、このメッセージは、ルートを最適化するためのCoTiメッセージとしての機能を有していない。
本実施の形態は、PMIPのROトンネルを最終的に確立するための時間を短くするために、上述の実施の形態の処理を整流化するよう意図されている。本実施の形態は、MAG間においてPMIPのROトンネルを確立するための時間を必要とする際に、とりわけ有用である。
本実施の形態において、MAG2と同様にMAG1は、MN1からのCoTiメッセージをインターセプトするべく構成されている。図18に示す例示的な処理によると、MAGに対して、MNの通信セッション内においてパケットをMAG間で直接送信することを可能にする情報を提供することが可能である。図18は、本発明の本実施の形態の処理における例示的なシーケンスを示す。図18から明らかなように、invite及びringingメッセージを交換した後は、MN2は、最初にRO処理を開始するエンティティである。それにもかかわらず、MN1又はMN2のいずれかも最初にRO処理を行うことができるので、これは単に一例にすぎない。
図8に示される上述の実施の形態の処理と同様に、MN1ならびにMN2は図18においてMAG1ならびにMAG2にそれぞれ接続されている。MN1ならびにMN2は、任意の方法を用いることによってMAG1のIDならびにMAG2のIDを、それぞれを取得する。例えば、当該任意の方法は、ネットワーク接続確立段階において発生するSIPシグナリング、又は、ネットワーク接続処理中の認証及び許可のためのAAAシグナリングである。類推的に、任意のトリガは任意の方法によって引き起こされるメッセージでありうる。さらにMN2は、SIP inviteメッセージを用いて、接続確立処理中にMN1の識別情報を把握する。このメッセージは、MN1の識別情報、通常はMN1のHoAを含んでいる。しかしながら、本実施の形態の目的のために、MN2が、任意の方法を介してさらにMN1のCoAを把握すると想定する。1つの可能な方法はSIPシグナリングの使用である。例えば、MN1は、上述のようにSIPプロキシサーバ(SIPpr1)へ送信されたinviteメッセージに、自身のCoAを含めることができる。SIPpr1はMN1のCoAの情報をさらにMN2へ転送する。同様にしてMN1は、いずれのエンティティが最初にRO処理を開始するかに依存して、任意の方法によってMN2 CoAを把握することができる。
任意のトリガに応答してMN2がRO処理を開始した際は、MN2は、RO処理の過程で送信されるべき任意のメッセージに、MN2_CoAならびにMAG2のIDを挿入する。この方法において、MN1はMN2に関する情報(MAG2のIDとMN2_CoAの間の関係)を取得する。さらにMN2は、RO処理の過程で、MN1に関する情報(例えばMN1_CoA)をMAG2が検知できる形式で任意のメッセージ(例えば、MN1あてのメッセージ)に挿入する。
MAG2はこのメッセージをインターセプトし、MN1に関する情報(例えばMN1_CoA)を把握する。次いで、MAG2はMN2のために実行されることとなるRO処理のための準備を開始する。このRO処理のための準備として、MAG2は、MN1_CoAによって特定されたMN(すなわちMN1)に接続するMAGの識別情報(すなわちMAG1のMAG1−ID)を取得(又は収集)するか、又は、MAG2と、MN1に接続しているMAG1との間のPMIPのROトンネルを確立するための先行準備を行う。
その一方で、MN1はMN1からMN2へと向かう方向でRO(RO2)を開始する。MN1は、MN2に関する情報(MN2_CoAならびにMAG2−ID)を、RO処理の過程で送信された任意のメッセージに、MAG1を検知できる形式で挿入する。この方法において、MAG1はこのメッセージをインターセプトし、MN2に関する情報(MN2_CoAとMAG2−IDの関係)を把握する。
上記の動作によると、MAG1はMN2に関する情報(MN2_CoAとMAG2−IDの関係)を把握することができる。さらにMAG2は、MN1に関する情報(例えば、MN1_CoAに関する関係)を把握し、早い(上述の実施の形態として早い)段階で、MN2のためのPMIPのROトンネルを確立するための準備(認証処理又は他の様々な設定処理の準備)を開始することができる。結果として、MN1とMN2との間の通信セッションのデータパケットを直接転送されるように、MAG1とMAG2との間でトンネルを確立することができる。MN1とMN2との間の通信セッションのデータパスは、パケットがこのトンネルを介して転送される時に、より短くなる。
以下において、本実施の形態の詳細な動作の一例を図19を参照に記載する。図19は本発明の本実施の形態の詳細なシーケンス処理の例を示す。図19では、詳細な動作は、図7に示すネットワーク構成に基づいて記載される。図19に示す詳細な動作は、当該動作がMN1からのROより始まるという点で、MN2がRO処理を開始する図18の動作とは異なる。
図19において、太字の黒線(MN1とHA1との間ならびにMN2とHA2との間)は、MIPv6トンネルを示し、太字の灰色線(MAG1とLMA1との間、ならびにMAG2とLMA2との間)はPMIPv6トンネルを示す。さらに、太字のイタリック体の文字は新規の情報又は新規の処理を示す。
まず最初に、データパケットは、MIP及びPMIPトンネル上をホームネットワークを介して送信される。MN1ならびにMN2は、上述のSIP方法又は通信時にMNに接続されているMAGによって通告された情報から等といった、任意の方法によって、MAGの識別情報をそれぞれ把握する(すなわちMNは、自身が接続されているMAGの識別情報を把握する)。すなわち、MN1はMAG1−IDを把握し、MN2はMAG2−IDを把握する。
MN1は、任意のトリガ(例えば、受信したSIP ringingメッセージ中のトリガ)に応答してMIPv6のRO処理を開始し、HoTi及びCoTiメッセージをMN2へ送信する。MN1からMN2へのHoTiメッセージならびにMN2からMN1へのHoTメッセージは、標準的なHoTi及びHoTメッセージとそれぞれ類似している。MN1からMN2へのHoTiメッセージの経路ならびにMN2からMN1へのHoTメッセージの経路は同一であり、HoTi/HoTメッセージは図19中で双方向矢印によって示す。
その一方で、CoTiメッセージに関しては、MN1は、追加情報の付いた(例えば、追加情報がこのメッセージ中の拡張フィールドに付加されている)拡張CoTiメッセージをMN2へ送信する。追加情報は、MN1のためのコレスポンデントノードであるMN2のアドレス(MN2_CoA又はMN2_HoA)といった、MN2を示す情報であることが好ましい。前の実施の形態では、CoTiメッセージのあて先IPアドレスはMN2のHoAであるとの想定があった。本実施の形態では、CoTiのあて先IPアドレスがMN2のCoAでありうる。MAG1がCoTiメッセージのあて先IPアドレスからMN2_CoA(又はMN2_HoA)を読み取ることもまた可能であり得る。この場合には、MN2_CoA(又はMN2_HoA)は、特別な追加情報として付加される必要はない。加えて、MN1がMAG間におけるPMIPのROトンネル確立を所望するか否かをはっきりと示す情報を、MN1は、(MN2との通信セッションのデータパケットをこのROトンネルを介して転送して)、追加情報として付加してもよい。このことによって、たとえMN1のアドレスならびにMN2のアドレスを標準的なCoTiメッセージから抽出する場合であっても、MAG1は、自身がトンネル確立のための後続の各処理を行うべきであるか否かを容易に判定することが可能になる。MN1が拡張CoTiメッセージを送信した時、このメッセージ自体が、MN1がMAG間におけるPMIPのROトンネル確立を所望することを示してもよい。図19において、CoTiメッセージのあて先アドレスは(HA2によってトンネリングされる)MN2_HoAである。図19は、MN2_CoAに拡張CoTiメッセージによって通知される場合を示す。
MAG1は、MN1によって送信された拡張CoTiメッセージを検知(傍受)する。MAG1はこのメッセージから追加情報(例えば、MN2_CoA)を抽出し、MN1に対するPMIPのRO処理のための準備を開始する。例えばMAG1は、自身がMIPのROを目的としたいくつかの情報を送信及び受信することを、例えばパケット転送経路を管理するための記憶エリア中に記憶する。さらに、MN1とMN2との間の通信セッションに関して、MAG1は、ROのためのメッセージをMN2から(又はMN2が接続されているMAGから)受信した時に実行される処理のための準備を開始する。
MN1に対するPMIPのRO処理のための準備として、MAG1は、MN2_CoAへとアドレス指定されたデータパケットを、MN2が接続されているMAGへと、MN1から転送するための転送テーブルを格納するための処理(しかしながら、MAG1はこの段階では正確なあて先を把握できない)、MAG2へ送信されるべき(認証のために必要な情報を始めとする)情報を提供するよう認証サーバに依頼するための処理、MAG2から認証情報を受信した時に容易に受け取るよう準備するための処理、MAG間におけるPMIPのROトンネルに用いられるトンネルインタフェースを設定するための処理、又は、QoS(サービスの質)のために必要なリソースを予約するための処理を行うことができるが、それら処理に限定されない。
MAG2から認証情報を受信した際に容易に受け取るよう準備するための上記処理に関しては、MAG1は、MN1によって送信された拡張CoTiメッセージにキーイング情報を付加して、MAG2がその結果このキーイング情報を含む認証情報を抽出及び使用できるようにしてもよい。これによってMAG1は、MAG2が、MN1のためのコレスポンデントノードであるMN2のMAGと同一であることを、容易に識別及び認証することが可能になる。
さらにMAG1は、MN1によって送信された拡張CoTiメッセージから追加情報を取り除き、次いで、このメッセージを標準的なCoTiメッセージ形式で転送してもよい。MAG1は、追加情報の付いた(又はさらなる追加情報が付加された)拡張CoTiメッセージを転送してもよい。MN1によって送信された拡張CoTiメッセージはRR処理の一部であり、MN2はこの拡張CoTiメッセージにCoTメッセージによって応答する。
RR処理が首尾よく完了した後に、MN1は、拡張BUメッセージ(拡張登録メッセージ)を把握したMAG1−IDを付けて送信する。例えば、把握したMAG1−IDは、このメッセージの拡張フィールド内に付加される。MN2は、この拡張BUメッセージを受信した後ただちに、MN1_HoAとMN1_CoAの関係を格納するBCEを作成し、BCEをMAG1−IDで拡張する。
その一方で、MN2はRR処理(HoTi/HoTメッセージとCoTi/CoTメッセージとの交換)も開始する。今回MN2は、MN1_CoAをあて先IPアドレスとして有するとともに、前に受信した拡張BUメッセージから把握したMAG1−IDを追加的に含む拡張CoTiメッセージを送信する。MAG2は、MN2によって送信された拡張CoTiメッセージを検知(傍受)する。MAG2は、拡張CoTiメッセージを検知した後ただちに、MN1_CoAとMAG1−IDの関係を抽出する。
MAG2は、拡張CoTiメッセージから追加情報(例えばMAG1−ID)を取り除き、次いでこのメッセージを(標準的なCoTiメッセージとして)MN1へ転送してもよい。MAG2は、この拡張CoTiメッセージをMN1へと修正を行わずに転送してもよい。後続の各処理は、標準的なMIPv6のRR処理における処理と(BUメッセージを送信するための処理とも)同じである。
MAG2は、MN1_CoAとMAG1−IDの関係を把握した後ただちに(すなわち、拡張CoTiメッセージから、MN1_CoAとMAG1−IDの関係を抽出した後ただちに)、MAG1とのPMIPのROトンネルの確立を即座に開始することができる。
MAG2は、MAG間におけるPMIPのROのために必要な自身の処理を行い、PMIPのRO処理のために必要な(認証情報、トンネル確立処理のための情報、又は、QoSの予約処理ための情報を始めとする)情報を、(MAG1−IDによって特定された)MAG1へ送信してもよい。このような情報交換は、MN2によるMIPのRO処理と並行して実行することができる。このようにして、PMIPのROトンネル確立のために必要な処理をより早い時期に開始することができる。
MAG1は、MN1のコレスポンデントノードに接続するMAG(MAG2)によって提供されるPMIPのRO処理を受け取る用意ができているので、MAG1は、PMIPのRO処理を即座に行うことができる(又は、クエリー処理を始めとする認証処理の一部を実行することができる)。
MIPのROがMN1とMN2との間で完了した時に、MAG1とMAG2との間でPMIPのROトンネルがすでに確立済である可能性が高い。この場合には、MIPとPMIPの両方によって最適化されたルートを介したデータパスが、即座に利用可能である。
MAG1ならびにMAG2がMAG間におけるPMIPのROトンネルを介してデータパケットを実際へ転送可能なことを判定する方法は、図19に示すように、MN1によって送信されたBAメッセージをインターセプトすることによって確認する方法であってもよいが、この方法に限定されない。MAG1ならびにMAG2は、MN1からMN2_CoAあてのデータパケット、又は、MN2からMN1_CoAあてのデータパケットを検知できた時に、作成した転送テーブルに基づいて転送を開始してもよい。代替的には、MN1及び/又はMN2は、MAGに対し、MIPのRO処理が完了したことを通知してもよい。さらに一方のMAGが他方のMAGに転送の開始を伝えてもよい。
MN1によって送信された拡張CoTiメッセージは、MAG1に自身の識別情報(MAG1−ID)を問い合わせるためのメッセージとしてもよい。この場合には、MAG1はMN1にMAG1−IDを通知する。このようにして、たとえMN1がMAG1−IDをあらかじめ(例えばSIP処理によって)把握していなかった場合であっても、MN1はこの段階でMAG1−IDを把握することができる。
さらに、MN1によって送信された拡張CoTiメッセージは、のMAG1−IDをMAG1からMN2に対して通知するよう依頼するためのメッセージとしてもよい。この場合には、MAG1は自身の識別情報(MAG1−ID)を拡張CoTiメッセージに付加するか、又は、他のメッセージを用いることによって、MN2に対して自己のID(MAG1−ID)を通知する。このように、MAG1−IDは、MN1からMN2へのBUメッセージに付加される必要はない。
さらに、MN1によって送信された拡張CoTiメッセージは、MN2に対してMAG1−IDを通知するためのメッセージとしてもよい(しかしながらMN1は、このメッセージを送信する前にMAG1の識別情報を把握するべきである)。この場合には、MN1からMN2へ送信されたBUメッセージにMAG1−IDを付加するための処理は、省略することができる。MN1が、MN2に接続するMAG2の識別情報(MAG2−ID)をすでに受信済である場合には、MN1はMN2_CoAとMAG2−IDの関係をBUメッセージに付加することができ、これによって、上記の関係をより早い段階でMAG1に通知することができる。
MN1ならびにMN2のそれぞれが、あらかじめ行われたSIP処理によって、又は、接続時等にMAGによって通告された情報から取得することによって、他の当事者のMAGの識別情報(MN1のためのMAG2−IDならびにMN2のためのMAG1−ID)を把握しうる場合には、MN1は、MN2_CoAとMAG2−IDの関係に関する情報を拡張CoTiメッセージに付加してもよく、MN2は、MN1_CoAとMAG1−IDの関係に関する情報を拡張CoTiメッセージに付加してもよい。拡張CoTiメッセージを送信する時にMNに接続されているMAGの識別情報を通知する方法によると、あるコレスポンデントノードのMAGに関する情報を、拡張CoTiメッセージによって通知することができる(この情報は、上述の実施の形態により図13中の拡張BUメッセージによって通知される)。さらに、両方のMNがMIPv6のROをほぼ同時に開始した場合には、各MNは、各MNが拡張BUメッセージを受信する時に、有効なCoTiメッセージをすでに送信済である。この場合には、各MNが各MAGに到達するようにする(図13に示す上述の実施の形態において再送信されたCoTiメッセージを始めとする)追加的なメッセージを送信することは必要ないかもしれない。場合によっては、本実施の形態において、いくつかの追加的なメッセージは送信されないかもしれない。しかしながら、上述の実施の形態と比較してより早くPMIPのROが始まる可能性が高い。
新規機能を備えたMAGならびにMNが両方のネットワークに配置されている一般的な環境を考慮すると、両方のネットワークにおける動作は対称的となるである。本実施の形態の原理によると、この対称性を効率的に活用することができる。言い換えれば、MAGは、CoTiメッセージが拡張されているか否かを、CoTiメッセージをインターセプトすることによってのみ、検知することができる(インターセプト処理は、単にメッセージを転送することと比較して、追加的な動作であろう)。このようにして、MAG1とMAG2の両方が本発明の機能を実装する場合には、MAG1ならびにMAG2が、最初にMN1によって送信されたCoTiメッセージと後にMN2によって送信されたCoTiメッセージの両方をインターセプトする可能性が高い。したがって、本実施の形態においてMAGによりインターセプトする処理負荷(図19に示す動作)は、上述の実施の形態(例えば、図13に示す動作)と比較して増加することはない。本実施の形態によると(図19に示す動作)、MAG1によってインターセプトする処理を活発に活用することができる。
MAG1によってインターセプトする処理は、MAG1に対するPMIPのROのための準備を依頼するためにMN2のアドレスをMAG1へ通知するために、ならびに、MN1とMAG1の関係をMN2に通知するために、拡張BUメッセージが用いられる場合にも活発に活用することができる。この場合には、各MAGによってインターセプトされるメッセージはBUメッセージ(又は拡張BUメッセージ)である。
加えて、拡張CoTiメッセージならびに拡張BUメッセージを始めとする拡張メッセージは、本発明のために必要な情報のためのオプションフィールド(拡張フィールド)持ちうるが、これに限定されない。
図18ならびに図19に記載された実施の形態は、MN1とMN2との間のMIPv6のRO/RR処理が完了する前に、MAG1とMAG2との間のPMIPのROトンネルが確立してもよいという利点を持つ。このようにして、MIPv6のRO/RR処理が完了すると即座に、データパケットは、PMIPのROトンネル上を流れ始める。その一方で、この欠点は、たとえMIPv6のRO処理に成功していない、すなわち、PMIPのROトンネルが必要でない場合であっても、PMIPのROトンネルがセットアップされることである。
本発明の他の実施の形態は、ハードウェアならびにソフトウェアを用いる上記の様々な実施の形態の実装に関する。本発明の様々な実施の形態は、演算装置(処理装置)を用いて実装又は実行してもよいことが認識されている。演算装置又は処理装置は例えば、汎用目的の処理装置、デジタル信号処理装置(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)又は他のプログラム可能な論理デバイス等であってもよい。本発明の様々な実施の形態は、これらデバイスの組み合わせによって実行又は具現化してもよい。
さらに、本発明の様々な実施の形態はまた、処理装置によって又は直接的にハードウェア内で実行されるソフトウェアモジュールの手段によって実装されてもよい。ソフトウェアモジュールとハードウェア実装の組み合わせもまた可能であろう。ソフトウェアモジュールは、任意の種類のコンピュータで読み取り可能な記憶媒体、例えばRAM、EPROM、EEPROM、フラッシュメモリ、レジスタ、ハードディスク、CD−ROM、DVD等に格納されてもよい。
前の諸段落では、本発明の様々な実施の形態ならびに変形例が記載されてきた。具体的な実施の形態において示されたように、非常に多数の変形例及び/又は修正が、広範に記載された本発明の精神又は範囲から逸脱することなく、本発明に対してなされうることが、当業者によって理解されるであろう。
さらに、実施の形態の大部分が、3GPPベースの通信システムに関して概略説明されるとともに、前の諸セクションで用いられた術語は主として3GPP術語に関することに留意するべきである。しかしながら、3GPPベースのアーキテクチャに関する様々な実施の形態の術語ならびに記載は、本発明の原理ならびに思想をかかるシステムに限定することを意図していない。
また、上記技術分野のセクションで与えられた詳細な説明は、本明細書中に記載されたほとんどが3GPPに特有の例示的な実施の形態をよりよく理解するよう意図されており、移動体通信ネットワークにおける処理及び機能の記載された具体的な実装に限定するものとして理解されるべきでない。それにもかかわらず、本明細書中で提案された諸改良は、技術分野のセクションに記載されたアーキテクチャ内に容易に適用されうる。さらに、本発明の概念は3GPPによって現在論じられたLTE RAN内にも容易に用いられうる。