JP4834133B2 - 電気通信 - Google Patents

Description

本発明は、第１のパケット交換データネットワークの第１のゲートウェイノードが、第１のネットワークでサービスを提供される移動体ノードの目的地パケットデータプロトコルアドレスへトンネルされたデータパケットを転送するための第１のチャンネルを選択することを可能にする装置および方法に関し、そのゲートウェイノードはデータパケットを移動体ノードの目的地パケットデータプロトコルアドレスへそれぞれ転送する複数のチャンネルから第１のチャンネルを選択するように構成され、その選択はゲートウェイノードにより受信されるデータパケットに関連するパケットデータプロトコルアドレスを複数のチャンネルに関連する１以上のデータパケットフィルタへマップすることにより行われる。

特に本発明は外部ＩＰネットワークの対応ノード（ＣＮ）によりＧＰＲＳネットワーク中の移動体ノード（ＭＮ）へ送信されるデータパケットを転送するための適切なパケットデータプロトコル（ＰＤＰ）コンテキストを２Ｇまたは３Ｇの一般的なパケット無線サービス（ＧＰＲＳ）ネットワークの一般的なパケット無線サービスゲートウェイサポートノード（ＧＧＳＮ）が選択することを可能にする装置および方法に関し、ＭＮのマクロの移動性は移動体インターネットプロトコルを使用してサポートされ、ＭＮはホームネットワーク（ＨＮ）から離れており、データパケットはＭＮのホームアドレスにアドレスされ、そのＨＮ中のＭＮのホームエージェントによりトンネルされる。

移動通信（ＧＳＭ）標準方式のためのグローバルシステムに準じるような通常の２Ｇ移動体ネットワークは回路交換音声およびデータサービスをユーザの移動局（ＭＳ）に提供する一方で、パケット交換移動体ネットワークを配備するために移動体電気通信産業に大きな勢いが存在する。パケット交換移動体ネットワークはネットワークおよび無線リソース効率に関して大きな利点を有し、またさらに進歩したユーザサービスの提供を可能にする。固定および移動体電気通信ネットワークの集中により、固定したネットワークで広く普及しているインターネットプロトコル（ＩＰ）は移動体パケットネットワークのパケット経路設定機構として自然な選択肢である。現在のＩＰバージョン４（ＩＰｖ４）は固定したネットワークドメインで広く普及して使用されている。しかしながら、非常に増加したアドレススペース、より効率的な経路設定、より大きなスケール能力、改良されたセキュリティ、サービス品質（ＱｏＳ）の統合、マルチキャストのサポート、その他の特性に関して特にＩＰｖ４よりも良好に認識された利点を提供するＩＰバージョン６（ＩＰｖ６）に徐々に移行することが予測されている。

現在配備されている移動体パケット交換サービスの特別な例は２Ｇ ＧＳＭネットワークと３Ｇ ユニバーサル移動体電気通信システム（ＵＭＴＳ）ネットワーク（以後ＧＰＲＳネットワークと呼ぶ）との両者で実行されているような一般的なパケット無線サービス（ＧＰＲＳ）を含んでいる。無線構内網（ｗＬＡＮ）のような非ＧＰＲＳ無線アクセス技術はホットスポット（会議場、空港、展覧会場等）のような幾つかの区域でローカルなブロードバンドサービスアクセスに対するフレキシブルで価格が効率的な補足手段を提供することも予測されている。したがって移動体ネットワークのオペレータはＧＰＲＳと非ＧＰＲＳネットワークまたはサブネットワークとの間の移動局のローミングをサポートすることを望んでいる。

最初から移動体ネットワークとして設計されているＧＰＲＳは、（ＧＰＲＳネットワーク内のＭＳに対して）組込みの移動管理手段と、（ＧＰＲＳネットワーク間のＭＲのローミングに対する）ローミング機能を有しているが、通常ＩＰユーザ端末の移動性をサポートするためにインターネットエンジニアリングタスクフォース（ＩＥＴＦ）でも作業が行われている。結局、ＩＥＴＦは移動体ＩＰ（ＭＩＰ）プロトコルを開発している。ＭＩＰは移動局（またはＭＩＰの用語では移動ノード（ＭＮ））が異なるサブネットの接頭辞（マクロ−移動性）を有するＩＰネットワーク間で移動するとき、移動性をサポートするように設計されている。例えばＭＩＰはＧＰＲＳネットワークと、ｗＬＡＮネットワークのような非ＧＰＲＳネットワークとの間の移動性をサポートするのに使用されることができる。移動体のＩＰはＷＣＤＭＡのよりソフト／ソフトハンドオーバーのようなアクセス技術特定層２の機構により典型的に管理されているネットワークまたはサブネットワーク（ミクロ−移動性）内の移動性管理に使用されることは期待されない。

ＩＰの２つのバージョンに対応する２つのバージョンのＭＩＰが存在する。ＭＩＰバージョン４（ＭＩＰｖ４）はＩＰバージョン４（ＩＰｖ４）アドレスに対してＩＰアドレス移動性を与えるように設計されており、一方、新しいＭＩＰバージョン６（ＭＩＰｖ６）ＭＩＰはＩＰバージョン６（ＩＰｖ６）アドレスに対するＩＰアドレス移動性を与えるように設計されている。ＭＩＰｖ４はＩＥＴＦウェブサイトhttp://www.ietf.org/rfc/rfc2000.txt?number=2002で利用可能なＩＥＴＦリクエスト・フォー・コメント（ＲＦＣ）２００２に記載されている。インターネット草案ＭＩＰｖ６はＩＥＴＦウェブサイト、http://search.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-18.txtで利用可能であり、draft-ietf-mobileip-ipv6-18.txtとして参照されるＩＥＴＦインターネット草案“Mobility Support in IPv6”に記載されている。

ＭＩＰｖ４移動体管理が図１に示されている。ＭＮ40はそのホームネットワーク（ＨＮ）42中でホームＩＰアドレス（ＨＡｄｄｒ）を割当てられている。ＨＮの経路設定手順はＭＮがＨＮ内にあるときはいつでも対応ノード（ＣＮ）46から送信されたＩＰパケットがＭＮに到達することを確実にする。しかしながら、ＭＮが外部のネットワーク（ＦＮ）44にローミングするとき、そのＨＡｄｄｒにアドレスされるＩＰパケットはＦＮ中の新しい位置に経路設定される必要がある。ＭＩＰｖ４では、ホームエージェント（ＨＡ）として知られているＨＮのルータ48はこれが常にホームから離れているときＭＮの代わりにパケット転送サービスとして作用するために使用される。（ＦＡ−ＣｏＡモードとして知られている）ＭＩＰｖ４の第１の動作モードでは、ＦＮに到着するとき、ＭＮは外部のエージェント（ＦＡ）として知られているＦＮのルータ50によりアドレスのケア（ＣｏＡ）を割当てられる。ＩＰｖ４アドレススペースの知覚される限定により、２以上のＭＮが同一のＣｏＡを共有することが考慮される。ＣｏＡの割当て後、ＦＡ50はＣｏＡを登録するために結合の更新をＨＡへ送信する。その後、ＣＮがパケットをそのＨＮのＭＮのＨＡｄｄｒに送信するとき（ケース１）、パケットはＨＡによりインターセプトされ、ＣｏＡを基礎としてトンネル52を介してＦＮ中のＦＡへトンネルする。

トンネル動作はそのソースおよび目的地アドレスとしてトンネルの開始および終了地点を示す新しいヘッダを有する第２のデータパケットのペイロードとして（ヘッダおよびペイロードを有する）第１のデータパケットをカプセル化し、正常であるとして第２のデータパケットをトンネルの終点へ転送し、ここで第１のパケットを得るためにカプセルを解除されるステップを含んでいる。カプセルの解除後、トンネルの終点、即ちＦＡはＦＮ中で経路設定手順を使用してもとのパケットをＭＮへ経路設定する。ＭＩＰでは、トンネル動作はＩＥＴＦリクエスト・フォー・コメント（ＲＦＣ）２００３を使用してＩＰカプセル化のＩＰを含んでいる。したがって、ＭＩＰｖ４では、ＩＰｖ４パケットは別のＩＰｖ４パケット内でそれをカプセル化することによりトンネルされる。

ＭＩＰｖ４の随意選択的な手順として、ＭＮはそのＣｏＡを登録するために結合の更新をＣＮへ送信することができる。その後、ＣＮはパケットをＨＡｄｄｒを介して間接的にではなく、直接的にその現在のＣｏＡのＭＮへアドレスし（ケース２）、これらのパケットはその後、ＦＮ中のＦＡにより受信され、ＦＮの経路設定手順を使用してＭＮに経路設定される。これは通常はＣＮとＦＡとの間の効率的な経路設定パス上にはないＨＡを介する潜在的に非効率的な三角形の経路設定を防止するのでルート最適化として知られている。

（ＣｏＣｏＡモードとして知られている）ＭＩＰｖ４の第２の随意選択的な動作モードでは、それらのホームネットワークから離れたＭＮによるＣｏＡの共有はなく、ＦＡは使用されない。ＭＮは標準的なダイナミックＩＰアドレス割当て手順を使用して−例えばダイナミックホスト制御プロトコル（ＤＨＣＰ）を使用して同一場所に位置されているＣｏＡ（ＣｏＣｏＡ）として知られている特有のＣｏＡを割当てられる。この動作モードにおいて、ＭＮはそれ自体、新しく割当てられたＣｏＣｏＡを登録するために結合の更新をそのＨＡへ送信しなければならない。その後、ＣＮにより送信されそのＨＡｄｄｒでＭＮにアドレスされるパケットはＨＡから直接ＭＮへトンネルされる。ＦＡ−ＣｏＡモードに関して、ＣｏＣｏＡモードの随意選択的な手順として、ＭＮはまたＣｏＣｏＡを登録するために結合の更新をＣＮへ送信することができる。その後、パケットはＣＮにより直接そのＣｏＣｏＡのＭＮに送信されることができる。

ＭＩＰｖ６移動性管理が図２に示されている。ＭＩＰｖ６とＭＩＰｖ４の２つの大きな違いを以下説明する。第１に、ＩＰｖ６では非常に増加されたアドレススペースのために、ＦＮ中のＭＮに割当てられたＣｏＡｓは共有されることがない（即ちこれらはＭＩＰｖ４の随意選択的なＣｏＣｏＡに対応する）。第２に、結果として、ＦＮ中にＦＡを配備する必要はない。図２を参照すると、ＭＩＰｖ６により、ＭＮ40がそのＨＮ42からＦＮ44に移動するとき、これは特有のＣｏＡを割当てられ、ＣｏＡを登録するために結合の更新をそのＨＮのＨＡ48へ送信する。ＨＡｄｄｒにアドレスされるＣＮ46からのパケットはＨＡ48によりインターセプトされ（ケース１）トンネル54を介してＣｏＡにトンネルされる。このトンネル動作はＩＥＴＦ ＲＦＣ２４７３に記載されているＩＰｖ６の一般的なパケットトンネル機構を使用して実現されることができる。しかしながらＭＩＰｖ６では、ルート最適化は１つの選択肢ではなく、プロトコルの基本的な部分であり、通常、ＭＮはパケットを直接そのＣｏＡのＭＮにアドレスするために結合の更新をＣＮへ送信すべきである（ケース２）。ＭＮがそのＭＮのＨＡを介してＣＮからトンネルされるパケットを受信するとき、これはＣＮがＭＮに対する結合をもたずＣＮ結合の更新を開始するという指示として取られる。ＭＩＰｖ６では、ＣＮの結合の更新はＩＰｖ６ヘッダ（ＭＩＰｖ６ＩＥＴＦインターネット草案の条項１１．６．２参照）のソースアドレスとしてＭＮの新しいＣｏＡを使用しなければならないことに注意すべきである。

