JP4444833B2 - 電気通信 - 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）である。（ｎ−１）対ｎ個のマッピングが存在する場合もまた、選択は直接的であるが、一致がＴＦＴに対して発見されないならば、消去の簡単なプロセスを含むことができる。

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

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

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

しかしながら、前述したように、ソースアドレス属性はある状態下で、ダウンリンクの入来パケットをＭＳにマップするのに十分ではない可能性がある。ＭＳがＭＩＰｖ４またはＭＩＰｖ６エネーブルされたＭＮ（ＧＰＲＳ ＭＳをＣＮと呼ぶ）との通信セッション中である場合に、本発明によれば、手順はＭＮ、ＧＧＳＮ、幾つかの実施形態ではＣＮにより後続され、変更される。

［第１の実施形態］
ＭＮがＩＰｖ６可能である本発明の第１の実施形態によれば、ＭＮはホームから離れているときにはいつでも、それがＣＮへ送信する全てのデータパケットに対してＩＰｖ６パケットのホップバイホップオプション拡張ヘッダ中にＨＡｄｄｒを含むように変更される。これは対応結合更新とユーザデータパケットにも当てはまる。図４のＡはデータパケットの構造を示している。基本的なＩＰｖ６ヘッダ100が最初に来る。標準規格ＩＰｖ６（ＲＦＣ２４６０）にしたがって、基本的ＩＰｖ６ヘッダ100のＩＰｖ６の次のヘッダフィールドにゼロを置くことによって、ＩＰｖ６のホップバイホップオプション拡張ヘッダ102の存在が示されている。ホップバイホップオプション拡張ヘッダ102は基本的ＩＰｖ６ヘッダ100の直ぐ後に後続する。最後に、ペイロード104、即ちＴＣＰまたはＵＤＰのような上部層ヘッダがホップバイホップオプション拡張ヘッダ102に後続する。図４のＢはホップバイホップオプション拡張ヘッダ102の構造を示している。ホップバイホップオプション拡張ヘッダ102の次のヘッダおよびＨｄｒ Ｅｘｔ Ｌｅｎフィールドは簡明にするために省略されている。ＭＮのＨＡｄｄｒはホップバイホップオプション拡張ヘッダ102のタイプ−長さ−値（ＴＬＶ）エンコードオプションに含まれる。したがって、適切なオプションタイプ番号（８ビット）106はオプションのタイプ（即ちＧＰＲＳ ＣＮへ送信されるパケットに対するＭＮのＨＡｄｄｒの仕様）を識別するために使用され、それに（ＨＡｄｄｒの長さに応じた）オプションデータ長108が後続し、それにオプションデータ自体、即ちＨＡｄｄｒ110が後続する。

この実施形態では、ＧＧＳＮはＩＰｖ６エネーブルされ、このようなヘッダを有する任意の受信されたＩＰｖ６パケットのホップバイホップ拡張ヘッダを検査する。ＧＧＳＮは中間ノードであり、ＩＰｖ６仕様（ＲＦＣ２４６０）によれば、ＧＧＳＮはホップバイホップ拡張ヘッダを検査しなければならないことに注意する必要がある。反対に、ＩＰｖ６仕様（ＲＦＣ２４６０）によれば、ＧＧＳＮはそれが中間のノードであるので、任意の他のＩＰｖ６拡張ヘッダを検査してはならないことに注意しなければならない。さらに、ＭＩＰｖ６手順、したがってＭＮは、対応結合更新の送信がＧＧＳＮに対して可視ではないために識別される問題の解決において助けにならないとき、ＩＰｖ６ホームアドレス目的地オプション拡張ヘッダのそのＨＡｄｄｒを送信することができる。

