JP4620050B2 - パケットデータ通信 - Google Patents

Description

本発明は、インターネットプロトコルに基づいて通信されるインターネットパケット及びインターネットパケットデータ通信システムに関する。

幾つかの実施の形態では、インターネットパケットは、モバイルインターネットプロトコル（ＩＰ）機能を提供するＩｐｖ６インターネットプロトコルに適用される。

特に、本発明の実施の形態は、パケット無線ネットワークを含むパケットデータ通信システムに適用される。一実施の形態においては、パケットデータ通信ネットワークは、汎用パケット無線サービス（General Packet Radio Service：以下、ＧＰＲＳという。）規格に基づいて動作する。

ＧＰＲＳは、移動ノードに／から、第２世代（例えば、ＧＳＭ）又は第３世代（例えば、ＵＭＴＳ）移動パケット無線ネットワークを用いて、効率的にデータパケットを通信するために開発されている。ＧＰＲＳは、例えば、インターネットデータパケット等のデータパケットを通信する際、ネットワーク及び無線リソースを最適化するように試みるパケット指向サービスをサポートする。

一般的に、ＧＰＲＳネットワークは、他のパケットデータ通信ネットワークに接続され、このパケットデータ通信ネットワークは、更に他のパケットデータ通信ネットワークに接続されていてもよい。ＧＰＲＳネットワークは、外部パケットデータ通信ネットワークと、ＧＰＲＳネットワークに接続されたノードとの間のインタフェースを提供するゲートウェイサポートノード（gateway support node：以下、ＧＧＳＮという。）を備え、ＧＧＳＮは、ノードとインターネットパケットを通信するための複数のベアラを提供する。

インターネットエンジニアリングタスクフォース（Internet Engineering Task Force：ＩＥＴＦ）によって開発されたインターネットプロトコルは、電気通信ネットワークを介してパケットデータを通信する一般的なプロトコルとなっている。インターネットプロトコルのバージョン４（Ｉｐｖ４）は、標準化され、多くの固定ネットワークに普及したが、改良された機能を提供するために、インターネットプロトコルのバージョン６が開発されている。これらの改良の１つとして、ＩＰセッション中に、ホームネットワーク（home network）から移動先ネットワーク（foreign network）に移動した移動ノードに／からインターネットパケットを通信することが可能になった［非特許文献１］。一般的に、後述する経路最適化として知られている処理の後に、それぞれ移動ノード（Mobile Node：以下、ＭＮという。）から及び移動ノードに設定されているＩＰデータパケットのヘッダ内の送信元アドレス及び宛先アドレスは、ＭＮのローミングの結果、移動先ネットワークに変更される。

移動ノードは、ＧＰＲＳネットワークに接続されている通信相手ノードとインターネットパケットを通信することができる。この結果、ＧＰＲＳネットワークのＧＧＳＮは、適切なベアラによって、通信相手ノードにインターネットパケットをルーティングするように構成する必要がある。この通信相手ノード自体も移動ノードであってもよい。移動ノードが、セッションの最中に（mid-session）、移動先ネットワークに移動した場合、ＧＧＳＮは、インターネットパケットを、適切なベアラによって通信相手ノード（移動ユーザ機器）にルーティングする必要がある。移動ノードがそのホームネットワークに接続されているときに、セッション開始が確立された場合、ＧＧＳＮによって適切なベアラが設定される。したがって、ベアラのためのパラメータは、移動ノードのホームアドレスを送信元アドレスとして参照して確立されてしまう。しかしながら、上述したように、インターネットパケットのヘッダの送信元アドレスは、セッション中に、ホームネットワークに接続されていたときの移動ノードのホームアドレスから、移動ノードが移動先ネットワークに移動した後の気付アドレス（care-of-address）に変化される。

係属中の英国特許出願第０２２６２８９．７号、第０２２２１８７．７号、第０２３０３３６．０号、第０２２２１６１．２号及び第０２３０３３５．２号には、ホップバイホップフィールド（hop-by-hop field）として知られているＩＰｖ６における拡張ヘッダフィールドに移動ノードのホームアドレスを格納する手法が開示されている。したがって、ＭＮのホームアドレスが、適切なベアラが設定された送信元アドレスを提供するので、ＧＧＳＮは、ＧＰＲＳネットワークに接続された通信相手ノード（correspondent node：以下、ＣＮという。）にＩＰデータパケットをルーティングすることができる適切なベアラを識別することができる。ここで、Ｉｐｖ６規格では、ホップバイホップフィールドオプションが選択された場合、ＭＮからＣＮにインターネットデータパケットをルーティングする通信パスに沿った全てのルータは、ホップバイホップフィールド内のＭＮのホームアドレスを読み出す必要がある。この結果、ルータは、移動ノードのホームアドレスを読み出すが、このアドレスは、ルータに関連していこともあり、したがって、この要求により、ルータによって構成されたネットワークの性能が低下する。

英国特許出願番号第０２２６２８９．７号 英国特許出願番号第０２２２１８７．７号 英国特許出願番号第０２３０３３６．０号 英国特許出願番号第０２２２１６１．２号 英国特許出願番号第０２３０３３５．２号 D. Johnson, C. Parkins, J. Arkko,"Mobility in Ipv6", Internet Draft, Internet Engineering Task Force, 20 January 2003. R. Steele, C-C Lee and P. Gould,"GSM, cdmaOne and 3G Systems," published by Wiley International ISBN 0 471 491853 S. Deering and R. Hinden, "Internet Protocol (Version 6 (IPv6)) Specification, Request for Comments 2460, Ipv6 standards document, www. ietf. org/r ISc/rfc2460. txt C. Partridge and A. Jackson, Ipv6 Router Alert Option, Request for Comments 2711, Ipv6 standards document, www.ietf.org/rfc/rfc2711.txt

本発明に係るインターネットパケットは、ヘッダフィールドを有し、ヘッダフィールドは、インターネットパケットの送信元アドレスを識別するフィールドと、インターネットパケットの宛先アドレスを識別するフィールドと、拡張ヘッダが当該ヘッダフィールドに続くか否か及び拡張ヘッダの種類を識別する次ヘッダフィールドとを含む。拡張ヘッダは、ホップバイホップ拡張ヘッダを示し、ホップバイホップ拡張ヘッダは、当該ホップバイホップ拡張ヘッダが、読み出するルータに対してオプションであることを示すルータアラートオプションヘッダと、ホップバイホップ拡張ヘッダの残りの部分がゲートウェイサポートノードに提供されていることを示す値フィールドとを含む。