ＧＰＲＳ標準として動作する第３世代のパートナーシッププロジェクト（３ＧＰＰ）はＭＩＰがＧＰＲＳネットワークでサポートされる必要があることを認識している。技術仕様書２３．０６０の条項５．７は、“３ＧＴＳ ２３．１２１を参照して、パケットドメインで効率的に随意選択的な移動体ＩＰサービスをサポートするために、外部エージェント（ＦＡ）機能がＧＧＳＮで与えられる必要があることを述べている。ＩＰアドレスのケアとＰＬＭＮのＧＴＰトンネルとの間のマッピングを含むＧＧＳＮとＦＡとの間のインターフェースはＧＧＳＮとして標準化されるとは仮定されず、ＦＡは１つの統合されたノードとして考慮される”ことを述べている。さらに、（http://www.3gpp.org/ftp/specs/2002-06/R1999/23_series/で３ＧＰＰウェブサイトから入手可能な）３Ｇ ＴＳ ２３．１２１は、“…移動体ＩＰをＵＭＴＳおよびＧＰＲＳユーザにも提供し、彼らが進行中のデータセッション、例えばＴＣＰまたはＵＤＰを維持しながら、他のアクセス技術との間でローミングすることを可能にすることが重要である”ことおよび、“ＩＰｖ４のＩＰアドレスが僅かであるとき、移動体ＩＰｖ４は好ましくは外部エージェント（ＦＡ）のアドレスケアと共に使用されることが仮定されることを述べている。同一場所に位置するアドレスのケアと比較して、ＦＡのアドレスのケアはＩＰアドレスを保護するだけでなく、無線インターフェースにわたってさらに効率的である”ことを述べている。

しかしながら、前述の仮定が間違っている状態が存在する。第１に、ＧＰＲＳネットワークオペレータはＭＩＰｖ４ではＦＡ ＣｏＡｓの代わりにＣｏＣｏＡｓを使用することを望む。例えば、ＩＰｖ４アドレスは特定のＧＰＲＳネットワーク内では僅かではない可能性があり、ＣｏＣｏＡｓはスケール能力と経路設定の効率を改良するために好まれる。第２に、ＧＰＲＳネットワークオペレータはＧＰＲＳネットワークを外部ネットワーク交換ネットワークへ接続するゲートウェイであるゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）でＦＡ機能を統合することを望まない。例えば、ＧＧＳＮは重くロードされ、ＧＧＳＮとＦＡ機能を分割することはロードのバランスを改良する。さらに、改良されたスケール能力のために、アクセスノードのようなＧＰＲＳネットワークのエッジに近いノード中にＦＡを位置させることは有益であると考えられている。第３に、３ＧＰＰはそれ自体最近、ＩＰｖ６がＵＭＴＳ Ｒ５ ＩＰマルチメディアシステム（ＩＭＳ）およびＩＰ無線アクセスネットワークで通常サポートされなければならないことを命令している。したがって、ＧＰＲＳネットワークはＭＩＰｖ６とＭＩＰｖ４を将来サポートする必要があり、前述したようにＭＩＰｖ６はＦＡをもたず、ＭＮ（即ち、常に“同一場所に存在する”）に特有のＣｏＡｓを使用することが明白である。

本発明は先に述べた３つの状態のそれぞれにおける現在のサービス説明（リリース１９９９）にしたがって構成されたＧＰＲＳネットワーク中で問題が生じることを認識している。ＧＰＲＳサービス記述のリリース１９９９およびポストリリース１９９９（例えばＲ４、Ｒ５）に準じているＧＰＲＳネットワークの１つの特別な特徴は、パケットデータプロトコル（ＰＤＰ）コンテキストとして知られているものをサポートする。異なるＰＤＰコンテキストの特定は種々の理由で有効である。特にＰＤＰコンテキストは異なるＱｏＳレベルと他のパラメータがＭＳの単一のＰＤＰアドレスとの間のトラフィックに対して特定されることを可能にする。これは実時間ではないトラフィック（例えば断続的およびバーストデータ転送、大量のデータの随時の転送）および実時間トラフィック（例えば音声、ビデオ）のような種々のデータトラフィックの効率的な転送を可能にする。例えばＩＰｖ４またはＩＰｖ６アドレスのようなＰＤＰアドレスを有するＧＰＲＳネットワーク中のＭＳは、それぞれに対して異なるＱｏＳパラメータを有する異なるＰＤＰコンテキストを使用して、外部パケット交換ネットワークの複数の他の電気通信装置と通信できる。通常、ＭＳの義務は必要に応じてＰＤＰコンテキストを生成し変更することである。

ＭＳへのダウンリンクで外部ネットワークから入来するデータパケットはＧＧＳＮによりＧＰＲＳネットワーク中で受信される。ＭＳのＰＤＰアドレスが多数の設定されたＰＤＰコンテキストを有するならば、ＧＧＳＮは各パケットに対して適切なＰＤＰコンテキストを決定することができ、それによってＭＳへ適切に転送されることが重要である。これはＰＤＰコンテキストに関連するトラフィックフローテンプレート（ＴＦＴ）の使用により実現される。ＴＦＴはダウンリンクデータパケットに対する適切なＰＤＰコンテキストを決定するためにＧＧＳＮにより使用されるパケット濾波情報を含むことができる。現在の３ＧＰＰ標準方式にしたがって、パケット濾波で使用するための情報の１つの特定されたアイテムは入来するデータパケットのソースアドレス、例えばＩＰパケットヘッダ中で特定されるようなソースノードのＩＰアドレスである。入来するデータパケットがＧＧＳＮに到着する時、そのソースアドレスはＭＳのＰＤＰアドレスに関連する既存のＴＦＴに対してチェックされる。一致が発見されるならば、適切なＰＤＰコンテキストにしたがって、そのＰＤＰアドレスにおけるＭＳに転送される。しかしながら、一致が発見されないならば、そのパケットはＧＧＳＮによりドロップされることができる。ここで問題が生じる。

ＧＰＲＳネットワーク中のＭＳがＭＩＰｖ６を通してマクロ−移動性を与えられ、ＦＮ、即ち（ＧＰＲＳネットワークであるかそうではない）ＨＮ中にＨＡおよびＨＡｄｄｒを有するＧＰＲＳネットワークに丁度移動し、ＣｏＡを割当てられているＧＰＲＳネットワークに移動されると仮定する。ＭＩＰ用語で一貫するため、ＭＳをＭＮと呼び、外部ネットワーク中の電気通信装置をＣＮと呼ぶことにする。ＧＰＲＳネットワークに移動後、ＭＮは結合の更新をそのＨＮ中のＨＡへ送信し、その新しいＣｏＡを報告する。通常、その新しいＣｏＡの結合の更新をＣＮに送信する。しかしながら、そうしても、種々の理由で、ＣＮは依然としてデータパケットをそのＨＡｄｄｒでＭＮへ送信できる。このようなデータパケットはＭＮのＨＡにより受取られ、ＩＰｖ６トンネル動作（ＲＦＣ ２４７３）を使用してＭＮへトンネルされる。ＲＦＣ ２４７３によれば、“カプセル化において、トンネルＩＰｖ６ヘッダのソースフィールドはトンネルエントリ点ノードのＩＰｖ６アドレスで満たされている”即ちＨＡのＩＰｖ６アドレスで満たされている。したがって、ＧＰＲＳネットワーク中のＧＧＳＮに到着するトンネルされたデータパケットはそのソースアドレスとしてＣＮのＩＰアドレスをもたないで、ＨＡのＩＰアドレスを有する（ｎｂはＭＮのＨＡｄｄｒではない）。このアドレスはＣＮのソースアドレスを識別するＴＦＴを使用してＧＧＳＮにより認識されることができないので、データパケットはドロップされる。

概念的に、ＭＩＰトンネルがＧＧＳＮを通過して延在し、ＧＧＳＮからＣＮソースアドレスを“隠す”問題が考えられる。これはＦＡがＧＧＳＮに統合されないで、さらにネットワークのエッジ方向またはＣｏＣｏＡｓが使用される場所に位置されるならば。ＭＩＰｖ４でも同じであり、それは両方の場合に、トンネルの終端点は再度ＧＧＳＮを超えて延在するためである。また、この問題は、通信セッションが特定のＣＮにより設定されても、ＭＮがＦＮとしてＧＰＲＳネットワークに移動する通常のケースにおいて当てはまることに注意すべきである。将来可能性のあるＣＮが種々の理由でそのＨＡｄｄｒを介してデータパケットをＭＮへ送信することを希望し、これはＨＡを通してトンネルされることが予測されるであろう。したがって、問題は一般的に生じる。

本発明は前述の問題に対する解決策を提供する。

本発明の第１の特徴によれば、第１のパケット交換データネットワークのゲートウェイノードが、トンネルされたデータパケットを第１のネットワークでサービスを行う移動体ノードの目的地のパケットデータプロトコルアドレスへ転送するための第１のチャンネルを選択することを可能にする方法が提供され、ゲートウェイノードはそれぞれ移動体ノードの目的地パケットデータプロトコルアドレスへデータパケットを転送するための複数のチャンネルから第１のチャンネルを選択するように構成され、その選択はゲートウェイノードにより受信されたデータパケットに関連されるパケットデータプロトコルアドレスを複数のチャンネルに関連される１以上のデータパケットフィルタと整合させることにより行われ、その方法は、
ａ）ゲートウェイノードが第１のネットワークに対して外部の第２のパケット交換データネットワークのトンネル動作ノードを介してトンネルされたデータパケットを受信することを示すトリガー事象を検出し、
ｂ）検出に応答して、第１のチャンネルに関連する第１のデータパケットフィルタに含まれるように第１のパケットデータプロトコルアドレスを構成し、第１のパケットデータプロトコルアドレスは、ゲートウェイノードにより受信されるデータパケットと関連されるとき、データパケットがトンネル動作ノードを介してトンネルされていることを示し、第１のデータパケットフィルタはデータパケットを目的地のパケットデータプロトコルアドレスにおける移動体ノードへ転送するための複数のチャンネルから選択するときゲートウェイノードにより使用される。

