(57)【要約】  ２つのノード間のパケット伝送で発生する伝送遅延やその他のネットワーク条件をより正確に調べる技術が開示される。バッファリングノード１０は、パケットを転送する機能を有するネットワークノードである。ネットワークインタフェース１１で受信したパケットをデータキャッシュ１４にバッファする際、バッファ時間プロセッサ１２は、内部クロック１３を参照して、そのときの時刻（バッファした時刻）を記憶する。そして、このパケットを転送する際、バッファ時間プロセッサは再び内部クロックが示す現在時刻を参照して、現在時刻からバッファした時刻を減算することで、パケット伝送におけるバッファリング遅延によって生じるバッファリング時間を算出する。このバッファリング時間はパケットに付加して送信される。
2008102564.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続可能なネットワークノードであって、
前記ネットワークからパケットを受信するパケット受信手段と、
前記パケットをバッファするパケットバッファ手段と、
前記パケットバッファ手段にバッファされている前記パケットの転送開始を判断する転送開始判断手段と、
前記転送開始と判断された前記パケットバッファ手段にバッファされている前記パケットを、特定のアドレスに送信するパケット送信手段と、
前記パケットバッファ手段に前記パケットがバッファされていたバッファリング時間を計算するバッファリング時間計算手段と、
前記バッファリング時間計算手段で計算された前記バッファリング時間をバッファリング時間情報として、前記パケット送信手段によって送信される前記パケットの転送先に送信するバッファリング時間情報送信手段とを、
有するネットワークノード。
【請求項２】
計時機能を有する計時手段と、
前記特定のアドレスあての前記パケットに関しては、前記特定のアドレスあての前記パケットに関連付けて前記計時手段から得られるそのときの時刻をバッファ時刻情報として記憶するとともに、前記パケットバッファ手段に前記パケットをバッファさせるバッファ時間処理部とを有し、
前記バッファリング時間計算手段が、前記転送開始判断手段で前記パケットの転送開始が決定された場合に、前記計時手段から得られる現在時刻と前記バッファ時刻情報とに基づいて、前記パケットがバッファされていた前記バッファリング時間を示すバッファリング時間情報を計算するように構成されている請求項１に記載のネットワークノード。
【請求項３】
前記パケットの転送先が移動端末であって、前記移動端末がハンドオーバ処理を行っている最中に前記ネットワーク内で伝送する前記移動端末あての前記パケットのバッファ要求を受けるバッファ要求受信手段と、
前記移動端末の前記ハンドオーバ処理中に前記移動端末あての前記パケットを前記パケットバッファ手段にバッファするバッファ制御手段とを有し、
前記転送開始判断手段が、前記移動端末の前記ハンドオーバの完了を検出した場合に、前記移動端末への前記パケットの転送開始を判断するように構成されている請求項１に記載のネットワークノード。
【請求項４】
前記パケットの転送先の端末から前記バッファリング時間の要求を受けた場合に、要求を行った前記端末あての前記パケットに係る前記バッファリング時間を前記端末に提供するように構成されている請求項１に記載のネットワークノード。
【請求項５】
前記バッファリング時間情報送信手段が、前記パケットのレイヤ２フレームの末尾、又は、前記パケットに付加されたトンネルヘッダに前記バッファリング時間情報を付加して送信するように構成されている請求項１に記載のネットワークノード。
【請求項６】
ネットワークに接続可能なネットワークノードであって、
前記ネットワークで伝送されるパケットを転送するパケット転送手段と、
特定の端末に関するフィルタルールを格納するフィルタルール格納手段と、
前記フィルタルール格納手段に格納されている前記フィルタルールの条件に一致した前記パケットを前記パケット転送手段で受信した場合に、前記条件に一致した前記フィルタルールに関連付けられている前記特定の端末までのネットワーク条件を調べるための処理を行うテスト始動手段とを、
有するネットワークノード。
【請求項７】
前記パケット転送手段が、前記パケットを前記特定の端末に転送した場合に、前記パケット転送手段で受信した前記パケットを複製して複製パケットを作成する複製パケット作成手段と、
前記パケット転送手段で転送した前記パケットが通るパスとは異なるパスを経由するよう、前記複製パケットを前記特定の端末に送信する複製パケット送信手段とを、
有する請求項６に記載のネットワークノード。
【請求項８】
計時機能を有する計時手段と、
前記ネットワークに送出する際、前記計時手段から得られる現在時刻を前記パケット及び前記複製パケットに付加するタイムスタンプ手段とを、
有する請求項６に記載のネットワークノード。
【請求項９】
前記テスト手段が、前記特定の端末までのネットワーク条件を調べるためのテストパケットを定期的に送信するように構成されている請求項６に記載のネットワークノード。
【請求項１０】
前記テスト手段が、前記特定の端末までの複数のパスのそれぞれに複数のサイズのテストパケットを送信するように構成されている請求項６に記載のネットワークノード。
【請求項１１】
前記パケット転送手段で転送する前記パケットをバッファするパケットバッファ手段を有し、
前記テスト手段が、前記パケットバッファ手段にバッファされた前記パケットの転送によって、前記特定の端末までのネットワーク条件を調べるための処理を行うように構成されている請求項６に記載のネットワークノード。
【請求項１２】
移動しながらネットワークと通信を行うことが可能な移動端末であって、
ネットワークに接続してパケットの送受信を行うパケット送受信手段と、
ネットワークにおける当該移動端末あての前記パケットのバッファリングを前記ネットワークに要求するバッファリング要求手段と、
前記バッファリング要求手段で要求した前記バッファリングによって前記パケットがバッファされていたバッファリング時間の記録を前記ネットワークに要求するバッファリング時間記録要求手段と、
前記ネットワークでバッファされていた前記パケットの受信に伴って、前記パケットの前記バッファリング時間を前記ネットワークから受信するバッファリング時間受信手段とを、
有する移動端末。
【請求項１３】
前記ネットワークでバッファされていた前記パケットを転送した任意のパケット転送装置から、前記パケットが送出されたパケット送出時刻を取得するパケット送出時刻取得手段と、
前記ネットワークでバッファされていた前記パケットを前記パケット送受信手段で受信したパケット受信時刻を取得するパケット受信時刻取得手段と、
前記パケット受信時刻から前記パケット送出時刻を減算した値から、前記パケットの前記バッファリング時間を更に減算した結果得られる値を、前記任意のパケット転送装置から当該移動端末へのパケット伝送に要する実効待ち時間とする実効待ち時間算出手段とを、
有する請求項１２に記載の移動端末。
【請求項１４】
前記任意のパケット転送装置が前記パケット送出時刻を取得するために参照している時計と、当該移動端末が前記パケット受信時刻を取得するために参照している時計とを同期させる同期制御手段を有する請求項１３に記載の移動端末。
【請求項１５】
前記ネットワークに接続可能な複数のインタフェースと、
前記実効待ち時間算出手段によって算出された前記複数のインタフェースのそれぞれの前記実効待ち時間に基づいて、前記複数のインタフェースのそれぞれと前記任意のパケット転送装置との間の各リンクのアクセス条件を取得するアクセス条件取得手段とを、
有する請求項１３に記載の移動端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット交換型データ通信ネットワークのシステムにおける通信技術分野に関連する。特に、本発明は、パケット交換型データ通信ネットワークのシステムにおいて、バッファリングによるパケットの伝送遅延やその他のネットワーク条件を判断するためのネットワークノード及び移動端末に関する。
【背景技術】
【０００２】
現在のインターネットインフラストラクチャを始めとする通信ネットワークシステムでは、送信元（ソース：source）からあて先（送信先：destination）へのパスは、あて先から送信元に戻る逆向きのパスとは異なる可能性がある。【０００３】
例えば、送信元とあて先との間の転送パスを形成する各ルータの配列と、逆向きのパス（リバースパス）を形成するルータの配列とが異なる場合に、２つのパスは異なるものとなる。このような状態で、１往復（round-trip）の測定を行った場合には、実際には、２つの異なるパスの性能がまとめて測定されることになる。【０００４】
しかしながら、送信元とあて先との間の往復パスは非対称であり、各方向のパスをそれぞれ測定すると、２つの異なる方向のパスの性能が大きく異なる場合がある。例えば、それぞれのパスで異なるＩＳＰ（Internet Service Provider：インターネットサービスプロバイダ）や異なるタイプのネットワーク（例えば、研究ネットワークと商業ネットワーク、ＡＴＭネットワークとPacket Over SONETなど）を経由するような場合には、２つのパスの性能の差異が明確となる。【０００５】
一方、ネットワークアプリケーションの性能は、一方向のパスの性能に依存している場合が多い。例えば、ＴＣＰ（Transmission Control Protocol：伝送制御プロトコル）を使用するファイル転送は、アクノレッジメントが伝送する方向よりはむしろ、データフローの方向の性能に依存する傾向にある。【０００６】
このことは、特にＭｏｎａｍｉ６（Mobile Nodes and Multiple Interfaces in IPv6）の場合にも当てはまる。Ｍｏｎａｍｉ６では、モバイルノード（ＭＮ：Mobile Node）は、複数のパスを通じて、そのデータフローをホームエージェント（ＨＡ：Home Agent）に伝送することが可能である。Ｍｏｎａｍｉ６では、ＭＮにとっては、ＨＡからＭＮの様々なインタフェースへのデータの伝送方法が重要となる。したがって、ＭＮは、どのパスが特定のフローに最適かを判断するために、様々なインタフェースのネットワーク条件（パケット伝送速度、レイテンシ（待ち時間）、ジッタ、エラーレート、パケットロス率など）をテストする必要がある。【０００７】
例えば、下記の非特許文献１に記載のＮＴＰ（Network Time Protocol：ネットワークタイムプロトコル）及び非特許文献２に記載のＩＣＭＰ（Internet Control Message Protocol：インターネット制御メッセージプロトコル）を組み合わせることによって、ＭＮは、ＭＮとＨＡとの間のパスのネットワーク条件をテストすることが可能である。【０００８】
ＮＴＰは、パケット交換型であり可変レイテンシ（variable-latency）なデータネットワークにおけるコンピュータシステム間でクロックを同期させるプロトコルである。ＮＴＰは、特に、可変レイテンシの影響を受けないように設計されている。【０００９】
ＮＴＰを使用した場合、ＭＮは、ＩＣＭＰエコーリクエストメッセージを使用して、ＨＡにタイプスタンプ付きのＩＣＭＰエコーレスポンスメッセージを返答させることが可能である。そして、ＭＮは、ＭＮがＩＣＭＰエコーレスポンスパケットを受信する時刻と、ＩＣＭＰエコーレスポンスパケットに付加されているタイムスタンプ（すなわち、ＨＡでＩＣＭＰエコーレスポンスメッセージが処理された時刻）との間の差分に基づいて、ＭＮとＨＡとの間の遅延を把握することが可能である。【００１０】
また、特にモバイルの場合には、ＭＮは移動可能であり、時間の経過に応じて異なるアクセスポイントに接続する可能性がある。例えば、ある特定の人が電車で旅行をしながら、無線インタフェース及びセルラインタフェースを有するラップトップの使用を開始したとする。電車が運行しているルートにはＡＰ（Access Point：アクセスポイント）がいくつか配置されており、これによって、連続した無線通信可能領域が提供されている。【００１１】
したがって、ラップトップの無線インタフェースは、例えばファストモバイルＩＰ（ＦＭＩＰ：Fast Mobile IP）などのような技術を用いて、ＡＰ間であらかじめハンドオフ処理を行うことによって、そのセッションを継続させることが可能である。【００１２】
新たなＡＰへのハンドオフ処理後、ラップトップは、接続を変更したインタフェースに関する新たなネットワーク条件のテストをホームエージェントに行わせることによって、新たなアクセスリンク上においても特定のデータフローの要件がまだ満たされているか否かを判断することが可能となる。このようなトリガは、例えば、ラップトップからＨＡに送信されるＩＣＭＰエコーリクエストメッセージを使用して行われる。【００１３】
また、下記の特許文献１には、連続した様々なサイズのテストパケットを使用して、例えば帯域幅、伝送遅延、待機遅延、２つのノード間のネットワーク内におけるパケットサイズなどのネットワーク特性を決定する技術が開示されている。【００１４】
また、一方向のテストの場合には、受信ノードが、テストパケットの結果を収集して、報告を行う。また、一方向のテストにおける統計的な報告を用いて、受信ノードは、様々なパケットサイズに関して、往復時間の平均遅延と最小遅延との間の差を求めることで、平均の待機遅延（バッファリング遅延）を計算することが可能である。【００１５】
また、下記の特許文献２に記載の技術では、応答者が、送受信時刻に加えて、プローブパケット内のフィールドにデルタ時間を付加する必要がある。このデルタ時間は、受信者がパケットをどのくらい保持しているかを表す値であり、送受信時刻に加えてデルタ時間を使用することにより、送信者と受信者との間におけるより正確な伝送遅延時間の計算が可能となる。
【特許文献１】米国特許公報第５４７７５３１号
【特許文献２】米国特許公報第６８６８０９４号
【非特許文献１】Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and analysis", RFC 1305, March 1992.
【非特許文献２】Postel, J., "Internet Control Message Protocol", RFC 792, September 1981.
【００１６】
しかしながら、上述のように、ＮＴＰとＩＣＭＰとを組み合わせて使用して、ＭＮとＨＡとの間の遅延を把握する環境において、ＦＭＩＰを使用した場合を考える。電車は、例えばトンネルなどの２つの無線通信ポイント間の無線通信不能領域に入ることもある。トンネルに入る前に、ラップトップコンピュータは、ＦＭＩＰを使用して新たなＡＰに接続し、新たなＡＰへのハンドオーバを実行しようとしていることをＨＡに通知する。ＨＡは、ラップトップの新たなアクセスリンクをテストするように始動（トリガ）され、新たなＡＰにテストパケットを送信する。【００１７】
このとき、ラップトップコンピュータはトンネル内（すなわち、無線通信不能領域）に存在しており、新たなＡＰに接続することは不可能である。したがって、ラップトップコンピュータが新たなＡＰにおける接続を確立するまで、テストパケットは新たなＡＰにバッファされることになる。このバッファリングによってラップトップコンピュータにおけるテストパケットの受信に遅延が生じてしまい、テストパケットによるアクセスリンクの条件（ネットワーク条件）の測定が、不正確なものとなってしまうという問題がある。【００１８】
さらに、電車内に位置する多数のＭＮが同一のＨＡによって管理されている場合には、ＨＡは、電車内の多数のＭＮからほぼ同時に多数のＩＣＭＰエコーリクエストメッセージを受信することになり、多数のＩＣＭＰエコーリクエストメッセージの処理によって、ＨＡのプロセッサの負荷が瞬間的に大幅に増大してしまうことになる。【００１９】
しかしながら、特許文献１に記載の技術によれば、各サイズに関して十分な数のテストパケットが送出される場合に、これらのパケットの少なくとも１つは、待機処理を受けずにネットワークを通り抜けると仮定する必要がある。このパケットが最小往復時間を記録することになる。このため、たくさんの量（十分な量）のテストパケットが創出される必要があるとともに、あくまでもパケットの最小往復時間は仮定を前提としており、正確性に欠ける結果が得られる可能性もある。【００２０】
しかしながら、特許文献２に記載の技術によれば、受信者が大量のプローブパケットを受信することは効率的とは言えず、ネットワークにとってはあまり好ましいことではない。送信者に向けて送信されるデータパケットを受信者が受信することによって、このようなアクセス条件のテストが開始されるようにしてもよい。この場合には、プローブパケットが送信される必要はなくなる。
【発明の開示】
【００２１】
本発明は、上記の課題を解決するため、パケット交換型データ通信ネットワークにおける２つのノード間のパケット伝送に発生する伝送遅延をより正確に算出したり、パケットの伝送条件（ネットワーク条件）を調べたりすることが可能なネットワークノード及び移動端末を提供することを目的とする。
【００２２】
上記の目的を達成するため、本発明のネットワークノードは、ネットワークに接続可能なネットワークノードであって、
前記ネットワークからパケットを受信するパケット受信手段と、
前記パケットをバッファするパケットバッファ手段と、
前記パケットバッファ手段にバッファされている前記パケットの転送開始を判断する転送開始判断手段と、
前記転送開始と判断された前記パケットバッファ手段にバッファされている前記パケットを、特定のアドレスに送信するパケット送信手段と、
前記パケットバッファ手段に前記パケットがバッファされていたバッファリング時間を計算するバッファリング時間計算手段と、
前記バッファリング時間計算手段で計算された前記バッファリング時間をバッファリング時間情報として、前記パケット送信手段によって送信される前記パケットの転送先に送信するバッファリング時間情報送信手段とを、
有する。
【００２３】
さらに、本発明のネットワークノードは、上記の構成に加えて、計時機能を有する計時手段と、
前記特定のアドレスあての前記パケットに関しては、前記特定のアドレスあての前記パケットに関連付けて前記計時手段から得られるそのときの時刻をバッファ時刻情報として記憶するとともに、前記パケットバッファ手段に前記パケットをバッファさせるバッファ時間処理部とを有し、
前記バッファリング時間計算手段が、前記転送開始判断手段で前記パケットの転送開始が決定された場合に、前記計時手段から得られる現在時刻と前記バッファ時刻情報とに基づいて、前記パケットがバッファされていた前記バッファリング時間を示すバッファリング時間情報を計算するように構成されている。
【００２４】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記パケットの転送先が移動端末であって、前記移動端末がハンドオーバ処理を行っている最中に前記ネットワーク内で伝送する前記移動端末あての前記パケットのバッファ要求を受けるバッファ要求受信手段と、
前記移動端末の前記ハンドオーバ処理中に前記移動端末あての前記パケットを前記パケットバッファ手段にバッファするバッファ制御手段とを有し、
前記転送開始判断手段が、前記移動端末の前記ハンドオーバの完了を検出した場合に、前記移動端末への前記パケットの転送開始を判断するように構成されている。
【００２５】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記パケットの転送先の端末から前記バッファリング時間の要求を受けた場合に、要求を行った前記端末あての前記パケットに係る前記バッファリング時間を前記端末に提供するように構成されている。
【００２６】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記バッファリング時間情報送信手段が、前記パケットのレイヤ２フレームの末尾、又は、前記パケットに付加されたトンネルヘッダに前記バッファリング時間情報を付加して送信するように構成されている。
【００２７】
また、上記の目的を達成するため、本発明のネットワークノードは、ネットワークに接続可能なネットワークノードであって、
前記ネットワークで伝送されるパケットを転送するパケット転送手段と、
特定の端末に関するフィルタルールを格納するフィルタルール格納手段と、
前記フィルタルール格納手段に格納されている前記フィルタルールの条件に一致した前記パケットを前記パケット転送手段で受信した場合に、前記条件に一致した前記フィルタルールに関連付けられている前記特定の端末までのネットワーク条件を調べるための処理を行うテスト始動手段とを、
有する。
【００２８】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記パケット転送手段が、前記パケットを前記特定の端末に転送した場合に、前記パケット転送手段で受信した前記パケットを複製して複製パケットを作成する複製パケット作成手段と、
前記パケット転送手段で転送した前記パケットが通るパスとは異なるパスを経由するよう、前記複製パケットを前記特定の端末に送信する複製パケット送信手段とを、
有する。
【００２９】
さらに、本発明のネットワークノードは、上記の構成に加えて、計時機能を有する計時手段と、
前記ネットワークに送出する際、前記計時手段から得られる現在時刻を前記パケット及び前記複製パケットに付加するタイムスタンプ手段とを、
有する。
【００３０】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記テスト手段が、前記特定の端末までのネットワーク条件を調べるためのテストパケットを定期的に送信するように構成されている。
【００３１】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記テスト手段が、前記特定の端末までの複数のパスのそれぞれに複数のサイズのテストパケットを送信するように構成されている。
【００３２】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記パケット転送手段で転送する前記パケットをバッファするパケットバッファ手段を有し、
前記テスト手段が、前記パケットバッファ手段にバッファされた前記パケットの転送によって、前記特定の端末までのネットワーク条件を調べるための処理を行うように構成されている。
【００３３】
また、上記の目的を達成するため、本発明の移動端末は、移動しながらネットワークと通信を行うことが可能な移動端末であって、
ネットワークに接続してパケットの送受信を行うパケット送受信手段と、
ネットワークにおける当該移動端末あての前記パケットのバッファリングを前記ネットワークに要求するバッファリング要求手段と、
前記バッファリング要求手段で要求した前記バッファリングによって前記パケットがバッファされていたバッファリング時間の記録を前記ネットワークに要求するバッファリング時間記録要求手段と、
前記ネットワークでバッファされていた前記パケットの受信に伴って、前記パケットの前記バッファリング時間を前記ネットワークから受信するバッファリング時間受信手段とを、
有する。
【００３４】
さらに、本発明の移動端末は、上記の構成に加えて、前記ネットワークでバッファされていた前記パケットを転送した任意のパケット転送装置から、前記パケットが送出されたパケット送出時刻を取得するパケット送出時刻取得手段と、
前記ネットワークでバッファされていた前記パケットを前記パケット送受信手段で受信したパケット受信時刻を取得するパケット受信時刻取得手段と、
前記パケット受信時刻から前記パケット送出時刻を減算した値から、前記パケットの前記バッファリング時間を更に減算した結果得られる値を、前記任意のパケット転送装置から当該移動端末へのパケット伝送に要する実効待ち時間とする実効待ち時間算出手段とを、
有する。
【００３５】
さらに、本発明の移動端末は、上記の構成に加えて、前記任意のパケット転送装置が前記パケット送出時刻を取得するために参照している時計と、当該移動端末が前記パケット受信時刻を取得するために参照している時計とを同期させる同期制御手段を有する。
【００３６】
さらに、本発明の移動端末は、上記の構成に加えて、前記ネットワークに接続可能な複数のインタフェースと、
前記実効待ち時間算出手段によって算出された前記複数のインタフェースのそれぞれの前記実効待ち時間に基づいて、前記複数のインタフェースのそれぞれと前記任意のパケット転送装置との間の各リンクのアクセス条件を取得するアクセス条件取得手段とを、
有する。
【００３７】
本発明のネットワークノード及び移動端末は上記の構成を有しており、２つのノード間のパケット伝送で発生する伝送遅延をより正確に算出したり、パケットの伝送条件（ネットワーク条件）を調べたりすることが可能となる。
【図面の簡単な説明】
【００３８】
【図１】本発明の実施の形態におけるバッファリングノードの構成の一例を示す図
【図２Ａ】本発明の実施の形態におけるバッファリングノードのバッファ時間プロセッサによるパケットバッファリング処理の一例を示すフローチャート
【図２Ｂ】本発明の実施の形態におけるバッファリングノードのバッファ時間プロセッサによるパケット転送処理の一例を示すフローチャート
【図３】本発明の実施の形態におけるネットワーク構成の一例を示す図
【図４】本発明の実施の形態におけるテスタノードの構成の一例を示す図
【図５】本発明の実施の形態における用いられるバインディングアップデートメッセージのフォーマットの一例を示す図
【図６】本発明の実施の形態におけるテスタノードが、特定のパケットがテストメカニズムのトリガか否かを決定する処理の一例を示すフローチャート
【図７】本発明の実施の形態におけるモバイルノードが処理する様々なリクエストに関するＭＮの処理の一例を示すフローチャート
【図８】本発明の実施の形態におけるモバイルノードがテストパケットを受信した場合に行われる処理の一例を示すフローチャート
【図９】本発明の実施の形態におけるモバイルノードの構成の一例を示す図
【発明を実施するための最良の形態】
【００３９】
以下、図面を参照しながら、本発明の実施の形態について説明する。なお、以下の説明では、本発明を説明するために、特定の番号や時間、構造、プロトコル名、及びその他のパラメータなどが詳細に説明される場合があるが、本明細書で用いられている特定の条件は、本発明を説明するために用いられているにすぎず、本発明を限定するものではない。また、以下では、本発明が不要に理解しづらくならないように、例えばブロックダイアグラムには周知のコンポーネントやモジュールが図示されている。【００４０】
本発明は、例えば、バッファリングノードのキャッシュにどのくらいの期間だけパケットがバッファされていたのか（バッファリング時間）をバッファリングノード自身が示すように構成されている。これにより、ノードは、この情報（パケットのバッファリング時間に関する情報）を使用して、バッファリングノードを経由して伝送されるパケットの待ち時間（レイテンシ）をより正確に計算することが可能となる。【００４１】
なお、本明細書では、“バッファリングノード”という用語は、バッファリングサービス（パケットバッファリングノードにおけるパケットのバッファリング）を要求したノード（要求ノード：requesting node）のパケットをバッファする通信ネットワークノードを表している。【００４２】
また、要求ノードが、パケットがバッファされた時間（バッファリング時間）を示すようにバッファリングノードに対して更に依頼した場合には、バッファリングノードは、パケットのバッファリング時間に関する情報を要求ノードに通知する。【００４３】
なお、本明細書では、主にアクセスポイント（ＡＰ：Access Point）がバッファリングノードとして動作する場合について説明するが、データを格納する機能を有する任意の通信装置がバッファリングノードとして動作可能である。【００４４】
また、本明細書では、“要求ノード”という用語は、要求ノードあてのパケットをバッファするようにバッファリングノードに対して要求する通信ネットワークノードを表している。上述のように、要求ノードは、バッファリングノードに対して、バッファリングノードでパケットがバッファされていたバッファリング時間に関する情報を提供するように要求することも可能である。【００４５】
なお、本明細書では、主にモバイルノード（ＭＮ：Mobile Node、移動端末）が要求ノードとして動作する場合について説明するが、要求ノードは、モバイルノード又は固定ノードのいずれであってもよい。【００４６】
さらに、本明細書では、“時間情報（timing information）”という用語は、バッファリングノードにおけるパケットのバッファに要した時間（すなわち、バッファリング時間）を表している。時間情報は、例えば、要求ノードに転送される前にデータパケットに付加される。【００４７】
図１には、本発明の実施の形態におけるバッファリングノード１０の構成の一例が図示されている。図１に図示されているバッファリングノード１０は、１つ又は複数のネットワークインタフェース１１、バッファ時間プロセッサ１２、内部クロック１３、データキャッシュ１４を有している。【００４８】
ネットワークインタフェース１１は、バッファリングノード１０が任意の通信媒体を介して別のノードと通信を行うために必要なあらゆるハードウェア又はソフトウェアを包含する機能ブロックである。【００４９】
なお、当業者に周知の用語を使用すると、ネットワークインタフェース１１は、レイヤ１（物理層）及びレイヤ２（データリンク層）の通信コンポーネント、ファームウェア、ドライバ、通信プロトコルを表している。また、図１には、ネットワークインタフェース１１が１つのみ図示されているが、バッファリングノード１０は、１つ又は複数のネットワークインタフェース１１を有することが可能である。また、ネットワークインタフェース１１は、シグナル／データパス１１０を通じて、バッファ時間プロセッサ１２にパケットを渡すことが可能である。【００５０】
また、内部クロック１３は計時機能を有しており、バッファ時間プロセッサ１２が特定のパケットのバッファリング時間を計算する際に使用されるクロック信号（例えば、現在時刻を示す信号）を生成することが可能である。内部クロック１３で生成されたクロック信号は、シグナル／データパス１３０を通じて、バッファ時間プロセッサ１２に渡される。【００５１】
また、データキャッシュ１４は、バッファリングノード１０におけるバッファリングサービスを要求した特定の要求ノードに関連するデータパケットをバッファする際に、そのバッファされるデータパケットのキャッシュを行う機能を有している。【００５２】
なお、これらのデータパケットには、データキャッシュ１４にパケットが格納された際の時刻を反映する情報が任意の形式で付加できることが望ましい。時刻の情報が付加されたデータパケットは、シグナル／データパス１４０を通じてバッファ時間プロセッサ１２に送られ、処理される。【００５３】
また、本発明では、バッファリングノード１０は、バッファ時間プロセッサ１２を有している。このバッファ時間プロセッサ１２は、バッファリングノード１０のデータキャッシュ１４にバッファされていたデータパケットのバッファリング時間を計算する機能を有している。【００５４】
なお、バッファ時間プロセッサ１２は、例えば、現在時刻と、バッファされたデータパケットがデータキャッシュ１４に格納された時刻との時間の差分を判断し、この時間の差分から、データパケットがデータキャッシュ１４に滞在していた時間（バッファリング時間）を把握することが可能である。【００５５】
また、バッファ時間プロセッサ１２は、シグナル／データパス１２０を通じて、内部クロック１３が示す現在時刻を参照することが可能となる。さらに、バッファ時間プロセッサ１２は、シグナル／データパス１２１を通じて、内部クロック１３から取得した現在時刻を付加したデータパケットをデータキャッシュ１４に格納することが可能となる。【００５６】
また、バッファ時間プロセッサ１２は、シグナル／データパス１２２を通じて、ネットワークインタフェース１１に時間情報を送信することが可能である。このとき、バッファ時間プロセッサ１２は、時間情報を要求ノード（バッファリングに関する情報（バッファリング時間など）を把握しようとしている要求ノード）に順番に発送する。【００５７】
また、本発明では、要求ノードがバッファリングノード１０に対して、バッファリングノード１０におけるネットワーク条件のテストを支援してくれるように依頼することも可能である。例えば、コレスポンデントノード（ＣＮ）との間で継続中の通信フローがバッファリングノード１０でサポートされている場合には、要求ノードであるモバイルノードは、バッファリングノード１０におけるネットワーク条件を把握する必要がある。【００５８】
ここでは、バッファリングノード１０は、ＭＮがハンドオフを行った後に、ＭＮのトラフィックフローの処理を行うＡＰ（アクセスポイント）とする。なお、ＭＮは、例えば、ＩＥＥＥ（Institute of Electrical and Electronics Engineers, Inc.）８０２．２１で規定されている情報サービスプロバイダを使用して、ＡＰの位置を特定することが可能であるが、この方法に限定されるものではない。【００５９】
ハンドオフ処理の前に、ＭＮは、パケットのバッファリングを要求するとともに、バッファリング時間記録要求メッセージ（record buffering time message）と呼ばれるメッセージをＡＰに送信して、ＭＮに発送されるパケットのバッファリング時間の記録を行うように指示する。なお、このパケットのバッファリング要求とバッファリング時間の記録要求は個別のメッセージで行われてもよく、また、１つのメッセージにまとめられてもよい。以下では、１つのメッセージにまとめた場合について説明する。【００６０】
なお、バッファリング時間記録要求メッセージには、例えばＭＮの識別情報や、ＡＰに対してＭＮあてのパケットのバッファリング時間を記録するように要求する情報などが含まれているが、これらに限定されるものではない。【００６１】
ＡＰがＭＮからの要求を承認した後、ＭＮに発送されるべき受信パケットは、一時的にバッファされるとともに、各パケットには、ＡＰがこのパケットを受信した時刻が付加される。そして、ＭＮがＡＰへのハンドオフ処理を完了すると、ＡＰは、バッファリングされたパケットを時間情報（バッファリング情報）と共にＭＮに転送する。【００６２】
しかしながら、この場合には、後で利用する意志がないにもかかわらず、悪意あるＭＮが、バッファリング時間記録要求メッセージを用いて、ＭＮあてのパケットを連続してバッファするように依頼することが可能である。これにより、ＡＰに対するサービス不能攻撃（ＤｏＳ（Denial of Service）攻撃）が引き起こされることになり、その結果、ＡＰでのバッファリングサービスを必要とする別のノードが、ＡＰのバッファの過負荷によって、サービスを受けられなくなる可能性がある。【００６３】
こうした攻撃を最低限に抑えるために、ＭＮ及びＡＰは、バッファリング時間記録要求メッセージの送受信の段階で、バッファされるパケット量に関する交渉を行うことが可能である。【００６４】
なお、こうした交渉の段階において、例えば、ＭＮが、特定の送信元アドレスからのパケットのバッファを行うようにＡＰに通知することも可能である。また、例えば、ＡＰがＭＮに対して、ＭＮあてのパケットのバッファリングに所定の時間長を割り当て、この時間長が経過する前にＭＮがバッファリングされたパケットを取得しなかった場合には、バッファリングされたパケットがＡＰのキャッシュから削除されるようにすることも可能である。【００６５】
さらには、バッファリングされるデータのうち、遅延を把握するための待ち時間（レイテンシ）の計測などに用いられているパケットにのみバッファリング時間を計測、付加することも可能である。これは、特定のテストメッセージの特定フィールドをチェックすることや、バッファリング時間の計測結果を書き込むことがあらかじめ決められているメッセージ（例えば、バッファリング時間の計測結果を書き込むためのフィールドが用意されているメッセージ）を受信することなどによって判別する。【００６６】
また、図２Ａ及び図２Ｂには、バッファリングノード１０のバッファ時間プロセッサ１２の機能を用いて、パケットがバッファリングノード１０のキャッシュにどのくらいの時間だけ格納されていたかを計算する本発明の好適な方法が示されている。図２Ａは、本発明の実施の形態におけるバッファリングノードのバッファ時間プロセッサによるパケットバッファリング処理の一例を示すフローチャートであり、図２Ｂは、本発明の実施の形態におけるバッファリングノードのバッファ時間プロセッサによるパケット転送処理の一例を示すフローチャートである。【００６７】
図２Ａにおいて、バッファ時間プロセッサ１２は、ＭＮ（要求ノード）からパケットのバッファ要求（バッファリング時間記録要求メッセージ）を受信すると（ステップＳ２００）、受信するすべてのパケットのチェック処理を行って、パケットがＭＮあてか否かの確認を行う（ステップＳ２０１）。【００６８】
受信したパケットがＭＮあてではない場合には、バッファ時間プロセッサ１２は、パケットに関して通常の処理（通常のパケット転送処理）を行い、再び、次に受信するパケットに対してチェック処理を継続する（ステップＳ２０２）。【００６９】
一方、パケットがＭＮあてであることが特定された場合には、バッファ時間プロセッサ１２は、内部クロック１３から現在時刻を取得して、この現在時刻の値をパケットに付加する（ステップＳ２０３）。そして、バッファ時間プロセッサ１２は、現在時刻の情報が付加されたパケットをデータキャッシュ１４に格納する処理を行う（ステップＳ２０４）。【００７０】
なお、ステップＳ２０１でＭＮあてであることが特定されたパケットすべてに対して、ステップＳ２０３で時刻情報を付加する必要はない。例えば、バッファ時間プロセッサ１２は、特定のパケット又は任意のパケットを選択してテストパケットとし、そのテストパケットに対してのみ時刻情報を付加してもよい。【００７１】
また、図２Ｂにおいて、バッファ時間プロセッサ１２は、ＭＮ（要求ノード）がＡＰへの接続に成功したという情報（トリガ）を受信して、ＭＮの接続を確認する（ステップＳ２１０）。なお、このトリガは、例えば、ネットワークインタフェース１１からバッファ時間プロセッサ１２に送信されるシグナル（ＭＮがＡＰの通信可能エリアに移動したことをバッファ時間プロセッサ１２に通知するシグナル）であるが、これに限定されるものではない。【００７２】
バッファ時間プロセッサ１２は、トリガを受けると、バッファされたＭＮあてのパケットをデータキャッシュ１４から取得する処理を行う（ステップＳ２１１）。そして、バッファ時間プロセッサ１２は、内部クロック１３から現在時刻を取得するとともに、バッファリングされたパケットに付加されている情報（格納された時刻）を抽出する（ステップＳ２１２）。【００７３】
次に、バッファ時間プロセッサ１２は、現在時刻と、パケットから抽出された時刻との差分を用いて、データキャッシュ１４にパケットがバッファされていたバッファリング時間を計算する（ステップＳ２１３）。なお、現在時刻と、パケットから抽出された時刻との差分をそのままをバッファリング時間としてもよく、あるいは、通常のパケット転送処理に要する時間（平均時間）を減算して、バッファによって発生した遅延時間をバッファリング時間とすることも可能である。また、ここでは、バッファリングノード１０がバッファリング時間（すなわち、パケットが送出される時刻からパケットが格納された時刻を減算した時間）を計算しているが、この計算を行わずに、後述のステップＳ２１４でパケットが送出される時刻及びパケットが格納された時刻の両方をパケットに付加してＭＮに送信してもよい。この場合、ＭＮが、パケットが送出される時刻及びパケットが格納された時刻からバッファリング時間の計算を行うことが可能である。【００７４】
バッファ時間プロセッサ１２は、ＭＮに発送されるバッファされたパケットのバッファリング時間を計算し終えると、この計算されたバッファリング時間を時間情報として、バッファされたパケットに付加する（ステップＳ２１４）。そして、バッファ時間プロセッサ１２は、時間情報が付加されたパケットをネットワークインタフェース１１経由でＭＮに転送し、その結果、パケットはＭＮに発送される（ステップＳ２１５）。【００７５】
なお、ＡＰがＭＮ３０のパケットに時間情報を付加できるようにする好適な方法としては、ＭＮ３０にパケットをトンネルして、トンネルヘッダのオプションに時間情報を挿入することが挙げられる。このトンネルを用いた方法によって、ＡＰは、パケットを改変することなく、パケットに追加ヘッダを付加することが可能となる。これは、例えば、ＩＰセキュリティ（ＩＰＳｅｃ）などの任意の暗号化スキームによってパケットが保護されている場合に有用である。【００７６】
また、別の方法として、ＡＰが、レイヤ２（データリンク層）の通信プロトコルを使用してパケットをＭＮ３０に発送し、レイヤ２フレームの後ろに時間情報を付加することも可能である。レイヤ２フレームの後ろに時間情報を付加することによって、時間情報の付加が、レイヤ２フレームのパケットのチェックサム計算によるチェックの妨げにならないようにすることが可能となる。【００７７】
また、ＭＮ３０あてのパケットが暗号化されていない場合には、ＡＰは、パケットのヘッダのオプションやトレーラ（ペイロード部に相当）に時間情報を付加することが可能である。【００７８】
また、ＩＰセキュリティ（ＩＰＳｅｃ）などの暗号化技術が使用されており、悪意ある攻撃者からパケットが保護されている場合には、ＡＰは、パケットの一部分（ＩＰＳｅｃによって保護されていない部分）を探索して、時間情報を含むオプションを付加することが可能である。【００７９】
例えば、パケットはＩＰＳｅｃの認証ヘッダ（ＡＨ：Authentication Header）方法によってのみ保護されている場合がある。この場合は、パケットのヘッダ部分が保護されているため、ヘッダに任意の情報を挿入するとＭＮによるパケットの認証チェックが困難になってしまうので、ＡＰは、時間情報のオプションをヘッダに挿入することが不可能である。したがって、この状況では、ＡＰは、パケットのトレーラに時間情報のオプションを挿入することが可能である。【００８０】
また、逆も同様であり、ＭＮ３０がＩＰＳｅｃのＥＳＰ（Encapsulating Security Payload）のみを使用している場合には、パケットのデータ部分が保護されているので、ＡＰは、パケットのヘッダに時間情報のオプションを付加することが可能である。【００８１】
また、図３には、本発明の実施の形態におけるネットワーク構成の一例が図示されている。図３に図示されているネットワーク構成において、モバイルノード（ＭＮ）３０は、ＭＮ３０あてのパケットのバッファリングを開始するようにバッファリングノードに通知することが可能な通信ノードである。【００８２】
ＭＮ３０は、リンク３１０ａ、３１１ｂを通じてインターネット３３への接続を実現するために、ＡＰ（アクセスポイント）に接続を行う。なお、ＭＮ３０は、ＩＥＥＥ８０２．１ｘの技術を用いてＡＰに接続することが可能であるが、これに限定されるものではない。【００８３】
さらに、このネットワーク構成において、ＡＰ１０ａ及びＡＰ１０ｂはルータとしても機能すると仮定し、ＭＮ３０は、アクセスシステム３１ａ、３１ｂのそれぞれの最初のホップルータとしてＡＰ１０ａ及びＡＰ１０ｂに接続することが可能である。【００８４】
なお、各アクセスシステム３１ａ、３１ｂにおけるネットワーク構成で使用されているリンクレイヤ技術として、例えばＩＥＥＥ８０２．１１やブルートゥース（登録商標）などを用いることが可能であるが、これらに限定されるものではない。【００８５】
さらに、ＡＰ１０ａ及びＡＰ１０は、ＭＮ３０にバッファリングサービスを提供するという追加機能を有しているバッファリングノードである。したがって、ＭＮ３０は、ＡＰ１０ａ及びＡＰ１０に対して、ＭＮ３０あてのパケットをＡＰ１０ａ及びＡＰ１０ｂでバッファするように要求することが可能となる。なお、バッファされるべきパケットは、例えば、ＭＮ３０を管理するホームエージェント（ＨＡ：Home Agent）３４から送信されるパケットであるが、これに限定されるものではない。【００８６】
このネットワーク構成において、ＭＮ３０がアクセスシステム３１ａからアクセスシステム３１ｂに移動しているとする。この移動によって、ＭＮ３０が接続されているＡＰは、ＡＰ１０ａからＡＰ１０ｂに変更される。このようなハンドオーバ処理が実行される際に、ファストモバイルＩＰ（ＦＭＩＰ：Fast Mobile IP）の使用が可能である。【００８７】
ここで、ＦＭＩＰが使用される場合について考える。まず、ＭＮ３０がＡＰ１０ａに接続されており、ＭＮ３０は、ＡＰ１０ａによって管理されているプレフィックスを使用して、プライマリ気付アドレス（ＣｏＡ：Care-of address）を構成しているとする。【００８８】
なお、ＡＰ１０ａはＭＮ３０に対して、例えば、ＡＰ１０ｂのＩＰアドレスやＡＰ１０ｂで管理されているプレフィックスなどのＡＰ１０ｂに関する情報を通知（アドバタイズ）するが、これらの情報に限定されるものではない。また、ＡＰ１０ａがＭＮ３０に情報を通知する方法としては、例えばルータアドバタイズメント（ＲＡ：Router Advertisement）の使用が挙げられるが、これに限定されるものではない。【００８９】
ここで、ＭＮ３０は、ＲＡ内に挿入されているＡＰ１０ｂのプレフィックス情報を使用して、ＮＣｏＡ（New Care-of address：新たな気付アドレス）を構成し、ファストバインディングアップデート（ＦＢＵ：Fast Binding Update）メッセージをＡＰ１０ａに送信する。【００９０】
なお、ＦＢＵにはＭＮ３０のＰＣｏＡ（Previous Care-of address：以前の気付アドレス）とバッファ時間記録要求オプション（Record Buffer Time option）が含まれていることが望ましいが、これらに限定されるものではない。レコードバッファ時間オプションは、ＭＮ３０に送信されるパケットのバッファリングに加えて、ＭＮ３０がＡＰ１０ｂに対してパケットのバッファリング時間を示すように要求したことを、ＡＰ１０ａに通知するためのものである。【００９１】
ＡＰ１０ａがＭＮ３０からＦＢＵを受信した場合、ＡＰ１０ａはハンドオーバイニシエート（ＨＩ：Handover Initiate）メッセージを生成して、ＡＰ１０ｂに発送する。なお、ＨＩメッセージには、レコードバッファ時間オプションに加えて、ＭＮ３０のＰＣｏＡ及びＮＣｏＡ、ＭＮ３０に送信されるパケットのバッファを行うようにＡＰ１０ｂに指示するフラグ（Ｕフラグ）が含まれていることが望ましいが、上述の情報に限定されるものではない。なお、ＡＰ１０ｂはＨＩメッセージの処理に成功した場合、ＡＰ１０ａに対してアクノレッジメントメッセージ（ＨＡｃｋメッセージ）を返信してもよい。【００９２】
ＡＰ１０ｂは、ＦＢＡｃｋ（Fast Binding Acknowledgement）メッセージをＭＮ３０に返信して、ＦＢＵの処理に成功した旨をＭＮ３０に通知する。この時点で、ＭＮ３０は、ＡＰ１０ａとの接続を切断する前であっても、ＭＮ３０のＮＣｏＡをＨＡ３４に通知する処理を行えるようになる。なお、ＭＮ３０は、ＡＰ１０ａとの接続を切断する直前にＮＣｏＡを含むＢＵをＨＡ３４に送信することが望ましい。【００９３】
ＨＡ３４は、ＭＮ３０のＮＣｏＡの登録（関連付け）に成功すると、ＭＮ３０あてのパケットをＡＰ１０ｂに発送し始める。ＡＰ１０ｂは、ＭＮ３０あてのパケットを受信すると、バッファされるパケットに関して、時間情報を計算する上述の方法を実行する。すなわち、ＭＮ３０がＡＰ１０ｂとの接続に成功した後、ＡＰ１０ｂは、バッファされているＭＮ３０あてのパケットを時間情報と共にＭＮ３０に転送する。【００９４】
このとき、ＡＰ１０ｂはレイヤ２の通信プロトコルによって、バッファされていたパケットをＭＮ３０に転送するとともに、レイヤ２フレームの後ろに時間情報を付加することが可能である。【００９５】
また、別の方法では、ＭＮ３０は、ＡＰ１０ａに対して、ＭＮ３０あてのパケットのバッファを依頼する一方、ＡＰ１０ｂの通信エリアに移動してＡＰ１０ｂへの接続を行う。そして、ＭＮ３０がＡＰ１０ｂの接続に成功した場合には、ＭＮ３０は、ＡＰ１０ｂを経由してＡＰ１０ａにＦＢＵメッセージを送信し、ＡＰ１０ａに対して、バッファされているパケットをＭＮ３０のＮＣｏＡに転送し始めるように通知する。この結果、ＡＰ１０ａは、バッファリングされているＭＮ３０あてのパケットをトンネルして、トンネルヘッダのオプションとして時間情報を挿入することが可能となる。【００９６】
なお、さらに、ＨＩメッセージに、ＡＰがＭＮに関する時間情報の計算を開始すべきときを示すオプションが含まれるようにしてもよい。例えば、ＭＮ３０は、ＭＮ３０がＡＰとのレイヤ２の接続を失ったことをＡＰが検出した時点で、時間情報の計算を開始するようにＡＰに依頼することが可能である。【００９７】
また、別の方法として、ＭＮ３０は、ＭＮ３０あてのデータが５メガバイトを超えてキャッシュされた場合に時間情報の計算を開始するようにＡＰに要求することも可能である。さらに別の方法として、ＨＡ３４がＭＮ３０に関連するバッファリングノードとして機能し、ＨＡ３４が上述のような時間情報の計算を実行することも可能である。【００９８】
本発明の実施の形態では、ＭＮ３０は、それぞれが異なるアクセスシステムに接続されている２つのインタフェースを有している。ＭＮ３０のインタフェースの一方は、第３世代セルラ（３Ｇ）ネットワークに接続されており、もう一方は、ワイヤレスネットワーク（Ｗｉ−Ｍａｘ）に接続されている。【００９９】
ＭＮ３０は、コレスポンデントノード（ＣＮ）において複数のバインディングエントリを生成する。すなわち、ＭＮ３０は、ＣＮにおいて、３Ｇネットワークに接続されているＣｏＡとＭＮ３０のホームアドレス（ＨｏＡ）とをバインドする。また、ＨＡ３４では、ＭＮ３０のＨｏＡは、Ｗｉ−ＭａｘネットワークにおけるＭＮ３０のＣｏＡに関連付けられている。【０１００】
ＭＮ３０のＷｉ−ＭａｘインタフェースがＷｉ−Ｍａｘネットワークに再接続する場合には、ＭＮ３０はＣＮに対して、ＣＮにおける両方のエントリを使用してテストパケットの発送を行うように依頼する。なお、ここでは、テストパケットには、ＣＮがパケットを送出した時刻が含まれるようにしているが、これに限定されるものではない。【０１０１】
同時に、ＭＮ３０はＨＡ３４に対して、ＭＮのパケットがバッファされた時間を示すように要求するバッファリング時間記録要求メッセージをＨＡ３４に送信する。ＣＮからのテストパケットがＨＡ３４に到着すると、ＨＡ３４は、パケットをバッファリングして、パケットがどれくらい長い時間だけバッファリングされるかを記録するためのタイマを始動する。【０１０２】
そして、ＭＮ３０がそのＷｉ−Ｍａｘインタフェースにおける再接続に成功すると、ＭＮ３０は、ＨＡ３４にＢＵを送信して、そのＷｉ−Ｍａｘインタフェースがアクティブであることを示す。ここで、ＨＡ３４はＭＮ３０に対して、時間情報と共にテストパケットをトンネルすることが可能である。【０１０３】
さらに、ＨＡ３４は、ＭＮ３０を管理する複数のホームエージェントによって構成されていてもよい。このようなネットワーク構成としては、ＭＮが複数のＨＡに属し、複数のホームアドレスを持っている場合に各ＨＡを連携させて使用する場合や、複数のＨＡが連携して１つの分散化されたＨＡとして動作するグローバルＨＡ−ＨＡシステムが挙げられる。グローバルＨＡ−ＨＡシステムでは、ＨＡは協同して地理的に分散されたオーバレイネットワークを形成し、エンドユーザにとって透過（トランスペアレント）な経路最適化が実現される。【０１０４】
この複数のＨＡを使用するシナリオでは、ＭＮ３０のバッファリングキャッシュは複数のＨＡに分散する構成を取ることになる。あるＨＡのデータキャッシュがいっぱいになった場合、そのＨＡは次のＨＡにパケットを渡して、そのＨＡにおいてキャッシュされる。
また、このＨＡのキャッシュもいっぱいになると、このパケットを次のＨＡに渡す。そして、キャッシュがいっぱいではないＨＡにパケットが到達するか、すべてのＨＡのキャッシュがいっぱいでパケットが破棄されるまで、パケットは次のＨＡに渡される。【０１０５】
また、次のＨＡへのパケット転送を開始する最初のＨＡが、転送するパケットに対して、パケットの時間情報を付加することが可能である。さらに、このＨＡが、すべてのＨＡに対して、このパケットに時間情報を付加しないように通知することも可能である。なお、すべてのＨＡに対して時間情報を付加しないように通知する方法としては、最初のＨＡがパケットにフラグを付加することが挙げられるが、これに限定されるものではない。このフラグは、パケットに時間情報を付加する中間ＨＡの機能を無効化（オーバライド）することを目的とする。ある場合においては、このオーバライド機能が有効となる。【０１０６】
さらに別の方法として、ＭＮ３０がＡＰに対して時間情報の記録を開始する要求を送信する代わりに、この処理がＨＡによって開始されてもよい。この場合、ＨＡは、例えば指標を付けた特別なパケットをＭＮ３０に送信して、バッファリングサービスを提供しているパス上のノード（バッファリングノード）を探索することが可能である。そして、ＨＡは探索によって発見されたバッファリングノードと交渉を行って、バッファリングや、ＭＮに関連するパケットの時間情報の計算を行うことが可能である。【０１０７】
ＭＮ３０は、パケットがＡＰにバッファされていた時間情報と共にバッファされていたパケットを受信すると、この時間情報を使用して、ＡＰとＨＡ３４との間の待ち時間（パケット転送に要する時間）をより正確に計算することが可能である。例えば、ＨＡ３４から送信されたパケットには、パケットが送信された時刻の情報が含まれている。ＭＮ３０は、ＡＰとＨＡ３４との間の待ち時間を計算する場合、パケットがＨＡ３４から送信された時刻と、ＭＮ３０がそのパケットを受信した時刻との差を計算する。この時間の差分は、ＨＡ３４からＭＮ３０までのパケット転送に要した時間であり、さらにこの時間の差分に基づいて、ＡＰとＨＡ３４との間の待ち時間がより正確に計算される。【０１０８】
この待ち時間は、ＭＮのハンドオフ直後にバッファリングされていたパケットを受信し始めた時点で計測可能でありながら、バッファリングが終了した時点以降のより安定した通信時の待ち時間とほぼ一致するため、パケット転送が安定するまで待ってから待ち時間の測定を行うことに比べて、より迅速に測定値に基づいた判断（フィルタルールの決定など）が可能となる。【０１０９】
さらに、待ち時間測定値を安定したパケット転送時の待ち時間により近づけるために、ＡＰ１０ａがパケットをＡＰ１０ｂに転送するタイミングを計測開始時刻、ＡＰ１０ｂがパケットをＭＮに送信するタイミングを測定終了時刻として、ＨＡ３４からＭＮ３０までのパケット転送に要した時間を算出することもできる。この場合、ＡＰ１０ａとＡＰ１０ｂの時刻は互いに同期している必要がある。【０１１０】
さらに、モバイルノード（ＭＮ３０）が自身のホームエージェント（ＨＡ）にフィルタルールを設定することによって、ＨＡが、ＭＮとＨＡとの間のネットワーク条件のテストを行えるようにしてもよい。例えば、ＭＮ３０は、ＭＮ３０への様々なパスを経由してテストパケットを送信するようＨＡに依頼する特別なフィルタルールを設定することが可能である。【０１１１】
このＨＡにフィルタルールを設定する方法は、Ｍｏｎａｍｉ６のようなシナリオに特に有用である。Ｍｏｎａｍｉ６では、複数のインタフェースを有するＭＮは、コレスポンデントノード（ＣＮ）から送信されるフローに関連付けられるパスを決定する前に、各インタフェースの様々なネットワーク条件を把握する必要がある。【０１１２】
このフィルタルールの設定では、ＨＡにおいてＭＮによる設定が行われるので、ＭＮはＨＡに要求を送信し続けることなく、テストを開始できるという利点がある。【０１１３】
なお、以下では、“テスタノード”という用語によって、複数のテストパケットを受信ノードに送信することによってテストプログラムを開始し、受信ノードにおけるネットワーク条件のテストを行う通信ネットワークノードを表す。【０１１４】
なお、ここでは、ホームエージェント（ＨＡ）がテスタノードである場合について説明するが、これに限定されるものではなく、テスタノードは、ここで説明されるテスト機能を始動できる能力を有することが可能な任意の通信装置によって実現可能である。【０１１５】
図４には、テスタノード４０の好適な構成例が図示されている。図４に図示されているテスタノード４０は、１つ又は複数のネットワークインタフェース４１、フィルタルールプロセッサ４２、フィルタキャッシュ４３、テストパケット生成部４４を有している。【０１１６】
ネットワークインタフェース４１は、テスタノード４０が任意の通信媒体を介して別のノードと通信を行うために必要なあらゆるハードウェア又はソフトウェアを包含する機能ブロックである。【０１１７】
なお、当業者に周知の用語を使用すると、ネットワークインタフェース４１は、レイヤ１（物理層）及びレイヤ２（データリンク層）の通信コンポーネント、ファームウェア、ドライバ、通信プロトコルを表している。また、図４には、ネットワークインタフェース４１が１つのみ図示されているが、テスタノード４０は、１つ又は複数のネットワークインタフェース４１を有することが可能である。また、ネットワークインタフェース４１は、シグナル／データパス４１０を通じて、フィルタルールプロセッサ４２にパケットを渡すことが可能である。【０１１８】
また、フィルタルールプロセッサ４２は、ＭＮで定義された様々なフィルタルールの処理を行う機能を有している。フィルタルールプロセッサ４２は、ネットワークインタフェース４１からパケットを受信すると、そのパケットに関連したフィルタルールを検索するためにフィルタキャッシュ４３にシグナルを送信する。【０１１９】
フィルタキャッシュ４３に格納されているフィルタルールの参照の結果、ＭＮへの様々なパスのテストを行うことがパケットに関連するフィルタルールとして規定されている旨が分かった場合には、フィルタルールプロセッサ４２は、ＭＮへの様々なパスのテストに利用されるテストパケットの生成をテストパケット生成器４４に開始させる。【０１２０】
さらに、ＭＮが生成したフィルタルールがフィルタルールプロセッサ４２で受信されると、フィルタキャッシュ４３に格納される。フィルタルールプロセッサ４２は、シグナル／データパス４２０を通じて、フィルタキャッシュ４３におけるフィルタルールの格納及び検索を行うことが可能である。【０１２１】
また、フィルタルールプロセッサ４２は、シグナル／データパス４２１を通じて、テストパケット生成器４４にテストパケットの生成を開始させることが可能である。フィルタルールプロセッサ４２は、シグナル／データパス４２２を通じて、ＭＮ３０へのパケットの発送方法に関する指示を行うことが可能である。【０１２２】
また、テストパケット生成器４４は、ＭＮへの様々なパスのネットワーク条件をテストするためにＭＮに送信される様々なテストパケットを生成する機能を有している。なお、テストパケットとして、任意のパケットを使用することが可能であるが、ＭＮに送信されるオリジナルのデータパケットをコピーしたものを使用することが望ましい。オリジナルのパケットが特定のパスを経由して送信されたものである場合には、オリジナルのパケットをコピーしたパケットを使用することにより、ＨＡとＭＮとの間のアクセスシステムでの実際のパケットに対する処理をテストすることが可能となる。【０１２３】
テストパケット生成器４４は、シグナル／データパス４４０を通じて、生成したテストパケットをフィルタルールプロセッサ４２に渡して、ＭＮへの様々なパスのテストを開始することが可能である。【０１２４】
また、フィルタキャッシュ４３には、テスタノードが関連するノードのフィルタルールが格納されている。なお、このフィルタルールには、ノードあてのパケットの発送方法に関する情報が含まれている。フィルタルールプロセッサ４２は、シグナル／データパス４３を通じて適切なフィルタルールを取得し、処理が行われる。【０１２５】
本発明では、特別なフィルタルールが導入され、この特別なフィルタルールによって、ＨＡが、ＭＮへの様々なパスを通じて、テストパケットを送信することが可能となる。なお、このフィルタルールはＭＮによって定義され、例えば、バインディングアップデート（ＢＵ）メッセージによってＨＡに送信されるようにしてもよい。【０１２６】
ＨＡは、このＢＵメッセージを処理し、ＢＵメッセージに含まれているフィルタルールをフィルタキャッシュ４３に格納する。なお、この特別なフィルタルールは、例えば、ＭＮへのフローがフィルタに一致しない（すなわち、適切なフィルタルールが見つからない）場合に、適用されるようにしてもよい。【０１２７】
図５には、本発明の実施の形態における用いられるバインディングアップデートメッセージ（ＢＵメッセージ５０）のフォーマットの一例が図示されている。図５に図示されているＢＵメッセージ５０は、ＩＰｖ６ヘッダ５１、あて先オプションヘッダ５２、モビリティヘッダ５３、バインディングアップデートヘッダ５４、フィルタオプション５５、テストオプション５６を有している。【０１２８】
ＩＰｖ６ヘッダ５１はパケットの先頭の４０オクテットであり、送信元アドレス及びあて先アドレス（それぞれ１２８ビット）、バージョン（４ビットのＩＰバージョン）、トラフィッククラス（８ビット、パケットの優先度）、フローラベル（２０ビット、ＱｏＳ管理用）、ペイロード長（１６ビット）、次ヘッダ（８ビット）、ホップリミット（８ビット、生存可能時間）が含まれている。【０１２９】
また、ペイロードは、標準モードでは６４ｋバイトのサイズまでであるか、“ジャンボペイロード”オプションを有する場合にはより大きなサイズとなる。オプションが存在する場合、ＩＰｖ６ヘッダに続く次ヘッダフィールドによって、追加されたオプションヘッダが指定される。【０１３０】
また、あて先オプションヘッダ５２は、パケットのあて先ノードによってのみ処理される必要がある付加的な情報を挿入するために使用される。この好適な例として、あて先オプションヘッダ５２には、ホームアドレスが挿入される。これにより、モバイルノードがホームから離れている状態であっても、モバイルノードのホームアドレスをその受信者に通知することが可能となる。【０１３１】
また、モビリティヘッダ５３は、モバイルノード、コレスポンデントノード、ホームエージェントが、バインディングの作成や管理に関連するすべてのメッセージングを行う際に使用される拡張ヘッダである。モビリティヘッダ５３には、対象となる特定のモビリティメッセージを識別するモビリティヘッダのタイプ（８ビット）が含まれている。本発明の好適な実施例では、ＭＨタイプの値は、メッセージがバインディングアップデート（ＢＵ）メッセージであることを示す“５”に設定される。【０１３２】
また、バインディングアップデートヘッダ５４には、モバイルノードが他のノードに新たな気付アドレスを自ら通知するために必要な情報が含まれている。【０１３３】
また、フィルタオプション５５は、ＭＮ３０のユーザによって定義されたフィルタルールを伝送するために使用される。このフィルタルールによって、ＭＮ３０は、ＭＮ３０のフローをフィルタリングしているノードに、ＭＮ３０へのフローの発送方法に関する情報を指示することが可能となる。なお、本発明の好適な実施例としては、ＭＮ３０のフローをフィルタリングしているノードはＨＡ３４である。【０１３４】
なお、本発明の実施の形態では、フィルタルールには、フィルタの識別情報、ＭＮ３０のＣｏＡ、ＣＮの送信元アドレスなどが含まれている場合について説明しているが、これらに限定されるものではない。【０１３５】
また、本発明では、ＢＵ３０内に新たなオプション（テストオプション５６と呼ぶこともある）を導入する。ＭＮ３０はＨＡ３４に対して、テストオプション５６を使用して、ＨＡ３４に実行してもらいたいテストに関する情報を指示する。なお、テストオプション５６で指定可能なテストの種類としては、例えば、周期的なテスト、バッファリングのテスト、統計的なテストなど、いくつかのテスト方法が挙げられるが、これらに限定されるものではない。各テスト方法の詳細については、後述の実施の形態で説明する。【０１３６】
ＨＡ３４は、ＭＮ３０からＢＵを受信すると、ＢＵの処理を行って、ＭＮ３０のバインディングエントリを生成する。このように、ＨＡ３４は、ＭＮ３０がＨＡ３４に対する正当な加入者であることを認証すると、ＭＮ３０のＨｏＡをＭＮ３０によって示されたＣｏＡに関連付ける。【０１３７】
また、ＭＮ３０によって定義されるフィルタルールがＢＵ３０に含まれている場合には、ＨＡ３４は、フィルタキャッシュ４３にこれらのルールを格納する。
例えば、ＭＮ３０は、２つのＣｏＡを有している。ＣｏＡ１は、ＭＮ３０がＷｉ−Ｍａｘネットワークに接続されているインタフェースに関連付けられている。ＣｏＡ２は、ＭＮ３０が３Ｇネットワークに接続されているインタフェースに関連付けられている。【０１３８】
ＭＮ３０は、ＨＡ３４で受信したパケットの送信元アドレスがＭＮ３０によって定義されたフィルタルール内に存在するいずれの送信元アドレスとも一致しない場合に、HA３４がパケットをＣｏＡ２に転送するフィルタルール（例えば、フィルタルール：ＦＩＤ１とする）を設定する。【０１３９】
これにより、ＨＡ３４は、ＭＮ３０によって定義されたフィルタルールに一致しない送信元アドレスのパケットを受信すると、ＦＩＤ１をトリガ（始動）して、ＭＮ３０のＣｏＡ２にパケットを転送する。【０１４０】
なお、ここでは、ＨＡ３４は、ＢＵにはテストオプション５６が更に含まれていることを発見する。このテストオプション５６は、ＨＡ３４に対してＭＮ３０によるネットワーク（Ｍ３０が接続されている様々なネットワーク）の条件のテストを支援するように通知するものである。【０１４１】
例えば、ＭＮ３０は、テストオプション５６を設定して、ＦＩＤ１が始動された場合には、ＭＮ３０の別のインタフェースに向かうテストパケットの複製を設定するようにＨＡ３４に通知する。【０１４２】
そして、ＨＡ３４がＦＩＤ１を始動すると、ＨＡ３４は、ＦＩＤ１に関するテストオプションを参照して、ＭＮのＣｏＡ１を経由して送信されるテストパケットの複製を生成する。これにより、ＭＮ３０はＨＡ３４に対して、テストメカニズムを始動するタイミングを指示することが可能となる。【０１４３】
また、図６には、本発明の実施の形態におけるテスタノードが、特定のパケットがテストメカニズムのトリガであるか否かを決定する処理の一例が図示されている。【０１４４】
図６において、フィルタルールプロセッサ４２は、ＭＮ３０あてのパケットを受信すると（ステップＳ６００）、パケットの識別情報（例えば、送信元アドレスなどのパケット内に含まれている任意の情報）がＭＮ３０によって定義されたフィルタルールのものと一致するか否かのチェック処理（ＦＩＤのチェック）を行う（ステップＳ６０１）。【０１４５】
もし何らかのフィルタルールのものとの一致が見つかれば、フィルタルールプロセッサ４２は、そのフィルタルールの処理を行い、ＭＮ３０へのパケットの送信方法に関して、ネットワークインタフェース４１に通知する。【０１４６】
一方、フィルタルールプロセッサ４２がこのパケットのフィルタルールを特定することができなかった場合には、フィルタルールプロセッサ４２は、ＭＮ３０への様々なパスのテストに用いられるテストパケットの生成をテストパケット生成器４４に開始させる（ステップＳ６０２）。なお、テストパケットはＭＮ３０あての任意のパケットでよいが、例えば、ＭＮ３０に送信されるオリジナルのデータパケットを複製したパケットや、ＭＮ３０に送信されるオリジナルのデータパケットと同一サイズのパケットであることが望ましい。さらには、上記オリジナルのデータパケットと同一サイズのバインディングリフレッシュリクエスト（ＢＲＲ：Binding Refresh Request）メッセージを使用し、テストパケットの送信によって、新たなネットワーク条件が反映されたＢＵメッセージやフィルタルールアップデートメッセージの送信をＭＮ３０に促すことも可能である。テストパケット生成器４４は、フィルタルールプロセッサ４２にテストパケットを送信する。【０１４７】
そして、フィルタルールプロセッサ４２は、上述の時間情報を付加する方法に従って、オリジナルパケット及びテストパケット（オリジナルパケットを複製したパケット）にタイムスタンプを付加してから、ネットワークインタフェース４１に対して、様々なパスを経由するＭＮ３０へのパケットの送信方法に関する指示を行い、ＭＮ３０に向けてパケット送信が行われる（ステップＳ６０３）。【０１４８】
なお、フィルタルールプロセッサ４２は、オリジナルパケット及び複製したパケットにタイムスタンプを付加せずに、オリジナルパケット及び複製したパケットをそれぞれＭＮ３０への様々なパスに分散して送信してもよい。これによって、ＭＮ３０は様々なパスのネットワーク条件を調べることができるようになる。また、テスタノードが、ＭＮ３０への様々なパスに同一タイミングでパケットの発送を行うことで、テスタノードからＭＮ３０までの各パスの伝送時間差を取得し、比較することができるようになる。【０１４９】
また、ＭＮ３０がテストオプションを設定して、ＭＮ３０への様々なパスを通じてテストパケットを周期的に送信するようＨＡ３４に依頼することも可能である。この方法によれば、ＭＮ３０は、ある期間におけるより正確なネットワーク条件を取得して、ＭＮ３０へのアクセスパスの通常のアップデートを行うことができるようになるという利点がある。したがって、ＭＮ３０へのフローパスは、定期的にアップデートできるようになる。【０１５０】
また、ＭＮ３０は、テストオプションを設定して、ＭＮ３０に発送されるパケットをバッファするようにＨＡ３４に通知し、テストプログラムを実行することも可能である。この方法では、ＨＡ３４が、テストパケットとしてＭＮ３０に発送される実際のパケットを使用することが可能である。ＭＮ３０への各パスに関して、ＨＡ３４は、これらのテストパケットをほぼ同時に送信する。この方法は、ＨＡ３４がテストパケット生成器４４を使用して、テスト用の複製パケットを生成する必要がないという利点がある。さらに、パケットがほぼ同時に送信されるので、パケットにタイムスタンプを付加する必要がないという利点がある。【０１５１】
また、ＭＮ３０は、テストオプションを使用して、ＭＮ３０への各パスを経由してパケットを発送するようにＨＡ３４に指示することも可能である。【０１５２】
例えば、コレスポンデントノード（ＣＮ）はＨＡ３４を経由して、ＭＮ３０あての一連のパケットを送信する。最初のパケットに関しては、ＨＡ３４は、ＭＮ３０への第１のパスを経由してＭＮ３０に発送する。また、２番目のパケットに関しては、ＨＡ３４は、ＭＮ３０への第２のパス（第１のパスとは異なる）を経由して発送し、ＭＮへのすべてのパスでテストが完了するまで、同様のパケット発送処理が行われる。この方法には、ＨＡ３４がテストパケット生成器４４を使用して、テスト用の複製パケットを生成する必要がないという利点がある。【０１５３】
さらに、ＭＮ３０がテストオプションを設定して、ＭＮ３０が様々なすべてのパスの統計的な結果を得たい旨をＨＡ３４に通知することも可能である。例えば、ＨＡ３４は、このテストオプションを確認すると、ＭＮ３０への様々なパスを通じて様々なサイズのパケットを送信し、ＭＮ３０は、ＭＮ３０への各パスに関する統計的な情報を収集することができるようになる。この方法によって、ＭＮ３０は、ＨＡ３４との間の様々なパスに関する統計量を収集することができるようになる。【０１５４】
上述の方法では、テストパケットはＨＡ３４によって生成されており、ＭＮ３０がテストパケットを受信している。その結果、ＭＮ３０は、受信したテストパケットから得られる情報に基づいて、テストが行われたＨＡ３４へのリンクのアクセス条件を判断することが可能となる。さらに、ＭＮ３０は、このようにして得られたアクセス条件を使用して、ＭＮ３０に発送される特定のフローにとって適切なリンクを選択できるようになる。そして、ＭＮ３０はフィルタをＨＡ３４に設定する。このフィルタは、例えば、ＭＮ３０とＨＡ３４との間における選択されたリンクを経由して特定のフローをＭＮ３０に発送するように、ＨＡ３４に対して指示するものである。【０１５５】
また、ＭＮ３０がテストパケットの生成を行うことも可能である。この場合、ＭＮ３０は、例えば、フィルタリングバインディングメッセージをテストパケットとして使用し、ＨＡ３４への様々なパスを経由してフィルタリングバインディングメッセージを送信することも可能である。この方法では、フィルタリングバインディングメッセージには時間情報が含まれており、ＨＡ３４は、ＭＮ３０への特定のフローに関して最良の利用可能パスを特定することができるようになる。ＨＡ３４は、最良の利用可能なパスを特定すると、バインディングが成功したか否かを示すアクノレッジメントメッセージを返信する。この方法は、ＭＮ３０がどのフローをテストするかをＭＮ３０自身が選択できるようになるという利点がある。【０１５６】
なお、上述の様々な実施例では、ＭＮ３０が、ＢＵ内にフィルタルール及びテストオプションを１つずつ設定する場合が説明されているが、ＭＮ３０は、ＢＵ内にフィルタルール及びテストオプションをそれぞれ複数設定することも可能である。【０１５７】
また、本発明では、バッファリング及び／又はアクセス条件のテストの要求は、主にＭＮ３０によって行われる。以下、図７を参照しながら、こうした要求を行うＭＮ３０の機能による動作について説明する。図７には、本発明の実施の形態におけるモバイルノードが処理する様々なリクエストに関するＭＮの処理の一例が図示されている。【０１５８】
ＭＮ３０では、トリガコマンドを受信すると、バッファリング及び／又はアクセス条件のテストの要求を行う機能（要求機能）が起動される（ステップＳ７００）。なお、トリガコマンドは、例えば、ユーザ入力やＭＮ３０に設定されているポリシの起動によって発生するが、これらに限定されるものではない。【０１５９】
要求機能は、受信したトリガに基づいて、トリガがバッファリングのみを要求するもの（バッファトリガ）であるか否かを判断する（ステップＳ７０１）。トリガがバッファトリガである場合には、要求機能は、バッファ時間記録要求オプションを有するバッファ要求メッセージの生成を行う（ステップＳ７０２）。例えば、ＭＮ３０がＦＭＩＰを実行している場合には、バッファ要求メッセージとしてファストバインディングアップデート（ＦＢＵ）メッセージを利用することが可能である。また、ＭＮ３０が、ＨＡ３４に対してＭＮ３０のパケットのバッファリングを依頼している場合には、バッファ要求メッセージとしてバインディングアップデート（ＢＵ）メッセージを利用することが可能である。【０１６０】
しかしながら、トリガがバッファトリガではない場合には、ＭＮ３０の要求機能は、そのトリガがアクセス条件のテストのみを実行することを要求するもの（テストトリガ）であるか否かをチェックする（ステップＳ７０３）。トリガがテストトリガである場合には、要求機能は、テストオプション５６を有するテスト要求メッセージの生成を行う（ステップＳ７０４）。【０１６１】
なお、テストオプション５６によって、ＭＮ３０が要求するアクセス条件に関するテストの種類（例えば、アクセス条件に関する統計的なテストの実行を要求するのか、あるいはアクセス条件に関するテストの１回のみの実行を要求するのか）が表される。【０１６２】
ステップＳ７０３において、そのトリガがテストトリガではない場合には、要求機能は、そのトリガがバッファリング及びアクセス条件のテストの両方を要求するもの（テスト及びバッファトリガ）であるか否かをチェックする（ステップＳ７０５）。トリガがテスト及びバッファトリガである場合には、要求機能は、バッファ時間記録要求オプション及びテストオプション５６の両方を含む要求メッセージの生成処理を行う（ステップＳ７０６）。【０１６３】
例えば、ＭＮ３０は、ＡＰ１０ａに接続されている状態で、ＡＰ１０ｂとの通信を行っているが、ＡＰ１０ｂが提供している無線通信可能領域に、これから移動しようとしているとする。ＭＮ３０は、ＡＰ１０ａとの接続を切断する前に、バッファ時間記録要求オプション及びテストオプション５６の両方を含む要求メッセージをＨＡ３４に送信する。例えば、要求メッセージとしてバインディングアップデート（ＢＵ）メッセージを利用することが可能である。【０１６４】
さらに、ＭＮ３０はＨＡ３４に対して、ＡＰ１０ｂがＭＮ３０に関するテストパケットのバッファリング時間を記録するように、ＭＮ３０の代理としてＨＡ３４からＡＰ１０ｂに通知が行われるように指示する。ＨＡ３４は、バッファ時間記録要求オプションを有するテストパケットを送信し、ＭＮ３０に関するテストパケットのバッファリング時間を記録するようにＡＰ１０ｂに通知する。【０１６５】
また、ステップＳ７０５において、要求機能がトリガコマンドによる要求を判断することができない場合には、要求機能は、トリガコマンドの発生をもたらした要求に対する処理できなかった旨を示すエラーメッセージをユーザに戻す（ステップＳ７０７）。また、ステップＳ７０２、Ｓ７０４、Ｓ７０６のいずれかにおいて要求メッセージが生成された場合には、要求機能は、適切なあて先に向けて、この要求メッセージを転送する（ステップＳ７０８）。【０１６６】
次に、図８を参照しながら、ＭＮ３０がテストパケットを受信した場合の動作について説明する。図８には、本発明の実施の形態におけるモバイルノードがテストパケットを受信した場合に行われる処理の一例が図示されている。【０１６７】
ＭＮ３０は、テストパケットを受信するとテストパケット処理機能を起動し（ステップＳ８００）、テストパケットに埋め込まれている情報を取得して、ＭＮ３０とＨＡ３４との間の待ち時間の計算を行う（ステップＳ８０１）。例えば、ＨＡ３４及びＭＮ３０は、ＮＴＰを使用してそれぞれの内部時計を同期させる。【０１６８】
これにより、テストパケットに埋め込まれている情報に、ＨＡ３４からテストパケットが送出された時刻（送出時刻）を示すＨＡ３４によるタイムスタンプオプションが含まれている場合には、ＭＮ３０は、このパケットの受信時刻から、タイムスタンプオプションで定義される送出時刻を減算することによって、待ち時間の計算が行われる。例えば、ＭＮ３０は１０００ミリ秒のタイミングでテストパケットを受信し、テストパケットのタイムスタンプオプションから、このパケットが８００ミリ秒のタイミングで送出されたことが把握された場合には、ＭＮ３０とＨＡ３４との間の待ち時間は２００ミリ秒となる。【０１６９】
ＭＮ３０は、待ち時間について計算すると、バッファ時間記録要求オプションがテストパケットに付加されているか否かを判断する（ステップＳ８０２）。テストパケットにバッファ時間記録要求オプションが付加されていることが検出された場合、テストパケット処理機能は、バッファ時間記録要求オプションに含まれる時間情報を取得する処理を行う（ステップＳ８０３）。なお、この時間情報は、ＭＮ３０に送信される前にテストパケットがＡＰ１０のバッファに格納されていた時間（バッファリング時間情報）を表している。【０１７０】
テストパケット処理機能は、バッファ時間記録要求オプションから時間情報を取得すると、ＭＮ３０とＨＡ３４との間の実際の待ち時間を計算する（ステップＳ８０４）。テストパケット処理機能は、ステップＳ８０１で計算された待ち時間から、ステップＳ８０３で取得された時間情報を減算することで、実際の待ち時間を計算する。例えば、時間情報によって、ＭＮ３０のテストパケットがＡＰ１０のバッファ内で５０ミリ秒をバッファリングされていたことが示されているとする。このとき、ＭＮ３０が実際の待ち時間を計算する場合、ＭＮ３０は、以前に計算された２００ミリ秒の待ち時間から５０ミリ秒を減算し、その結果、実際の待ち時間として１５０ミリ秒の値が得られる。したがって、ＭＮ３０とＨＡ３４の間の実際の待ち時間は１５０ミリ秒である。【０１７１】
この計算結果の情報を用いて、テストパケット処理機能は、パケットがＨＡ３４からＭＮ３０に伝送される際に要する時間をユーザに通知する（ステップＳ８０５）。また、ステップＳ８０２において、テストパケットにバッファ時間記録要求オプションが付加されていないと判断された場合には、テストパケット処理機能は、バッファリング時間を考慮せずに、パケットがＨＡ３４からＭＮ３０に伝送される際に要する時間として、ステップＳ８０２で計算された待ち時間（上述の２００ミリ秒）をユーザに通知する。【０１７２】
なお、ここでは、モバイルノードがトリガコマンドの処理を行っているが、このような機能は、本発明に係る機能をサポートする他のノード（例えばＡＲやＨＡ）によって実現されてもよい。さらに、テストパケットの処理を行うモバイルノードに関しても、本発明に係る機能をサポートする他のノード（例えばＡＲやＨＡ）によって実現されてもよい。【０１７３】
また、図９には、本発明の実施の形態におけるモバイルノードの構成の一例が図示されている。図９に図示されているモバイルノード９０は、１つ又は複数のネットワークインタフェース９１、要求機能実現部９２、テストパケット処理機能実現部９３を有している。なお、ネットワークインタフェース９１が受信したパケットは、そのパケットの種類に応じて、シグナル／データパス９１０を通じて要求機能実現部９２に、あるいは、シグナル／データパス９３０を通じてテストパケット処理機能実現部９３に渡される。また、要求機能実現部９２が外部のネットワークノードにパケットを送信する場合には、シグナル／データパス９２０を通じてネットワークインタフェース９１にパケットを渡し、テストパケット処理機能実現部９３が外部のネットワークノードにパケットを送信する場合には、シグナル／データパス９４０を通じてネットワークインタフェース９１にパケットを渡す。【０１７４】
ネットワークインタフェース９１は、モバイルノード９０が任意の通信媒体を介して別のノードと通信を行うために必要なあらゆるハードウェア又はソフトウェアを包含する機能ブロックである。図１や図４に図示されているネットワークインタフェース１１、４１と同様に、ネットワークインタフェース９１は、レイヤ１（物理層）及びレイヤ２（データリンク層）の通信コンポーネント、ファームウェア、ドライバ、通信プロトコルを表している。なお、モバイルノード９０は、移動しながら通信を行うため、ネットワークインタフェース９１は無線通信機能を有している。【０１７５】
また、要求機能実現部９２は、所定のネットワークノードに対して、バッファリング要求及びバッファリング時間の記録要求を行ったり、テストパケットの発送を要求したりする機能を有しており、上述の図７に図示されている動作を実現することが可能である。【０１７６】
要求機能実現部９２は、具体的には、例えば、当該モバイルノード９０あてのパケットのバッファリングを要求する機能及びそのバッファリング時間の記録及び報告を要求する機能、当該移動端末へのテストパケットの送信を要求する機能などを有している。【０１７７】
また、テストパケット処理機能実現部９３は、テストパケットを受信した場合にテストパケットに関する処理を行って、テストパケットが伝送されてきた経路に関する情報（アクセスリンクの安定度を示すアクセス条件など）を取得する機能を有しており、上述の図８に図示されている動作を実現することが可能である。【０１７８】
テストパケット処理機能実現部９３は、所定のパケット（テストパケット）がバッファリングノード１０でバッファされていたバッファリング時間を取得する機能、テストパケットを送信したテスタノード４０と当該モバイルノード９０との間の待ち時間（バッファリングノード１０でバッファされていた時間も含むレイテンシ）を取得する機能、テストパケットの待ち時間からバッファリング時間を減算して、バッファリングノード１０でパケットがバッファされずに伝送される場合の待ち時間を算出する機能、自身の内部時計を他のネットワークノード（特にテスタノード）の内部時計と同期させる機能などを有している。【０１７９】
なお、本明細書では、本発明が最も実用的かつ好適な実施例となるように考慮されて図示及び説明されているが、当業者であれば、上述の各ノードの構成要素に係る設計やパラメータの詳細において、発明の範囲から逸脱しない程度に様々な変更が行われてもよいことは明白である。【０１８０】
例えば、本発明は、モバイルノード、モバイルルータ、モバイルＩＰのホームエージェント、ネットワークモビリティのホームエージェント、仮想プライベートネットワークのゲートウェイ、ＩＰｖ６−ＩＰｖ４変換ゲートウェイなどを始めとするバッファリングノードに適用可能である。【０１８１】
また、本発明は、例えば、ＮｅｔＬＭＭ（Network-based Localized Mobility Management）のようなローカライズされたモビリティ環境に対しても適用可能である。Ｎｅｔｌｍｍに適用した場合、ＭＮは、ローカライズされたモビリティ環境に配置されているアクセスルータ（ＡＲ）間を移動していることに気付くと、ＡＲに対して、ＭＮに属するパケットをバッファするように要求し、ＡＲは、こうしてバッファされたパケットに時間情報（バッファリング時間の情報）を付加することが可能である。【０１８２】
また、ＡＰが、図６に図示されているような構成要素を有し、テスタノードとして機能することも可能である。この場合、ＭＮは、ＡＰに対して、ＭＮに関するパケットをバッファするように依頼することに加えて、ＡＰがＭＮのバッファリングを行う方法を定めたルールを設定することが可能である。例えば、ＭＮは、ＡＰにフィルタルールオプションを送信して、任意のタイプのトラフィック／パケット／プロトコルをバッファすることを示すルールをＡＰに設定することが可能である。【０１８３】
なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。【０１８４】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。【０１８５】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
【産業上の利用可能性】
【０１８６】
本発明のネットワークノード及び移動端末は、２つのノード間のパケット伝送で発生する伝送遅延をより正確に算出したり、パケットの伝送条件（ネットワーク条件）を調べたりすることが可能であり、パケット交換型データ通信ネットワークのシステムにおける通信技術分野に適用可能である。また、特に、パケット交換型データ通信ネットワークのシステムにおいて、バッファリングによるパケットの伝送遅延やその他のネットワーク条件を判断する技術に適用可能である。
【図１】
2008102564.tif 000003
【図２Ａ】
2008102564.tif 000004
【図２Ｂ】
2008102564.tif 000005
【図３】
2008102564.tif 000006
【図４】
2008102564.tif 000007
【図５】
2008102564.tif 000008
【図６】
2008102564.tif 000009
【図７】
2008102564.tif 000010
【図８】
2008102564.tif 000011
【図９】
2008102564.tif 000012
【手続補正書】
【提出日】平成21年8月5日(2009.8.5)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークに接続可能なネットワークノードであって、
前記ネットワークからパケットを受信するパケット受信手段と、
前記パケットをバッファするパケットバッファ手段と、
前記パケットバッファ手段にバッファされている前記パケットの転送開始を判断する転送開始判断手段と、
前記転送開始と判断された前記パケットバッファ手段にバッファされている前記パケットを、特定のアドレスに送信するパケット送信手段と、
前記パケットバッファ手段に前記パケットがバッファされていたバッファリング時間を計算するバッファリング時間計算手段と、
前記バッファリング時間計算手段で計算された前記バッファリング時間をバッファリング時間情報として、前記パケット送信手段によって送信される前記パケットの転送先に送信するバッファリング時間情報送信手段とを、
有するネットワークノード。
【請求項２】
計時機能を有する計時手段と、
前記特定のアドレスあての前記パケットに関しては、前記特定のアドレスあての前記パケットに関連付けて前記計時手段から得られるそのときの時刻をバッファ時刻情報として記憶するとともに、前記パケットバッファ手段に前記パケットをバッファさせるバッファ時間処理部とを有し、
前記バッファリング時間計算手段が、前記転送開始判断手段で前記パケットの転送開始が決定された場合に、前記計時手段から得られる現在時刻と前記バッファ時刻情報とに基づいて、前記パケットがバッファされていた前記バッファリング時間を示すバッファリング時間情報を計算するように構成されている請求項１に記載のネットワークノード。
【請求項３】
前記パケットの転送先が移動端末であって、前記移動端末がハンドオーバ処理を行っている最中に前記ネットワーク内で伝送する前記移動端末あての前記パケットのバッファ要求を受けるバッファ要求受信手段と、
前記移動端末の前記ハンドオーバ処理中に前記移動端末あての前記パケットを前記パケットバッファ手段にバッファするバッファ制御手段とを有し、
前記転送開始判断手段が、前記移動端末の前記ハンドオーバの完了を検出した場合に、前記移動端末への前記パケットの転送開始を判断するように構成されている請求項１に記載のネットワークノード。
【請求項４】
前記パケットの転送先の端末から前記バッファリング時間の要求を受けた場合に、要求を行った前記端末あての前記パケットに係る前記バッファリング時間を前記端末に提供するように構成されている請求項１に記載のネットワークノード。
【請求項５】
前記バッファリング時間情報送信手段が、前記パケットのレイヤ２フレームの末尾、又は、前記パケットに付加されたトンネルヘッダに前記バッファリング時間情報を付加して送信するように構成されている請求項１に記載のネットワークノード。
【請求項６】
ネットワークに接続可能なネットワークノードであって、
前記ネットワークで伝送されるパケットを転送するパケット転送手段と、
特定の端末に関するフィルタルールを格納するフィルタルール格納手段と、
前記フィルタルール格納手段に格納されている前記フィルタルールの条件に一致した前記パケットを前記パケット転送手段で受信した場合に、前記条件に一致した前記フィルタルールに関連付けられている前記特定の端末までのネットワーク条件を調べるための処理を行うテスト始動手段とを、
有するネットワークノード。
【請求項７】
前記パケット転送手段が、前記パケットを前記特定の端末に転送した場合に、前記パケット転送手段で受信した前記パケットを複製して複製パケットを作成する複製パケット作成手段と、
前記パケット転送手段で転送した前記パケットが通るパスとは異なるパスを経由するよう、前記複製パケットを前記特定の端末に送信する複製パケット送信手段とを、
有する請求項６に記載のネットワークノード。
【請求項８】
計時機能を有する計時手段と、
前記ネットワークに送出する際、前記計時手段から得られる現在時刻を前記パケット及び前記複製パケットに付加するタイムスタンプ手段とを、
有する請求項６に記載のネットワークノード。
【請求項９】
前記テスト手段が、前記特定の端末までのネットワーク条件を調べるためのテストパケットを定期的に送信するように構成されている請求項６に記載のネットワークノード。
【請求項１０】
前記テスト手段が、前記特定の端末までの複数のパスのそれぞれに複数のサイズのテストパケットを送信するように構成されている請求項６に記載のネットワークノード。
【請求項１１】
前記パケット転送手段で転送する前記パケットをバッファするパケットバッファ手段を有し、
前記テスト手段が、前記パケットバッファ手段にバッファされた前記パケットの転送によって、前記特定の端末までのネットワーク条件を調べるための処理を行うように構成されている請求項６に記載のネットワークノード。
【請求項１２】
移動しながらネットワークと通信を行うことが可能な移動端末であって、
ネットワークに接続してパケットの送受信を行うパケット送受信手段と、
ネットワークにおける当該移動端末あての前記パケットのバッファリングを前記ネットワークに要求するバッファリング要求手段と、
前記バッファリング要求手段で要求した前記バッファリングによって前記パケットがバッファされていたバッファリング時間の記録を前記ネットワークに要求するバッファリング時間記録要求手段と、
前記ネットワークでバッファされていた前記パケットの受信に伴って、前記パケットの前記バッファリング時間を前記ネットワークから受信するバッファリング時間受信手段とを、
有する移動端末。
【請求項１３】
前記ネットワークでバッファされていた前記パケットを転送した任意のパケット転送装置から、前記パケットが送出されたパケット送出時刻を取得するパケット送出時刻取得手段と、
前記ネットワークでバッファされていた前記パケットを前記パケット送受信手段で受信したパケット受信時刻を取得するパケット受信時刻取得手段と、
前記パケット受信時刻から前記パケット送出時刻を減算した値から、前記パケットの前記バッファリング時間を更に減算した結果得られる値を、前記任意のパケット転送装置から当該移動端末へのパケット伝送に要する実効待ち時間とする実効待ち時間算出手段とを、
有する請求項１２に記載の移動端末。
【請求項１４】
前記任意のパケット転送装置が前記パケット送出時刻を取得するために参照している時計と、当該移動端末が前記パケット受信時刻を取得するために参照している時計とを同期させる同期制御手段を有する請求項１３に記載の移動端末。
【請求項１５】
前記ネットワークに接続可能な複数のインタフェースと、
前記実効待ち時間算出手段によって算出された前記複数のインタフェースのそれぞれの前記実効待ち時間に基づいて、前記複数のインタフェースのそれぞれと前記任意のパケット転送装置との間の各リンクのアクセス条件を取得するアクセス条件取得手段とを、
有する請求項１３に記載の移動端末。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット交換型データ通信ネットワークのシステムにおける通信技術分野に関連する。特に、本発明は、パケット交換型データ通信ネットワークのシステムにおいて、バッファリングによるパケットの伝送遅延やその他のネットワーク条件を判断するためのネットワークノード及び移動端末に関する。
【背景技術】
【０００２】
現在のインターネットインフラストラクチャを始めとする通信ネットワークシステムでは、送信元（ソース：source）からあて先（送信先：destination）へのパスは、あて先から送信元に戻る逆向きのパスとは異なる可能性がある。
【０００３】
例えば、送信元とあて先との間の転送パスを形成する各ルータの配列と、逆向きのパス（リバースパス）を形成するルータの配列とが異なる場合に、２つのパスは異なるものとなる。このような状態で、１往復（round-trip）の測定を行った場合には、実際には、２つの異なるパスの性能がまとめて測定されることになる。
【０００４】
しかしながら、送信元とあて先との間の往復パスは非対称であり、各方向のパスをそれぞれ測定すると、２つの異なる方向のパスの性能が大きく異なる場合がある。例えば、それぞれのパスで異なるＩＳＰ（Internet Service Provider：インターネットサービスプロバイダ）や異なるタイプのネットワーク（例えば、研究ネットワークと商業ネットワーク、ＡＴＭネットワークとPacket Over SONETなど）を経由するような場合には、２つのパスの性能の差異が明確となる。
【０００５】
一方、ネットワークアプリケーションの性能は、一方向のパスの性能に依存している場合が多い。例えば、ＴＣＰ（Transmission Control Protocol：伝送制御プロトコル）を使用するファイル転送は、アクノレッジメントが伝送する方向よりはむしろ、データフローの方向の性能に依存する傾向にある。
【０００６】
このことは、特にＭｏｎａｍｉ６（Mobile Nodes and Multiple Interfaces in IPv6）の場合にも当てはまる。Ｍｏｎａｍｉ６では、モバイルノード（ＭＮ：Mobile Node）は、複数のパスを通じて、そのデータフローをホームエージェント（ＨＡ：Home Agent）に伝送することが可能である。Ｍｏｎａｍｉ６では、ＭＮにとっては、ＨＡからＭＮの様々なインタフェースへのデータの伝送方法が重要となる。したがって、ＭＮは、どのパスが特定のフローに最適かを判断するために、様々なインタフェースのネットワーク条件（パケット伝送速度、レイテンシ（待ち時間）、ジッタ、エラーレート、パケットロス率など）をテストする必要がある。
【０００７】
例えば、下記の非特許文献１に記載のＮＴＰ（Network Time Protocol：ネットワークタイムプロトコル）及び非特許文献２に記載のＩＣＭＰ（Internet Control Message Protocol：インターネット制御メッセージプロトコル）を組み合わせることによって、ＭＮは、ＭＮとＨＡとの間のパスのネットワーク条件をテストすることが可能である。
【０００８】
ＮＴＰは、パケット交換型であり可変レイテンシ（variable-latency）なデータネットワークにおけるコンピュータシステム間でクロックを同期させるプロトコルである。ＮＴＰは、特に、可変レイテンシの影響を受けないように設計されている。
【０００９】
ＮＴＰを使用した場合、ＭＮは、ＩＣＭＰエコーリクエストメッセージを使用して、ＨＡにタイプスタンプ付きのＩＣＭＰエコーレスポンスメッセージを返答させることが可能である。そして、ＭＮは、ＭＮがＩＣＭＰエコーレスポンスパケットを受信する時刻と、ＩＣＭＰエコーレスポンスパケットに付加されているタイムスタンプ（すなわち、ＨＡでＩＣＭＰエコーレスポンスメッセージが処理された時刻）との間の差分に基づいて、ＭＮとＨＡとの間の遅延を把握することが可能である。
【００１０】
また、特にモバイルの場合には、ＭＮは移動可能であり、時間の経過に応じて異なるアクセスポイントに接続する可能性がある。例えば、ある特定の人が電車で旅行をしながら、無線インタフェース及びセルラインタフェースを有するラップトップの使用を開始したとする。電車が運行しているルートにはＡＰ（Access Point：アクセスポイント）がいくつか配置されており、これによって、連続した無線通信可能領域が提供されている。
【００１１】
したがって、ラップトップの無線インタフェースは、例えばファストモバイルＩＰ（ＦＭＩＰ：Fast Mobile IP）などのような技術を用いて、ＡＰ間であらかじめハンドオフ処理を行うことによって、そのセッションを継続させることが可能である。
【００１２】
新たなＡＰへのハンドオフ処理後、ラップトップは、接続を変更したインタフェースに関する新たなネットワーク条件のテストをホームエージェントに行わせることによって、新たなアクセスリンク上においても特定のデータフローの要件がまだ満たされているか否かを判断することが可能となる。このようなトリガは、例えば、ラップトップからＨＡに送信されるＩＣＭＰエコーリクエストメッセージを使用して行われる。
【００１３】
また、下記の特許文献１には、連続した様々なサイズのテストパケットを使用して、例えば帯域幅、伝送遅延、待機遅延、２つのノード間のネットワーク内におけるパケットサイズなどのネットワーク特性を決定する技術が開示されている。
【００１４】
また、一方向のテストの場合には、受信ノードが、テストパケットの結果を収集して、報告を行う。また、一方向のテストにおける統計的な報告を用いて、受信ノードは、様々なパケットサイズに関して、往復時間の平均遅延と最小遅延との間の差を求めることで、平均の待機遅延（バッファリング遅延）を計算することが可能である。
【００１５】
また、下記の特許文献２に記載の技術では、応答者が、送受信時刻に加えて、プローブパケット内のフィールドにデルタ時間を付加する必要がある。このデルタ時間は、受信者がパケットをどのくらい保持しているかを表す値であり、送受信時刻に加えてデルタ時間を使用することにより、送信者と受信者との間におけるより正確な伝送遅延時間の計算が可能となる。
【特許文献１】米国特許公報第５４７７５３１号
【特許文献２】米国特許公報第６８６８０９４号
【非特許文献１】Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and analysis", RFC 1305, March 1992.
【非特許文献２】Postel, J., "Internet Control Message Protocol", RFC 792, September 1981.
【発明の開示】
【発明が解決しようとする課題】
【００１６】
しかしながら、上述のように、ＮＴＰとＩＣＭＰとを組み合わせて使用して、ＭＮとＨＡとの間の遅延を把握する環境において、ＦＭＩＰを使用した場合を考える。電車は、例えばトンネルなどの２つの無線通信ポイント間の無線通信不能領域に入ることもある。トンネルに入る前に、ラップトップコンピュータは、ＦＭＩＰを使用して新たなＡＰに接続し、新たなＡＰへのハンドオーバを実行しようとしていることをＨＡに通知する。ＨＡは、ラップトップの新たなアクセスリンクをテストするように始動（トリガ）され、新たなＡＰにテストパケットを送信する。
【００１７】
このとき、ラップトップコンピュータはトンネル内（すなわち、無線通信不能領域）に存在しており、新たなＡＰに接続することは不可能である。したがって、ラップトップコンピュータが新たなＡＰにおける接続を確立するまで、テストパケットは新たなＡＰにバッファされることになる。このバッファリングによってラップトップコンピュータにおけるテストパケットの受信に遅延が生じてしまい、テストパケットによるアクセスリンクの条件（ネットワーク条件）の測定が、不正確なものとなってしまうという問題がある。
【００１８】
さらに、電車内に位置する多数のＭＮが同一のＨＡによって管理されている場合には、ＨＡは、電車内の多数のＭＮからほぼ同時に多数のＩＣＭＰエコーリクエストメッセージを受信することになり、多数のＩＣＭＰエコーリクエストメッセージの処理によって、ＨＡのプロセッサの負荷が瞬間的に大幅に増大してしまうことになる。
【００１９】
しかしながら、特許文献１に記載の技術によれば、各サイズに関して十分な数のテストパケットが送出される場合に、これらのパケットの少なくとも１つは、待機処理を受けずにネットワークを通り抜けると仮定する必要がある。このパケットが最小往復時間を記録することになる。このため、たくさんの量（十分な量）のテストパケットが送出される必要があるとともに、あくまでもパケットの最小往復時間は仮定を前提としており、正確性に欠ける結果が得られる可能性もある。
【００２０】
しかしながら、特許文献２に記載の技術によれば、受信者が大量のプローブパケットを受信することは効率的とは言えず、ネットワークにとってはあまり好ましいことではない。送信者に向けて送信されるデータパケットを受信者が受信することによって、このようなアクセス条件のテストが開始されるようにしてもよい。この場合には、プローブパケットが送信される必要はなくなる。
【００２１】
本発明は、上記の課題を解決するため、パケット交換型データ通信ネットワークにおける２つのノード間のパケット伝送に発生する伝送遅延をより正確に算出したり、パケットの伝送条件（ネットワーク条件）を調べたりすることが可能なネットワークノード及び移動端末を提供することを目的とする。
【課題を解決するための手段】
【００２２】
上記の目的を達成するため、本発明のネットワークノードは、ネットワークに接続可能なネットワークノードであって、
前記ネットワークからパケットを受信するパケット受信手段と、
前記パケットをバッファするパケットバッファ手段と、
前記パケットバッファ手段にバッファされている前記パケットの転送開始を判断する転送開始判断手段と、
前記転送開始と判断された前記パケットバッファ手段にバッファされている前記パケットを、特定のアドレスに送信するパケット送信手段と、
前記パケットバッファ手段に前記パケットがバッファされていたバッファリング時間を計算するバッファリング時間計算手段と、
前記バッファリング時間計算手段で計算された前記バッファリング時間をバッファリング時間情報として、前記パケット送信手段によって送信される前記パケットの転送先に送信するバッファリング時間情報送信手段とを、
有する。
【００２３】
さらに、本発明のネットワークノードは、上記の構成に加えて、計時機能を有する計時手段と、
前記特定のアドレスあての前記パケットに関しては、前記特定のアドレスあての前記パケットに関連付けて前記計時手段から得られるそのときの時刻をバッファ時刻情報として記憶するとともに、前記パケットバッファ手段に前記パケットをバッファさせるバッファ時間処理部とを有し、
前記バッファリング時間計算手段が、前記転送開始判断手段で前記パケットの転送開始が決定された場合に、前記計時手段から得られる現在時刻と前記バッファ時刻情報とに基づいて、前記パケットがバッファされていた前記バッファリング時間を示すバッファリング時間情報を計算するように構成されている。
【００２４】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記パケットの転送先が移動端末であって、前記移動端末がハンドオーバ処理を行っている最中に前記ネットワーク内で伝送する前記移動端末あての前記パケットのバッファ要求を受けるバッファ要求受信手段と、
前記移動端末の前記ハンドオーバ処理中に前記移動端末あての前記パケットを前記パケットバッファ手段にバッファするバッファ制御手段とを有し、
前記転送開始判断手段が、前記移動端末の前記ハンドオーバの完了を検出した場合に、前記移動端末への前記パケットの転送開始を判断するように構成されている。
【００２５】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記パケットの転送先の端末から前記バッファリング時間の要求を受けた場合に、要求を行った前記端末あての前記パケットに係る前記バッファリング時間を前記端末に提供するように構成されている。
【００２６】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記バッファリング時間情報送信手段が、前記パケットのレイヤ２フレームの末尾、又は、前記パケットに付加されたトンネルヘッダに前記バッファリング時間情報を付加して送信するように構成されている。
【００２７】
また、上記の目的を達成するため、本発明のネットワークノードは、ネットワークに接続可能なネットワークノードであって、
前記ネットワークで伝送されるパケットを転送するパケット転送手段と、
特定の端末に関するフィルタルールを格納するフィルタルール格納手段と、
前記フィルタルール格納手段に格納されている前記フィルタルールの条件に一致した前記パケットを前記パケット転送手段で受信した場合に、前記条件に一致した前記フィルタルールに関連付けられている前記特定の端末までのネットワーク条件を調べるための処理を行うテスト始動手段とを、
有する。
【００２８】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記パケット転送手段が、前記パケットを前記特定の端末に転送した場合に、前記パケット転送手段で受信した前記パケットを複製して複製パケットを作成する複製パケット作成手段と、
前記パケット転送手段で転送した前記パケットが通るパスとは異なるパスを経由するよう、前記複製パケットを前記特定の端末に送信する複製パケット送信手段とを、
有する。
【００２９】
さらに、本発明のネットワークノードは、上記の構成に加えて、計時機能を有する計時手段と、
前記ネットワークに送出する際、前記計時手段から得られる現在時刻を前記パケット及び前記複製パケットに付加するタイムスタンプ手段とを、
有する。
【００３０】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記テスト手段が、前記特定の端末までのネットワーク条件を調べるためのテストパケットを定期的に送信するように構成されている。
【００３１】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記テスト手段が、前記特定の端末までの複数のパスのそれぞれに複数のサイズのテストパケットを送信するように構成されている。
【００３２】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記パケット転送手段で転送する前記パケットをバッファするパケットバッファ手段を有し、
前記テスト手段が、前記パケットバッファ手段にバッファされた前記パケットの転送によって、前記特定の端末までのネットワーク条件を調べるための処理を行うように構成されている。
【００３３】
また、上記の目的を達成するため、本発明の移動端末は、移動しながらネットワークと通信を行うことが可能な移動端末であって、
ネットワークに接続してパケットの送受信を行うパケット送受信手段と、
ネットワークにおける当該移動端末あての前記パケットのバッファリングを前記ネットワークに要求するバッファリング要求手段と、
前記バッファリング要求手段で要求した前記バッファリングによって前記パケットがバッファされていたバッファリング時間の記録を前記ネットワークに要求するバッファリング時間記録要求手段と、
前記ネットワークでバッファされていた前記パケットの受信に伴って、前記パケットの前記バッファリング時間を前記ネットワークから受信するバッファリング時間受信手段とを、
有する。
【００３４】
さらに、本発明の移動端末は、上記の構成に加えて、前記ネットワークでバッファされていた前記パケットを転送した任意のパケット転送装置から、前記パケットが送出されたパケット送出時刻を取得するパケット送出時刻取得手段と、
前記ネットワークでバッファされていた前記パケットを前記パケット送受信手段で受信したパケット受信時刻を取得するパケット受信時刻取得手段と、
前記パケット受信時刻から前記パケット送出時刻を減算した値から、前記パケットの前記バッファリング時間を更に減算した結果得られる値を、前記任意のパケット転送装置から当該移動端末へのパケット伝送に要する実効待ち時間とする実効待ち時間算出手段とを、
有する。
【００３５】
さらに、本発明の移動端末は、上記の構成に加えて、前記任意のパケット転送装置が前記パケット送出時刻を取得するために参照している時計と、当該移動端末が前記パケット受信時刻を取得するために参照している時計とを同期させる同期制御手段を有する。
【００３６】
さらに、本発明の移動端末は、上記の構成に加えて、前記ネットワークに接続可能な複数のインタフェースと、
前記実効待ち時間算出手段によって算出された前記複数のインタフェースのそれぞれの前記実効待ち時間に基づいて、前記複数のインタフェースのそれぞれと前記任意のパケット転送装置との間の各リンクのアクセス条件を取得するアクセス条件取得手段とを、
有する。
【発明の効果】
【００３７】
本発明のネットワークノード及び移動端末は上記の構成を有しており、２つのノード間のパケット伝送で発生する伝送遅延をより正確に算出したり、パケットの伝送条件（ネットワーク条件）を調べたりすることが可能となる。
【発明を実施するための最良の形態】
【００３８】
以下、図面を参照しながら、本発明の実施の形態について説明する。なお、以下の説明では、本発明を説明するために、特定の番号や時間、構造、プロトコル名、及びその他のパラメータなどが詳細に説明される場合があるが、本明細書で用いられている特定の条件は、本発明を説明するために用いられているにすぎず、本発明を限定するものではない。また、以下では、本発明が不要に理解しづらくならないように、例えばブロックダイアグラムには周知のコンポーネントやモジュールが図示されている。
【００３９】
本発明は、例えば、バッファリングノードのキャッシュにどのくらいの期間だけパケットがバッファされていたのか（バッファリング時間）をバッファリングノード自身が示すように構成されている。これにより、ノードは、この情報（パケットのバッファリング時間に関する情報）を使用して、バッファリングノードを経由して伝送されるパケットの待ち時間（レイテンシ）をより正確に計算することが可能となる。
【００４０】
なお、本明細書では、“バッファリングノード”という用語は、バッファリングサービス（パケットバッファリングノードにおけるパケットのバッファリング）を要求したノード（要求ノード：requesting node）のパケットをバッファする通信ネットワークノードを表している。
【００４１】
また、要求ノードが、パケットがバッファされた時間（バッファリング時間）を示すようにバッファリングノードに対して更に依頼した場合には、バッファリングノードは、パケットのバッファリング時間に関する情報を要求ノードに通知する。
【００４２】
なお、本明細書では、主にアクセスポイント（ＡＰ：Access Point）がバッファリングノードとして動作する場合について説明するが、データを格納する機能を有する任意の通信装置がバッファリングノードとして動作可能である。
【００４３】
また、本明細書では、“要求ノード”という用語は、要求ノードあてのパケットをバッファするようにバッファリングノードに対して要求する通信ネットワークノードを表している。上述のように、要求ノードは、バッファリングノードに対して、バッファリングノードでパケットがバッファされていたバッファリング時間に関する情報を提供するように要求することも可能である。
【００４４】
なお、本明細書では、主にモバイルノード（ＭＮ：Mobile Node、移動端末）が要求ノードとして動作する場合について説明するが、要求ノードは、モバイルノード又は固定ノードのいずれであってもよい。
【００４５】
さらに、本明細書では、“時間情報（timing information）”という用語は、バッファリングノードにおけるパケットのバッファに要した時間（すなわち、バッファリング時間）を表している。時間情報は、例えば、要求ノードに転送される前にデータパケットに付加される。
【００４６】
図１には、本発明の実施の形態におけるバッファリングノード１０の構成の一例が図示されている。図１に図示されているバッファリングノード１０は、１つ又は複数のネットワークインタフェース１１、バッファ時間プロセッサ１２、内部クロック１３、データキャッシュ１４を有している。
【００４７】
ネットワークインタフェース１１は、バッファリングノード１０が任意の通信媒体を介して別のノードと通信を行うために必要なあらゆるハードウェア又はソフトウェアを包含する機能ブロックである。
【００４８】
なお、当業者に周知の用語を使用すると、ネットワークインタフェース１１は、レイヤ１（物理層）及びレイヤ２（データリンク層）の通信コンポーネント、ファームウェア、ドライバ、通信プロトコルを表している。また、図１には、ネットワークインタフェース１１が１つのみ図示されているが、バッファリングノード１０は、１つ又は複数のネットワークインタフェース１１を有することが可能である。また、ネットワークインタフェース１１は、シグナル／データパス１１０を通じて、バッファ時間プロセッサ１２にパケットを渡すことが可能である。
【００４９】
また、内部クロック１３は計時機能を有しており、バッファ時間プロセッサ１２が特定のパケットのバッファリング時間を計算する際に使用されるクロック信号（例えば、現在時刻を示す信号）を生成することが可能である。内部クロック１３で生成されたクロック信号は、シグナル／データパス１３０を通じて、バッファ時間プロセッサ１２に渡される。
【００５０】
また、データキャッシュ１４は、バッファリングノード１０におけるバッファリングサービスを要求した特定の要求ノードに関連するデータパケットをバッファする際に、そのバッファされるデータパケットのキャッシュを行う機能を有している。
【００５１】
なお、これらのデータパケットには、データキャッシュ１４にパケットが格納された際の時刻を反映する情報が任意の形式で付加できることが望ましい。時刻の情報が付加されたデータパケットは、シグナル／データパス１４０を通じてバッファ時間プロセッサ１２に送られ、処理される。
【００５２】
また、本発明では、バッファリングノード１０は、バッファ時間プロセッサ１２を有している。このバッファ時間プロセッサ１２は、バッファリングノード１０のデータキャッシュ１４にバッファされていたデータパケットのバッファリング時間を計算する機能を有している。
【００５３】
なお、バッファ時間プロセッサ１２は、例えば、現在時刻と、バッファされたデータパケットがデータキャッシュ１４に格納された時刻との時間の差分を判断し、この時間の差分から、データパケットがデータキャッシュ１４に滞在していた時間（バッファリング時間）を把握することが可能である。
【００５４】
また、バッファ時間プロセッサ１２は、シグナル／データパス１２０を通じて、内部クロック１３が示す現在時刻を参照することが可能となる。さらに、バッファ時間プロセッサ１２は、シグナル／データパス１２１を通じて、内部クロック１３から取得した現在時刻を付加したデータパケットをデータキャッシュ１４に格納することが可能となる。
【００５５】
また、バッファ時間プロセッサ１２は、シグナル／データパス１２２を通じて、ネットワークインタフェース１１に時間情報を送信することが可能である。このとき、バッファ時間プロセッサ１２は、時間情報を要求ノード（バッファリングに関する情報（バッファリング時間など）を把握しようとしている要求ノード）に順番に発送する。
【００５６】
また、本発明では、要求ノードがバッファリングノード１０に対して、バッファリングノード１０におけるネットワーク条件のテストを支援してくれるように依頼することも可能である。例えば、コレスポンデントノード（ＣＮ）との間で継続中の通信フローがバッファリングノード１０でサポートされている場合には、要求ノードであるモバイルノードは、バッファリングノード１０におけるネットワーク条件を把握する必要がある。
【００５７】
ここでは、バッファリングノード１０は、ＭＮがハンドオフを行った後に、ＭＮのトラフィックフローの処理を行うＡＰ（アクセスポイント）とする。なお、ＭＮは、例えば、ＩＥＥＥ（Institute of Electrical and Electronics Engineers, Inc.）８０２．２１で規定されている情報サービスプロバイダを使用して、ＡＰの位置を特定することが可能であるが、この方法に限定されるものではない。
【００５８】
ハンドオフ処理の前に、ＭＮは、パケットのバッファリングを要求するとともに、バッファリング時間記録要求メッセージ（record buffering time message）と呼ばれるメッセージをＡＰに送信して、ＭＮに発送されるパケットのバッファリング時間の記録を行うように指示する。なお、このパケットのバッファリング要求とバッファリング時間の記録要求は個別のメッセージで行われてもよく、また、１つのメッセージにまとめられてもよい。以下では、１つのメッセージにまとめた場合について説明する。
【００５９】
なお、バッファリング時間記録要求メッセージには、例えばＭＮの識別情報や、ＡＰに対してＭＮあてのパケットのバッファリング時間を記録するように要求する情報などが含まれているが、これらに限定されるものではない。
【００６０】
ＡＰがＭＮからの要求を承認した後、ＭＮに発送されるべき受信パケットは、一時的にバッファされるとともに、各パケットには、ＡＰがこのパケットを受信した時刻が付加される。そして、ＭＮがＡＰへのハンドオフ処理を完了すると、ＡＰは、バッファリングされたパケットを時間情報（バッファリング情報）と共にＭＮに転送する。
【００６１】
しかしながら、この場合には、後で利用する意志がないにもかかわらず、悪意あるＭＮが、バッファリング時間記録要求メッセージを用いて、ＭＮあてのパケットを連続してバッファするように依頼することが可能である。これにより、ＡＰに対するサービス不能攻撃（ＤｏＳ（Denial of Service）攻撃）が引き起こされることになり、その結果、ＡＰでのバッファリングサービスを必要とする別のノードが、ＡＰのバッファの過負荷によって、サービスを受けられなくなる可能性がある。
【００６２】
こうした攻撃を最低限に抑えるために、ＭＮ及びＡＰは、バッファリング時間記録要求メッセージの送受信の段階で、バッファされるパケット量に関する交渉を行うことが可能である。
【００６３】
なお、こうした交渉の段階において、例えば、ＭＮが、特定の送信元アドレスからのパケットのバッファを行うようにＡＰに通知することも可能である。また、例えば、ＡＰがＭＮに対して、ＭＮあてのパケットのバッファリングに所定の時間長を割り当て、この時間長が経過する前にＭＮがバッファリングされたパケットを取得しなかった場合には、バッファリングされたパケットがＡＰのキャッシュから削除されるようにすることも可能である。
【００６４】
さらには、バッファリングされるデータのうち、遅延を把握するための待ち時間（レイテンシ）の計測などに用いられているパケットにのみバッファリング時間を計測、付加することも可能である。これは、特定のテストメッセージの特定フィールドをチェックすることや、バッファリング時間の計測結果を書き込むことがあらかじめ決められているメッセージ（例えば、バッファリング時間の計測結果を書き込むためのフィールドが用意されているメッセージ）を受信することなどによって判別する。
【００６５】
また、図２Ａ及び図２Ｂには、バッファリングノード１０のバッファ時間プロセッサ１２の機能を用いて、パケットがバッファリングノード１０のキャッシュにどのくらいの時間だけ格納されていたかを計算する本発明の好適な方法が示されている。図２Ａは、本発明の実施の形態におけるバッファリングノードのバッファ時間プロセッサによるパケットバッファリング処理の一例を示すフローチャートであり、図２Ｂは、本発明の実施の形態におけるバッファリングノードのバッファ時間プロセッサによるパケット転送処理の一例を示すフローチャートである。
【００６６】
図２Ａにおいて、バッファ時間プロセッサ１２は、ＭＮ（要求ノード）からパケットのバッファ要求（バッファリング時間記録要求メッセージ）を受信すると（ステップＳ２００）、受信するすべてのパケットのチェック処理を行って、パケットがＭＮあてか否かの確認を行う（ステップＳ２０１）。
【００６７】
受信したパケットがＭＮあてではない場合には、バッファ時間プロセッサ１２は、パケットに関して通常の処理（通常のパケット転送処理）を行い、再び、次に受信するパケットに対してチェック処理を継続する（ステップＳ２０２）。
【００６８】
一方、パケットがＭＮあてであることが特定された場合には、バッファ時間プロセッサ１２は、内部クロック１３から現在時刻を取得して、この現在時刻の値をパケットに付加する（ステップＳ２０３）。そして、バッファ時間プロセッサ１２は、現在時刻の情報が付加されたパケットをデータキャッシュ１４に格納する処理を行う（ステップＳ２０４）。
【００６９】
なお、ステップＳ２０１でＭＮあてであることが特定されたパケットすべてに対して、ステップＳ２０３で時刻情報を付加する必要はない。例えば、バッファ時間プロセッサ１２は、特定のパケット又は任意のパケットを選択してテストパケットとし、そのテストパケットに対してのみ時刻情報を付加してもよい。
【００７０】
また、図２Ｂにおいて、バッファ時間プロセッサ１２は、ＭＮ（要求ノード）がＡＰへの接続に成功したという情報（トリガ）を受信して、ＭＮの接続を確認する（ステップＳ２１０）。なお、このトリガは、例えば、ネットワークインタフェース１１からバッファ時間プロセッサ１２に送信されるシグナル（ＭＮがＡＰの通信可能エリアに移動したことをバッファ時間プロセッサ１２に通知するシグナル）であるが、これに限定されるものではない。
【００７１】
バッファ時間プロセッサ１２は、トリガを受けると、バッファされたＭＮあてのパケットをデータキャッシュ１４から取得する処理を行う（ステップＳ２１１）。そして、バッファ時間プロセッサ１２は、内部クロック１３から現在時刻を取得するとともに、バッファリングされたパケットに付加されている情報（格納された時刻）を抽出する（ステップＳ２１２）。
【００７２】
次に、バッファ時間プロセッサ１２は、現在時刻と、パケットから抽出された時刻との差分を用いて、データキャッシュ１４にパケットがバッファされていたバッファリング時間を計算する（ステップＳ２１３）。なお、現在時刻と、パケットから抽出された時刻との差分をそのままをバッファリング時間としてもよく、あるいは、通常のパケット転送処理に要する時間（平均時間）を減算して、バッファによって発生した遅延時間をバッファリング時間とすることも可能である。また、ここでは、バッファリングノード１０がバッファリング時間（すなわち、パケットが送出される時刻からパケットが格納された時刻を減算した時間）を計算しているが、この計算を行わずに、後述のステップＳ２１４でパケットが送出される時刻及びパケットが格納された時刻の両方をパケットに付加してＭＮに送信してもよい。この場合、ＭＮが、パケットが送出される時刻及びパケットが格納された時刻からバッファリング時間の計算を行うことが可能である。
【００７３】
バッファ時間プロセッサ１２は、ＭＮに発送されるバッファされたパケットのバッファリング時間を計算し終えると、この計算されたバッファリング時間を時間情報として、バッファされたパケットに付加する（ステップＳ２１４）。そして、バッファ時間プロセッサ１２は、時間情報が付加されたパケットをネットワークインタフェース１１経由でＭＮに転送し、その結果、パケットはＭＮに発送される（ステップＳ２１５）。
【００７４】
なお、ＡＰがＭＮ３０のパケットに時間情報を付加できるようにする好適な方法としては、ＭＮ３０にパケットをトンネルして、トンネルヘッダのオプションに時間情報を挿入することが挙げられる。このトンネルを用いた方法によって、ＡＰは、パケットを改変することなく、パケットに追加ヘッダを付加することが可能となる。これは、例えば、ＩＰセキュリティ（ＩＰＳｅｃ）などの任意の暗号化スキームによってパケットが保護されている場合に有用である。
【００７５】
また、別の方法として、ＡＰが、レイヤ２（データリンク層）の通信プロトコルを使用してパケットをＭＮ３０に発送し、レイヤ２フレームの後ろに時間情報を付加することも可能である。レイヤ２フレームの後ろに時間情報を付加することによって、時間情報の付加が、レイヤ２フレームのパケットのチェックサム計算によるチェックの妨げにならないようにすることが可能となる。
【００７６】
また、ＭＮ３０あてのパケットが暗号化されていない場合には、ＡＰは、パケットのヘッダのオプションやトレーラ（ペイロード部に相当）に時間情報を付加することが可能である。
【００７７】
また、ＩＰセキュリティ（ＩＰＳｅｃ）などの暗号化技術が使用されており、悪意ある攻撃者からパケットが保護されている場合には、ＡＰは、パケットの一部分（ＩＰＳｅｃによって保護されていない部分）を探索して、時間情報を含むオプションを付加することが可能である。
【００７８】
例えば、パケットはＩＰＳｅｃの認証ヘッダ（ＡＨ：Authentication Header）方法によってのみ保護されている場合がある。この場合は、パケットのヘッダ部分が保護されているため、ヘッダに任意の情報を挿入するとＭＮによるパケットの認証チェックが困難になってしまうので、ＡＰは、時間情報のオプションをヘッダに挿入することが不可能である。したがって、この状況では、ＡＰは、パケットのトレーラに時間情報のオプションを挿入することが可能である。
【００７９】
また、逆も同様であり、ＭＮ３０がＩＰＳｅｃのＥＳＰ（Encapsulating Security Payload）のみを使用している場合には、パケットのデータ部分が保護されているので、ＡＰは、パケットのヘッダに時間情報のオプションを付加することが可能である。
【００８０】
また、図３には、本発明の実施の形態におけるネットワーク構成の一例が図示されている。図３に図示されているネットワーク構成において、モバイルノード（ＭＮ）３０は、ＭＮ３０あてのパケットのバッファリングを開始するようにバッファリングノードに通知することが可能な通信ノードである。
【００８１】
ＭＮ３０は、リンク３１０ａ、３１１ｂを通じてインターネット３３への接続を実現するために、ＡＰ（アクセスポイント）に接続を行う。なお、ＭＮ３０は、ＩＥＥＥ８０２．１ｘの技術を用いてＡＰに接続することが可能であるが、これに限定されるものではない。
【００８２】
さらに、このネットワーク構成において、ＡＰ１０ａ及びＡＰ１０ｂはルータとしても機能すると仮定し、ＭＮ３０は、アクセスシステム３１ａ、３１ｂのそれぞれの最初のホップルータとしてＡＰ１０ａ及びＡＰ１０ｂに接続することが可能である。
【００８３】
なお、各アクセスシステム３１ａ、３１ｂにおけるネットワーク構成で使用されているリンクレイヤ技術として、例えばＩＥＥＥ８０２．１１やブルートゥース（登録商標）などを用いることが可能であるが、これらに限定されるものではない。
【００８４】
さらに、ＡＰ１０ａ及びＡＰ１０は、ＭＮ３０にバッファリングサービスを提供するという追加機能を有しているバッファリングノードである。したがって、ＭＮ３０は、ＡＰ１０ａ及びＡＰ１０に対して、ＭＮ３０あてのパケットをＡＰ１０ａ及びＡＰ１０ｂでバッファするように要求することが可能となる。なお、バッファされるべきパケットは、例えば、ＭＮ３０を管理するホームエージェント（ＨＡ：Home Agent）３４から送信されるパケットであるが、これに限定されるものではない。
【００８５】
このネットワーク構成において、ＭＮ３０がアクセスシステム３１ａからアクセスシステム３１ｂに移動しているとする。この移動によって、ＭＮ３０が接続されているＡＰは、ＡＰ１０ａからＡＰ１０ｂに変更される。このようなハンドオーバ処理が実行される際に、ファストモバイルＩＰ（ＦＭＩＰ：Fast Mobile IP）の使用が可能である。
【００８６】
ここで、ＦＭＩＰが使用される場合について考える。まず、ＭＮ３０がＡＰ１０ａに接続されており、ＭＮ３０は、ＡＰ１０ａによって管理されているプレフィックスを使用して、プライマリ気付アドレス（ＣｏＡ：Care-of address）を構成しているとする。
【００８７】
なお、ＡＰ１０ａはＭＮ３０に対して、例えば、ＡＰ１０ｂのＩＰアドレスやＡＰ１０ｂで管理されているプレフィックスなどのＡＰ１０ｂに関する情報を通知（アドバタイズ）するが、これらの情報に限定されるものではない。また、ＡＰ１０ａがＭＮ３０に情報を通知する方法としては、例えばルータアドバタイズメント（ＲＡ：Router Advertisement）の使用が挙げられるが、これに限定されるものではない。
【００８８】
ここで、ＭＮ３０は、ＲＡ内に挿入されているＡＰ１０ｂのプレフィックス情報を使用して、ＮＣｏＡ（New Care-of address：新たな気付アドレス）を構成し、ファストバインディングアップデート（ＦＢＵ：Fast Binding Update）メッセージをＡＰ１０ａに送信する。
【００８９】
なお、ＦＢＵにはＭＮ３０のＰＣｏＡ（Previous Care-of address：以前の気付アドレス）とバッファ時間記録要求オプション（Record Buffer Time option）が含まれていることが望ましいが、これらに限定されるものではない。レコードバッファ時間オプションは、ＭＮ３０に送信されるパケットのバッファリングに加えて、ＭＮ３０がＡＰ１０ｂに対してパケットのバッファリング時間を示すように要求したことを、ＡＰ１０ａに通知するためのものである。
【００９０】
ＡＰ１０ａがＭＮ３０からＦＢＵを受信した場合、ＡＰ１０ａはハンドオーバイニシエート（ＨＩ：Handover Initiate）メッセージを生成して、ＡＰ１０ｂに発送する。なお、ＨＩメッセージには、レコードバッファ時間オプションに加えて、ＭＮ３０のＰＣｏＡ及びＮＣｏＡ、ＭＮ３０に送信されるパケットのバッファを行うようにＡＰ１０ｂに指示するフラグ（Ｕフラグ）が含まれていることが望ましいが、上述の情報に限定されるものではない。なお、ＡＰ１０ｂはＨＩメッセージの処理に成功した場合、ＡＰ１０ａに対してアクノレッジメントメッセージ（ＨＡｃｋメッセージ）を返信してもよい。
【００９１】
ＡＰ１０ｂは、ＦＢＡｃｋ（Fast Binding Acknowledgement）メッセージをＭＮ３０に返信して、ＦＢＵの処理に成功した旨をＭＮ３０に通知する。この時点で、ＭＮ３０は、ＡＰ１０ａとの接続を切断する前であっても、ＭＮ３０のＮＣｏＡをＨＡ３４に通知する処理を行えるようになる。なお、ＭＮ３０は、ＡＰ１０ａとの接続を切断する直前にＮＣｏＡを含むＢＵをＨＡ３４に送信することが望ましい。
【００９２】
ＨＡ３４は、ＭＮ３０のＮＣｏＡの登録（関連付け）に成功すると、ＭＮ３０あてのパケットをＡＰ１０ｂに発送し始める。ＡＰ１０ｂは、ＭＮ３０あてのパケットを受信すると、バッファされるパケットに関して、時間情報を計算する上述の方法を実行する。すなわち、ＭＮ３０がＡＰ１０ｂとの接続に成功した後、ＡＰ１０ｂは、バッファされているＭＮ３０あてのパケットを時間情報と共にＭＮ３０に転送する。
【００９３】
このとき、ＡＰ１０ｂはレイヤ２の通信プロトコルによって、バッファされていたパケットをＭＮ３０に転送するとともに、レイヤ２フレームの後ろに時間情報を付加することが可能である。
【００９４】
また、別の方法では、ＭＮ３０は、ＡＰ１０ａに対して、ＭＮ３０あてのパケットのバッファを依頼する一方、ＡＰ１０ｂの通信エリアに移動してＡＰ１０ｂへの接続を行う。そして、ＭＮ３０がＡＰ１０ｂの接続に成功した場合には、ＭＮ３０は、ＡＰ１０ｂを経由してＡＰ１０ａにＦＢＵメッセージを送信し、ＡＰ１０ａに対して、バッファされているパケットをＭＮ３０のＮＣｏＡに転送し始めるように通知する。この結果、ＡＰ１０ａは、バッファリングされているＭＮ３０あてのパケットをトンネルして、トンネルヘッダのオプションとして時間情報を挿入することが可能となる。
【００９５】
なお、さらに、ＨＩメッセージに、ＡＰがＭＮに関する時間情報の計算を開始すべきときを示すオプションが含まれるようにしてもよい。例えば、ＭＮ３０は、ＭＮ３０がＡＰとのレイヤ２の接続を失ったことをＡＰが検出した時点で、時間情報の計算を開始するようにＡＰに依頼することが可能である。
【００９６】
また、別の方法として、ＭＮ３０は、ＭＮ３０あてのデータが５メガバイトを超えてキャッシュされた場合に時間情報の計算を開始するようにＡＰに要求することも可能である。さらに別の方法として、ＨＡ３４がＭＮ３０に関連するバッファリングノードとして機能し、ＨＡ３４が上述のような時間情報の計算を実行することも可能である。
【００９７】
本発明の実施の形態では、ＭＮ３０は、それぞれが異なるアクセスシステムに接続されている２つのインタフェースを有している。ＭＮ３０のインタフェースの一方は、第３世代セルラ（３Ｇ）ネットワークに接続されており、もう一方は、ワイヤレスネットワーク（Ｗｉ−Ｍａｘ）に接続されている。
【００９８】
ＭＮ３０は、コレスポンデントノード（ＣＮ）において複数のバインディングエントリを生成する。すなわち、ＭＮ３０は、ＣＮにおいて、３Ｇネットワークに接続されているＣｏＡとＭＮ３０のホームアドレス（ＨｏＡ）とをバインドする。また、ＨＡ３４では、ＭＮ３０のＨｏＡは、Ｗｉ−ＭａｘネットワークにおけるＭＮ３０のＣｏＡに関連付けられている。
【００９９】
ＭＮ３０のＷｉ−ＭａｘインタフェースがＷｉ−Ｍａｘネットワークに再接続する場合には、ＭＮ３０はＣＮに対して、ＣＮにおける両方のエントリを使用してテストパケットの発送を行うように依頼する。なお、ここでは、テストパケットには、ＣＮがパケットを送出した時刻が含まれるようにしているが、これに限定されるものではない。
【０１００】
同時に、ＭＮ３０はＨＡ３４に対して、ＭＮのパケットがバッファされた時間を示すように要求するバッファリング時間記録要求メッセージをＨＡ３４に送信する。ＣＮからのテストパケットがＨＡ３４に到着すると、ＨＡ３４は、パケットをバッファリングして、パケットがどれくらい長い時間だけバッファリングされるかを記録するためのタイマを始動する。
【０１０１】
そして、ＭＮ３０がそのＷｉ−Ｍａｘインタフェースにおける再接続に成功すると、ＭＮ３０は、ＨＡ３４にＢＵを送信して、そのＷｉ−Ｍａｘインタフェースがアクティブであることを示す。ここで、ＨＡ３４はＭＮ３０に対して、時間情報と共にテストパケットをトンネルすることが可能である。
【０１０２】
さらに、ＨＡ３４は、ＭＮ３０を管理する複数のホームエージェントによって構成されていてもよい。このようなネットワーク構成としては、ＭＮが複数のＨＡに属し、複数のホームアドレスを持っている場合に各ＨＡを連携させて使用する場合や、複数のＨＡが連携して１つの分散化されたＨＡとして動作するグローバルＨＡ−ＨＡシステムが挙げられる。グローバルＨＡ−ＨＡシステムでは、ＨＡは協同して地理的に分散されたオーバレイネットワークを形成し、エンドユーザにとって透過（トランスペアレント）な経路最適化が実現される。
【０１０３】
この複数のＨＡを使用するシナリオでは、ＭＮ３０のバッファリングキャッシュは複数のＨＡに分散する構成を取ることになる。あるＨＡのデータキャッシュがいっぱいになった場合、そのＨＡは次のＨＡにパケットを渡して、そのＨＡにおいてキャッシュされる。
また、このＨＡのキャッシュもいっぱいになると、このパケットを次のＨＡに渡す。そして、キャッシュがいっぱいではないＨＡにパケットが到達するか、すべてのＨＡのキャッシュがいっぱいでパケットが破棄されるまで、パケットは次のＨＡに渡される。
【０１０４】
また、次のＨＡへのパケット転送を開始する最初のＨＡが、転送するパケットに対して、パケットの時間情報を付加することが可能である。さらに、このＨＡが、すべてのＨＡに対して、このパケットに時間情報を付加しないように通知することも可能である。なお、すべてのＨＡに対して時間情報を付加しないように通知する方法としては、最初のＨＡがパケットにフラグを付加することが挙げられるが、これに限定されるものではない。このフラグは、パケットに時間情報を付加する中間ＨＡの機能を無効化（オーバライド）することを目的とする。ある場合においては、このオーバライド機能が有効となる。
【０１０５】
さらに別の方法として、ＭＮ３０がＡＰに対して時間情報の記録を開始する要求を送信する代わりに、この処理がＨＡによって開始されてもよい。この場合、ＨＡは、例えば指標を付けた特別なパケットをＭＮ３０に送信して、バッファリングサービスを提供しているパス上のノード（バッファリングノード）を探索することが可能である。そして、ＨＡは探索によって発見されたバッファリングノードと交渉を行って、バッファリングや、ＭＮに関連するパケットの時間情報の計算を行うことが可能である。
【０１０６】
ＭＮ３０は、パケットがＡＰにバッファされていた時間情報と共にバッファされていたパケットを受信すると、この時間情報を使用して、ＡＰとＨＡ３４との間の待ち時間（パケット転送に要する時間）をより正確に計算することが可能である。例えば、ＨＡ３４から送信されたパケットには、パケットが送信された時刻の情報が含まれている。ＭＮ３０は、ＡＰとＨＡ３４との間の待ち時間を計算する場合、パケットがＨＡ３４から送信された時刻と、ＭＮ３０がそのパケットを受信した時刻との差を計算する。この時間の差分は、ＨＡ３４からＭＮ３０までのパケット転送に要した時間であり、さらにこの時間の差分に基づいて、ＡＰとＨＡ３４との間の待ち時間がより正確に計算される。
【０１０７】
この待ち時間は、ＭＮのハンドオフ直後にバッファリングされていたパケットを受信し始めた時点で計測可能でありながら、バッファリングが終了した時点以降のより安定した通信時の待ち時間とほぼ一致するため、パケット転送が安定するまで待ってから待ち時間の測定を行うことに比べて、より迅速に測定値に基づいた判断（フィルタルールの決定など）が可能となる。
【０１０８】
さらに、待ち時間測定値を安定したパケット転送時の待ち時間により近づけるために、ＡＰ１０ａがパケットをＡＰ１０ｂに転送するタイミングを計測開始時刻、ＡＰ１０ｂがパケットをＭＮに送信するタイミングを測定終了時刻として、ＨＡ３４からＭＮ３０までのパケット転送に要した時間を算出することもできる。この場合、ＡＰ１０ａとＡＰ１０ｂの時刻は互いに同期している必要がある。
【０１０９】
さらに、モバイルノード（ＭＮ３０）が自身のホームエージェント（ＨＡ）にフィルタルールを設定することによって、ＨＡが、ＭＮとＨＡとの間のネットワーク条件のテストを行えるようにしてもよい。例えば、ＭＮ３０は、ＭＮ３０への様々なパスを経由してテストパケットを送信するようＨＡに依頼する特別なフィルタルールを設定することが可能である。
【０１１０】
このＨＡにフィルタルールを設定する方法は、Ｍｏｎａｍｉ６のようなシナリオに特に有用である。Ｍｏｎａｍｉ６では、複数のインタフェースを有するＭＮは、コレスポンデントノード（ＣＮ）から送信されるフローに関連付けられるパスを決定する前に、各インタフェースの様々なネットワーク条件を把握する必要がある。
【０１１１】
このフィルタルールの設定では、ＨＡにおいてＭＮによる設定が行われるので、ＭＮはＨＡに要求を送信し続けることなく、テストを開始できるという利点がある。
【０１１２】
なお、以下では、“テスタノード”という用語によって、複数のテストパケットを受信ノードに送信することによってテストプログラムを開始し、受信ノードにおけるネットワーク条件のテストを行う通信ネットワークノードを表す。
【０１１３】
なお、ここでは、ホームエージェント（ＨＡ）がテスタノードである場合について説明するが、これに限定されるものではなく、テスタノードは、ここで説明されるテスト機能を始動できる能力を有することが可能な任意の通信装置によって実現可能である。
【０１１４】
図４には、テスタノード４０の好適な構成例が図示されている。図４に図示されているテスタノード４０は、１つ又は複数のネットワークインタフェース４１、フィルタルールプロセッサ４２、フィルタキャッシュ４３、テストパケット生成部４４を有している。
【０１１５】
ネットワークインタフェース４１は、テスタノード４０が任意の通信媒体を介して別のノードと通信を行うために必要なあらゆるハードウェア又はソフトウェアを包含する機能ブロックである。
【０１１６】
なお、当業者に周知の用語を使用すると、ネットワークインタフェース４１は、レイヤ１（物理層）及びレイヤ２（データリンク層）の通信コンポーネント、ファームウェア、ドライバ、通信プロトコルを表している。また、図４には、ネットワークインタフェース４１が１つのみ図示されているが、テスタノード４０は、１つ又は複数のネットワークインタフェース４１を有することが可能である。また、ネットワークインタフェース４１は、シグナル／データパス４１０を通じて、フィルタルールプロセッサ４２にパケットを渡すことが可能である。
【０１１７】
また、フィルタルールプロセッサ４２は、ＭＮで定義された様々なフィルタルールの処理を行う機能を有している。フィルタルールプロセッサ４２は、ネットワークインタフェース４１からパケットを受信すると、そのパケットに関連したフィルタルールを検索するためにフィルタキャッシュ４３にシグナルを送信する。
【０１１８】
フィルタキャッシュ４３に格納されているフィルタルールの参照の結果、ＭＮへの様々なパスのテストを行うことがパケットに関連するフィルタルールとして規定されている旨が分かった場合には、フィルタルールプロセッサ４２は、ＭＮへの様々なパスのテストに利用されるテストパケットの生成をテストパケット生成器４４に開始させる。
【０１１９】
さらに、ＭＮが生成したフィルタルールがフィルタルールプロセッサ４２で受信されると、フィルタキャッシュ４３に格納される。フィルタルールプロセッサ４２は、シグナル／データパス４２０を通じて、フィルタキャッシュ４３におけるフィルタルールの格納及び検索を行うことが可能である。
【０１２０】
また、フィルタルールプロセッサ４２は、シグナル／データパス４２１を通じて、テストパケット生成器４４にテストパケットの生成を開始させることが可能である。フィルタルールプロセッサ４２は、シグナル／データパス４２２を通じて、ＭＮ３０へのパケットの発送方法に関する指示を行うことが可能である。
【０１２１】
また、テストパケット生成器４４は、ＭＮへの様々なパスのネットワーク条件をテストするためにＭＮに送信される様々なテストパケットを生成する機能を有している。なお、テストパケットとして、任意のパケットを使用することが可能であるが、ＭＮに送信されるオリジナルのデータパケットをコピーしたものを使用することが望ましい。オリジナルのパケットが特定のパスを経由して送信されたものである場合には、オリジナルのパケットをコピーしたパケットを使用することにより、ＨＡとＭＮとの間のアクセスシステムでの実際のパケットに対する処理をテストすることが可能となる。
【０１２２】
テストパケット生成器４４は、シグナル／データパス４４０を通じて、生成したテストパケットをフィルタルールプロセッサ４２に渡して、ＭＮへの様々なパスのテストを開始することが可能である。
【０１２３】
また、フィルタキャッシュ４３には、テスタノードが関連するノードのフィルタルールが格納されている。なお、このフィルタルールには、ノードあてのパケットの発送方法に関する情報が含まれている。フィルタルールプロセッサ４２は、シグナル／データパス４３を通じて適切なフィルタルールを取得し、処理が行われる。
【０１２４】
本発明では、特別なフィルタルールが導入され、この特別なフィルタルールによって、ＨＡが、ＭＮへの様々なパスを通じて、テストパケットを送信することが可能となる。なお、このフィルタルールはＭＮによって定義され、例えば、バインディングアップデート（ＢＵ）メッセージによってＨＡに送信されるようにしてもよい。
【０１２５】
ＨＡは、このＢＵメッセージを処理し、ＢＵメッセージに含まれているフィルタルールをフィルタキャッシュ４３に格納する。なお、この特別なフィルタルールは、例えば、ＭＮへのフローがフィルタに一致しない（すなわち、適切なフィルタルールが見つからない）場合に、適用されるようにしてもよい。
【０１２６】
図５には、本発明の実施の形態における用いられるバインディングアップデートメッセージ（ＢＵメッセージ５０）のフォーマットの一例が図示されている。図５に図示されているＢＵメッセージ５０は、ＩＰｖ６ヘッダ５１、あて先オプションヘッダ５２、モビリティヘッダ５３、バインディングアップデートヘッダ５４、フィルタオプション５５、テストオプション５６を有している。
【０１２７】
ＩＰｖ６ヘッダ５１はパケットの先頭の４０オクテットであり、送信元アドレス及びあて先アドレス（それぞれ１２８ビット）、バージョン（４ビットのＩＰバージョン）、トラフィッククラス（８ビット、パケットの優先度）、フローラベル（２０ビット、ＱｏＳ管理用）、ペイロード長（１６ビット）、次ヘッダ（８ビット）、ホップリミット（８ビット、生存可能時間）が含まれている。
【０１２８】
また、ペイロードは、標準モードでは６４ｋバイトのサイズまでであるか、“ジャンボペイロード”オプションを有する場合にはより大きなサイズとなる。オプションが存在する場合、ＩＰｖ６ヘッダに続く次ヘッダフィールドによって、追加されたオプションヘッダが指定される。
【０１２９】
また、あて先オプションヘッダ５２は、パケットのあて先ノードによってのみ処理される必要がある付加的な情報を挿入するために使用される。この好適な例として、あて先オプションヘッダ５２には、ホームアドレスが挿入される。これにより、モバイルノードがホームから離れている状態であっても、モバイルノードのホームアドレスをその受信者に通知することが可能となる。
【０１３０】
また、モビリティヘッダ５３は、モバイルノード、コレスポンデントノード、ホームエージェントが、バインディングの作成や管理に関連するすべてのメッセージングを行う際に使用される拡張ヘッダである。モビリティヘッダ５３には、対象となる特定のモビリティメッセージを識別するモビリティヘッダのタイプ（８ビット）が含まれている。本発明の好適な実施例では、ＭＨタイプの値は、メッセージがバインディングアップデート（ＢＵ）メッセージであることを示す“５”に設定される。
【０１３１】
また、バインディングアップデートヘッダ５４には、モバイルノードが他のノードに新たな気付アドレスを自ら通知するために必要な情報が含まれている。
【０１３２】
また、フィルタオプション５５は、ＭＮ３０のユーザによって定義されたフィルタルールを伝送するために使用される。このフィルタルールによって、ＭＮ３０は、ＭＮ３０のフローをフィルタリングしているノードに、ＭＮ３０へのフローの発送方法に関する情報を指示することが可能となる。なお、本発明の好適な実施例としては、ＭＮ３０のフローをフィルタリングしているノードはＨＡ３４である。
【０１３３】
なお、本発明の実施の形態では、フィルタルールには、フィルタの識別情報、ＭＮ３０のＣｏＡ、ＣＮの送信元アドレスなどが含まれている場合について説明しているが、これらに限定されるものではない。
【０１３４】
また、本発明では、ＢＵ３０内に新たなオプション（テストオプション５６と呼ぶこともある）を導入する。ＭＮ３０はＨＡ３４に対して、テストオプション５６を使用して、ＨＡ３４に実行してもらいたいテストに関する情報を指示する。なお、テストオプション５６で指定可能なテストの種類としては、例えば、周期的なテスト、バッファリングのテスト、統計的なテストなど、いくつかのテスト方法が挙げられるが、これらに限定されるものではない。各テスト方法の詳細については、後述の実施の形態で説明する。
【０１３５】
ＨＡ３４は、ＭＮ３０からＢＵを受信すると、ＢＵの処理を行って、ＭＮ３０のバインディングエントリを生成する。このように、ＨＡ３４は、ＭＮ３０がＨＡ３４に対する正当な加入者であることを認証すると、ＭＮ３０のＨｏＡをＭＮ３０によって示されたＣｏＡに関連付ける。
【０１３６】
また、ＭＮ３０によって定義されるフィルタルールがＢＵ３０に含まれている場合には、ＨＡ３４は、フィルタキャッシュ４３にこれらのルールを格納する。
例えば、ＭＮ３０は、２つのＣｏＡを有している。ＣｏＡ１は、ＭＮ３０がＷｉ−Ｍａｘネットワークに接続されているインタフェースに関連付けられている。ＣｏＡ２は、ＭＮ３０が３Ｇネットワークに接続されているインタフェースに関連付けられている。
【０１３７】
ＭＮ３０は、ＨＡ３４で受信したパケットの送信元アドレスがＭＮ３０によって定義されたフィルタルール内に存在するいずれの送信元アドレスとも一致しない場合に、HA３４がパケットをＣｏＡ２に転送するフィルタルール（例えば、フィルタルール：ＦＩＤ１とする）を設定する。
【０１３８】
これにより、ＨＡ３４は、ＭＮ３０によって定義されたフィルタルールに一致しない送信元アドレスのパケットを受信すると、ＦＩＤ１をトリガ（始動）して、ＭＮ３０のＣｏＡ２にパケットを転送する。
【０１３９】
なお、ここでは、ＨＡ３４は、ＢＵにはテストオプション５６が更に含まれていることを発見する。このテストオプション５６は、ＨＡ３４に対してＭＮ３０によるネットワーク（Ｍ３０が接続されている様々なネットワーク）の条件のテストを支援するように通知するものである。
【０１４０】
例えば、ＭＮ３０は、テストオプション５６を設定して、ＦＩＤ１が始動された場合には、ＭＮ３０の別のインタフェースに向かうテストパケットの複製を設定するようにＨＡ３４に通知する。
【０１４１】
そして、ＨＡ３４がＦＩＤ１を始動すると、ＨＡ３４は、ＦＩＤ１に関するテストオプションを参照して、ＭＮのＣｏＡ１を経由して送信されるテストパケットの複製を生成する。これにより、ＭＮ３０はＨＡ３４に対して、テストメカニズムを始動するタイミングを指示することが可能となる。
【０１４２】
また、図６には、本発明の実施の形態におけるテスタノードが、特定のパケットがテストメカニズムのトリガであるか否かを決定する処理の一例が図示されている。
【０１４３】
図６において、フィルタルールプロセッサ４２は、ＭＮ３０あてのパケットを受信すると（ステップＳ６００）、パケットの識別情報（例えば、送信元アドレスなどのパケット内に含まれている任意の情報）がＭＮ３０によって定義されたフィルタルールのものと一致するか否かのチェック処理（ＦＩＤのチェック）を行う（ステップＳ６０１）。
【０１４４】
もし何らかのフィルタルールのものとの一致が見つかれば、フィルタルールプロセッサ４２は、そのフィルタルールの処理を行い、ＭＮ３０へのパケットの送信方法に関して、ネットワークインタフェース４１に通知する。
【０１４５】
一方、フィルタルールプロセッサ４２がこのパケットのフィルタルールを特定することができなかった場合には、フィルタルールプロセッサ４２は、ＭＮ３０への様々なパスのテストに用いられるテストパケットの生成をテストパケット生成器４４に開始させる（ステップＳ６０２）。なお、テストパケットはＭＮ３０あての任意のパケットでよいが、例えば、ＭＮ３０に送信されるオリジナルのデータパケットを複製したパケットや、ＭＮ３０に送信されるオリジナルのデータパケットと同一サイズのパケットであることが望ましい。さらには、上記オリジナルのデータパケットと同一サイズのバインディングリフレッシュリクエスト（ＢＲＲ：Binding Refresh Request）メッセージを使用し、テストパケットの送信によって、新たなネットワーク条件が反映されたＢＵメッセージやフィルタルールアップデートメッセージの送信をＭＮ３０に促すことも可能である。テストパケット生成器４４は、フィルタルールプロセッサ４２にテストパケットを送信する。
【０１４６】
そして、フィルタルールプロセッサ４２は、上述の時間情報を付加する方法に従って、オリジナルパケット及びテストパケット（オリジナルパケットを複製したパケット）にタイムスタンプを付加してから、ネットワークインタフェース４１に対して、様々なパスを経由するＭＮ３０へのパケットの送信方法に関する指示を行い、ＭＮ３０に向けてパケット送信が行われる（ステップＳ６０３）。
【０１４７】
なお、フィルタルールプロセッサ４２は、オリジナルパケット及び複製したパケットにタイムスタンプを付加せずに、オリジナルパケット及び複製したパケットをそれぞれＭＮ３０への様々なパスに分散して送信してもよい。これによって、ＭＮ３０は様々なパスのネットワーク条件を調べることができるようになる。また、テスタノードが、ＭＮ３０への様々なパスに同一タイミングでパケットの発送を行うことで、テスタノードからＭＮ３０までの各パスの伝送時間差を取得し、比較することができるようになる。
【０１４８】
また、ＭＮ３０がテストオプションを設定して、ＭＮ３０への様々なパスを通じてテストパケットを周期的に送信するようＨＡ３４に依頼することも可能である。この方法によれば、ＭＮ３０は、ある期間におけるより正確なネットワーク条件を取得して、ＭＮ３０へのアクセスパスの通常のアップデートを行うことができるようになるという利点がある。したがって、ＭＮ３０へのフローパスは、定期的にアップデートできるようになる。
【０１４９】
また、ＭＮ３０は、テストオプションを設定して、ＭＮ３０に発送されるパケットをバッファするようにＨＡ３４に通知し、テストプログラムを実行することも可能である。この方法では、ＨＡ３４が、テストパケットとしてＭＮ３０に発送される実際のパケットを使用することが可能である。ＭＮ３０への各パスに関して、ＨＡ３４は、これらのテストパケットをほぼ同時に送信する。この方法は、ＨＡ３４がテストパケット生成器４４を使用して、テスト用の複製パケットを生成する必要がないという利点がある。さらに、パケットがほぼ同時に送信されるので、パケットにタイムスタンプを付加する必要がないという利点がある。
【０１５０】
また、ＭＮ３０は、テストオプションを使用して、ＭＮ３０への各パスを経由してパケットを発送するようにＨＡ３４に指示することも可能である。
【０１５１】
例えば、コレスポンデントノード（ＣＮ）はＨＡ３４を経由して、ＭＮ３０あての一連のパケットを送信する。最初のパケットに関しては、ＨＡ３４は、ＭＮ３０への第１のパスを経由してＭＮ３０に発送する。また、２番目のパケットに関しては、ＨＡ３４は、ＭＮ３０への第２のパス（第１のパスとは異なる）を経由して発送し、ＭＮへのすべてのパスでテストが完了するまで、同様のパケット発送処理が行われる。この方法には、ＨＡ３４がテストパケット生成器４４を使用して、テスト用の複製パケットを生成する必要がないという利点がある。
【０１５２】
さらに、ＭＮ３０がテストオプションを設定して、ＭＮ３０が様々なすべてのパスの統計的な結果を得たい旨をＨＡ３４に通知することも可能である。例えば、ＨＡ３４は、このテストオプションを確認すると、ＭＮ３０への様々なパスを通じて様々なサイズのパケットを送信し、ＭＮ３０は、ＭＮ３０への各パスに関する統計的な情報を収集することができるようになる。この方法によって、ＭＮ３０は、ＨＡ３４との間の様々なパスに関する統計量を収集することができるようになる。
【０１５３】
上述の方法では、テストパケットはＨＡ３４によって生成されており、ＭＮ３０がテストパケットを受信している。その結果、ＭＮ３０は、受信したテストパケットから得られる情報に基づいて、テストが行われたＨＡ３４へのリンクのアクセス条件を判断することが可能となる。さらに、ＭＮ３０は、このようにして得られたアクセス条件を使用して、ＭＮ３０に発送される特定のフローにとって適切なリンクを選択できるようになる。そして、ＭＮ３０はフィルタをＨＡ３４に設定する。このフィルタは、例えば、ＭＮ３０とＨＡ３４との間における選択されたリンクを経由して特定のフローをＭＮ３０に発送するように、ＨＡ３４に対して指示するものである。
【０１５４】
また、ＭＮ３０がテストパケットの生成を行うことも可能である。この場合、ＭＮ３０は、例えば、フィルタリングバインディングメッセージをテストパケットとして使用し、ＨＡ３４への様々なパスを経由してフィルタリングバインディングメッセージを送信することも可能である。この方法では、フィルタリングバインディングメッセージには時間情報が含まれており、ＨＡ３４は、ＭＮ３０への特定のフローに関して最良の利用可能パスを特定することができるようになる。ＨＡ３４は、最良の利用可能なパスを特定すると、バインディングが成功したか否かを示すアクノレッジメントメッセージを返信する。この方法は、ＭＮ３０がどのフローをテストするかをＭＮ３０自身が選択できるようになるという利点がある。
【０１５５】
なお、上述の様々な実施例では、ＭＮ３０が、ＢＵ内にフィルタルール及びテストオプションを１つずつ設定する場合が説明されているが、ＭＮ３０は、ＢＵ内にフィルタルール及びテストオプションをそれぞれ複数設定することも可能である。
【０１５６】
また、本発明では、バッファリング及び／又はアクセス条件のテストの要求は、主にＭＮ３０によって行われる。以下、図７を参照しながら、こうした要求を行うＭＮ３０の機能による動作について説明する。図７には、本発明の実施の形態におけるモバイルノードが処理する様々なリクエストに関するＭＮの処理の一例が図示されている。
【０１５７】
ＭＮ３０では、トリガコマンドを受信すると、バッファリング及び／又はアクセス条件のテストの要求を行う機能（要求機能）が起動される（ステップＳ７００）。なお、トリガコマンドは、例えば、ユーザ入力やＭＮ３０に設定されているポリシの起動によって発生するが、これらに限定されるものではない。
【０１５８】
要求機能は、受信したトリガに基づいて、トリガがバッファリングのみを要求するもの（バッファトリガ）であるか否かを判断する（ステップＳ７０１）。トリガがバッファトリガである場合には、要求機能は、バッファ時間記録要求オプションを有するバッファ要求メッセージの生成を行う（ステップＳ７０２）。例えば、ＭＮ３０がＦＭＩＰを実行している場合には、バッファ要求メッセージとしてファストバインディングアップデート（ＦＢＵ）メッセージを利用することが可能である。また、ＭＮ３０が、ＨＡ３４に対してＭＮ３０のパケットのバッファリングを依頼している場合には、バッファ要求メッセージとしてバインディングアップデート（ＢＵ）メッセージを利用することが可能である。
【０１５９】
しかしながら、トリガがバッファトリガではない場合には、ＭＮ３０の要求機能は、そのトリガがアクセス条件のテストのみを実行することを要求するもの（テストトリガ）であるか否かをチェックする（ステップＳ７０３）。トリガがテストトリガである場合には、要求機能は、テストオプション５６を有するテスト要求メッセージの生成を行う（ステップＳ７０４）。
【０１６０】
なお、テストオプション５６によって、ＭＮ３０が要求するアクセス条件に関するテストの種類（例えば、アクセス条件に関する統計的なテストの実行を要求するのか、あるいはアクセス条件に関するテストの１回のみの実行を要求するのか）が表される。
【０１６１】
ステップＳ７０３において、そのトリガがテストトリガではない場合には、要求機能は、そのトリガがバッファリング及びアクセス条件のテストの両方を要求するもの（テスト及びバッファトリガ）であるか否かをチェックする（ステップＳ７０５）。トリガがテスト及びバッファトリガである場合には、要求機能は、バッファ時間記録要求オプション及びテストオプション５６の両方を含む要求メッセージの生成処理を行う（ステップＳ７０６）。
【０１６２】
例えば、ＭＮ３０は、ＡＰ１０ａに接続されている状態で、ＡＰ１０ｂとの通信を行っているが、ＡＰ１０ｂが提供している無線通信可能領域に、これから移動しようとしているとする。ＭＮ３０は、ＡＰ１０ａとの接続を切断する前に、バッファ時間記録要求オプション及びテストオプション５６の両方を含む要求メッセージをＨＡ３４に送信する。例えば、要求メッセージとしてバインディングアップデート（ＢＵ）メッセージを利用することが可能である。
【０１６３】
さらに、ＭＮ３０はＨＡ３４に対して、ＡＰ１０ｂがＭＮ３０に関するテストパケットのバッファリング時間を記録するように、ＭＮ３０の代理としてＨＡ３４からＡＰ１０ｂに通知が行われるように指示する。ＨＡ３４は、バッファ時間記録要求オプションを有するテストパケットを送信し、ＭＮ３０に関するテストパケットのバッファリング時間を記録するようにＡＰ１０ｂに通知する。
【０１６４】
また、ステップＳ７０５において、要求機能がトリガコマンドによる要求を判断することができない場合には、要求機能は、トリガコマンドの発生をもたらした要求に対する処理できなかった旨を示すエラーメッセージをユーザに戻す（ステップＳ７０７）。また、ステップＳ７０２、Ｓ７０４、Ｓ７０６のいずれかにおいて要求メッセージが生成された場合には、要求機能は、適切なあて先に向けて、この要求メッセージを転送する（ステップＳ７０８）。
【０１６５】
次に、図８を参照しながら、ＭＮ３０がテストパケットを受信した場合の動作について説明する。図８には、本発明の実施の形態におけるモバイルノードがテストパケットを受信した場合に行われる処理の一例が図示されている。
【０１６６】
ＭＮ３０は、テストパケットを受信するとテストパケット処理機能を起動し（ステップＳ８００）、テストパケットに埋め込まれている情報を取得して、ＭＮ３０とＨＡ３４との間の待ち時間の計算を行う（ステップＳ８０１）。例えば、ＨＡ３４及びＭＮ３０は、ＮＴＰを使用してそれぞれの内部時計を同期させる。
【０１６７】
これにより、テストパケットに埋め込まれている情報に、ＨＡ３４からテストパケットが送出された時刻（送出時刻）を示すＨＡ３４によるタイムスタンプオプションが含まれている場合には、ＭＮ３０は、このパケットの受信時刻から、タイムスタンプオプションで定義される送出時刻を減算することによって、待ち時間の計算が行われる。例えば、ＭＮ３０は１０００ミリ秒のタイミングでテストパケットを受信し、テストパケットのタイムスタンプオプションから、このパケットが８００ミリ秒のタイミングで送出されたことが把握された場合には、ＭＮ３０とＨＡ３４との間の待ち時間は２００ミリ秒となる。
【０１６８】
ＭＮ３０は、待ち時間について計算すると、バッファ時間記録要求オプションがテストパケットに付加されているか否かを判断する（ステップＳ８０２）。テストパケットにバッファ時間記録要求オプションが付加されていることが検出された場合、テストパケット処理機能は、バッファ時間記録要求オプションに含まれる時間情報を取得する処理を行う（ステップＳ８０３）。なお、この時間情報は、ＭＮ３０に送信される前にテストパケットがＡＰ１０のバッファに格納されていた時間（バッファリング時間情報）を表している。
【０１６９】
テストパケット処理機能は、バッファ時間記録要求オプションから時間情報を取得すると、ＭＮ３０とＨＡ３４との間の実際の待ち時間を計算する（ステップＳ８０４）。テストパケット処理機能は、ステップＳ８０１で計算された待ち時間から、ステップＳ８０３で取得された時間情報を減算することで、実際の待ち時間を計算する。例えば、時間情報によって、ＭＮ３０のテストパケットがＡＰ１０のバッファ内で５０ミリ秒をバッファリングされていたことが示されているとする。このとき、ＭＮ３０が実際の待ち時間を計算する場合、ＭＮ３０は、以前に計算された２００ミリ秒の待ち時間から５０ミリ秒を減算し、その結果、実際の待ち時間として１５０ミリ秒の値が得られる。したがって、ＭＮ３０とＨＡ３４の間の実際の待ち時間は１５０ミリ秒である。
【０１７０】
この計算結果の情報を用いて、テストパケット処理機能は、パケットがＨＡ３４からＭＮ３０に伝送される際に要する時間をユーザに通知する（ステップＳ８０５）。また、ステップＳ８０２において、テストパケットにバッファ時間記録要求オプションが付加されていないと判断された場合には、テストパケット処理機能は、バッファリング時間を考慮せずに、パケットがＨＡ３４からＭＮ３０に伝送される際に要する時間として、ステップＳ８０２で計算された待ち時間（上述の２００ミリ秒）をユーザに通知する。
【０１７１】
なお、ここでは、モバイルノードがトリガコマンドの処理を行っているが、このような機能は、本発明に係る機能をサポートする他のノード（例えばＡＲやＨＡ）によって実現されてもよい。さらに、テストパケットの処理を行うモバイルノードに関しても、本発明に係る機能をサポートする他のノード（例えばＡＲやＨＡ）によって実現されてもよい。
【０１７２】
また、図９には、本発明の実施の形態におけるモバイルノードの構成の一例が図示されている。図９に図示されているモバイルノード９０は、１つ又は複数のネットワークインタフェース９１、要求機能実現部９２、テストパケット処理機能実現部９３を有している。なお、ネットワークインタフェース９１が受信したパケットは、そのパケットの種類に応じて、シグナル／データパス９１０を通じて要求機能実現部９２に、あるいは、シグナル／データパス９３０を通じてテストパケット処理機能実現部９３に渡される。また、要求機能実現部９２が外部のネットワークノードにパケットを送信する場合には、シグナル／データパス９２０を通じてネットワークインタフェース９１にパケットを渡し、テストパケット処理機能実現部９３が外部のネットワークノードにパケットを送信する場合には、シグナル／データパス９４０を通じてネットワークインタフェース９１にパケットを渡す。
【０１７３】
ネットワークインタフェース９１は、モバイルノード９０が任意の通信媒体を介して別のノードと通信を行うために必要なあらゆるハードウェア又はソフトウェアを包含する機能ブロックである。図１や図４に図示されているネットワークインタフェース１１、４１と同様に、ネットワークインタフェース９１は、レイヤ１（物理層）及びレイヤ２（データリンク層）の通信コンポーネント、ファームウェア、ドライバ、通信プロトコルを表している。なお、モバイルノード９０は、移動しながら通信を行うため、ネットワークインタフェース９１は無線通信機能を有している。
【０１７４】
また、要求機能実現部９２は、所定のネットワークノードに対して、バッファリング要求及びバッファリング時間の記録要求を行ったり、テストパケットの発送を要求したりする機能を有しており、上述の図７に図示されている動作を実現することが可能である。
【０１７５】
要求機能実現部９２は、具体的には、例えば、当該モバイルノード９０あてのパケットのバッファリングを要求する機能及びそのバッファリング時間の記録及び報告を要求する機能、当該移動端末へのテストパケットの送信を要求する機能などを有している。
【０１７６】
また、テストパケット処理機能実現部９３は、テストパケットを受信した場合にテストパケットに関する処理を行って、テストパケットが伝送されてきた経路に関する情報（アクセスリンクの安定度を示すアクセス条件など）を取得する機能を有しており、上述の図８に図示されている動作を実現することが可能である。
【０１７７】
テストパケット処理機能実現部９３は、所定のパケット（テストパケット）がバッファリングノード１０でバッファされていたバッファリング時間を取得する機能、テストパケットを送信したテスタノード４０と当該モバイルノード９０との間の待ち時間（バッファリングノード１０でバッファされていた時間も含むレイテンシ）を取得する機能、テストパケットの待ち時間からバッファリング時間を減算して、バッファリングノード１０でパケットがバッファされずに伝送される場合の待ち時間を算出する機能、自身の内部時計を他のネットワークノード（特にテスタノード）の内部時計と同期させる機能などを有している。
【０１７８】
なお、本明細書では、本発明が最も実用的かつ好適な実施例となるように考慮されて図示及び説明されているが、当業者であれば、上述の各ノードの構成要素に係る設計やパラメータの詳細において、発明の範囲から逸脱しない程度に様々な変更が行われてもよいことは明白である。
【０１７９】
例えば、本発明は、モバイルノード、モバイルルータ、モバイルＩＰのホームエージェント、ネットワークモビリティのホームエージェント、仮想プライベートネットワークのゲートウェイ、ＩＰｖ６−ＩＰｖ４変換ゲートウェイなどを始めとするバッファリングノードに適用可能である。
【０１８０】
また、本発明は、例えば、ＮｅｔＬＭＭ（Network-based Localized Mobility Management）のようなローカライズされたモビリティ環境に対しても適用可能である。Ｎｅｔｌｍｍに適用した場合、ＭＮは、ローカライズされたモビリティ環境に配置されているアクセスルータ（ＡＲ）間を移動していることに気付くと、ＡＲに対して、ＭＮに属するパケットをバッファするように要求し、ＡＲは、こうしてバッファされたパケットに時間情報（バッファリング時間の情報）を付加することが可能である。
【０１８１】
また、ＡＰが、図６に図示されているような構成要素を有し、テスタノードとして機能することも可能である。この場合、ＭＮは、ＡＰに対して、ＭＮに関するパケットをバッファするように依頼することに加えて、ＡＰがＭＮのバッファリングを行う方法を定めたルールを設定することが可能である。例えば、ＭＮは、ＡＰにフィルタルールオプションを送信して、任意のタイプのトラフィック／パケット／プロトコルをバッファすることを示すルールをＡＰに設定することが可能である。
【０１８２】
なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０１８３】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
【０１８４】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
【産業上の利用可能性】
【０１８５】
本発明のネットワークノード及び移動端末は、２つのノード間のパケット伝送で発生する伝送遅延をより正確に算出したり、パケットの伝送条件（ネットワーク条件）を調べたりすることが可能であり、パケット交換型データ通信ネットワークのシステムにおける通信技術分野に適用可能である。また、特に、パケット交換型データ通信ネットワークのシステムにおいて、バッファリングによるパケットの伝送遅延やその他のネットワーク条件を判断する技術に適用可能である。
【図面の簡単な説明】
【０１８６】
【図１】本発明の実施の形態におけるバッファリングノードの構成の一例を示す図
【図２Ａ】本発明の実施の形態におけるバッファリングノードのバッファ時間プロセッサによるパケットバッファリング処理の一例を示すフローチャート
【図２Ｂ】本発明の実施の形態におけるバッファリングノードのバッファ時間プロセッサによるパケット転送処理の一例を示すフローチャート
【図３】本発明の実施の形態におけるネットワーク構成の一例を示す図
【図４】本発明の実施の形態におけるテスタノードの構成の一例を示す図
【図５】本発明の実施の形態における用いられるバインディングアップデートメッセージのフォーマットの一例を示す図
【図６】本発明の実施の形態におけるテスタノードが、特定のパケットがテストメカニズムのトリガか否かを決定する処理の一例を示すフローチャート
【図７】本発明の実施の形態におけるモバイルノードが処理する様々なリクエストに関するＭＮの処理の一例を示すフローチャート
【図８】本発明の実施の形態におけるモバイルノードがテストパケットを受信した場合に行われる処理の一例を示すフローチャート
【図９】本発明の実施の形態におけるモバイルノードの構成の一例を示す図
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2008102564.tif 000013
【図２Ａ】
2008102564.tif 000014
【図２Ｂ】
2008102564.tif 000015
【図３】
2008102564.tif 000016
【図４】
2008102564.tif 000017
【図５】
2008102564.tif 000018
【図６】
2008102564.tif 000019
【図７】
2008102564.tif 000020
【図８】
2008102564.tif 000021
【図９】
2008102564.tif 000022
【国際調査報告】
2008102564.tif 000023
2008102564.tif 000024
2008102564.tif 000025
2008102564.tif 000026
2008102564.tif 000027
2008102564.tif 000028
2008102564.tif 000029