同じ出願人による係属中の英国特許出願第０２２６２８９．７号に説明されているように、ホップバイホップ拡張ヘッダのフィールドで移動ノードのホームアドレスを提供することによって、モバイルＩＰ機能をサポートする際、パケット無線ネットワークのゲートウェイサポートノードと、データ通信ネットワークとの相互動作が実現される。しかしながら、移動ノードと通信相手ノードとの間の通信パス上の全てのルータがホップバイホップ拡張ヘッダの全てのデータを読み出す必要があると、ルータによって構成されたネットワークの性能が低下する虞がある。ホップバイホップ拡張ヘッダ内でルータアラートオプションフィールドを提供することによって、比較的短い指示により、ホップバイホップ拡張ヘッダのフィールドがゲートウェイサポートノードに対して情報を提供していることを示すことができ、したがって、ルータによって読み出す必要がないことを示すことができる。これにより、ルータがホップバイホップ拡張ヘッダのフィールドを読み出すために生じる潜在的な性能の劣化を抑制することができる。

幾つかの実施の形態では、インターネットパケットは、Ｉｐｖ６仕様に基づいて生成され、ルータ及びパケット無線ネットワークは、Ｉｐｖ６仕様書をサポートする。Ｉｐｖ６ルータアラートオプション規格に基づき、ルータアラートオプションフィールドの最初の３ビットをゼロに設定し、このルータアラートオプションの種類を認識しない全てのルータは、ホップバイホップ拡張ヘッドのフィールド内の情報をスキップする。幾つかの具体例（以下で、説明する）では、ホップバイホップ拡張ヘッダの残りの部分に、少なくとも１２８ビットのアドレスを含むことができる。www.ietf.org/rfc/rfc2460txtに定義されているＩＰ−Ｉｐｖ６仕様書［非特許文献３］によれば、パケットの通信パスに沿った全てのノードにおいて、ホップバイホップ拡張ヘッダのフィールドを読み出して、処理する必要がある。ノード又はルータが読み出す必要がある情報を、メッセージの残りの部分がパケット無線ネットワークのゲートウェイサポートノードのみに関連していることを示す比較的短いフィールド（３ビット）にすることにより、ホップバイホップ拡張ヘッダのフィールドの全体を読み出すことに比べて、性能に影響する処理負担を比較的小さくすることができる。

一具体例においては、ゲートウェイサポートノードは、ＩＰセッションが設定された際のインターネットパケットの送信元アドレスに基づいて、移動ノードから、パケット無線ネットワークを介して、このネットワークに接続された通信相手ノードＣＮにインターネットパケットを通信するためのパケットデータベアラを確立する。セッション中に、移動ノードが移動先ネットワークに移動した結果、ベーシックＩｐｖ６ヘッダ内のインターネットパケットの送信元アドレスが変化した場合、ゲートウェイサポートノードは、送信元アドレスを認識しなくなり、インターネットパケットを落とす。パケット無線ネットワークに亘るベアラを確立する際に用いられた元の送信元アドレスは、ホームアドレスと呼ばれる。ホップバイホップ拡張ヘッダにホームアドレスを格納することによって、ゲートウェイサポートノードは、ベーシックＩｐｖ６ヘッダのインターネットパケットの送信元アドレスが、ゲートウェイサポートノードにとって未知の気付アドレスに変化しても、適切なベアラを識別することができる。

本発明の様々な更なる側面及び特徴は、添付の特許請求の範囲に定義されている。これらの側面には、ゲートウェイサポートノード及びインターネットパケットの通信方法が含まれる。

移動パケット無線ネットワークアーキテクチャ
パケットデータ通信をサポートするように構成された移動パケット無線ネットワークの例示的アーキテクチャを図１に示す。このアーキテクチャの詳細は、添付資料１に開示されている。本発明の実施の形態及びこの実施の形態によって提供される利点を明瞭にするために、以下、簡単な説明を行う。図１に示す移動パケット無線ネットワークは、汎用パケット無線システム（General Packet Radio System：ＧＰＲＳ）／ユニバーサル移動通信システム（Universal Mobile Telecommunications System：ＵＭＴＳ）規格に準拠し、インターネットデータパケットを、汎用陸上無線アクセスネットワーク部（Universal Terrestrial Radio Access Network part：ＵＴＲＡＮ）と呼ばれる陸上無線ベアラによって、当該ネットワークに接続されたノードに通信する移動パケット無線ネットワークを提供する。移動パケット無線ネットワークは、外部パケットデータ通信ネットワーク（外部ＰＤＮ）２１２と、ＧＰＲＳ／ＵＭＴＳネットワークに接続されたノードとの間のインタフェースを提供するゲートウェイサポートノード（GPRS Gateway Support Node：ＧＧＳＮ）１００を備える。これらのノードは、ＵＴＲＡＮの無線インタフェースを介して通信を行うので、通常、移動ノードであってもよい。なお、以下の説明では、移動パケット無線ネットワークに接続される移動ユーザ機器（ＵＥ）１１６、１１８を通信相手ノード（correspondent node）ＣＮと呼ぶ。後述するように、ＧＰＲＳ／ＵＭＴＳネットワークは、ＧＧＳＮ１００から通信相手ノードＣＮに、及び通信相手ノードＣＮからＧＧＳＮ１００にインターネットパケットを通信するための複数のパケットデータベアラを有する。通常、通信相手ノードＣＮからＧＧＳＮ１００によって受信されたパケットは、移動パケット無線ネットワークから外部ＰＤＮ２１２に送出することができる。これらのパケットは、外部ＰＤＮ２１２又は他のネットワークに接続された他のノードに宛てられてもよく、パケットは、外部ＰＤＮ２１２を介して、これらのノードに到着する。

モバイルＩｐｖ６経路最適化
経路最適化は、インターネットプロトコル規格のバージョン６（Ｉｐｖ６）の一部として知られており、ホームネットワークから移動先ネットワークに移動するノードに対して、実行することができる。経路最適化は、ホームネットワークから移動先ネットワークに所属（affiliation）を変更したノードが、Ｉｐｖ４の場合と同様に、ホームネットワークを介したルーティングを行うことなく、ホームエージェントを必要とすることなく、インターネットパケットを、移動先ネットワークを介してノードに／から通信できるようにするための処理である。以下の説明では、そのホームネットワークから移動先ネットワークに移動することによって所属を変更するノードを移動ノード（mobile node）と呼ぶ。