１実施形態では、ゲートウェイノードが、受信されたデータパケットのソースアドレスを複数のチャンネルに関連する１以上のデータパケットに一致することにより、複数のチャンネルから選択するように構成されており、第１のパケットデータプロトコルアドレスはトンネル動作ノードのパケットデータプロトコルアドレスである。したがって、第１の問題はゲートウェイノードの標準化された機能に対する変更により、またはその変更なしで解決されることができる。

好ましくは、トリガー事象は移動体ノードにより検出され、移動体ノードは第１のデータパケットフィルタ中に第１のパケットデータプロトコルアドレスを含むように構成される。好ましくは、移動体ノードは第２のネットワークのホームパケットデータプロトコルアドレスを有し、トリガー事象はトンネル動作ノードによりその目的地パケットデータプロトコルアドレスを登録する移動体ノードであり、それによってそのホームパケットデータプロトコルアドレスにおける移動体ノードにアドレスされたデータパケットはトンネル動作ノードによりその目的地パケットデータプロトコルアドレスの移動体ノードへトンネルされることができる。

さらに本発明の特徴は、前述の第１の特徴の方法にしたがって構成された移動体ノードおよびゲートウェイノードを含んでいる。

本発明の第２の特徴によれば、第１のパケット交換データネットワークのゲートウェイノードが、トンネルされたデータパケットを第１のネットワークでサービスを与えられる移動体ノードの目的地のパケットデータプロトコルアドレスへ転送するための第１のチャンネルを選択することを可能にする方法が提供され、ゲートウェイノードはそれぞれ移動体ノードの目的地パケットデータプロトコルアドレスへデータパケットを転送するために複数のチャンネルから第１のチャンネルを選択するように構成され、トンネルされたデータパケットは対応ノードから送信され、第１のネットワークに対して外部の第２のネットワークのトンネル動作ノードによりトンネルされ、その方法は、
ａ）トンネル動作ノードがトンネルされたデータパケットを対応ノードのパケットデータプロトコルアドレスに関連付け、
ｂ）ゲートウェイノードが、ゲートウェイノードにより受信されたトンネルされたデータパケットに関連されるパケットデータプロトコルアドレスを第１のチャンネルに関連される第１のデータパケットフィルタに一致することにより第１のチャンネルを選択するステップを含んでいる。

本発明の更に別の特徴は、前述の第２の特徴の方法にしたがって構成されたゲートウェイノードおよびトンネル動作ノードを含んでいる。

本発明の更に別の特徴が特許請求の範囲に記載されている。

単なる例示によって、本発明の好ましい実施形態の詳細な説明を以下説明する。

ＭＩｐｖ４で与えられるような移動性管理を示す概念図。 ＭＩｐｖ６で与えられるような移動性管理を示す概念図。 外部パケット交換ネットワーククラウドを介して接続されたＧＰＲＳネットワークとｗＬＡＮネットワークを示すネットワークの構造図。 本発明の第１および第３の実施形態にしたがって、ＧＧＳＮがＭＮへダウンリンクするためのトンネルされたパケットをＰＤＰコンテキストの適切なトンネルに一致することを可能にするＧＰＲＳネットワークのＰＤＰコンテキスト変形手順を示すメッセージのフロー図。 本発明の第１および第３の実施形態にしたがって、ＧＰＲＳネットワークのＧＧＳＮが後続する変形された手順を示すフロー図。 本発明の第２の実施形態にしたがって、ＨＡにより送信されたＩＰｖ６データパケットの変形された構造を示すブロック図。 本発明の第２の実施形態にしたがって、ＧＰＲＳネットワークのＧＧＳＮが後続する変形された手順を示すフロー図。 本発明の第４の実施形態にしたがって、ＨＡにより送信されたＩＰｖ６データパケットの変形された構造を示すブロック図。 本発明の第４の実施形態にしたがって、ＧＰＲＳネットワークのＧＧＳＮが後続する変形された手順を示すフロー図。

詳細な説明

図３は、ＧＰＲＳネットワーク10とｗＬＡＮネットワーク20の両者が外部パケットネットワーククラウド30の１以上の外部パケットネットワークと接続されているネットワークアーキテクチャを示している。

ＧＰＲＳネットワーク10は、（ここでは１つのＧＧＳＮ12だけが示されているが）１以上のゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）を介して外部パケットネットワークに接続されており、１以上のゲートウェイＧＰＲＳサポートノードは内部のＩＰベースのパケット交換バックボーンネットワークを介して（ここでは１つのＳＧＳＮ14だけが示されているが）１以上のサービングＧＰＲＳサポートノード（ＳＧＳＮ）と通信する。ＳＧＳＮ14はＧＰＲＳサービスに取付けられる個々の移動局（ＭＳ）の位置の追跡を維持し、セキュリティ機能とアクセス制御を行う。ＳＧＳＮ14はそれ自体、１以上の無線アクセスネットワーク（ＲＡＮ）16（２Ｇ ＧＳＭネットワークの基地局サブシステム（ＢＳＳ）または３Ｇ ＵＭＩＴＳネットワークのＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ））に接続される。ＲＡＮは１以上のＭＳ18との無線による通信を制御している。

ＧＳＭとＵＭＴＳの加入データを記憶するホーム位置レジスタ（ＨＬＲ）および回路交換サービスを管理し個々の移動局（ＭＳ）の位置の追跡を維持する移動体交換センタ／ビジタ位置レジスタ（ＭＳＣ／ＶＬＲ）のようなＧＰＲＳネットワーク10の他の主要なコンポーネントは図を明瞭にするために省略されている。3G TS 23.060 v3.12.0（2002-06）として呼ばれ、http://www.3gpp.org/ftp/specs/2002-06/R1999/23_series/において３ＧＰＰウェブサイトから入手可能なＧＰＲＳサービス記述（リリース１９９９）技術仕様書を参照し、これは２Ｇ（ＧＰＲＳ／ＧＳＭ）および３Ｇ（ＧＰＲＳ／ＵＭＴＳ）移動体パケットネットワークの詳細なサービスの説明を行っている。ＧＰＲＳネットワークの機能はまた通常よく知られているが、以下さらに特徴を詳細に説明する。

ＷＬＡＮネットワーク20は無線で１以上のＭＳ26と通信する１以上のアクセス点24を制御するアクセス制御装置（ＡＣ）22を介して外部パケットネットワークに接続される。ｗＬＡＮの機能は一般的によく知られており、ここではさらに詳細な説明はない。

ＧＰＲＳパケット交換サービスにアクセスするために、ＭＳは最初にＳＧＳＮ（２Ｇ ＧＳＭ ＧＰＲＳアタッチまたは３Ｇ ＵＭＴＳ ＧＰＲＳアタッチ）によるＧＰＲＳアタッチ手順を行う。認証および位置更新手順が行われ、成功したならば、ＧＰＲＳアタッチ手順はＭＳをＳＧＳＮを介するページングおよび入来するパケットデータの通知に対して利用可能にする。しかしながら、実際にパケットデータを送信し受信するために、ＭＳは割当てられたパケットデータプロトコル（ＰＤＰ）アドレス（例えばＩＰアドレス）をもたなければならず、そのＰＤＰアドレスと共に使用するために少なくとも１つのＰＤＰコンテキストを付勢しなければならない。ＭＳに対する各ＰＤＰアドレスはそれに関連する１以上のＰＤＰコンテキストを有し、ＰＤＰコンテキストを規定するデータはＭＳ、ＳＧＳＮ、ＧＧＳＮ中に記憶される。ＰＤＰコンテキストの付勢プロセスはＭＳをＳＧＳＮだけでなく、対応するＧＧＳＮに知られるようにし、外部データネットワークとの相互動作が開始できる。

ＰＤＰコンテキストはＧＰＲＳネットワークのノードの経路設定情報およびサービス品質（ＱｏＳ）要求のような状態を維持するために使用される。特に、多数のＰＤＰコンテキストは１以上のレベルのＱｏＳがＭＳの単一のＰＤＰアドレスに対して特定されることを可能にし、それによって非実時間トラフィック（例えば断続的およびバーストデータ転送、大量のデータの随時の転送）および実時間トラフィック（例えば音声、ビデオ）のような種々のデータトラフィックの効率的な転送を可能にする。したがって単一のＰＤＰアドレスを有するＭＳで動作するアプリケーションは１以上のＰＤＰコンテキストの使用によりその必要性にしたがって１以上のレベルのＱｏＳを使用してもよい。ＰＤＰコンテキストは２つの状態の１つ、即ちアクチブまたはインアクチブである。インアクチブであるとき、ＰＤＰコンテキストはＰＤＰアドレスに関連するパケットを処理するための経路設定またはマッピング情報を含まない。転送されることのできるデータはない。アクチブであるとき、ＰＤＰアドレスに対するＰＤＰコンテキストはＭＳ、ＳＧＳＮ、ＧＧＳＮ中で付勢される。ＰＤＰコンテキストはその特定のＰＤＰアドレスに対してＰＤＰパケットをＭＳとＧＧＳＮとの間で転送するためのマッピングおよび経路設定情報を含んでいる。

ユーザデータはトンネル動作を使用して、外部ネットワークとＭＳ間で転送される。ＳＧＳＮとＭＳとの間で、トンネル動作手順が使用され、これは２Ｇ ＧＳＭと３Ｇ ＵＭＴＳネットワークでは異なっている。しかしながら、ＧＧＳＮとＳＧＳＮとの間では、パケットはＧＰＲＳトンネル動作プロトコル（ＧＴＰ）にしたがって共通のカプセル化手順を使用してトンネルされる。パケットドメインＰＬＭＮバックボーンネットワークはＧＴＰヘッダを有するデータパケットをカプセル化し、このＧＴＰパケットをＵＤＰパケットに挿入し、それは再度ＩＰパケットに挿入される。ＩＰおよびＧＴＰパケットヘッダは、ＧＳＮアドレスと、ＰＤＰコンテキストを特有にアドレスするのに必要なトンネル終端点識別子とを含んでいる。ＭＳの単一のＰＤＰアドレスに対する多数のＰＤＰコンテキストが存在する場合、パケットデータ転送に対してＧＧＳＮとＳＧＳＮとの間に対応する数のＧＴＰトンネルが設定されなければならない。ＧＰＲＳネットワークで使用されるＧＴＰトンネルはＭＩＰトンネルと混同されないことに注意すべきである。

多数のＰＤＰコンテキストがＰＤＰアドレスに存在するとき、ＧＧＳＮはＰＤＰコンテキストに割当てられたいわゆるトラフィックフローテンプレート（ＴＦＴ）に基づいて、ダウンリンクパケットを異なるＧＴＰトンネルに経路設定する。各ＰＤＰコンテキストはＴＦＴに関連されることができる。しかしながら、厳密なルールとして、同一のＰＤＰアドレスに関連されるせいぜい１つのＰＤＰコンテキストはＴＳＴがそれに割当てられずに任意の時間に存在できる。したがって、ｎ個の多数のＰＤＰコンテキストにより、常に、それぞれｎ個の個々のＰＤＰコンテキストにそれぞれ対応するＴＦＴまたは（ｎ−１）ＴＦＴが存在する。各ＰＤＰコンテキストに対応しているＴＦＴとＧＴＰトンネルとの間で１対１のマッピングが存在するならば、ＧＴＰトンネルの選択はＴＦＴを基礎として直接的（straight forward）である。（ｎ−１）対ｎ個のマッピングが存在する場合もまた、選択は直接的であるが、一致がＴＦＴに対して発見されないならば、削除の簡単なプロセスを含むことができる。