さらに、ＧＧＳＮは受信されたＩＰｖ６データパケットのホップバイホップ拡張ヘッダで識別されるＭＮのＨＡｄｄｒをＧＰＲＳネットワークのＣＮのＩＰアドレスに関連するＰＤＰコンテキストに対して記憶されているＴＦＴパケットフィルタにマップしようと試み、一致が発見されるならば、データパケットをそれに応じて転送するように変更される。ＧＧＳＮが後続するプロセスは図５に示されている。プロセスはステップ120で開始する。ステップ122で、ＧＧＳＮはＧＰＲＳネットワーク中のＣＮの特定のＩＰアドレスにダウンリンクするためのデータパケットを受信する。ステップ124で、ＧＧＳＮは受信されたパケットのホップバイホップオプション拡張ヘッダを試験する。ステップ126で、ＧＧＳＮはホップバイホップオプション拡張ヘッダ中で特定されたＭＮのＨＡｄｄｒを、ＣＮのＩＰアドレスに関連するＰＤＰコンテキストのＴＦＴのソースアドレスフィールドに対してチェックする。ステップ128で、一致が存在することが決定されたならば、プロセスはステップ130に進み、ここでパケットは一致するＴＦＴを含んだＰＤＰコンテキストを使用してＣＮへ転送される。プロセスはその後、ステップ132へ進み終了する。しかしながら、ステップ128で、一致が存在しないことが決定されたならば、プロセスはステップ132に移ってそこで終了する。

ＧＧＳＮはまた標準的なＧＧＳＮ機能にしたがって、受信されたデータパケットのソースアドレスを、ＣＮに関連するＰＤＰコンテキストのＴＦＴのソースアドレスフィールドと一致させようと試みる。したがって、例えば標準的および変更された手順の組合せを使用して、ソースアドレス属性ＯＲに一致するソースアドレスを有するか、ソースアドレス属性に一致するホップバイホップオプションヘッダにおいて特定されるＩＰアドレス、即ちＭＮのＨＡｄｄｒを有するかのいずれかのデータパケットは、ＴＦＴパケットフィルタの少なくともこれらの属性に一致し、適切なＰＤＰコンテキストに対応するＧＴＰトンネルに導かれる。

データパケットがＣＮに到達するとき、これはそのソースアドレスとしてＭＮのＣｏＡを有するか否かにかかわらず、ＣＮにより認識され、その理由はこれがＨＡｄｄｒを特定するＩＰｖ６ホップバイホップオプション拡張ヘッダを有するためである。また、ＣＮに可視であるＨＡｄｄｒを特定するホームアドレス目的地オプション拡張ヘッダも有することができる。

［第２の実施形態］
前述の第１の実施形態の変形である第２の実施形態によれば、ＭＮは対応結合更新のためＣＮに送信するシグナリングＩＰｖ６パケットのホップバイホップオプション拡張ヘッダ中にそのＨＡｄｄｒだけを含む。したがって、前述したように、対応結合更新はＣＮに到達することができる。対応結合更新を受信するとき、ＣＮはＭＮのＣｏＡを知り、その後、ホップバイホップオプション拡張ヘッダを使用する必要なく、ＧＧＳＮがそのＣｏＡのＭＮから送信されたその次のデータパケットを経路設定するようにＰＤＰコンテキストを生成または変更することができる。これは以下のように行われる。

ＣＮは３Ｇ ＴＳ ２３．０６の９．２．３条項に記載され、ここで参考文献とされているＭＳ開始ＰＤＰコンテキスト変更手順を使用して、ＰＤＰコンテキストに関連されるＴＦＴに、ＭＮのＣｏＡ、即ちＩＰｖ４またはＩＰｖ６アドレスを含むように（ＭＮとの通信セッションで使用される）付勢されたＰＤＰコンテキストを変更できる。図６は、ＰＤＰコンテキスト変更手順を示している。ステップ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に進み、終了する。データパケットのソースアドレスをＴＦＴに一致させることに失敗したことはデータパケットのドロップを生じるか、代わりに、存在するならば、関連されるＴＦＴのないＰＤＰコンテキストを使用してＣＮへ転送されることに注意すべきである。

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

したがって、ＭＮとの通信セッションで付勢されるＰＤＰコンテキストは、１）（増加された属性リストを使用して）ＭＮのＨＡｄｄｒおよびＣｏＡの両者を有する１つのパケットフィルタ、またはその代わりに２）（増加されたまたは標準的な属性リストを使用して）一方がＭＮのＨＡｄｄｒを有し、他方がＭＮのＣｏＡを有する２つのパケットフィルタと関連されたＴＦＴを有するように変更されてもよい。

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

このようにして、開始対応結合更新後、ホップバイホップオプション拡張ヘッダを継続使用する必要なく、このような継続使用を必要とする処理オーバーヘッドなしに、ＭＮにより送信されるパケットはホームから離れていながら、ＣＮの適切なＰＤＰコンテキストへ濾波されることができる。