インターネットプロトコルにおいて周知であるように、互いの間でインターネットパケットを通信するノードは、送信元アドレスだけではなく、宛先アドレスをインターネットパケットヘッダによって提供する。図２は、ＧＰＲＳ／ＵＭＴＳネットワーク２６０に接続された通信相手ノードＣＮと、移動ノードＭＮとの間の経路最適化処理を説明する図である。図２では、通信相手ノードＣＮがＧＰＲＳ／ＵＭＴＳネットワーク２６０に所属している間に、通信相手ノードＣＮは、移動ノードＭＮに／からインターネットパケットを通信する。移動ノードＭＮの位置２０２、２０４の２つの位置で示すように、最初に、ホームネットワーク２１０を介して通信相手ノードＣＮとインターネットパケットを通信していた移動ノードＭＮは、外部ＰＤＮ２１２に移動する。すなわち、移動ノードＭＮは、最初は、ホームエージェントＨＡを介してインターネットパケットを通信していた。移動ノードＭＮが位置２０２のホームネットワーク２１０から位置２０４の外部ＰＤＮ２１２に移動したとき、Ｉｐｖ４の周知の動作では、インターネットパケットは、ホームエージェントＨＡを介してルーティングする必要がある。すなわち、移動ノードＭＮに送信されるパケットの宛先アドレスは、そのホームアドレスであり、移動ノードＭＮから送信されるパケットの送信元アドレスも、そのホームアドレスである。したがって、インターネットパケットは、ＧＰＲＳ／ＵＭＴＳネットワーク２６０を介して、通信相手ノードＣＮに／から、外部ＰＤＮ２１２及びホームネットワーク２１０を介して、ルーティングする必要がある。なお、移動ノードＭＮが移動先ネットワークに移動した後に、ホームエージェントＨＡを介してパケットをルーティングすることは、不必要にネットワークリソースを消費し、更に、インターネットパケットの通信における遅延を増加させることは、言うまでもない。

上述のように、経路最適化は、ホームエージェントＨＡを介することなく、通信相手ノードＣＮと移動ノードＭＮ間でインターネットパケットを通信し、これによって、インターネットパケットを通信するために必要なリソースを低減する処理である。また、これによって、多くの場合、パケット通信における遅延も減少する。

図２及び図３は、後述する本発明の実施の形態を理解する際に有用な経路最適化処理に関連した部分の概要を示している。図３は、経路最適化の前後におけるインターネットパケットヘッダの具体例を示している。図３に示すインターネットパケットヘッダ３００は、ホームネットワーク２１０に接続された位置２０２の移動ノードＭＮから、ＧＰＲＳ／ＵＭＴＳネットワーク２６０に接続された通信相手ノードＣＮに送信するインターネットパケット（ＩＰ）ヘッダの具体例を示している。インターネットパケットヘッダ３００は、宛先アドレスフィールド３０２内に通信相手ノードＣＮのアドレスを含み、送信元アドレスフィールド３０４内に移動ノードＭＮのホームアドレスを含む。また、インターネットパケットヘッダ３００は、後述するホップバイホップフィールド３０６として知られている更なるフィールドを含む。移動ノードＭＮから通信相手ノードＣＮに通信するためのインターネットパケットヘッダ３００は、ダウンリンクインターネットパケットと呼ばれる。

アップリンク、すなわち通信相手ノードＣＮから移動ノードＭＮに通信する場合、インターネットパケットヘッダ３１０は、宛先アドレスフィールド３１２内に移動ノードＭＮのホームアドレスを含み、送信元アドレスフィールド３１４内に通信相手ノードＣＮのアドレスを含む。

移動ノードＭＮの所属の変化に基づく経路最適化の後に、移動ノードＭＮは、その新たなアドレスを、通信相手ノードＣＮに知らせる必要がある。新たなアドレス、すなわち移動先ネットワークを介して移動ノードＭＮにアクセスするために用いられるアドレスは、気付アドレス（care-of-address）と呼ばれる。移動ノードＭＮの気付アドレスを通信相手ノードＣＮに知らせるために、移動ノードＭＮは、対応付け更新メッセージ（binding update）を通信相手ノードＣＮに送信する。

対応付け更新の後、ダウンリンク用のインターネットパケットヘッダ３５０は、今度は、送信元アドレスフィールド３５２に移動ノードＭＮの気付アドレスを含んでいる。これに対応して、移動ノードＭＮに送信されてくるインターネットパケットのインターネットパケットヘッダ３６０は、宛先アドレスフィールド３６２に移動ノードＭＮの気付アドレスを含んでいる。

通信相手ノードＣＮ自体がネットワーク内で又は移動先ネットワークに所属を変更した場合、これに対応して、通信相手ノードＣＮにより対応付け更新が実行される。図２に示すように、移動ノードＭＮのキャッシュアドレスメモリ２３０は、通信相手ノードＣＮのアドレスに関連して通信相手ノードＣＮの気付アドレスを含むように更新され、これにより、その後のインターネットパケットは、通信相手ノードＣＮのホームアドレスの代わりに、通信相手ノードＣＮの気付アドレスを用いる。

ＧＧＳＮの機能
以下、図４を用いて、図２に示すＧＰＲＳ／ＵＭＴＳネットワーク２６０の一部を構成する要素を備える本発明の例示的な実施の形態について説明する。図４には、ゲートウェイサポートノード（gateway support node：以下、ＧＧＳＮという。）４００と、サービスＧＰＲＳサポートノード（Serving GPRS Support Node：以下、ＳＧＳＮという。）４０２と、汎用陸上無線アクセスネットワーク部（Universal Terrestrial Radio Access Network part：以下、ＵＴＲＡＮという。）４０４とが示されている。ＧＧＳＮ４００、ＳＧＳＮ４０２及びＵＴＲＡＮ４０４は、図１に示すように、例えば、通信相手ノードＣＮを構成する移動ユーザ機器（ＵＥ）４０６に／からデータパケットを通信する移動パケット無線ネットワークの一部を構成している。ＵＴＲＡＮ４０４は、図１に示すように、ＲＮＣと、ノードＢとを含み、移動ＵＥ４０６を有するノードＢによって構成される無線アクセスインタフェースを介してパケットを通信する。

アップリンク方向においては、すなわち、通信相手ノードＣＮである移動ユーザ機器４０６からＧＧＳＮ４００の方向では、インターネットパケットがＧＰＲＳ／ＵＭＴＳネットワーク２６０から外部ＰＤＮ２１２に送出されるように、ＧＧＳＮ４００にインターネットパケットをルーティングして戻す、対応するトンネリングが採用される。図４に示すように、移動ノードＭＮからＧＧＳＮ４００までの通信パスは、移動先ネットワークである外部ＰＤＮ２１２内に複数のルータ４２０、４２２、４２６を含む。

また、図４に示すように、ＧＰＲＳ／ＵＭＴＳネットワーク２６０の要素として、ＧＧＳＮ４００内には、トラヒックフローテンプレートコントローラ（Traffic Flow Template controller：以下、ＴＦＴコントローラという。）４７０と、サービスベースローカルポリシコントローラ（Service Based Local Policy controller：以下、ＳＢＬＰコントローラという。）４７２とが含まれている。ＴＦＴコントローラ４７０及びＳＢＬＰコントローラ４７２は、後述するように、本発明の実施の形態に基づいて動作し、ＧＧＳＮ４００から移動ＵＥ（ＣＮ）４０６への、及び移動ＵＥ（ＣＮ）４０６からＧＧＳＮ４００への且つ外部ＰＤＮ２１２に向けてのＩＰデータパケットの通信を管理する。