ＴＦＴはまた評価優先インデックスを使用して優先順位を定められる。データパケットを受信するとき、ＧＧＳＮは最初に、全てのＴＦＴの中から最小の評価優先インデックスを有するパケットフィルタの一致を評価し、一致が発見されないならば、それらの評価優先インデックスの昇順でパケットフィルタの評価を進行する。この手順は一致が発見されるまで実行され、この場合データパケットは一致するＴＦＴパケットフィルタに対応しているＰＤＰコンテキストに関連されるＧＴＰトンネルを介してＳＧＳＮへトンネルされる。３Ｇ ＴＳ ２３．０６０の９．３条項にしたがって、一致が発見されない場合には、データパケットはそれに割当てられたＴＦＴをもたないＰＤＰコンテキストを介してトンネルされるが、全てのＰＤＰコンテキストが割当てられたＴＦＴを有するならば、ＧＧＳＮは静かにそのデータパケットを破棄しなければならない。

ＴＦＴはデータパケットを濾波し、したがってそれらを正確なＰＤＰコンテキストのためにＧＴＰトンネルへ経路設定またはマップするために使用されるダウンリンクデータパケットのヘッダに関連する属性を含んでいる。その属性はＩＰヘッダフィールドに関して規定される。３Ｇ ＴＳ ２３．０６０の１５．３．２条項にしたがって、ＴＦＴに含まれているデータパケットヘッダ属性はＩＰｖ４およびＩＰｖ６ヘッダフィールドの両者に関して特定される。各ＴＦＴは１から８のパケットフィルタからなり、それぞれ特有のパケットフィルタ識別子により識別される。パケットフィルタはまた同一のＰＤＰアドレスを共有するＰＤＰコンテキストに関連する全てのＴＦＴ内で特有である評価優先インデックスを有する。３Ｇ ＴＳ ２３．０６０の１５．３．２条項にしたがって、それぞれの有効なパケットフィルタは所定のＴＦＴ内で特有の識別子と、１つのＰＤＰアドレスに対する全てのＴＦＴ内で特有である評価優先インデックスと、少なくとも１つの以下のＩＰｖ４またはＩＰｖ６パケットヘッダ属性とを含んでいる。それらの属性は、
−ソースアドレスおよびサブネットマスク、
−プロトコル番号（ＩＰｖ４）または次のヘッダ（ＩＰｖ６）、
−目的地ポートレンジ、
−ソースポートレンジ、
−ＩＰＳｅｃセキュリティパラメータインデックス（ＳＰＩ）、
−サービスのタイプ（ＴｏＳ）（ＩＰｖ４）またはトラフィッククラス（ＩＰｖ６）およびマスク、
−フローラベル（ＩＰｖ６）。

しかしながら、これらの全てが矛盾を生じずに組合わせて使用されるわけではない。実際には、ソースアドレスおよびサブネットマスクは、一般使用の場合にはＭＳは各異なる対応ノードＰＤＰアドレスに対するその（または１つの）ＰＤＰアドレスに対して異なるＰＤＰコンテキストを設定するので、最も普通に使用される。属性リストは目的地アドレス属性を含まず、目的地ポート範囲だけを含むことに注意すべきである。これはＴＦＴパケットフィルタがパケットを複数の目的地アドレスのうちの１つへマップするために使用されないで、単一のＭＳの単一の目的地アドレスに対して設定される複数のＰＤＰコンテキストのうちの１つに対応するＧＴＰチャンネルにマップするために使用されるためである。

しかしながら、前述したように、ソースアドレス属性はある状態下で、ダウンリンクの入来パケットをＭＳにマップするのに十分ではない。本発明によれば、ＭＩＰｖ４またはＭＩＰｖ６によるＭＳのエネーブルが後続する手順（これをＭＮと呼ぶ）が変更される。ＧＰＲＳネットワークに移動するとき、ＭＮはＧＰＲＳネットワークに添付し、ＧＰＲＳネットワークに留まる期間に使用するためのＣｏＡ（またはＣｏＣｏＡ）、即ちＩＰｖ４またはＩＰｖ６アドレスが与えられる。通常のＭＩＰ手順を使用して、ＭＮはＭＩＰｖ４またはＭＩＰｖ６ホーム結合更新手順を使用して、このアドレスをそのＨＮ中のＨＡにより登録する。これを行うために、最初に、ここで参考文献とされている３Ｇ ＴＳ ２３．０６０の９．２．２条項に記載されているＭＳ開始ＰＤＰコンテキスト付勢手順を使用してＧＰＲＳネットワーク中のＰＤＰコンテキストを付勢しなければならない。

［第１の実施形態］
本発明の第１の実施形態によれば、成功したホーム結合のとき、ＭＮはその後、ＰＤＰコンテキストに関連されるＴＦＴ中にホームエージェントアドレス、即ちＩＰｖ４またはＩＰｖ６アドレスを含むように、付勢されたＰＤＰコンテキストを変更し、ＧＧＳＮがＨＡをトンネルするパケットを濾波することを可能にする。ＭＮはここで参考文献とされている３Ｇ ＴＳ ２３．０６０の９．２．３条項に記載されているＭＳ開始ＰＤＰコンテキスト変更手順を使用する。図４は、ＰＤＰコンテキスト変更手順を示している。ステップ60で、ＭＮ18は付勢されたＰＤＰコンテキストを使用して、そのＨＮ（図示せず）中のＨＡによりＭＩＰホーム結合手順を実行する。これが成功したことを仮定すると、ステップ62で、ＭＮは変更ＰＤＰコンテキストリクエストをそのＳＧＳＮ14に送信する。変更ＰＤＰコンテキストリクエストメッセージは、ＨＮ中のＭＮのホームエージェントのＩＰアドレスを含むように、ＰＤＰコンテキストに関連するＴＦＴを付加または変更するための命令を含んでいる。ＭＮは随意選択的に変更ＰＤＰコンテキストリクエストメッセージ中のＱｏＳプロフィールを変更するための命令も送信してもよいことに注意すべきである。ステップ64で、ＳＧＳＮ14は前述したように、ＴＦＴを付加または変更するための命令を含んでいる更新ＰＤＰコンテキストリクエストメッセージをＧＧＳＮ12へ送信する。ＧＧＳＮ12は（例えばＴＦＴのパケットフィルタの属性が有効な組合せを形成するか否かを見るために）命令をチェックし、受入れ可能ならば、それに応じてＰＤＰコンテキストに対してＴＦＴを記憶または変更する。その後、ステップ66で、ＧＧＳＮ12は成功したことを示す更新ＰＤＰコンテキスト応答メッセージをＳＧＳＮ14へ送信する。ステップ68で、（例えばＰＤＰコンテキストのＱｏＳプロフィールが変更されているＩｕモードの３Ｇ ＧＰＲＳネットワークで）無線アクセスベアラ変更が行われる。ステップ70で、ＳＧＳＮ14はＰＤＰコンテキストの変更が成功したことを確認するために変更ＰＤＰコンテキスト受入れメッセージをＭＮへ送信する（即ちＴＦＴ）。

第１の実施形態の別のバージョンでは、変更されたＴＦＴパケットフィルタが使用され、ここでは、パケットフィルタに含まれることのできる可能なＩＰｖ４またはＩＰｖ６パケットヘッダ属性のリストが以下のように増加される。
−ソースアドレスおよびサブネットマスク、
−ホームエージェントアドレス、
−プロトコル番号（ＩＰｖ４）または次のヘッダ（ＩＰｖ６）、
−目的地ポートレンジ、
−ソースポートレンジ、
−ＩＰＳｅｃセキュリティパラメータインデックス（ＳＰＩ）、
−サービスのタイプ（ＴｏＳ）（ＩＰｖ４）またはトラフィッククラス（ＩＰｖ６）およびマスク、
−フローラベル（ＩＰｖ６）。
ここでは、ホームエージェントアドレスはそのＨＮ中のＭＮに対するＭＩｐｖ４またはＭＩＰｖ６ＨＡのＩＰｖ４またはＩＰｖ６アドレスである。

したがって、ＰＤＰコンテキストに対して、ＭＮに記憶されているＴＦＴパケットフィルタと、ＧＧＳＮは特別に識別されたフィールド中にＭＮのホームエージェントのＩＰｖ４またはＩＰｖ６アドレスを含むことができる。ホームエージェントアドレス属性の性質は、他の属性との組合せの有効性に関しては、ソースアドレス属性（３Ｇ ＴＳ ２３．０６０の１５．３．２条項参照）の性質と同一である。しかしながら、ＴＦＴはソースアドレスおよびホームエージェントアドレス属性を単一にまたはソースアドレスとホームエージェントアドレス属性の両者を組合わせて有しているパケットフィルタを具備していてもよい。両属性が単一のＴＦＴパケットフィルタにおいて特定される場合には、これらは代用可能として扱われ、即ちこれらは論理演算子ＯＲを使用して結合される。したがって、ソースアドレス属性ＯＲに一致するソースアドレスを有するか、ホームエージェントアドレス属性に一致するソースアドレスを有するデータパケットはＴＦＴパケットフィルタの少なくともこれらの属性を整合する。ＧＧＳｎの機能は変更されたＴＦＴパケットフィルタを使用して、ＭＳへダウンリンクするための入来データパケットの整合を行うように変更される。同一の効果が２つのパケットフィルタをＴＦＴに含むことにより実現され、一方のパケットフィルタは規定されたソースアドレス属性を有し、他方は規定されたホームエージェントアドレス属性を有することに注意する必要がある。

第１の実施形態の第１のバージョンによるＧＧＳＮが後続する変更されたプロセスを図５のフロー図に示している。プロセスはステップ80で開始する。ステップ82で、ＧＧＳＮはＧＰＲＳネットワーク中のＣｏＡを有する特定のＭＮへダウンリンクするためのデータパケットを受信する。ステップ84で、ＧＧＳＮはデータパケットのソースアドレスをＭＮのＣｏＡに関連されるＰＤＰコンテキストのＴＦＴのソースアドレスフィールドに対してチェックする。ステップ86で、一致が存在することが決定されたならば、プロセスはステップ88に継続し、ここでパケットは一致するＴＦＴを含んだＰＤＰコンテキストを使用してＭＮへ転送される。プロセスはその後、ステップ96へ移行し終了する。これはＧＧＳＮの通常の動作に対応する。しかしながら、ステップ86で、一致が存在しないことが決定されたならば、プロセスはステップ90に移り、ここでＧＧＳＮはデータパケットのソースアドレスをＭＮのＣｏＡに関連されるＰＤＰコンテキストのＴＦＴの増加されたホームエージェントアドレスフィールドに対してチェックする。ステップ92で、一致が存在することが決定されたならば、プロセスはステップ94に続き、ここでパケットは一致するＴＦＴを含んだＰＤＰコンテキストを使用してＭＮへ転送される。プロセスはその後、ステップ96へ進み終了する。しかしながら、ステップ92で、一致が存在しないことが決定されたならば、プロセスはステップ96に進み、終了する。データパケットのソースアドレスをＴＦＴに一致させることに失敗したことはデータパケットのドロップを生じるか、代わりに、存在するならば、関連されるＴＦＴのないＰＤＰコンテキストを使用してＭＮへ転送されることに注意すべきである。

