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

Abstract

インターネットパケットは、インターネットパケットの送信元アドレスを特定するフィールドと、インターネットパケットの宛先アドレスを特定するフィールドと、拡張ヘッダがヘッダに続くか否か及び拡張ヘッダの種類を特定する次ヘッダフィールドとを含むヘッダフィールドとを有する。拡張ヘッダは、ホップバイホップオプションヘッダを示し、ホップバイホップ拡張ヘッダは、拡張フィールドの読出がルータにおいて任意であることを示すルータアラートオプションヘッダと、パケット無線ネットワークのゲートウェイサポートノードについての情報を提供するフィールドとを含む。これにより、例えば、モバイルインターネットプロトコル（ＩＰ）をサポートするために必要な情報をゲートウェイサポートノードに提供することができる。なお、ルータアラートオプションフィールドを提供することによって、ルータは、ホップバイホップオプションフィールドの残りの部分を読み出す必要がない。この結果、ルータが全てのホップバイホップ拡張フィールドを読み出す必要がある場合に生じる、インターネットパケットをルーティングする際のルータの性能の低下を抑制できる。

Description

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

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

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

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

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

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

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

係属中の英国特許出願第０２２６２８９．７号、第０２２２１８７．７号、第０２３０３３６．０号、第０２２２１６１．２号及び第０２３０３３５．２号には、ホップバイホップフィールドとして知られるＩＰｖ６における拡張ヘッダフィールドに移動ノードのホームアドレスを格納する手法が開示されている。これにより、適切なベアラがセットアップされた送信元アドレスをＭＮのホームアドレスが提供するので、ＧＧＳＮは、ＧＰＲＳネットワークに接続された通信相手ノード（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

本発明に係るインターネットパケットは、インターネットパケットの送信元アドレスを特定するフィールドと、インターネットパケットの宛先アドレスを特定するフィールドと、拡張ヘッダがヘッダに続くか否か及び拡張ヘッダの種類を特定する次ヘッダフィールドとを含むヘッダフィールドとを有する。拡張ヘッダは、ホップバイホップオプションヘッダを示し、ホップバイホップオプション拡張ヘッダは、拡張フィールドの読出がルータにおいて任意であることを示すルータアラートオプションヘッダと、パケット無線ネットワークのゲートウェイサポートノードについての情報を提供するフィールドとを含む。

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

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

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

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

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

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

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

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

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

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

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

対応付け更新により、ダウンリンクインターネットパケットヘッダ３５０は、送信元フィールド３５２に移動ノードＭＮの気付アドレスを格納する。これに対応して、移動ノードＭＮに送信されるインターネットパケットのインターネットパケットヘッダ３６０は、宛先フィールドに移動ノードＭＮの気付アドレスを格納する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ｓ６：ステップＳ６において、ＧＧＳＮは、他のタスクの処理を継続するが、ＧＧＳＮ情報フィールドのコンテンツによっては、現在のパケットの処理を継続してもよい。

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

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

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

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

Ｓ１０：ＧＧＳＮが、特定されたパケットデータベアラを介するインターネットパケットの受入を許可する。Ｓ１１：ＧＧＳＮがインターネットパケットを除外する。

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

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

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

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

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

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

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

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

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

図１０に示すように、ＰＤＰコンテキストアクティブ化を用いて、通信相手ノードＣＮにおいて開始されたベアラ９００は、移動ノードＭＮへのアップリンク通信を提供する。アップリンク方向にインターネットパケットと共に通信される、例示的なインターネットパケットヘッダ９０２は、ベアラ９００を用いて、ＵＴＲＡＮ４０４、ＳＧＳＮ４０２、ＧＧＳＮ４００を介して、移動先ネットワーク２１２の外部に送り出される。なお、ＧＧＳＮ４００内には、ＣＮ（移動ユーザ機器）による、ＵＭＴＳネットワーク内のサービス品質リソース及び外部パケットデータ通信ネットワーク２１２へのアクセスを制御するためにＳＢＬＰが設けられている。ＳＢＬＰ４７２は、不正なパーティによるサービスアタックを抑制するために、ポリシ決定点又はポリシ強制点として、ポリシ機能を実現する。例えば、正当な権原を有さない不正なパーティが、ＩＰマルチメディアサブシステムサービス（ＩＭＳ）に不正にアクセスしようとする場合がある。ここで、ＧＧＳＮは、正当な宛先アドレスを認識しない場合、パケットを除外する。宛先アドレスは、ＩＰセッションがセットアップされた際に確立された正当なアドレスである。移動ノードの場合、このアドレスは、ホームアドレスである。

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

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

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

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

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

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

添付資料１
汎用パケット無線システム（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 (29)

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. 請求項２７又は２８記載のコンピュータプログラムを表す信号が記録されたコンピュータにより読取可能な媒体。

Images