以下の説明において、移動ＵＥ４０６は、図２に示すように、通信相手ノードＣＮを構成し、移動ＵＥ４０６がインターネットデータパケットを受信し、及びインターネットデータパケットを送信するノードは、図２を用いて説明したように、外部ＰＤＮ２１２に移動する移動ノードＭＮを構成する。

本発明の実施の形態を明瞭に説明するために、まず、図４に示すＴＦＴコントローラ４７０の動作について、図５を用いて簡潔に説明する。

トラヒックフローテンプレート（ＧＧＳＮにおけるＴＦＴベースのパケットフィルタリング）
図５に示すように、ＧＧＳＮ移動ＩＰ層４１２内で動作するＴＦＴコントローラ４７０には、送信元アドレスのリスト５０２が供給され、ＴＦＴコントローラ４７０は、このリスト５０２を用いて、インターネットパケットヘッダ内に含まれている送信元アドレスに基づき、ＩＰデータパケットの通信を制御する。ＴＦＴコントローラ４７０は、移動ＵＥ（ＣＮ）４０６内の又は移動ノードＭＮ上のアプリケーションによって起動され、必要な宛先にログオンする処理に類似したパケットデータプロトコルコンテキストアクティブ化（packet data protocol context activation：以下、ＰＤＰコンテキストアクティブ化という。）によって設定された適切なベアラによって、ＩＰデータパケットを通信するように構成されている。

適切なＵＭＴＳベアラを選択するために、ＧＧＳＮ４００は、以下のパラメータに基づいて、トラヒックフローテンプレートを確立する。
・ＩＰＶ４送信元アドレスタイプ
・ＩＰＶ６送信元アドレスタイプ
・プロトコル識別子／次ヘッダタイプ
・単一の宛先ポートタイプ
・宛先ポート範囲タイプ
・単一の送信元ポートタイプ
・送信元ポート範囲タイプ
・機密保護周辺インデックスタイプ
・サービスタイプ／トラヒッククラスタイプ
・フローレベルタイプ
マルチメディアセッションのために用いられる各ＰＤＰコンテキストについて、移動端末は、トラヒックフローテンプレートを生成し、これをＧＧＳＮ４００に送信し、ＧＧＳＮ４００は、このトラヒックフローテンプレートを用いて、テンプレートによって提供された情報に基づいて、入力パケットをフィルタリングする。例えば、Ｉｐｖ６の移動ノードＭＮから送信されてきたパケットに体して、通信相手ノードＣＮは、ダウンリンク方向のパケットのＩｐｖ６送信元アドレスとして、移動ノードＭＮのＩＰアドレスを生成するトラヒックフローテンプレートを生成する。

図５に示すように、外部ＰＤＮ２１２から、ダウンリンクを介して受信され、通信相手ノードＣＮである移動ユーザ機器（ＣＮ）４０６に送信されるインターネットパケット５０４は、宛先アドレスフィールド５０６内に通信相手ノードＣＮのアドレスＣＮ−ＡＤＤを含むことができる。インターネットパケット５０４は、送信元アドレスフィールド５０８内に移動ノードＭＮのホームアドレスＨＡを含むことができる。

実際の動作では、ＴＦＴコントローラ４７０は、リスト５０２に基づいてインターネットパケット５０４の送信元アドレスをチェックし、それぞれの通信相手ノードＣＮにインターネットパケットを通信する、このＴＦＴコントローラ４７０内で設定された適切なデータベアラによって、インターネットパケット５０４をルーティングする。ここで、図２に示すように、移動ノードＭＮが、そのホームネットワーク２１０から移動先ネットワークである外部ＰＤＮ２１２に移動した場合の処理について説明する。

図３を用いて説明したように、経路最適化の後に、移動ノードＭＮの送信元アドレスは、移動ノードＭＮの気付アドレスになっている。したがって、経路最適化が実行された後は、インターネットパケット５０４に対応するインターネットパケットヘッダ５１０は、通信相手ノードＣＮである移動ユーザ機器４０６に通信するために、移動ノードＭＮからＧＧＳＮ４００に送られる。図５に示すように、移動ノードＭＮが外部ＰＤＮ２１２に接続されたときに、移動ノードＭＮから受信されるインターネットパケットヘッダ５１０は、その宛先アドレスフィールド５１２内に通信相手ノードＣＮである移動ユーザ機器４０６のホームアドレスＣＮ−ＡＤＤを含むが、その送信元アドレスフィールド５１４内には、移動ノードＭＮの気付アドレスＣｏｆＡ−ＭＮを含む。ＴＦＴコントローラ４７０は、送信元アドレスに関するインターネットパケットを通信相手ノードＣＮに搬送するために設定及び定義されたパケットベアラを有する。しかしながら、外部ＰＤＮ２１２に移動した後の移動ノードＭＮから受信されるインターネットパケットヘッダ５１０は、ＧＧＳＮ４００に対して何らかの適応化を行わない限り、ＴＦＴコントローラ４７０によっては認識されず、したがって、パケットが落とされる。

ホップバイホップ拡張ヘッダフィールドの使用
経路最適化の後のＧＧＳＮ４００内のＴＦＴコントローラ４７０との間の相互動作の問題を解決するために既に提案されている解決策として、ホップバイホップフィールド５１６として知られている拡張ヘッダフィールド内に、移動ノードＭＮのホームアドレスを含ませる手法がある［特許文献１〜５］。ホップバイホップフィールド５１６内に移動ノードＭＮのホームアドレスを含ませることによって、ＴＦＴコントローラ４７０は、通信相手ノードＣＮにインターネットパケットを搬送するために用いる適切なベアラを識別することができる。これは、セッション開始の一部として、ＰＤＰコンテキストアクティブ化中に設定されたパケットベアラである。したがって、移動ノードＭＮが、セッションの最中に（mid-session）に、移動先ネットワークに移動した場合、ホップバイホップフィールド５１６で移動ノードＭＮのホームアドレスを提供することによって、ＴＦＴコントローラ４７０は、通信相手ノードＣＮである移動ユーザ機器（ＣＮ）４０６にインターネットパケットを搬送するために用いる適切なベアラを識別することができる。また、ホップバイホップフィールド５１６は、ルーティングヘッダタイプ２（ＩＰ６パケットのヘッダの拡張）としても知られている。

Ｉｐｖ６仕様書［非特許文献３］に基づき、各中間ルータは、ホップバイホップ拡張ヘッダフィールドを読み出さなければならない。したがって、ホップバイホップ拡張ヘッダを用いて移動ノードのホームアドレスを提供するためには、移動ノードから通信相手ノードにインターネットパケットを通信するパスにある各ルータが、ホップバイホップ拡張ヘッダ内の移動ノードのホームアドレスを読み出す必要がある。この要求は、ホップバイホップ拡張ヘッダ内の移動ノードのホームアドレスを読み出すための要求に起因したＩＰネットワークの実質的な性能劣化を意味する。