代わりに、第１の実施形態の第２のバージョンでは、標準的なＴＦＴパケットフィルタ属性が使用され、図４を参照して前述したＭＳ開始ＰＤＰコンテキスト変形手順は標準的なソースアドレス属性中にＭＮのＨＡを含んでいる新しいパケットフィルタを付加するように既存のＴＦＴに付加するかまたはそれを変更するために使用される。この新しいパケットフィルタはＴＦＴの任意の既存のパケットフィルタに付加される。代わりに、パケットフィルタは既存のパケットフィルタを置換または変更してもよい。

ＭＩＰホーム結合更新手順を行った後に付勢されたＰＤＰコンテキストが変更されることを前述したが、任意の付勢されたＰＤＰコンテキストはＭＮのＨＡアドレスを含むように新しいＴＦＴパケットフィルタを含むように変更されるか既存のＴＦＴパケットフィルタを変更できることが明白である。したがって、例えば、ＣＮとの通信セッションで付勢されるＰＤＰコンテキストは、１）（増加された属性リストを使用して）ＣＮのソースアドレスおよびＭＮのＨＡアドレスの両者を有する１つのパケットフィルタ、または代わりに２）（増加されたまたは標準的な属性リストを使用して）一方がＣＮのソースアドレスを有し、他方がＭＮのＨＡアドレスを有する２つのパケットフィルタと関連されたＴＦＴを有するように変更されてもよい。このようにして、ＣＮによりＭＮのＨＡｄｄｒに送信され、ＨＡを介してトンネルされるパケットは、ＣＮにより直接的にＭＮのＣｏＡ（またはＣｏＣｏＡ）へ送信されるパケットと同様に、ＧＧＳＮにより適切なＰＤＰコンテキストにより濾波されることができる。

ＰＤＰコンテキストは、ここで参考文献とされている３Ｇ ＴＳ ２３．０６０の９．２．２条項に記載されているＭＳ開始ＰＤＰコンテキスト付勢手順を使用して、ＭＮのＨＡアドレスを含んでいる関連されたＴＦＴパケットフィルタと共に付勢されることができることも明白である。したがって、例えば、ＰＤＰコンテキストはＣＮとの通信セッションに対して付勢され、その付勢手順では、ＴＦＴは１）（増加された属性リストを使用して）ＣＮのソースアドレスおよびＭＮのＨＡアドレスの両者を有する１つのパケットフィルタ、または代わりに２）（増加されたまたは標準的な属性リストを使用して）一方がＣＮのソースアドレスを有し、他方がＭＮのＨＡアドレスを有する２つのパケットフィルタのいずれかを有するＰＤＰコンテキストと関連されてもよい。このようにして、ＣＮによりＭＮのＨＡｄｄｒに送信され、ＨＡを介してトンネルされるパケットは、ＣＮにより直接ＭＮのＣｏＡ（またはＣｏＣｏＡ）へ送信されるパケットと同様に、ＧＧＳＮにより適切なＰＤＰコンテキストに濾波されることができる。

第１の実施形態では、ホーム結合手順を実行するＭＮ以外の事象が前述したようにＴＦＴパケットフィルタの生成または変更をトリガーするために使用されることができることが明白である。一般に、ＧＰＲＳネットワークの任意のノードはＭＮのパケットがトンネルされることを検出し、したがって説明するようにＴＦＴパケットフィルタを生成または変更するようにＭＮに命令するかまたはその他の方法でそれを実行する。

［第２の実施形態］
ＩＰｖ６ＨＡｄｄｒを有するＭＮに適用する本発明の第２の実施形態にしたがって、ＭＮのＨＡは、それがＭＮにトンネルする全てのデータパケットに対するカプセル化ＩＰｖ６パケットのＩＰｖ６のホップバイホップ選択肢拡張ヘッダ中にＣＮのＩＰアドレスを含むように変形される。図６のＡは、カプセル化データパケットの構造を示している。基本的なＩＰｖ６ヘッダ100が最初に来る。標準的なＩＰｖ６（ＲＦＣ２４６０）にしたがって、基本的ＩＰｖ６ヘッダ100のＩＰｖ６の次のヘッダフィールドにゼロを置くことによって、ＩＰｖ６のホップバイホップ選択肢拡張ヘッダ102の存在が示されている。ホップバイホップ選択肢拡張ヘッダ102は基本的ＩＰｖ６ヘッダ100の直ぐ後に後続する。最後に、ペイロード104、即ちＴＣＰまたはＵＤＰのような上部層ヘッダとカプセル化されたデータパケットがホップバイホップ選択肢拡張ヘッダ102に後続する。図６のＢはホップバイホップ選択肢拡張ヘッダ102の構造を示している。ホップバイホップ選択肢拡張ヘッダ102の次のヘッダおよびＨｄｒ Ｅｘｔ Ｌｅｎフィールドは明瞭にする目的で省略されている。ＣＮのＩＰアドレスはホップバイホップ選択肢拡張ヘッダ102のタイプ−長さ−値（ＴＬＶ）エンコード選択肢に含まれる。したがって、適切な選択肢タイプ番号（８ビット）106は選択肢のタイプ（即ちＭＮのＨＡを介してトンネルされるパケットに対するＭＮのＨＡｄｄｒの仕様）を識別するために使用され、それに（ＣＮアドレスの長さに応じた）選択肢データ長108が後続し、それに選択肢データ自体、即ちＣＮアドレス110が後続する。

この実施形態では、ＧＧＳＮはＩＰｖ６エネーブルされ、このようなヘッダを有する任意の受信されたＩＰｖ６パケットのホップバイホップ拡張ヘッダを検査する。ＨＡからのトンネルがＭＮまで延在するので、ＧＧＳＮは中間のノードであり、ＩＰｖ６仕様（ＲＦＣ２４６０）によれば、ＧＧＳＮはホップバイホップ拡張ヘッダを検査しなければならないことに注意する必要がある。反対に、ＩＰｖ６仕様（ＲＦＣ２４６０）によれば、ＧＧＳＮはそれが中間のノードであるので、任意の他のＩＰｖ６拡張ヘッダを検査してはならないことに注意しなければならない。さらに、ＧＧＳＮはホップバイホップ拡張ヘッダを含んでいるＩＰｖ６データパケットで識別されるＣＮのＩＰアドレスをＭＮのＣｏＡに関連されるＰＤＰコンテキストに対して記憶されているＴＦＴパケットフィールドにマップし、一致が発見されるならば、データパケットをそれに応じて転送しようとするように変更される。ＧＧＳＮが後続するプロセスは図７に示されている。プロセスはステップ120で開始する。ステップ122で、ＧＧＳＮはＧＰＲＳネットワーク中にＣｏＡを有する特定のＭＮにダウンリンクするためのデータパケットを受信する。ステップ124で、ＧＧＳＮは受信されたパケットのホップバイホップ選択肢拡張ヘッダを試験する。ステップ126で、ＧＧＳＮはホップバイホップ選択肢拡張ヘッダ中で特定されたＣＮアドレスを、ＭＮのＩＰアドレス（即ちそのＣｏＡ）に関連するＰＤＰコンテキストのＴＦＴのソースアドレスフィールドに対してチェックする。ステップ128で、一致が存在することが決定されたならば、プロセスはステップ130に進み、ここでパケットは一致するＴＦＴを含んだＰＤＰコンテキストを使用してＭＮへ転送される。プロセスはその後、ステップ132へ進み終了する。しかしながら、ステップ128で、一致が存在しないことが決定されたならば、プロセスはステップ132に移り、そこで終了する。

ＧＧＳＮはまた標準的なＧＧＳＮ機能にしたがって、受信されたデータパケットのソースアドレスを、ＭＮに関連するＰＤＰコンテキストのＴＦＴのソースアドレスフィールドと一致させようとする。したがって、ソースアドレス属性ＯＲに一致するソースアドレスを有するか、ソースアドレス属性に一致するホップバイホップ選択肢ヘッダで特定されるＩＰアドレス、即ちＣＮのＩＰアドレスを有するデータパケットは、ＴＦＴパケットフィルタの少なくともこれらの属性に一致し、適切なＰＤＰコンテキストに対応するＧＴＰトンネルに経路設定される。データパケットをＴＦＴに一致することに失敗するとデータパケットはドロップされるか、あるいは、存在するならば、関連されるＴＦＴのないＰＤＰコンテキストを使用してＭＮへ転送されることに注意する必要がある。随意選択的に、トンネル動作されたデータパケットの受信後、ＭＮは、第１の実施形態に関して説明したように、トンネルされたデータパケットがＧＧＳＮによりＭＮへ転送されることを可能にするために新しいＰＤＰコンテキストを変更または生成することができる。

第２の実施形態の変形では、ＭＮのＨＡはそれがＭＮにトンネルするデータパケットのカプセル化ＩＰｖ６パケットのＩＰｖ６のホップバイホップ選択肢拡張ヘッダ中にＣＮのＩＰアドレスを選択的に含むように変更される。この含ませる動作はＭＮがＧＰＲＳネットワークでサービスを与えられていることをＨＡが検出したときにのみ行われる。したがって、ａ）トンネルされたデータパケットのホップバイホップ選択肢拡張ヘッダを含んでいるＨＡと、ｂ）ホップバイホップ選択肢拡張ヘッダを検査する（ＧＧＳＮを含んだ）ＭＮ方向へのルート上の中間ノードの処理オーバーヘッドは、これらが必要ではない場合には、除去される。

［第３の実施形態］
本発明の第３の実施形態によれば、関連するＴＦＴのないＰＤＰコンテキストは、ＭＩＰエネーブルされたＭＮがＧＰＲＳネットワークのホームから離れているときには常に設定される。したがってデータパケットを受信するとき、ＧＧＳＮはパケットを関連するＴＦＴを有するこれらのＰＤＰコンテキストに一致しようと試みるが、これが失敗した場合には、パケットは関連するＴＦＴのないＰＤＰコンテキストを使用して経路設定される。したがってＭＮのＨＡを介してトンネルされるパケットはＧＧＳＮによりＭＮへ転送され、ここでカプセルを解除されることができる。ＭＮはその後、既存の通信セッションが存在するならば、カプセルを解除されたパケットのソースアドレスを検査することによって、パケットをそれに関連付ける。ＭＮはその後、第１の実施形態に関して前述したように、トンネルされたデータパケットがＧＧＳＮによりＭＮへ転送されることを可能にするために新しいＰＤＰコンテキストを変更または生成することができる。