第１および第２の実施形態の変形では、ＭＮはこれ（ＭＮ）がホームから、離れているとき、ユーザデータパケットのＩＰｖ６ホップバイホップオプション拡張ヘッダまたはそれがＣＮへ送信する対応結合更新パケット中にそのＨＡｄｄｒを選択的に含むように変更される。この含ませる動作はＣＮがＧＰＲＳネットワークでサービスを提供されていることをＭＮが検出した時にのみ行われる。したがって、ａ）トンネルされたデータパケット中にホップバイホップオプション拡張ヘッダを含んでいるＭＮと、ｂ）ホップバイホップオプション拡張ヘッダを検査するＧＧＳＮの方向へのルートにおける中間ノードとの処理オーバーヘッドは必要ない場合は除去される。

［第３の実施形態］
本発明の第３の実施形態によれば、ＭＮは、好ましくは（ここで参考文献とされているＭＩＰｖ６ ＩＥＴＦ草案の６．３条項に記載されている）ＭＩＰホームアドレス目的地オプションを使用して、対応結合更新をＣＮへ送信するとき常にそのＨＡｄｄｒを含まなければならない。また、関連するＴＦＴをもたないＰＤＰコンテキストは（ここで参考文献とされている３Ｇ ＴＳ ２３．０６０の９．２．２条項に記載されている）ＰＤＰコンテキスト付勢手順を使用してＧＰＲＳネットワーク中に常に設定される。対応結合更新データパケットをＭＮから受信するとき、ＧＧＳＮはそのパケットを通常の方法で関連するＴＦＴを有するＰＤＰコンテキストへ一致しようとするが、ソースアドレスがＭＮの新しいＣｏＡまたはＣｏＣｏＡであるためにこれが失敗した時、パケットは関連するＴＦＴをもたないＰＤＰコンテキストを使用してＣＮへ経路設定される。ＣＮが対応結合更新を受信するとき。それは認識するＭＮのＨＡｄｄｒを含んでいるホームアドレス目的地オプションヘッダまたは他のヘッダを検査する。ＭＮはその後、パケットをＭＮとの既存の通信セッションに関連付けることができる。ＣＮはその後、第２の実施形態に関して前述したようにＭＮのＣｏＡを含むように、既存のＰＤＰコンテキストを変更するか、新しいＰＤＰコンテキストを生成することができる。

第３の実施形態の変形では、ＭＮはそれ（ＭＮ）がホームから離れているときにＣＮに送信する対応結合更新パケットのホームアドレス目的地オプションヘッダまたはその他のヘッダ中にそのＨＡｄｄｒを選択的に含むように変更される。含ませる動作はＣＮがＧＰＲＳネットワークでサービスを提供されていることをＭＮが検出したときにのみ行われる。

［第４の実施形態］
ＭＮがＩＰｖ６である第４の実施形態の変形によれば、ＭＮはホームから離れているときにはいつでも、好ましくはそれがＣＮへ送信する全てのＩＰｖ６データパケットでＩＰｖ６目的地オプション拡張ヘッダ中にそのＨＡｄｄｒを含むように変更される。これは対応結合更新およびユーザデータパケットにも当てはまる。しかしながら、中間ノードは通常この情報を読取ることができないので、ＧＰＲＳネットワーク中のＧＧＳＮのアドレスはＣＮ自体のアドレスではなくＩＰｖ６データパケットの目的地アドレスとして提供される。それをまだ知らないならば、ＭＮにＧＧＳＮのアドレスが与えられる態様を以下手短に説明する。さらにＣＮのアドレスはデータパケットのＩＰｖ６経路設定ヘッダタイプ０拡張ヘッダ中に含まれる。この経路設定ヘッダはパケットの目的地アドレス（この場合はＧＧＳＮ）へ転送され、その後経路設定ヘッダ（この場合はＣＮのＩＰアドレス）に含まれるさらに別の経路設定アドレスのリストに対応する各ノードへ次に転送されることによって、複数のアドレス開始においてＩＰｖ６パケットが複数のノードを通って経路設定されることを可能にする。

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

図８のＢは、ＩＰｖ６目的地オプション拡張ヘッダ142自体の構造を示している。この拡張ヘッダのフォーマットはＲＥＣ２４６０に記載されている。目的地オプション拡張ヘッダ142の次のヘッダおよびＨｄｒ Ｅｘｔ Ｌｅｎフィールドは明瞭にするために省略されている。ＭＮのＨＡｄｄｒは目的地オプション拡張ヘッダ142中のタイプ−長さ−値（ＴＬＶ）エンコードオプションに含まれている。したがって、オプションタイプ番号148はオプションのタイプを識別するために使用され、それに（ＨＡｄｄｒのアドレスの長さに依存する）オプションデータ長150が後続し、それにオプションデータ自体、即ちＨＡｄｄｒ152が後続する。

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

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

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