ＧＧＳＮ情報のためのルータアラートオプションの使用
通信パスに沿った全てのルータがホップバイホップ拡張ヘッダフィールド内の移動ノードのホームアドレスを読み出す必要性に起因した性能の劣化を防ぐために、本発明の実施の形態に基づくインターネットパケットは、ＧＧＳＮのためのＩｐｖ６の移動、例えば移動ノードのホームアドレスを含むホップバイホップ拡張ヘッダのルータアラートオプション（router alert option）のサポートに関連する情報を含んでいる。インターネットパケットのヘッダを図６に示す。

図６に示す「バージョン」フィールド６０１、「トラヒッククラス」フィールド６０２、「フローラベル」フィールド６０４、「ペイロード長」フィールド６０６、「ホップリミット」フィールド６０８は、［非特許文献３］に開示されており、ここでは詳細には説明しない。「次ヘッダ」フィールド６１０は、（値＝０によって）現在のヘッダの次のヘッダがホップバイホップオプションを提供し、したがって、読み出す必要があることを示す。「送信元アドレス」フィールド６１２及び「宛先アドレス」フィールド６１４は、図３に関して説明したように、送信元アドレス及び宛先にアドレスを提供する。

ホップバイホップ拡張ヘッダ部６１８内の「次ヘッダ」フィールド６１６は、更なるヘッダが現在の拡張ヘッダに続いているか否かを示す。「ヘッダ拡張長」フィールド６２０は、拡張ヘッダが存在する場合、拡張ヘッダの長さを示す。

ＩＰパケットの次のフィールドは、ルータアラートオプションタイプに基づいて指定される［非特許文献４］。これらのフィールドのうちの第１のフィールドは、「ルータアラートオプション」フィールド６２２である。「ルータアラートオプション」フィールド６２２は、このフィールドがルータにアラートを与えるものであり、３ビット（０００）によって示されるゼロの値を有する。次のフィールドは、５ビットのフィールド長によって５の値に設定される「ホップバイホップオプションタイプ」フィールド６２４である。

次のフィールド６２６は、値フィールドを有し、この値フィールドは、ＧＰＲＳネットワークのＧＧＳＮのために、ヘッダの残りの部分の情報を示す値に設定される。この値は、仕様書［非特許文献４］によって確保されている値以外であれば、如何なる値であってもよい。例えば、この値を「３」としてもよい。これに代えて、「データグラムがアクティブネットワークメッセージを含む」ことを意味する値「２」等、既に確保された値を使用してもよい。値「２」の定義が、この値をＧＧＳＮの移動情報のために用いることを許可している場合、この値を再使用することができる。他の場合、次の使用可能な値である値「３」を用いる。残りのフィールド６２８は、ＧＧＳＮに情報を提供するためのフィールドである。

フィールド６２６によって提供できるＧＧＳＮへの情報の一具体例としては、移動ノードのホームアドレスがある。この場合、１２８ビットのアドレスフィールドを用いる。一方、「ルータアラートオプション」フィールド６２２は、３ビットだけで表現され、「ホップバイホップオプションタイプ」フィールド６２４は、５ビットだけで表現される。この結果、通信パスに沿う全てのルータは、３ビットを読み出すだけで、その情報がルータに関連しているか否かを判定することができ、通信パスに沿う全てのルータが残りの１２８ビットのアドレスフィールドを読み出す必要がある場合に比べて、性能の劣化が実質的に抑制される。

ＴＦＴコントローラのためのＧＧＳＮの動作の要約
要約すれば、送信元アドレスフィールドと共にホップバイホップフィールドを解析することによって、リスト５０２が移動ノードＭＮのホームアドレスを含むので、ＴＦＴコントローラ４７０は、通信相手ノードＣＮにインターネットパケットを提供するための適切なベアラ５２０を識別することができる。パケット無線ネットワークに受け入れられるＩＰパケットを受信する場合のＧＧＳＮの動作を図７のフローチャートに示し、以下に説明する。

Ｓ１：ＧＧＳＮは、図６の具体例に基づくインターネットパケットを外部ネットワークから受信する。

Ｓ２：ＧＧＳＮは、インターネットパケットの次ヘッダフィールドがホップバイホップフィールドオプションを含むか否かを判定する。次ヘッダフィールドがホップバイホップフィールドオプションを含むことをＧＧＳＮが検出した場合、処理は、ステップＳ３に進み、その他の場合、ステップＳ６に進む。

Ｓ３：ＧＧＳＮは、ホップバイホップ拡張ヘッダを検出した場合、ホップバイホップ拡張ヘッダフィールド内にルータアラートヘッダタイプが存在しているか否かを判定する。幾つかの実施の形態では、このステップを省略してもよい。

Ｓ４：ＧＧＳＮは、情報を表すデータを提供するホップバイホップ拡張ヘッダフィールドによって提供されたフィールドから情報を再生する。

Ｓ５：そして、ＧＧＳＮは、再生された情報に基づいて、パケット無線ネットワークに対するインターネットパケットの送出及び／又は受入を制御する。

Ｓ６：ＧＧＳＮは、他の機能の処理を継続するが、ＧＧＳＮ情報フィールドの内容によっては、現在のパケットの処理を継続してもよい。

ホップバイホップ拡張ヘッダフィールドにおけるフィールドの１つを用いて、送信元アドレスとして、移動ノードのホームアドレスを提供することにより、ＴＦＴコントローラは、通信相手ノードにインターネットパケットを通信するための適切なベアラを識別することができる。この例示的な実施の形態におけるＧＧＳＮの動作を図８のフローチャートに示し、以下に説明する。

Ｓ７：ＧＧＳＮは、ゲートウェイサポートノードに対してホップバイホップ拡張ヘッダフィールドにより提供されたデータ、又はインターネットパケットの送信元アドレスから、インターネットパケットを通信する移動ノードの送信元ホームアドレスを検出する。

Ｓ８：ＧＧＳＮは、インターネットパケットの送信元アドレスが、パケット無線ネットワークに接続された通信相手ノードにインターネットパケットを通信するためのパケットデータベアラを識別しているか否かを判定する。そして、送信元アドレスがパケットデータベアラに対応している場合、処理はステップＳ１０に進み、他の場合、処理は、ステップＳ９に進む。

Ｓ９：ＧＧＳＮは、ＧＧＳＮ情報フィールドによって提供されたホームアドレスが、パケット無線ネットワークに接続された通信相手ノードにインターネットパケットを通信するためのパケットデータベアラを識別しているか否かを判定する。ホームアドレスがパケットデータベアラに対応している場合、処理はステップＳ１０に進み、他の場合、処理はステップＳ１１に進み、このインターネットパケットは、落とされる。