ＰＤＰコンテキストが関連されたＴＦＴをもたないので、この方法でサポートされることのできるＱｏＳが存在しないために、第１および第２の実施形態の方法は、第３の実施形態の方法に対して好ましい。また、ＰＤＰコンテキストおよび対応するＧＴＰトンネルが既にＣＮとの通信セッションを設定しているにもかかわらず、ＧＴＰトンネルおよびＰＤＰコンテキストはＭＮのＨＡを介して可能に経路設定されたトラフィックで維持されなければならないので、この方法はベアラリソースを浪費する。しかしながら、この方法はバックグラウンドクラスサービスおよび非実時間サービスのような特別なＱｏＳ要求なしに幾つかのサービスで有効である。

［第４の実施形態］
本発明の第４の実施形態によれば、ＨＡトンネル手順は以下のように変更される。第１に、ＨＡはトンネルされたデータパケットをＭＮのＣｏＡにアドレスするのではなく、ＧＰＲＳネットワークのＧＧＳＮのアドレスにアドレスする。まだ知られていないならば、ＨＡがどのようにしてＧＧＳＮのアドレスを与えられるかを、以下手短に説明する。第２に、ＨＡはトンネルされたデータパケットの到着時にＧＧＳＮにより読取られることができるＩＰｖ６目的地選択肢ヘッダ中にＣＮアドレスを含んでいる。第３に、ＭＮのＣｏＡはトンネルされたパケットのＩＰｖ６経路設定ヘッダタイプ０拡張ヘッダ中に含まれている。この経路設定ヘッダはパケットの目的地アドレス（この場合はＧＧＳＮ）へ転送され、その後経路設定ヘッダ（この場合は丁度、ＭＮのＣｏＡ）に含まれるさらに別の経路設定アドレスのリストに対応する各ノードへ順番に転送されることによって、種々のアドレス開始においてＩＰｖ６パケットが複数のノードを通って経路設定されることを可能にする。

図８のＡはカプセル化データパケットの構造を示している。基本ＩＰｖ６ヘッダ140が最初に来る。ＩＰｖ６経路設定ヘッダ（タイプ０）142の存在は、標準的なＩＰｖ６（ＲＦＣ２４６０）にしたがって、基本ＩＰｖ６ヘッダ100のＩＰｖ６の次のヘッダフィールドで示されている。基本ＩＰｖ６ヘッダ140の目的地アドレスはＧＧＳＮのアドレスであることに注意する必要がある。ＩＰｖ６経路設定ヘッダ（タイプ０）142は基本ＩＰｖ６ヘッダ140の直ぐ後に後続する。ＩＰｖ６目的地選択肢拡張ヘッダ144の存在は、標準的なＩＰｖ６（ＲＦＣ２４６０）にしたがって、ＩＰｖ６経路設定ヘッダ（タイプ０）142のＩＰｖ６の次のヘッダフィールドで示されている。ＩＰｖ６目的地選択肢拡張ヘッダ144はＩＰｖ６経路設定ヘッダ（タイプ０）142の直ぐ後に後続する。最後に、ペイロード146、即ちＴＣＰまたはＵＤＰのような上部層ヘッダおよびカプセル化されたデータパケットが目的地選択肢拡張ヘッダ144に後続する。

図８のＢは、目的地選択肢拡張ヘッダ144自体の構造を示している。この拡張ヘッダのフォーマットはＭＩＰｖ６インターネット草案の条項６．３に記載されている。目的地選択肢拡張ヘッダ144の次のヘッダおよびＨｄｒ Ｅｘｔ Ｌｅｎフィールドは明瞭にする目的で省略されている。ＣＮのアドレスは目的地選択肢拡張ヘッダ144中のタイプ−長さ−値（ＴＬＶ）エンコード選択肢に含まれる。したがって、選択肢タイプ番号148は選択肢のタイプ（この場合はＭＩＰｖ６で特定されるように201）を識別するために使用され、それに（ＣＮアドレスの長さにしたがう）選択肢データ長150が後続し、それに選択肢データ自体、即ちＣＮアドレス152が後続する。

図８のＣは経路設定ヘッダ（タイプ０）拡張ヘッダ142自体の構造を示している。この拡張ヘッダのフォーマットはＩＰｖ６（ＲＦＣ２４６０）に記載されている。経路設定ヘッダ（タイプ０）拡張ヘッダ142の次のヘッダおよびＨｄｒ Ｅｘｔ Ｌｅｎフィールドは明瞭にする目的で省略されている。経路設定タイプフィールド154（即ちこの場合は０）が次にきて、その後に残されたセグメントフィールドが後続し、これはＨＡにより最初に１に設定されている（これはデータパケットがＧＧＳＮからＭＮのＣｏＡに転送されるときに０までカウントダウンする）。保留されたフィールド（０に設定）とＭＮ自体のＣｏＡがそれに後続する。

この実施形態では、ＧＧＳＮはＩＰｖ６エネーブルであり、経路設定ヘッダ（タイプ０）拡張ヘッダ142にしたがって、それを転送する前に受信されたＩＰｖ６パケットの目的地選択肢拡張ヘッダ144を検査する。目的地アドレスとしてＧＧＳＮのアドレスを提供することにより、トンネルされたパケットは最初にＧＧＳＮに転送され、そのＧＧＳＮは（第３の実施形態のように中間ノードではなく）目的地ノードであり、それ故、目的地選択肢拡張ヘッダ144を読取ることができることに注意しなければならない。さらに、ＧＧＳＮは目的地選択肢ヘッダ中で識別されるＣＮのＩＰアドレスをＭＮのＣｏＡに関連するＰＤＰコンテキストに対して記憶されたＴＦＴパケットフィールドにマップしようとするように変更され、これはＩＰｖ６経路設定ヘッダタイプ０選択肢中に含まれている。一致が発見されたならば、ＧＧＳＮはそれに応じて、ＭＮのＣｏＡの適切なＰＤＰコンテキストに関連されるＧＴＰトンネルにデータパケットを転送する。

ＧＧＳＮにより後続されるプロセスが図９に示されている。このプロセスはステップ170で開始する。ステップ172で、ＧＧＳＮはＩＰｖ６経路設定ヘッダタイプ０を有するデータパケットを受信し、これはパケットがＧＰＲＳネットワーク中にＣｏＡを有する特定のＭＮのＣｏＡへのダウンリンクのためのものであることを示している。ステップ174で、ＧＧＳＮは受信されたパケットの目的地選択肢拡張ヘッダを検査する。ステップ176で、ＧＧＳＮは目的地選択肢拡張ヘッダで特定されたＣＮアドレスを、ＭＮのＣｏＡに関連するＰＤＰコンテキストのＴＦＴのソースアドレスフィールドに対してチェックする。ステップ178で、一致が存在することが決定されたならば、プロセスはステップ180に進み、ここでパケットは一致するＴＦＴを含んだＰＤＰコンテキストを使用してＭＮへ転送される。プロセスはその後、ステップ182へ続き終了する。しかしながら、ステップ178で、一致が存在しないことが決定されたならば、プロセスはステップ182に移り、終了する。

ＧＧＳＮはまた、標準的なＧＧＳＮ機能にしたがって、受信されたデータパケットのソースアドレスをＭＮに関連するＰＤＰコンテキストのＴＦＴのソースアドレスフィールドと一致させようとする。したがって、ソースアドレス属性ＯＲに一致するソースアドレスを有するか、ソースＩＰアドレス属性に一致する目的地選択肢ヘッダで特定されるＩＰアドレス、即ちＣＮのＩＰアドレスを有するデータパケットは、ＴＦＴパケットフィルタの少なくともこれらの属性に一致し、適切なＰＤＰコンテキストに対応するＧＴＰトンネルに経路設定される。随意選択的に、ＭＮはその後、第１の実施形態に関して説明したように、トンネルされたデータパケットがＧＧＳＮによりＭＮに転送されることを可能にするため新しいＰＤＰコンテキストを変更または生成できる。

しかしながら、前述したように、この手順はＨＡがＧＰＲＳネットワーク中のＧＧＳＮのアドレスを知るかそれを与えられることを必要とする。ＨＡは例えばローミングの同意のような２つのネットワーク間の市場構造の理由によりＧＰＲＳネットワークのＧＧＳＮのアドレスを知ることができる。しかしながら、知らないならば、以下のようにしてアドレスが与えられることができる。好ましくはホーム結合の更新手順を行うのと同時に、しかし恐らくはその後に、ＭＮはメッセージを送信するか、好ましくはＧＧＳＮ自体にＧＧＳＮのＩＰアドレスを含むメッセージをＨＡへ送信するように命令する。ＭＮはここで参考文献とされている３Ｇ ＴＳ ２３．０６０の条項９．２．２に記載されているＰＤＰ構造選択肢を使用して、そのＧＧＳＮにこのようなパケットを送信するように命令することができる。ＰＤＰ構造選択肢はＧＧＳＮがＭＳに転送する随意選択的なＰＤＰパラメータを含んでいる。これらの随意選択的なＰＤＰパラメータの送信は、最初にＧＰＲＳネットワークに移動するＭＮにおいて、ホーム結合更新をＨＡへ送信するときに使用するためのＰＤＰコンテキストの設定に使用される付勢ＰＤＰコンテキストリクエストメッセージ中のＭＮによりリクエストされてもよい。

第４の実施形態の変形では、ＨＡ機能はＨＡがＭＮにより、それ（ＭＮ）がＧＰＲＳネットワーク中でサービスを与えられていることを通知されるときのみ前述の手順を選択的に使用するように変更される。

本発明はＧＰＲＳネットワーク以外のネットワークに適用できることが明白である。一般的に、これはダウンリンクパケットをユーザまたはネットワーク側ノードの方向へ転送するためにゲートウェイノードが（ＰＤＰコンテキストまたはその他の）複数のチャンネルから１つを選択することを必要とする。

本発明はノード（ユーザノードまたはネットワークのノード）がＭＩＰエネーブルＭＮである以外の理由でトンネルされたパケットを受信する場合のような状況に適用できることも明白である。通常、本発明はパケットがネットワークまたはサブネットワーク間でトンネルされることができる時、ゲートウェイノードがダウンリンクパケットをノード方向に転送するための複数のチャンネルから１つを選択する必要がある場合、およびトンネルがゲートウェイノードまたは目的地ネットワークのノードを超えて延在する場合にはいつでも適用することができることは明白である。例えば、本発明は層２トンネル動作プロトコル（Ｌ２ＴＰ）または他のトンネル動作プロトコルを使用して、バーチャル私設ネットワークで応用を有する。

本発明はまたゲートウェイノードが通常のパケット濾波および／またはサービス／ベアラ（bearer）アクセスおよび／またはサービスの妨害に対して保護するためのファイヤウォール機能を行う必要がある状態に適用できる。