ＧＧＳＮはまた、標準的なＧＧＳＮ機能にしたがって、受信されたデータパケットのソースアドレスをＭＮに関連するＰＤＰコンテキストのＴＦＴのソースアドレスフィールドと一致させようとする。したがって、ソースアドレス属性ＯＲに一致するソースアドレスを有するか、ソースＩＰアドレス属性に一致する目的地オプションヘッダで特定されるＩＰアドレス、即ちＭＮのＨＡｄｄｒアドレスを有するデータパケットは、ＴＦＴパケットフィルタの少なくともこれらの属性に一致し、適切なＰＤＰコンテキストに対応するＧＴＰトンネルに経路設定される。

しかしながら、前述したように、この手順はＭＮがＧＰＲＳネットワーク中のＧＧＳＮのアドレスを知っているかそれを与えられることを必要とする。これは以下のように行われることができる。好ましくはＭＮとの通信セッションを開始する直ぐ後、または恐らく後に、ＣＮはメッセージを送信するか、好ましくはＧＧＳＮ自体にＧＧＳＮのＩＰアドレスを含むメッセージをＭＮへ送信するように命令する。ＣＮはここで参考文献とされている３Ｇ ＴＳ ２３．０６０の条項９．２．２に記載されているＰＤＰ構造オプションを使用して、そのＧＧＳＮにこのようなパケットを送信するように命令することができる。ＰＤＰ構造オプションはＧＧＳＮがＭＳに転送する随意選択的なＰＤＰパラメータを含んでいる。これらの随意選択的なＰＤＰパラメータの送信は、ＭＮにより設定された通信セッションで付勢ＰＤＰコンテキストリクエストメッセージ中のＣＮによりリクエストされてもよい。

［第５の実施形態］
前述の第４の実施形態の変形である第５の実施形態によれば、ＭＮは対応結合更新パケットの第４の実施形態に記載されている変更された手順にのみしたがう。したがって、ＭＮは好ましくはＩＰ目的地オプション拡張ヘッダ中にそのＨＡｄｄｒを含み、データパケットをＧＧＳＮへアドレスし、対応結合更新パケットに対してのみ経路設定ヘッダタイプ０オプション中にＣＮアドレスを含んでいる。したがって前述したように、対応結合更新はＣＮに到達することができる。対応結合更新を受信するとき、ＣＮはＭＮのＣｏＡを知り、その後、第４の実施形態で説明した手順の使用を必要とせずに、ＧＧＳＮがそのＣｏＡにおいてＭＮから送信されたその次のデータパケットを経路設定するようにＰＤＰコンテキストを生成または変更できる。これは第２の実施形態に関して前述したように行われる。

第４および第５の実施形態の変形では、ＣＮがＧＰＲＳネットワーク中でサービスを与えられていることをＭＮが検出するときのみこれらの実施形態で説明された手順を選択的に使用するように変更される。

前述の実施形態はＭＮのＨＡｄｄｒ以外のデータパケットと関連するデータを使用して実行されることができることが明白である。ＣＮまたはＧＧＳＮへのＭＮを特有に識別できるか、ＭＮがＣｏＡまたはＣｏＣｏＡを与えられる前にＣＮまたはＧＧＳＮに知られている（例えばＭＮによる通信セッションから知られている）任意のデータはこれを行うであろう。さらに、別のデータがホップバイホップオプション拡張ヘッダまたは目的地オプション拡張ヘッダに含まれることができ、また変更または新たに生成されたＴＦＴに含まれることができて、それによってさらにＭＮ乃至ＣＮまたはＧＧＳＮを特定し、さらにＧＧＳＮまたはＣＮにより受信されたデータパケットの濾波を行うことが明白であろう。

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

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

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

Claims (48)

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. 第１のパケット交換データネットワークは汎用パケット無線サービス（ＧＰＲＳ）標準方式にしたがっており、複数のチャンネルは第１のパケット交換データネットワーク中の複数のパケットデータプロトコルコンテキストに対応している請求項４２乃至４７のいずれか１項記載の対応ノード。

Images