Ｓ１０：ＧＧＳＮは、識別されたパケットデータベアラによるインターネットパケットの受入を許可する。Ｓ１１：ＧＧＳＮは、インターネットパケットを落とす。

ルータ動作の要約
上述のように、移動ノードと通信相手ノードとの間の通信パスに沿ったルータは、ホップバイホップ拡張ヘッダの全体を読み出す必要なく、規格に基づいて動作することができる。これは、ルータがルータアラートオプションフィールドのみを読み出せばよく、ホップバイホップ拡張ヘッダの残りの部分を無視できるためである。

要約すれば、ルータは、図６に示す構成に基づき、図９のフローチャートに示し、以下に説明するように、インターネットパケットを処理することができる。

Ｓ２０：ルータは、図６に示す具体例に基づいて、インターネットパケットを受信する。

Ｓ２２：ルータは、インターネットパケットの次ヘッダフィールドがホップバイホップフィールドオプションを含むか否かを検出する。次ヘッダフィールドがホップバイホップフィールドオプションを含まない場合、ルータは、ステップＳ２８において、拡張されていないヘッダ内の発信元及び宛先アドレスに基づいて、インターネットパケットを通常に処理する。

Ｓ２４：ルータは、ホップバイホップ拡張ヘッダが存在していることを検出した場合、ルータアラートフィールド（Ｉｐｖ６［非特許文献４］では３ビット）を読み出すことによって、ホップバイホップ拡張ヘッダフィールド内にルータアラートヘッダタイプが存在しているか否かを判定する。ルータアラートヘッダが存在している場合、処理はステップＳ２８に進み、ルータは、拡張ヘッダフィールドを読み出さない。

Ｓ２６：ルータアラートヘッダが検出されない場合、ルータは、ホップバイホップ拡張ヘッダを読み出し、ヘッダを処理する。

Ｓ２８：ルータアラートヘッダが検出された場合、又はホップバイホップ拡張ヘッダフィールドが存在していない場合、ルータは、宛先アドレスに基づいて、インターネットパケットを送信し、ホップバイホップ拡張ヘッダフィールドの内容を読み出さない。

Ｓ３０：ルータは、インターネットパケットの処理を継続する。

モバイルＩＰＶ６とＧＰＲＳ／ＵＭＴＳネットワーク内のＩＭＳのＳＢＬＰコントローラの相互動作
図１０は、図５を用いて上述したダウンリンク通信に対応する通信相手ノードＣＮから移動ノードＭＮへのアップリンクでデータパケットを通信する、図４に示すＧＰＲＳ／ＵＭＴＳネットワークの一部の概略を示している。

図１０に示すように、ＰＤＰコンテキストアクティブ化を用いて、通信相手ノードＣＮによって開始されたベアラ９００は、移動ノードＭＮへのアップリンク通信に用いられる。アップリンク上でインターネットパケットによって通信される例示的なインターネットパケットヘッダ９０２は、ベアラ９００を用いて、ＵＴＲＡＮ４０４、ＳＧＳＮ４０２及びＧＧＳＮ４００を介して、移動先ネットワークである外部ＰＤＮ２１２に送出される。なお、ＧＧＳＮ４００内には、移動ユーザ機器（ＣＮ）による、ＧＰＲＳ／ＵＭＴＳネットワーク内のサービス品質リソース及び外部パケットデータ通信ネットワーク２１２へのアクセスを規制するために、ＳＢＬＰコントローラ４７２が設けられている。ＳＢＬＰコントローラ４７２は、不正なパーティ（unscrupulous parties）によるサービス攻撃の剽窃（theft）を防止するために、ポリシ決定点（policy decision point）又はポリシ強制点（policy enforcement point）として、ポリシ機能（policy function）を生成する。例えば、正当な権限を有さない不正なパーティが、ＩＰマルチメディアサブシステムサービス（IP multimedia subsystem service：ＩＭＳ）に不正にアクセスしようとする場合がある。ここで、ＧＧＳＮ４００は、正当な宛先アドレスを認識できない場合、パケットを落とす。宛先アドレスは、ＩＰセッションが設定されたときに確立された正当なアドレスである。移動ノードＭＮの場合、このアドレスは、ホームアドレスである。

図６に示すアップリンク通信の具体例に基づいたインターネットパケットを用いることによって、すなわち、ホップバイホップ拡張ヘッダ内に宛先の移動ノードのホームアドレスを提供することによって、サービスベースローカルポリシ（ＳＢＬＰ）機能に基づいて、インターネットパケットをＧＧＳＮから送出することができる。なお、ここでも、ルータアラートオプションヘッダの一部としてホームアドレスを提供することによって、ネットワーク内のルータがホップバイホップフィールドを読み出すために生じる潜在的な性能の劣化を抑制することができる。

ＧＰＲＳネットワークからパケットを送出するＧＧＳＮの動作を図１１に示し、以下に説明する。

Ｓ３０：ＧＧＳＮは、複数のパケットデータベアラから受信されるインターネットパケットの宛先アドレスに基づいて、送出パケットフィルタリングを実行する。送出が許可されるインターネットパケットは、サービスベースローカルポリシ（ＳＢＬＰ）機能に基づく正当な宛先アドレスを有するインターネットパケットのみである。

Ｓ３２：ＧＧＳＮは、図６に示すインターネットパケットを受信したときに、ゲートウェイサポートノードに対するホップバイホップ拡張ヘッダフィールド内で提供されるデータから、インターネットパケットの宛先である移動通信相手ノードの宛先ホームアドレスを検出する。

Ｓ３４：ホップバイホップ拡張ヘッダフィールドが正当な宛先ホームアドレスを含む場合、ステップＳ３５において、インターネットパケットの送出が許可される。他の場合、ステップＳ３６において、インターネットパケットは落とされる。

本発明の様々な更なる側面及び特徴は、添付の特許請求の範囲に定義されている。本発明の範囲から逸脱することなく、本明細書に記載された実施の形態を様々に変更することができる。

添付資料１
汎用パケット無線システム（General Packet Radio System：ＧＰＲＳ）／ユニバーサル移動通信システム（Universal Mobile Telecommunications System：ＵＭＴＳ）のアーキテクチャ
ＵＭＴＳのために用いられ、第３世代移動通信システムの標準化プロジェクト（Third Generation Partnership Project：以下、３ＧＰＰという。）によって管理され、提案された用語及びアーキテクチャに対応する図１に示す用語及びアーキテクチャの更なる詳細は、非特許文献１に開示されている。図１において、ゲートウェイＧＰＲＳサポートノード（GPRS Gateway Support Node：ＧＧＳＮ）１００は、外部パケットデータ通信ネットワーク（外部ＰＤＮ）２１２に接続されている。外部ＰＤＮ２１２は、インターネットプロトコル（ＩＰ）を用いてパケットを通信する。ＧＧＳＮ１００と外部ＰＤＮ２１２間のインタフェース１０４は、標準化されたＧｉのラベルが付されている。なお、更なる側面も標準化されている。また、ＧＧＳＮ１００には、これも標準化されているＧｎ／Ｇｐのラベルが付されたインタフェース１６８を介して、サービスＧＰＲＳサポートノード（ＳＧＳＮ）１０６が接続されている。