Claims (56)

1. 第１のパケット交換データネットワークのゲートウェイノードが、トンネルされたデータパケットを第１のパケット交換データネットワークでサービスを与えられる移動体ノードの目的地パケットデータプロトコルアドレスへ転送するための第１のチャンネルを選択することを可能にする方法において、
   ゲートウェイノードは移動体ノードの目的地パケットデータプロトコルアドレスへデータパケットを転送するための複数のチャンネルから第１のチャンネルを選択するように構成され、選択はゲートウェイノードにより受信されたデータパケットに関連されるパケットデータプロトコルアドレスを複数のチャンネルに関連される１以上のデータパケットフィルタに一致することにより行われ、前記方法は、
   ａ）第１のパケット交換データネットワークに対して外部の第２のパケット交換データネットワークのトンネル動作ノードを介してトンネルされるデータパケットをゲートウェイノードが受信することを示すトリガー事象を検出し、
   ｂ）検出に応答して、第１のチャンネルに関連する第１のデータパケットフィルタに含まれるように第１のパケットデータプロトコルアドレスを構成し、第１のパケットデータプロトコルアドレスは、ゲートウェイノードにより受信されたデータパケットと関連されるとき、データパケットがトンネル動作ノードを介してトンネルされたことを示し、
   第１のデータパケットフィルタはパケットデータを目的地パケットデータプロトコルアドレスにおける移動体ノードへ転送するために複数のチャンネルから選択するときゲートウェイノードにより使用される方法。
2. ゲートウェイノードは、受信されたデータパケットのソースアドレスが複数のチャンネルに関連する１以上のデータパケットに一致することにより、複数のチャンネルから選択するように構成されており、第１のパケットデータプロトコルアドレスはトンネル動作ノードのパケットデータプロトコルアドレスである請求項１記載の方法。
3. トリガー事象は移動体ノードにより検出され、移動体ノードは第１のデータパケットフィルタに第１のパケットデータプロトコルアドレスを含むように構成する請求項１または２記載の方法。
4. 移動体ノードは第２のパケット交換データネットワークのホームパケットデータプロトコルアドレスを有しており、トリガー事象はトンネル動作ノードによりその目的地パケットデータプロトコルアドレスを登録する移動体ノードであり、それによってそのホームパケットデータプロトコルアドレスにおいて移動体ノードにアドレスされたデータパケットはトンネル動作ノードによりその目的地パケットデータプロトコルアドレスにおける移動体ノードへトンネルされることができる請求項３記載の方法。
5. トリガー事象は関連するデータパケットフィルタをもたない第２のチャンネルを通ってゲートウェイノードから送信されるトンネルされたデータパケットを受信する移動体ノードである請求項３記載の方法。
6. ネットワークまたはサブネットワーク間の移動体ノードの移動性は移動体インターネットプロトコル（ＭＩＰ）標準を使用してサポートされ、トンネル動作ノードは移動体ノードのホームエージェント（ＨＡ）であり、目的地パケットデータプロトコルアドレスは移動体ノードのアドレスのケア（ＣｏＡ、ＣｏＣｏＡ）である請求項１乃至５のいずれか１項記載の方法。
7. 第１のパケットデータプロトコルアドレスは第２のパケット交換データネットワーク中の移動体ノードのホームエージェント（ＨＡ）のアドレスである請求項６記載の方法。
8. ステップｂ）に先立って、ゲートウェイノードが、移動体ノードとの通信セッションに含まれる対応ノードによって送信されるデータパケットを転送するための第１のチャンネルを選択することを可能にするために第１のパケットフィルタが生成され、ステップｂ）において、第１のデータパケットフィルタが第１のパケットデータプロトコルアドレスを含むように変更される請求項１乃至７のいずれか１項記載の方法。
9. 第１のパケットデータプロトコルアドレスは第１のデータパケットフィルタの対応ノードのデータパケットプロトコルアドレスを置換する請求項８記載の方法。
10. 第１のパケットデータプロトコルアドレスは、対応するノードのデータパケットプロトコルアドレスを含んでいる第１のデータパケットフィルタに付加される請求項８記載の方法。
11. 第１のパケットフィルタは前記ステップｂ）で新たに生成される請求項１乃至１０のいずれか１項記載の方法。
12. 第１のパケット交換データネットワークは一般的なパケット無線サービス（ＧＰＲＳ）標準に準じており、複数のチャンネルは第１のパケット交換データネットワーク中の複数のパケットデータプロトコルコンテキストに対応する請求項１乃至１１のいずれか１項記載の方法。
13. 第１のパケット交換データネットワーク中でサービスを与えられ、第１のパケット交換データネットワークにおける目的地パケットデータプロトコルを有する移動体ノードにおいて、その移動体ノードは、
    ａ）移動体ノードの目的地パケットデータプロトコルアドレスにアドレスされ、第１のパケット交換データネットワークに対して外部の第２のパケット交換データネットワークのトンネル動作ノードを介してトンネルされたデータパケットを第１のパケット交換データネットワークのゲートウェイノードが受信することを示すトリガー事象を検出し、
    ｂ）その検出に応答して、第１のパケットデータプロトコルアドレスが、第１のチャンネルに関連する第１のデータパケットフィルタ中に含まれるように構成し、ゲートウェイノードにより受信されるデータパケットと関連されるとき、第１のパケットデータプロトコルアドレスはデータパケットがトンネル動作ノードを介してトンネルされたことを示し、第１のデータパケットフィルタはデータパケットを目的地パケットデータプロトコルアドレスの移動体ノードへ転送するためのチャンネルを選択するときゲートウェイノードによって使用され、選択はゲートウェイノードにより受信されたデータパケットに関連されるパケットデータプロトコルアドレスを複数のチャンネルに関連される１以上のデータパケットフィルタに一致させることによって行われ、それぞれのチャンネルはデータパケットを移動体ノードの目的地パケットデータプロトコルアドレスへ転送する移動体ノード。
14. ゲートウェイノードは、受信されたデータパケットのソースアドレスを複数のチャンネルに関連する１以上のデータパケットに一致することにより、複数のチャンネルから選択するように構成されており、第１のパケットデータプロトコルアドレスはトンネル動作ノードのパケットデータプロトコルアドレスである請求項１３記載の移動体ノード。
15. 移動体ノードは第２のパケット交換データネットワークにおけるホームパケットデータプロトコルアドレスを有し、トリガー事象はトンネル動作ノードによりその目的地パケットデータプロトコルアドレスを登録する移動体ノードであり、それによってそのホームパケットデータプロトコルアドレスの移動体ノードにアドレスされたデータパケットはトンネル動作ノードによりその目的地パケットデータプロトコルアドレスの移動体ノードへトンネルされることができる請求項１３または１４記載の移動体ノード。
16. トリガー事象は関連するデータパケットフィルタをもたない第２のチャンネルを通って、ゲートウェイノードから送信されるトンネルされたデータパケットを受信する移動体ノードである請求項１３または１４記載の移動体ノード。
17. ネットワークまたはサブネットワーク間の移動体ノードの移動性は移動体インターネットプロトコル（ＭＩＰ）標準方式を使用してサポートされ、トンネル動作ノードは移動体ノードのホームエージェント（ＨＡ）であり、目的地パケットデータプロトコルアドレスは移動体ノードのアドレスのケア（ＣｏＡ、ＣｏＣｏＡ）である請求項１３乃至１６のいずれか１項記載の移動体ノード。
18. 第１のパケットデータプロトコルアドレスは第２のパケット交換データネットワークの移動体ノードのホームエージェント（ＨＡ）のアドレスである請求項１７記載の移動体ノード。
19. ステップｂ）の前に、移動体ノードとの通信セッションに含まれる対応ノードにより送信されたデータパケットを転送するための第１のチャンネルをゲートウェイノードが選択することを可能にするために第１のパケットフィルタが生成され、ステップｂ）において、第１のデータパケットフィルタは第１のパケットデータプロトコルアドレスを含むように変更される請求項１３乃至１８のいずれか１項記載の移動体ノード。
20. 第１のパケットデータプロトコルアドレスは第１のデータパケットフィルタの対応ノードのデータパケットプロトコルアドレスを置換する請求項１９記載の移動体ノード。
21. 第１のパケットデータプロトコルアドレスは、対応するノードのデータパケットプロトコルアドレスを具備している第１のデータパケットフィルタに付加される請求項１９記載の移動体ノード。
22. 第１のパケットフィルタはステップｂ）で新たに生成される請求項１３乃至１８のいずれか１項記載の移動体ノード。
23. 第１のパケット交換データネットワークは一般的なパケット無線サービス（ＧＰＲＳ）標準方式にしたがっており、複数のチャンネルは第１のパケット交換データネットワークの複数のパケットデータプロトコルコンテキストに対応している請求項１３乃至２２のいずれか１項記載の移動体ノード。
24. データパケットを第１のパケット交換データネットワークでサービスを与えられる移動体ノードの目的地パケットデータプロトコルアドレスへ転送するために複数のチャンネルから１つのチャンネルを選択するように構成され、複数のチャンネルのそれぞれは移動体ノードの目的地パケットデータプロトコルアドレスへデータパケットを転送するためのものであり、選択はゲートウェイノードにより受信されたデータパケットに関連されるパケットデータプロトコルアドレスを複数のチャンネルに関連される１以上のデータパケットフィルタに一致することにより行われる第１のパケット交換データネットワークのゲートウェイノードにおいて、
    第１のパケット交換データネットワークに対して外部の第２のパケット交換データネットワークのトンネル動作ノードを介してトンネルされるデータパケットをゲートウェイノードが受信できることを示すトリガー事象の検出に応答して、ゲートウェイノードは受信されたデータパケットに関連するパケットデータプロトコルアドレスが第１のチャンネルに関連される第１のデータパケットフィルタに含まれる第１のパケットデータプロトコルアドレスと一致することにより、複数のチャンネルから第１のチャンネルを選択できるように構成され、第１のパケットデータプロトコルアドレスは、ゲートウェイノードにより受信されるデータパケットと関連されるとき、データパケットがトンネル動作ノードを介してトンネルされていることを示しているゲートウェイノード。
25. ゲートウェイノードは、受信されたデータパケットのソースアドレスを複数のチャンネルに関連する１以上のデータパケットに一致させることにより、複数のチャンネルから選択するように構成されており、第１のパケットデータプロトコルアドレスはトンネル動作ノードのパケットデータプロトコルアドレスである請求項２４記載のゲートウェイノード。
26. トリガー事象は移動体ノードにより検出され、ゲートウェイノードは第１のデータパケットフィルタに第１のパケットデータプロトコルアドレスを含むように移動体ノードにより命令される請求項２４または２５記載のゲートウェイノード。
27. 移動体ノードは第２のパケット交換データネットワークのホームパケットデータプロトコルアドレスを有しており、トリガー事象はトンネル動作ノードによりその目的地パケットデータプロトコルアドレスを登録する移動体ノードであり、それによってそのホームパケットデータプロトコルアドレスの移動体ノードにアドレスされたデータパケットはトンネル動作ノードによりその目的地パケットデータプロトコルアドレスの移動体ノードへトンネルされることができる請求項２６記載のゲートウェイノード。
28. トリガー事象は関連するデータパケットフィルタをもたない第２のチャンネルを通ってゲートウェイノードから送信されたトンネルされたデータパケットを受信する移動体ノードである請求項２７記載のゲートウェイノード。
29. ネットワークまたはサブネットワーク間の移動体ノードの移動性は移動体インターネットプロトコル（ＭＩＰ）標準方式を使用してサポートされ、トンネル動作ノードは移動体ノードのホームエージェント（ＨＡ）であり、目的地パケットデータプロトコルアドレスは移動体ノードのアドレスのケア（ＣｏＡ、ＣｏＣｏＡ）である請求項２４乃至２８のいずれか１項記載のゲートウェイノード。
30. 第１のパケットデータプロトコルアドレスは第２のパケット交換データネットワークの移動体ノードのホームエージェント（ＨＡ）のアドレスである請求項２９記載のゲートウェイノード。
31. ステップｂ）の前に、ゲートウェイノードが、移動体ノードとの通信セッション中に含まれる対応ノードによって送信されるデータパケットを転送するための第１のチャンネルを選択することを可能にするために第１のパケットフィルタが生成され、ステップｂ）において、第１のデータパケットフィルタが第１のパケットデータプロトコルアドレスを含むように変更される請求項２４乃至３０のいずれか１項記載のゲートウェイノード。
32. 第１のパケットデータプロトコルアドレスは第１のデータパケットフィルタの対応ノードのデータパケットプロトコルアドレスを置換する請求項３１記載のゲートウェイノード。
33. 第１のパケットデータプロトコルアドレスは、対応するノードのデータパケットプロトコルアドレスを含んでいる第１のデータパケットフィルタに付加される請求項３１記載のゲートウェイノード。
34. 第１のパケットフィルタはステップｂ）において新しく生成される請求項２４乃至３０のいずれか１項記載のゲートウェイノード。
35. 第１のパケット交換データネットワークは一般的なパケット無線サービス（ＧＰＲＳ）標準にしたがっており、複数のチャンネルは第１のパケット交換データネットワーク中の複数のパケットデータプロトコルコンテキストに対応している請求項２４乃至３４のいずれか１項記載のゲートウェイノード。
36. 第１のパケット交換データネットワークのゲートウェイノードが、トンネルされたデータパケットを第１のパケット交換データネットワークでサービスを与えられる移動体ノードの目的地パケットデータプロトコルアドレスへ転送するための第１のチャンネルを選択することを可能にする方法において、ゲートウェイノードは移動体ノードの目的地パケットデータプロトコルアドレスへデータパケットを転送するための複数のチャンネルから第１のチャンネルを選択するように構成され、トンネルされたデータパケットは対応ノードから送信され、第１のパケット交換データネットワークに対して外部の第２のパケット交換データネットワークのトンネル動作ノードによりトンネルされ、その方法は、
    ａ）トンネル動作ノードがトンネルされたデータパケットを対応ノードのパケットデータプロトコルアドレスに関連付け、
    ｂ）ゲートウェイノードが、ゲートウェイノードにより受信されたトンネルされたデータパケットに関連されるパケットデータプロトコルアドレスを第１のチャンネルに関連される第１のデータパケットフィルタと一致させることによって第１のチャンネルを選択するステップを含んでいる方法。
37. トンネルされたデータパケットはインターネットプロトコルバージョン６（ＩＰｖ６）データパケットであり、対応ノードのパケットデータプロトコルアドレスはトンネルされたデータパケットのホップバイホップ拡張ヘッダ中に含まれていることによりトンネルされたデータパケットに関連付けられる請求項３６記載の方法。
38. 対応ノードのパケットデータプロトコルアドレスはトンネルされたデータパケットの目的地選択肢拡張ヘッダ中に含まれることによりトンネルされたデータパケットに関連付けられる請求項３６記載の方法。
39. トンネル動作ノードはトンネルされたデータパケットをゲートウェイノードのパケットデータプロトコルアドレスにアドレスし、移動体ノードの目的地パケットデータプロトコルアドレスはトンネルされたデータパケットに関連される請求項３８記載の方法。
40. トンネルされたデータパケットはインターネットプロトコルバージョン６（ＩＰｖ６）データパケットであり、移動体ノードの目的地パケットデータプロトコルアドレスはトンネルされたデータパケットの経路設定ヘッダタイプ０選択肢ヘッダに含まれることにより、ゲートウェイノードに送信されるトンネルされたデータパケットに関連付けられる請求項３９記載の方法。
41. ネットワークまたはサブネットワーク間の移動体ノードの移動性は移動体インターネットプロトコル（ＭＩＰ）標準を使用してサポートされ、トンネル動作ノードは移動体ノードのホームエージェント（ＨＡ）である請求項３６乃至４０のいずれか１項記載の方法。
42. 第１のパケット交換データネットワークは一般的なパケット無線サービス（ＧＰＲＳ）標準にしたがっており、複数のチャンネルは第１のパケット交換データネットワークの複数のパケットデータプロトコルコンテキストに対応している請求項３６乃至４１のいずれか１項記載の方法。
43. トンネルされたデータパケットを第１のパケット交換データネットワークでサービスを与えられる移動体ノードの目的地パケットデータプロトコルアドレスへ転送するための第１のチャンネルを選択するように構成され、第１のチャンネルは移動体ノードの目的地パケットデータプロトコルアドレスへデータパケットを転送するための複数のチャンネルから選択され、トンネルされたデータパケットは対応ノードから送信され、第１のパケット交換データネットワークに対して外部の第２のパケット交換データネットワークのトンネル動作ノードによりトンネルされるように構成されている第１のパケット交換データネットワークのゲートウェイノードにおいて、
    ゲートウェイノードは、ゲートウェイノードにより受信されたトンネルされたデータパケットに関連される対応ノードのパケットデータプロトコルアドレスが第１のチャンネルに関連される第１のデータパケットフィルタに一致することによって第１のチャンネルを選択するように構成されているゲートウェイノード。
44. トンネルされたデータパケットはインターネットプロトコルバージョン６（ＩＰｖ６）データパケットであり、対応ノードのパケットデータプロトコルアドレスはトンネルされたデータパケットのホップバイホップ拡張ヘッダ中に含まれることによりトンネルされたデータパケットに関連付けられている請求項４３記載のゲートウェイノード。
45. 対応ノードのパケットデータプロトコルアドレスはトンネルされたデータパケットの目的地オプション拡張ヘッダ中に含まれることによりトンネルされたデータパケットに関連付けられている請求項４３記載のゲートウェイノード。
46. トンネルされたデータパケットはゲートウェイノードのパケットデータプロトコルアドレスにアドレスされ、移動体ノードの目的地パケットデータプロトコルアドレスはトンネルされたデータパケットに関連されている請求項４５記載のゲートウェイノード。
47. トンネルされたデータパケットはインターネットプロトコルバージョン６（ＩＰｖ６）データパケットであり、移動体ノードの目的地パケットデータプロトコルアドレスはトンネルされたデータパケットの経路設定ヘッダタイプ０選択肢ヘッダに含まれることにより、ゲートウェイノードに送信されるトンネルされたデータパケットに関連付けられている請求項４６記載のゲートウェイノード。
48. ネットワークまたはサブネットワーク間の移動体ノードの移動性は移動体インターネットプロトコル（ＭＩＰ）標準を使用してサポートされ、トンネル動作ノードは移動体ノードのホームエージェント（ＨＡ）である請求項４３乃至４７のいずれか１項記載のゲートウェイノード。
49. 第１のパケット交換データネットワークは一般的なパケット無線サービス（ＧＰＲＳ）標準にしたがっており、複数のチャンネルは第１のパケット交換データネットワーク中の複数のパケットデータプロトコルコンテキストに対応している請求項４３乃至４８のいずれか１項記載のゲートウェイノード。
50. 第１のパケット交換データネットワークに対して外部の第２のパケット交換データネットワークのトンネル動作ノードにおいて、トンネル動作ノードは対応ノードから第１のパケット交換データネットワークでサービスを提供される移動体ノードへ送信されるデータパケットをトンネルするように構成され、第１のパケット交換データネットワークはトンネルされたデータパケットを移動体ノードの目的地パケットデータプロトコルアドレスへ転送するための第１のチャンネルを選択するように構成されたゲートウェイノードを具備し、ゲートウェイノードは移動体ノードの目的地パケットデータプロトコルアドレスへデータパケットを転送するための複数のチャンネルから第１のチャンネルを選択するように構成され、
    トンネル動作ノードは、トンネルされたデータパケットを対応ノードのパケットデータプロトコルアドレスに関連付けるように構成され、ゲートウェイノードはゲートウェイノードにより受信されるトンネルされたデータパケットに関連するパケットデータプロトコルアドレスが第１のチャンネルに関連される第１のデータパケットフィルタと一致されることにより第１のチャンネルを選択するトンネル動作ノード。
51. トンネルされたデータパケットはインターネットプロトコルバージョン６（ＩＰｖ６）データパケットであり、対応ノードのパケットデータプロトコルアドレスはトンネルされたデータパケットのホップバイホップ拡張ヘッダ中に含まれることによりトンネルされたデータパケットに関連付けられている請求項５０記載のトンネル動作ノード。
52. 対応ノードのパケットデータプロトコルアドレスはトンネルされたデータパケットの目的地選択肢ヘッダに含まれることによりトンネルされたデータパケットに関連付けられる請求項５１記載のトンネル動作ノード。
53. トンネル動作ノードは移動体の目的地パケットデータプロトコルアドレスをトンネルされたデータパケットに関連付け、トンネルされたデータパケットをゲートウェイノードのパケットデータプロトコルアドレスにアドレスする請求項５２記載のトンネル動作ノード。
54. トンネルされたデータパケットはインターネットプロトコルバージョン６（ＩＰｖ６）データパケットであり、移動体ノードの目的地パケットデータプロトコルアドレスはトンネルされたデータパケットの経路設定ヘッダタイプ０選択肢ヘッダに含まれることにより、ゲートウェイノードに送信されたトンネルされたデータパケットに関連されている請求項５３記載のトンネル動作ノード。
55. ネットワークまたはサブネットワーク間の移動体ノードの移動性は移動体インターネットプロトコル（ＭＩＰ）標準方式を使用してサポートされ、トンネル動作ノードは移動体ノードのホームエージェント（ＨＡ）である請求項５０乃至５４のいずれか１項記載のトンネル動作ノード。
56. 第１のパケット交換データネットワークは一般的なパケット無線サービス（ＧＰＲＳ）標準方式にしたがっており、複数のチャンネルは第１のパケット交換データネットワークの複数のパケットデータプロトコルコンテキストに対応している請求項５０乃至５５のいずれか１項記載のトンネル動作ノード。

Images