ＧＧＳＮ１００及びＳＧＳＮ１０６は、ＧＰＲＳをサポートする必要がある２つのネットワークコンポーネントである。ＧＧＳＮ１００は、外部パケットデータ通信ネットワーク（ＰＤＮ）２１２と、ＧＰＲＳをサポートする移動ネットワークとの間のゲートウェイとして機能する。ＧＧＳＮ１００は、入力ＩＰデータパケットを、ＳＧＳＮ１０６にルーティングする、すなわち移動パケット無線ネットワークによって提供される無線アクセス機能によってデータを受信する移動機器である特定のユーザ機器（ＵＥ）に送達するために十分な情報を含んでいる。例えば、一実施の形態においては、無線アクセス機能は、３ＧＰＰ規格によって定義されている汎用陸上無線アクセスネットワーク（Universal Terrestrial Radio Access Network：以下、ＵＴＲＡＮという。）方式に基づいて、提供される。ＳＧＳＮ１０６は、同じ公衆陸上移動ネットワーク（Public Land Mobile Network：以下、ＰＬＭＮという。）内にある場合、Ｇｎインタフェースを介して、ＧＧＳＮ１００に接続され、Ｇｐインタフェースを介して、他のＰＬＭＮに属するＧＧＳＮに接続される。

ＳＧＳＮ１０６は、移動パケット無線ネットワークによってサポートされた領域内で移動するユーザ機器（ＵＥ）の移動管理（mobility management）を提供する。この目的で、ＳＧＳＮ１０６は、ホーム位置レジスタ（Home Location Register：以下、ＨＬＲという。）１１０にアクセスする。ＳＧＳＮ１０６は、データパケットを、ＵＴＲＡＮ無線アクセス機能によって移動ユーザＵＥ１１６、１１８と通信を行う無線ネットワークコントローラ（ＲＮＣ）１１２、１１４にルーティングするように構成されている。ＵＴＲＡＮ無線アクセス機能は、移動通信ネットワークによって提供される領域の無線有効範囲を提供する基地局を構成するノードＢ装置１２０、１２２、１２４、１２６、１２８によって、提供される。各ＲＮＣ１１２、１１４と、ノードＢ装置１２０、１２２、１２４、１２６、１２８との間のＩｕｂのラベルが付されたインタフェース１３０、１３２、１３４、１３６、１３８は、制定された又は開発中の規格に準拠している。同様に、ＳＧＳＮ１０６と、各ＲＮＣ１１２、１１４との間のＩｕ−ｐｓのラベルが付されたインタフェース１４０、１４２は、開発中の規格に準拠している。

パケットデータ通信をサポートするように構成された移動パケット無線ネットワークの例示的アーキテクチャを示す図である。 ホームネットワークを介して通信相手ノードと通信し、移動先ネットワークに移動した後に、経路最適化手続を実行する移動ノードを示す図である。 経路最適化手続の異なる処理段におけるインターネットパケットの具体例を示す図である。 パケット無線通信ネットワークの一部を概略的に示す図である。 ダウンリンクパケットを通信相手ノードに通信するためのゲートウェイサポートノードの動作を説明するために、図４の一部を概略的に示す図である。 図２のＧＧＳＮに情報を提供するためのフィールドと共に、ホップバイホップ拡張ヘッダの一部として、ルータアラートヘッダを提供するインターネットパケットの構成を示す図である。 ダウンリンク通信方向に、図６に示す具体例の形式でインターネットパケットを処理するゲートウェイサポートノードの動作を示すフローチャートである。 ＧＧＳＮ情報フィールドが送信元ホームアドレスを含む、図６に示す具体例の形式でインターネットパケットを処理するゲートウェイサポートノードの動作を示すフローチャートである。 図６に示す具体例の形式でインターネットパケットを処理するルータの動作を示すフローチャートである。 アップリンク通信方向へのゲートウェイサポートノードの動作を示す、図４に示す構成の一部の略図である。 アップリンク通信方向について、図６に示す具体例の形式で、インターネットパケットを処理するゲートウェイサポートノードの動作を示すフローチャートである。

Claims (11)

1. 外部パケットデータ通信ネットワークとパケット無線ネットワーク間のインタフェースを提供するゲートウェイサポートノードであって、該パケット無線ネットワークは、該パケット無線ネットワークに接続されたノードにインターネットパケットを通信するための複数のパケットデータベアラを有し、該複数のパケットデータベアラのそれぞれは、インターネットパケットを通信するノードの送信元ホームアドレスに関して定義され、当該ゲートウェイサポートノードは、ヘッダフィールドを有するインターネットパケットを受信し、該ヘッダフィールドは、該インターネットパケットの送信元アドレスを識別するフィールドと、該インターネットパケットの宛先アドレスを識別するフィールドと、拡張ヘッダが該ヘッダフィールドに続くか否か及び該拡張ヘッダの種類を識別する次ヘッダフィールドとを含み、該ヘッダフィールドは、該拡張ヘッダがホップバイホップ拡張ヘッダを含むことを識別し、該ホップバイホップ拡張ヘッダは、該ホップバイホップ拡張ヘッダが読み出すルータに対してオプションであることを示すルータアラートオプションヘッダと、該ホップバイホップ拡張ヘッダの残りの部分が当該ゲートウェイサポートノードに提供されていることを示す値フィールドとを含み、該ホップバイホップ拡張ヘッダの残りの部分は、移動ノードのホームアドレスを提供するフィールドを含み、
   当該ゲートウェイサポートノードは、上記インターネットパケットを受信したときに、
   上記インターネットパケットの次ヘッダフィールドがホップバイホップフィールドオプションを含むことを検出し、
   上記ホップバイホップ拡張ヘッダ内のルータアラートオプションヘッダと、上記ホップバイホップ拡張ヘッダの残りの部分が当該ゲートウェイサポートノードに提供されていることを示す値フィールドとを検出し、
   上記ホップバイホップ拡張ヘッダの残りの部分が当該ゲートウェイサポートノードに提供されていることを示す値フィールドを検出したときに、該ホップバイホップ拡張ヘッダの残りの部分で提供されるフィールドから情報を再生し、該情報に基づいて、上記パケット無線ネットワークに対するインターネットパケットの送出及び／又は受入を制御し、
   当該ゲートウェイサポートノードは、
   上記ホップバイホップ拡張ヘッダの残りの部分で提供される情報から、インターネットパケットを通信する移動通信相手ノードの送信元ホームアドレスを検出し、
   上記送信元ホームアドレスを用いて、上記パケット無線ネットワークに接続された通信相手ノードに上記インターネットパケットを通信するためのパケットデータベアラを識別し、
   上記識別されたパケットデータベアラへのインターネットパケットの受入を許可することによって、
   上記外部パケットデータ通信ネットワークから上記パケット無線ネットワークのパケットデータベアラへのインターネットパケットの受入を制御するゲートウェイサポートノード。
2. 当該ゲートウェイサポートノードは、
   上記インターネットパケットの送信元アドレスフィールドのアドレス又は当該ゲートウェイサポートノードに対する上記ホップバイホップ拡張ヘッダのフィールドで提供されるアドレスがパケットデータベアラに対応している場合、上記インターネットパケットの受入を許可することを特徴とする請求項１記載のゲートウェイサポートノード。
3. 当該ゲートウェイサポートノードは、
   複数のパケットデータベアラから受信されるインターネットパケットの宛先アドレスに基づいて、送出パケットフィルタリングを実行して、正当な宛先アドレスを有するインターネットパケットについて、該インターネットパケットの送出を許可し、
   当該ゲートウェイサポートノードは、上記インターネットパケットを受信したときに、
   当該ゲートウェイサポートノードに対する上記ホップバイホップ拡張ヘッダのフィールドで提供されるデータから、上記インターネットパケットの宛先である移動通信相手ノードの宛先ホームアドレスを検出し、
   当該ゲートウェイサポートノードが、上記宛先ホームアドレスを正当なホームアドレスとして認識した場合、上記インターネットパケットの送出を許可することを特徴とする請求項１又は２記載のゲートウェイサポートノード。
4. 当該ゲートウェイサポートノードは、
   上記インターネットパケットの宛先アドレスフィールドのアドレス又は当該ゲートウェイサポートノードに対する上記ホップバイホップ拡張ヘッダで提供されるアドレスが正当な宛先アドレスである場合、該インターネットパケットの送出を許可することを特徴とする請求項３記載のゲートウェイサポートノード。
5. 当該ゲートウェイサポートノードは、汎用パケット無線システム規格に基づくゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）として動作することを特徴とする請求項１乃至４いずれか１項記載のゲートウェイサポートノード。
6. 外部パケットデータ通信ネットワークと当該パケット無線ネットワークに接続されたノードとの間でインターネットパケットを通信するパケット無線ネットワークにおいて、
   当該パケット無線ネットワークは、当該パケット無線ネットワークに接続されたノードに／からインターネットパケットを通信するための複数のパケットデータベアラを有し、 請求項１乃至５いずれか１項記載のゲートウェイサポートノードを備えるパケット無線ネットワーク。
7. 当該パケット無線ネットワークは、汎用パケット無線システム（ＧＰＲＳ）規格に基づいて動作し、上記ゲートウェイサポートノードは、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）であることを特徴とする請求項６記載のパケット無線ネットワーク。
8. 外部パケットデータ通信ネットワークとパケット無線ネットワーク間のインタフェースを提供するゲートウェイサポートノードの動作方法であって、該パケット無線ネットワークは、該パケット無線ネットワークに接続されたノードにインターネットパケットを通信するための複数のパケットデータベアラを有し、該複数のパケットデータベアラのそれぞれは、インターネットパケットを通信するノードの送信元ホームアドレスに関して定義され、
   当該ゲートウェイサポートノードの動作方法は、
   上記インターネットパケットがヘッダフィールドを有し、該ヘッダフィールドが、該インターネットパケットの送信元アドレスを識別するフィールドと、該インターネットパケットの宛先アドレスを識別するフィールドと、拡張ヘッダが該ヘッダフィールドに続くか否か及び該拡張ヘッダの種類を識別する次ヘッダフィールドとを含み、該ヘッダフィールドが該拡張ヘッダがホップバイホップ拡張ヘッダを含むことを識別し、該ホップバイホップ拡張ヘッダが、該ホップバイホップ拡張ヘッダが読み出すルータに対してオプションであることを示すルータアラートオプションヘッダと、該ホップバイホップ拡張ヘッダの残りの部分が当該ゲートウェイサポートノードに提供されていることを示す値フィールドとを含み、該ホップバイホップ拡張ヘッダの残りの部分が移動ノードのホームアドレスを提供するフィールドを含み、上記インターネットパケットを受信するステップと、
   上記インターネットパケットの次ヘッダフィールドが、拡張ヘッダがホップバイホップフィールドオプションを含むことを識別することを検出するステップと、
   上記ホップバイホップ拡張ヘッダ内のルータアラートオプションヘッダと、上記ホップバイホップ拡張ヘッダの残りの部分が当該ゲートウェイサポートノードに提供されていることを示す値フィールドとを検出するステップと、
   上記ホップバイホップ拡張ヘッダの残りの部分が当該ゲートウェイサポートノードに提供されていることを示す値フィールドを検出したときに、該ホップバイホップ拡張ヘッダの残りの部分で提供されるフィールドから情報を再生し、該情報に基づいて、上記パケット無線ネットワークに対するインターネットパケットの送出及び／又は受入を制御するステップとを有し、
   上記情報に基づいて、パケット無線ネットワークに対するインターネットパケットの受入を制御するステップは、
   上記ホップバイホップ拡張ヘッダの残りの部分で提供される情報から、インターネットパケットを通信する移動通信相手ノードの送信元ホームアドレスを検出し、該送信元ホームアドレスを用いて、上記パケット無線ネットワークに接続された通信相手ノードに上記インターネットパケットを通信するためのパケットデータベアラを識別するステップと、
   上記識別されたパケットデータベアラへのインターネットパケットの受入を許可し、他の場合、インターネットパケットを落とすステップとを有することを特徴とするゲートウェイサポートノードの動作方法。
9. 複数のパケットデータベアラから受信されるインターネットパケットの宛先アドレスに基づいて、送出パケットフィルタリングを実行して、正当な宛先アドレスを有するインターネットパケットについて、該インターネットパケットの送出を許可するステップと、
   上記インターネットパケットを受信したときに、当該ゲートウェイサポートノードに対する上記ホップバイホップ拡張ヘッダのフィールドで提供されるデータからインターネットパケットの宛先である移動通信相手ノードの宛先ホームアドレスを検出するステップと、
   上記ゲートウェイサポートノードが、上記宛先ホームアドレスを正当なホームアドレスとして認識した場合、上記インターネットパケットの送出を許可するステップとを更に有する請求項８記載のゲートウェイサポートノードの動作方法。
10. データプロセッサにロードされ、該データプロセッサに、請求項８又は９記載のゲートウェイサポートノードの動作方法を実行させるコンピュータプログラム。
11. 請求項１０記載のコンピュータプログラムを表す信号が記録されたコンピュータにより読取可能な媒体。

Images