(57)【要約】移動端末がハンドオーバを行う際に、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることを目的とする。例えば、ＭＮ１０１が、新たな接続先（ＡＲ１０９）におけるアドレス（ＮＣｏＡ）を取得していない状態で、ＱＮＥ（プロキシ）１２３に対して、新たな接続先に接続した場合に使用するＱｏＳ経路の確立処理の開始を要求する。ＱＮＥ（プロキシ）は、自ノードとＣＮ１２１との間のリソース予約を行い、その結果、ＱＮＥ（ＣＲＮ）１１５より上流では、ＭＮがＡＲ１０５に接続している状態で使用されている経路情報（ｆｉｌｔｅｒＡ）に、新たな経路情報（ｆｉｌｔｅｒＢ）が関連付けられる。ＭＮが移動後に実際の新たなＣｏＡを使用してＱｏＳ経路の更新を行うまでの間は、データパケットは、プロキシノードによってカプセル化されて、経路情報（ｆｉｌｔｅｒＢ）に基づいて伝送される。【特許請求の範囲】
【請求項１】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な通信システムであって、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続し、前記第１アクセスルータが構成する第１サブネットで取得する第１アドレスを使用して通信を行う移動可能な移動端末と、
前記通信ネットワークに接続されており、前記移動端末の通信相手となる通信相手端末と、
前記移動端末が、前記複数のアクセスルータのうちの１つである第２アクセスルータに接続した場合に前記第２アクセスルータが構成する第２サブネットで取得する第２アドレスを使用せずに、前記第１アクセスルータに接続している前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路が確立された状態で、前記第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始することが可能な前記通信ネットワーク内に存在する通信ノードとを、
有する通信システム。
【請求項２】
前記通信ノードが、前記第２アクセスルータの近隣に存在する請求項１に記載の通信システム。
【請求項３】
前記通信ノードが、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信し、前記トリガ情報に基づいて前記第２経路を確立する処理を開始するように構成されている請求項１に記載の通信システム。
【請求項４】
前記移動端末が、前記トリガ情報を前記通信ノードに送信するように構成されている請求項３に記載の通信システム。
【請求項５】
前記通信ノードが、自ノードを一方の終端とする前記第２経路を確立するように構成されている請求項１に記載の通信システム。
【請求項６】
前記通信ノードは、前記移動端末が前記第２サブネットに移動して割り当てられた第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始するように構成されている請求項１に記載の通信システム。
【請求項７】
前記通信ノードが、前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている請求項６に記載の通信システム。
【請求項８】
前記第２経路の終端が前記通信ノード及び前記通信相手端末であり、前記通信相手端末が、前記移動端末にパケットを送信する際に前記通信ノードのアドレスをあて先アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記通信相手端末から前記移動端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている請求項６に記載の通信システム。
【請求項９】
前記第２経路の終端が前記第２アクセスルータの近隣に存在する前記通信ノード及び前記通信相手端末の近隣に存在する相手側近隣通信ノードであり、前記相手側近隣通信ノードが、前記通信相手端末から前記移動端末へのパケットを転送する際に前記通信ノードのアドレスをあて先アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記通信相手端末から前記移動端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている請求項６に記載の通信システム。
【請求項１０】
前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第１サブネットに接続している状態で使用されていた前記第１経路、及び前記通信ノードによって確立された前記第２経路が削除されるように構成されている請求項６に記載の通信システム。
【請求項１１】
前記通信ノードが、自ノードと前記通信相手端末との間の経路上の中間通信ノードに、前記第２経路を確立する処理を行う際に送受信されるシグナリングメッセージのルーティングのためのステートを導入する処理を開始するように構成されている請求項１に記載の通信システム。
【請求項１２】
前記通信ノードが、前記中間通信ノードに対して、自ノードのアドレス及び前記通信相手端末のアドレスにより構成された識別情報を送信し、前記中間通信ノードが、前記識別情報を保持して、前記識別情報を有するシグナリングメッセージを特定するように構成されている請求項１１に記載の通信システム。
【請求項１３】
前記通信ノードは、前記移動端末が前記第２サブネットに移動して割り当てられた第２アドレスを取得した場合に、前記第２経路に係る付加的サービスを提供するための情報を含むシグナリングメッセージを送信し、前記中間通信ノードが、前記シグナリングメッセージのルーティングのためのステートを使用して、前記シグナリングメッセージの伝送を行うように構成されている請求項１１に記載の通信システム。
【請求項１４】
前記付加的サービスが、ＱｏＳ保証である請求項１に記載の通信システム。
【請求項１５】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な前記通信ネットワークに存在する通信ノード内のリソース管理装置であって、
前記経路において、付加的サービスを提供するためのリソースを確保するためのリソース確保手段と、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続している前記移動端末と、前記通信ネットワークに接続されており前記移動端末の通信相手となる通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信するトリガ受信手段と、
前記トリガ受信手段で前記トリガ情報を受信した場合、前記トリガ情報に基づいて、前記第１アクセスルータとは異なる第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始するメッセージを生成するメッセージ生成手段とを、
有するリソース管理装置。
【請求項１６】
前記メッセージには、前記移動端末の代理として経路設定を行う旨を示す情報が付加されている請求項１５に記載のリソース管理装置。
【請求項１７】
前記第２アクセスルータの近隣に存在する前記通信ノード内に配置されている請求項１６に記載のリソース管理装置。
【請求項１８】
前記トリガ情報に、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスが少なくとも含まれている請求項１６に記載のリソース管理装置。
【請求項１９】
前記移動端末から前記トリガ情報を受信する請求項１８に記載のリソース管理装置。
【請求項２０】
前記通信ノードを一方の終端とする前記第２経路を確立するように構成されている請求項１６に記載のリソース管理装置。
【請求項２１】
前記移動端末が前記第２サブネットに移動して割り当てられた前記第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始するように構成されている請求項１６に記載のリソース管理装置。
【請求項２２】
前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている請求項２１に記載のリソース管理装置。
【請求項２３】
前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第２経路を削除するためのメッセージを送信するように構成されている請求項２０に記載のリソース管理装置。
【請求項２４】
前記付加的サービスが、ＱｏＳ保証である請求項１５に記載のリソース管理装置。
【請求項２５】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な前記通信ネットワークに存在する通信ノードで行われるリソース管理方法であって、
前記経路において、付加的サービスを提供するためのリソースを確保するためのリソース確保ステップと、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続している前記移動端末と、前記通信ネットワークに接続されており前記移動端末の通信相手となる通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信するトリガ受信ステップと、
前記トリガ受信ステップで前記トリガ情報を受信した場合、前記トリガ情報に基づいて、前記第１アクセスルータとは異なる第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始するメッセージを生成するメッセージ生成ステップとを、
有するリソース管理方法。
【請求項２６】
前記メッセージには、前記移動端末の代理として経路設定を行う旨を示す情報が付加されている請求項２５に記載のリソース管理方法。
【請求項２７】
前記第２アクセスルータの近隣に存在する前記通信ノード内に配置されている請求項２６に記載のリソース管理方法。
【請求項２８】
前記トリガ情報に、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスが少なくとも含まれている請求項２６に記載のリソース管理方法。
【請求項２９】
前記移動端末から前記トリガ情報を受信する請求項２８に記載のリソース管理方法。
【請求項３０】
前記通信ノードを一方の終端とする前記第２経路を確立する請求項２６に記載のリソース管理方法。
【請求項３１】
前記移動端末が前記第２サブネットに移動して割り当てられた前記第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始する請求項２６に記載のリソース管理方法。
【請求項３２】
前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化ステップを有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化ステップにおいてカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられる請求項３１に記載のリソース管理方法。
【請求項３３】
前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第２経路を削除するためのメッセージを送信する請求項３０に記載のリソース管理方法。
【請求項３４】
前記付加的サービスが、ＱｏＳ保証である請求項２５に記載のリソース管理方法。
【請求項３５】
シグナリングメッセージをルーティングする機能を有する第１ユニットと、提供する付加的サービスに関する情報を管理するための機能を有する第２ユニットとにより構成された通信プロトコルを使用して２つの通信ノード間で行われる通信において、前記２つの通信ノード間の経路上に存在し、前記２つの通信ノード間で伝送されるデータパケットに対して前記付加的サービスを提供する通信ノード内の通信管理装置であって、
前記第１ユニットが、前記２つの通信ノード間の経路の一部であって、自ノードを含んだ任意の両端点を有する前記経路の一部において伝送される前記シグナリングメッセージのルーティングのためのステートを管理するステート管理手段を有し、
前記第２ユニットが、前記シグナリングメッセージによって伝送されるフィルタ情報であって、前記付加的サービスを提供する対象となるデータパケットを特定するための前記フィルタ情報を管理するフィルタ情報管理手段を有する通信管理装置。
【請求項３６】
前記ステートが、前記任意の両端点のアドレスを有し、前記フィルタ情報が、前記２つの通信ノードのアドレスを有する請求項３５に記載の通信管理装置。
【請求項３７】
前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層に配置されている請求項３５に記載の通信管理装置。
【請求項３８】
シグナリングメッセージをルーティングする機能を有する第１ユニットと、提供する付加的サービスに関する情報を管理するための機能を有する第２ユニットとにより構成された通信プロトコルを使用して２つの通信ノード間で行われる通信において、前記２つの通信ノード間の経路上に存在し、前記２つの通信ノード間で伝送されるデータパケットに対して前記付加的サービスを提供する通信ノードで行われる通信管理方法であって、
前記第１ユニットが、前記２つの通信ノード間の経路の一部であって、自ノードを含んだ任意の両端点を有する前記経路の一部において伝送される前記シグナリングメッセージのルーティングのためのステートを管理するステート管理ステップと、
前記第２ユニットが、前記シグナリングメッセージによって伝送されるフィルタ情報であって、前記付加的サービスを提供する対象となるデータパケットを特定するための前記フィルタ情報を管理するフィルタ情報管理ステップとを、
有する通信管理方法。
【請求項３９】
前記ステートが、前記任意の両端点のアドレスを有し、前記フィルタ情報が、前記２つの通信ノードのアドレスを有する請求項３８に記載の通信管理方法。
【請求項４０】
前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層に配置されている請求項３８に記載の通信管理方法。
【請求項４１】
前記第１及び第２ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されている請求項３８に記載の通信管理方法。
【請求項４２】
前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層の任意の機能が参照可能なＮＳＬＰ共通部に配置されている請求項３８に記載の通信管理方法。
【請求項４３】
前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層の特定の機能部に配置されていて、前記特定の機能部から前記ＮＳＬＰ層の任意の機能部に、前記フィルタ情報の一部又は全部が渡されるように構成されている請求項３８に記載の通信管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、通信システム、リソース管理装置、リソース管理方法、通信管理装置並びに通信管理方法に関し、特に、パケット伝送が行われる通信ネットワークにおける通信システム、リソース管理装置、リソース管理方法、通信管理装置並びに通信管理方法に関する。
【背景技術】
【０００２】  移動端末から無線ネットワークを通じてインターネットなどの通信ネットワークにアクセスするユーザに対して、移動しながらでもシームレスに通信ネットワークの接続を提供できる技術として、次世代インターネットプロトコルであるモバイルＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）を利用したものが普及してきている。【０００３】  一方、ネットワークを利用した通信においては、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）保証を始めとしたサービス（本明細書では、こうしたサービスを付加的サービスと呼ぶことにする）が存在しており、こうした付加的サービスを実現するための様々な通信プロトコルが存在している。このような様々な通信プロトコルのうち、ＱｏＳ保証をするためのプロトコルとして、例えば、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）が挙げられる（例えば、下記の非特許文献１参照）。ＲＳＶＰは、データの送信を行う送信側通信端末からデータの受信を行う受信側通信端末への経路（フロー）上における帯域予約を行うことによって、送信側通信端末から受信側通信端末に、データがスムーズに伝送されるようにするものである。【０００４】  サブネット（サブネットワーク）間のハンドオーバを行うＭＮ（Ｍｏｂｉｌｅ  Ｎｏｄｅ：モバイルノード）に関しては、ハンドオーバ前に受けていたＱｏＳ保証を始めとする付加的サービスを、ハンドオーバ後においても継続して受けられるべきであるという要請があるが、上述したＲＳＶＰは、ＭＮの移動に対して十分には対応していないという問題がある。【０００５】  この問題を解決するために、現在、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）において、ＮＳＩＳ（Ｎｅｘｔ  Ｓｔｅｐ  ｉｎ  Ｓｉｇｎａｌｉｎｇ）と呼ばれる新しいプロトコルを標準化するための議論が行われている（下記の非特許文献２参照）。このＮＳＩＳは、モバイル環境において、ＱｏＳ保証を始めとする様々な付加的サービスに特に有効であると期待されており、ＮＳＩＳにおいてＱｏＳ保証やモビリティサポートを実現するための要件や実現方法などが記載された文献も存在する（例えば、下記の非特許文献３〜７参照）。以下に、現在ＩＥＴＦのＮＳＩＳワーキンググループでドラフト仕様となっているＮＳＩＳの概要と、ＱｏＳ経路確立の方法を説明する（非特許文献４及び非特許文献７参照）。【０００６】  図１０には、従来の技術におけるＮＳＩＳのプロトコル構成を説明するために、ＮＳＩＳ及びその下位層のプロトコルスタックが図示されている。ＮＳＩＳプロトコル層はＩＰ及び下位層のすぐ上に位置する。さらにＮＳＩＳプロトコル層は、それぞれの付加的サービスを提供するためのシグナリングメッセージ生成、及びその処理を行うプロトコルであるＮＳＬＰ（ＮＳＩＳ  Ｓｉｇｎａｌｉｎｇ  Ｌａｙｅｒ  Ｐｒｏｔｏｃｏｌ）と、ＮＳＬＰのシグナリングメッセージのルーティングを行うＮＴＬＰ（ＮＳＩＳ  Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｐｒｏｔｏｃｏｌ）の２層からなる。ＮＳＬＰには、ＱｏＳのためのＮＳＬＰ（ＱｏＳ  ＮＳＬＰ）や、その他のある付加的サービス（サービスＡやサービスＢ）のためのＮＳＬＰ（サービスＡのＮＳＬＰ、サービスＢのＮＳＬＰ）など、様々なＮＳＬＰが存在している。【０００７】  また、図１１は、従来の技術におけるＮＳＩＳのノードであるＮＥやＱＮＥが「隣り合う」という概念を説明するための模式図である。図１１に示すように、ＮＳＩＳ機能を持ったすべてのノード（ＮＥ：ＮＳＩＳ  Ｅｎｔｉｔｙ）には、少なくともＮＴＬＰが実装されている。このＮＴＬＰの上には、ＮＳＬＰが必ずしも存在しなくてもよく、また、１つ以上のＮＳＬＰが存在してもよい。なお、ここでは、特に、ＱｏＳのためのＮＳＬＰを持ったＮＥをＱＮＥ（ＱｏＳ  ＮＳＩＳ  Ｅｎｔｉｔｙ）と呼ぶことにする。なお、ＮＥになり得るのは端末やルータである。また、隣り合うＮＥの間には、ＮＥではない複数のルータが存在することもあり得るし、隣り合うＱＮＥの間には、ＮＥではないルータ及びＱｏＳ  ＮＳＬＰを持たないＮＥが複数存在することもあり得る。【０００８】  なお、ＮＳＩＳは、モバイル環境だけでなく通常の静的なネットワークにおける様々な機能も網羅するものであるが、本明細書では、ＮＳＩＳの機能の１つであるモビリティサポートされた付加的サービスの確立を実現する機能に着目し、ＮＳＩＳの実装によって、モビリティサポートされた付加的サービスの確立が実現されるものとする。【０００９】  また、ＭＮが新たなサブネットワーク（以下、サブネットと呼ぶ）に移動する場合、新たなＱｏＳ経路が、ＭＮとＣＮ（Ｃｏｒｒｅｓｐｏｎｄｅｎｔ  Ｎｏｄｅ：通信相手ノード）との間で確立される必要がある。新たなＱｏＳ経路が確立されるまでは、データパケットは必要なＱｏＳ処理を受けられず、ＱｏＳの中断が起こることになる。このＱｏＳの中断は、スムーズかつシームレスなモビリティが実現されるように、最低限に抑えられる必要がある。【００１０】  こうした問題を扱う１つの方法として、下記の非特許文献８には、ＭＲＳＶＰが提示されている。この非特許文献８では、ＲＳＶＰに変更を加えることによって、モバイルＩＰの三角ルート用のＱｏＳ経路をあらかじめ確立する方法が提案されている。ここでは、「ローカルプロキシエージェント（ＨＡ（Ｈｏｍｅ  Ａｇｅｎｔ：ホームエージェント）に相当する）」及び「リモートプロキシエージェント（ＦＡ（Ｆｏｒｅｉｇｎ  Ａｇｅｎｔ：フォーリンエージェント）に相当する）」が、ＭＮのためのＱｏＳ経路を確立することが可能である。【００１１】  リモートプロキシエージェントは、ＭＮのＮＣｏＡ（Ｎｅｗ  Ｃａｒｅ−ｏｆ  Ａｄｄｒｅｓｓ：新たな気付アドレス）取得した後に、自身とＣＮとの間にＱｏＳ経路のセットアップを行う。続いて、リモートプロキシエージェントとローカルプロキシエージェントとの間（すなわち、ＦＡとＨＡとの間）の経路が新たに確立されて、この経路と、ローカルプロキシエージェントとＣＮとの間（すなわち、ＦＡとＣＮとの間）の経路とが併合される。なお、経路の併合の具体的な方法に関しては説明されていない。【００１２】  また、ＭＮがサブネット間においてハンドオーバを行う場合、ハンドオーバ前の古い経路の一部とハンドオーバ後の新しい経路の一部とが重複する場合がある。このような場合には、重複経路における２重予約の問題や、経路の変更が困難であることなど、様々な問題が起こり得る。こうした問題を解く方法の１つとして、古い経路と新しい経路とが分岐（クロスオーバ）する位置を特定する方法が挙げられる。この分岐点上に存在する通信ノードはＣＲＮ（Ｃｒｏｓｓｏｖｅｒ  Ｎｏｄｅ：クロスオーバノード）と呼ばれ、このＣＲＮを特定する方法としては、例えば、下記の非特許文献９、１０などに記載されている方法が知られている。【００１３】  なお、本明細書に記載されているＱｏＳ経路の確立とは、ＱｏＳが保証されるデータパケットが通る経路であって、ＮＴＬＰ層においてシグナリングメッセージをルーティングするためのステートが確立されており、かつＮＳＬＰ層によってＱｏＳ保証のためのリソース予約手続きが完了した状態のことを指す。なお、ＱｏＳ保証のためのリソース予約と、ＮＴＬＰ層のルーティングのためのステートの確立は、同時に行われる場合もあるし、また、ルーティングのためのステートの確立の後に、ＱｏＳ保証のためのリソース予約が行われる場合もある。【００１４】  また、下記の非特許文献１１Ａによれば、シグナリングメッセージのルーティングのためのステートは、ＮＳＩＳの最初のメッセージが、ｄｏｗｎｓｔｒｅａｍ方向（データパケットが送られる方向）に対して送られる際に確立される。すなわち、あるセッションに対するデータパケットに対してＱｏＳ保証が行われる場合、データパケットが通過する最初のＱＮＥは、ＱｏＳ予約のためのシグナリングメッセージ、又はその準備のためのシグナリングメッセージを、データパケットの受信者に向けて送信する。このとき、このシグナリングメッセージのＮＴＬＰ層に、セッションを識別するセッションＩＤやフローを識別するフローＩＤなどの情報が付けられるほかに、ＩＰ層にはＲＡＯ（Ｒｏｕｔｅｒ  Ａｌｅｒｔ  Ｏｐｔｉｏｎ）が付けられる。そして、このシグナリングメッセージが通過しようとするＱＮＥのＩＰ層において、ＲＡＯの存在によりこのシグナリングメッセージはインタセプトされて、ＮＳＩＳ層（ＮＴＬＰ層及びＮＳＬＰ層）に渡され、ＮＳＩＳ層によって、シグナリングメッセージの中身が確認されるようになる。【００１５】  シグナリングメッセージをインタセプトしたＱＮＥのＮＴＬＰ層では、まず、ルーティングのためのステートとして、フローＩＤやセッションＩＤの情報、及び、このシグナリングメッセージが送信されてきた１つ前の隣り合うＱＮＥのＩＰアドレスの情報を格納する。そして、１つ前の隣り合うＱＮＥに対して、ＮＴＬＰレベルでの返信メッセージを返す。これにより、１つ前のＱＮＥのＮＴＬＰ層は、１つ後ろのＱＮＥのＩＰアドレスを知ることができ、このＩＰアドレスをルーティングのためのステートに書き込むことによって保持する。また、シグナリングメッセージの送受信をセキュアに行いたい場合などには、このほかに、メッセージアソシエーションなどの手順を行い、セキュリティに関するネゴシエーションなどを行う。【００１６】  一方、ＮＳＬＰ側では、ＮＳＬＰメッセージの中身に応じた処理を行い、この処理が済むと再びＮＴＬＰにより、シグナリングメッセージがあて先（ここでは、データパケットの受信者）に向けて転送される。【００１７】  こうして、このシグナ��ングメッセージが所定のあて先に到達することにより、ＮＴＬＰ層にはメッセージのルーティングのためのステートに係る情報が確立される。特に、メッセージアソシエーションが確立された場合には、以後の該当セッションＩＤ、フローＩＤを持つシグナリングメッセージに関しては、ＲＡＯを用いることなく、上述のように確立されたルーティングのためのステートを用いて送受信される。【００１８】  また、ＮＡＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ：ネットワークアドレス変換）やＦＷ（Ｆｉｒｅｗａｌｌ：ファイアウォール）におけるポリシールールを動的に作成するため、ＮＳＩＳではＮＳＬＰ層の機能の１つとして、ＮＡＴＦＷ  ＮＳＬＰ（下記の非特許文献１３参照）が提案されている。【００１９】  なお、ＮＡＴとは、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）内のみで使われるプライベートアドレス情報と、インターネット上で使われるグローバルアドレス情報の変換を行う技術である。なお、アドレス情報にはＩＰアドレスのほかに、ＩＰアドレスとポート番号の組み合わせなども用いられる。どのプライベートアドレス情報と、どのグローバルアドレス情報とを対応させるかという変換情報は、ポリシールールという形でＮＡＴ対応ノード内に保有される。また、ＦＷとは、ＬＡＮ内に通すパケット、又はＬＡＮ内からＬＡＮ外（例えば、インターネット）に送出するパケットをフィルタリングする技術である。なお、フィルタリングには、ＩＰアドレスやポート番号などが用いられる。このフィルタリング情報は、ポリシールールという形でＦＷ対応ノード内に保有される。また、ＮＡＴ及びＦＷの両方の機能が１つのノードに実装される場合も多い。本明細書では、ＮＡＴ及びＦＷの両方の機能をＮＡＴＦＷと呼び、ＮＡＴ及びＦＷの両方の機能を有するノードをＮＡＴＦＷノードと呼ぶ。【００２０】  ＮＡＴＦＷ  ＮＳＬＰの基本動作は、以下の通りである。
（１）データ送信者であるＮＡＴＦＷ  ＮＳＬＰ対応ノードが，データ受信者であるＮＡＴＦＷ  ＮＳＬＰ対応ノードに対して、ＣＲＥＡＴＥメッセージを送信する。
（２）経路上に存在するＮＡＴＦＷ  ＮＳＬＰ対応ノードが、このＣＲＥＡＴＥメッセージをインタセプトする。
（３）このノードがＮＡＴＦＷ機能を持つものであった場合、このＣＲＥＡＴＥメッセージに含まれるパラメータに基づいて、ポリシールールを作成する。【００２１】  なお、ＣＲＥＡＴＥメッセージに含まれるパラメータとは、対象となるデータパケットのアドレス情報、アクション（例えば、パケットを通す／通さないという処理など）及びアクションに対する補足情報（ライフタイムなど）である。このデータパケットのアドレス情報は、フローＩＤより引用される。【００２２】  なお、ＱｏＳ  ＮＳＬＰの場合と同様に、データ送信者及びデータ受信者がＮＡＴＦＷ  ＮＳＬＰ対応ノードではない場合には、データ経路上に存在するＮＡＴＦＷ  ＮＳＬＰ対応ノードで、データ送信者（又はデータ受信者）に一番近いノードが、シグナリングメッセージの送信者（又は受信者）となる。また、ＣＲＥＡＴＥメッセージを送信する前提として、ＮＡＴＦＷノードには、ＮＳＩＳメッセージを通すためのポリシールールがあらかじめ作成されていることが定められている。【００２３】  また、ＮＴＬＰにはフローＩＤが含まれており、このフローＩＤが、ＮＳＬＰレイヤにおいてデータパケットのフィルタリング情報（例えば、ＱｏＳ保証におけるパケットクラシファイア（ｐａｃｋｅｔ  ｃｌａｓｓｉｆｉｅｒ：パケット分類情報）として使用される。データパケットのフィルタリング情報がＮＡＴに対応できるようにするため、非特許文献１１Ｂでは、ＮＡＴがＮＴＬＰ対応であり、かつ、ＮＡＴにおいて、パケットヘッダのアドレス情報の変換と同時にフローＩＤの中身も変換されることが要請されている。
【非特許文献１】Ｒ．Ｂｒａｄｅｎ，Ｌ．Ｚｈａｎｇ，Ｓ．Ｂｅｒｓｏｎ，Ｓ．Ｈｅｒｚｏｇ  ａｎｄ  Ｓ．Ｊａｍｉｎ，″Ｒｅｓｏｕｒｃｅ  ＲｅＳｅｒ  Ｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ−Ｖｅｒｓｉｏｎ  １  Ｆｕｎｃｔｉｏｎａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ″，ＲＦＣ  ２２０５，Ｓｅｐｔｅｍｂｅｒ  １９９７．
【非特許文献２】ＮＳＩＳ  ＷＧ（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ．ｃｈａｒｔｅｒｓ／ｎｓｉｓ−ｃｈａｒｔｅｒ．ｈｔｍｌ）
【非特許文献３】Ｈ．Ｃｈａｓｋａｒ，Ｅｄ，″Ｒｅｑｕｉｒｅｍｅｎｔｓ  ｏｆ  ａ  Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ（ＱｏＳ）Ｓｏｌｕｔｉｏｎ  ｆｏｒ  Ｍｏｂｉｌｅ  ＩＰ″，ＲＦＣ３５８３，Ｓｅｐｔｅｍｂｅｒ  ２００３
【非特許文献４】Ｓｖｅｎ  Ｖａｎ  ｄｅｎ  Ｂｏｓｃｈ，Ｇｅｏｒｇｉｏｓ  Ｋａｒａｇｉａｎｎｉｓ  ａｎｄ  Ａｎｄｒｅｗ  ＭｃＤｏｎａｌｄ″ＮＳＬＰ  ｆｏｒ  Ｑｕａｌｉｔｙ−ｏｆ−Ｓｅｒｖｉｃｅ  ｓｉｇｎａｌｌｉｎｇ″，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｑｏｓ−ｎｓｌｐ−０５．ｔｘｔ，Ｏｃｔｏｂｅｒ  ２００４
【非特許文献５】Ｘ．Ｆｕ，Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ，Ｈ．Ｔｓｃｈｏｆｅｎｉｇ，″Ｍｏｂｉｌｉｔｙ  ｉｓｓｕｅｓ  ｉｎ  Ｎｅｘｔ  Ｓｔｅｐ  ｓｉｇｎａｌｉｎｇ″，ｄｒａｆｔ−ｆｕ−ｎｓｉｓ−ｍｏｂｉｌｉｔｙ−０１．ｔｘｔ，Ｏｃｔｏｂｅｒ  ２００３
【非特許文献６】Ｓ．Ｌｅｅ，ｅｔ．Ａｌ．，“Ａｐｐｌｉｃａｂｉｌｉｔｙ  Ｓｔａｔｅｍｅｎｔ  ｏｆ  ＮＳＩＳ  Ｐｒｏｔｏｃｏｌｓ  ｉｎ  Ｍｏｂｉｌｅ  Ｅｎｖｉｒｏｎｍｅｎｔｓ”，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ａｐｐｌｉｃａｂｉｌｉｔｙ−ｍｏｂｉｌｉｔｙ−ｓｉｇｎａｌｉｎｇ−００．ｔｘｔ，Ｏｃｔｏｂｅｒ  １８，２００４
【非特許文献７】Ｒ．Ｈａｎｃｏｃｋ（ｅｄｉｔｏｒ），“Ｎｅｘｔ  Ｓｔｅｐｓ  ｉｎ  Ｓｉｇｎａｌｉｎｇ：Ｆｒａｍｅｗｏｒｋ”，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｆｗ−０７．ｔｘｔ，Ｎｏｖｅｍｂｅｒ  １，２００３
【非特許文献８】ＭＲＳＶＰ：Ａ．Ｋ．ＴＡＬＵＫＤＡＲ，Ｂ．Ｒ．ＢＡＤＲＩＮＡＴＨ  ａｎｄ  Ａ．ＡＣＨＡＲＹＡ，“Ａ  Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  ａｎ  Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅ  Ｎｅｔｗｏｒｋ  ｗｉｔｈ  Ｍｏｂｉｌｅ  Ｈｏｓｔｓ”，Ｗｉｒｅｌｅｓｓ  Ｎｅｔｗｏｒｋ  ７  ｐｐ５−１９，２００１
【非特許文献９】Ｔ．Ｓａｎｄａ，Ｔ．Ｕｅ，“Ｐｒｅ  ＣＲＮ  ｄｉｓｃｏｖｅｒｙ  ｆｒｏｍ  ｐｒｏｘｙ  ｏｎ  ｃａｎｄｉｄａｔｅ  ｎｅｗ  ｐａｔｈ”，ｄｒａｆｔ−ｓａｎｄａ−ｎｓｉｓ−ｍｏｂｉｌｉｔｙ−ｑｏｓ−ｐｒｏｘｙ−０１．ｔｘｔ，Ｆｅｒｕａｒｙ  ２００４
【非特許文献１０】三田貴子，上豊樹，荒牧隆，“モビリティをサポートしたシームレスなＱｏＳ経路確立方法に関する提案”，電子情報通信学会モバイルマルチメディア通信（ＭｏＭｕＣ）研究会，Ｖｏｌ．１０４  Ｎｏ．３８，ｐｐ５９−６４，２００４年５月
【非特許文献１１Ａ】Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ，Ｒ．Ｈａｎｃｏｃｋ，“ＧＩＭＰＳ：  Ｇｅｎｅｒａｌ  Ｉｎｔｅｒｎｅｔ  Ｍｅｓｓａｇｉｎｇ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  Ｓｉｇｎａｌｉｎｇ”，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｎｔｌｐ−０５．ｔｘｔ，Ｆｅｂｒｕａｒｙ  ２００５
【非特許文献１１Ｂ】Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ，Ｒ．Ｈａｎｃｏｃｋ，“ＧＩＭＰＳ：  Ｇｅｎｅｒａｌ  Ｉｎｔｅｒｎｅｔ  Ｍｅｓｓａｇｉｎｇ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  Ｓｉｇｎａｌｉｎｇ”，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｎｔｌｐ−０７．ｔｘｔ，Ｊｕｌｙ  １８，２００５
【非特許文献１２】三田貴子他，“モバイルＩＰを用いた通信におけるＱｏＳステート管理方法に関する提案”，電子情報通信学会情報ネットワーク（ＩＮ）研究会，  ｖｏｌ．１０４，ｎｏ．５６４，ＩＮ２００４−１４４，ｐｐ．１−６，２００５年１月
【非特許文献１３】Ｍ．Ｓｔｉｅｍｅｒｌｉｎｇ，Ｈ．Ｔｓｃｈｏｆｅｎｉｇ  ａｎｄ  Ｃ．Ａｏｕｎ“ＮＡＴ／Ｆｉｒｅｗａｌｌ  ＮＳＩＳ  Ｓｉｇｎａｌｉｎｇ  Ｌａｙｅｒ  Ｐｒｏｔｏｃｏｌ（ＮＳＬＰ）”，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｎｓｌｐ−ｎａｔｆｗ−０７．ｔｘｔ，Ｊｕｌｙ  １８，２００５
【００２４】  従来の技術には、主に、下記の２つの課題（第１及び第２の課題）が存在する。【００２５】  まず、従来の技術に係る第１の課題について説明する。例えば、上記の非特許文献８に記載されている方法では、ＭＮのためのＱｏＳ経路をあらかじめ確立するために、新たなサブネットワークにおけるプロキシが用いられる。しかしながら、ＭＮのＮＣｏＡを取得した後にのみ、プロキシによってＱｏＳ経路が確立されるが、プロキシは、ＭＮが実際に移動する前にＭＮのＮＣｏＡを取得できない可能性があり、事前にＮＣｏＡを取得する処理によって、スムーズな経路の確立が妨げられてしまう可能性がある。【００２６】  また、ＱｏＳ経路を確立するための試みが、いくつもの経路にわたって実行される必要があり、ＭＮは、こうしたＱｏＳ経路の確立結果に基づいて、新たな接続ポイントへの移動を決定する場合がある。したがって、ＭＮのＮＣｏＡは、ＱｏＳ経路の確立後に生成される場合もあり、この場合には、プロキシが、ＭＮの新たな接続ポイントとなり得る各接続ポイントにおけるＭＮのＮＣｏＡを取得することは困難である。【００２７】  次に、従来の技術に係る第２の課題について説明する。ＮＳＩＳの現仕様では、フローＩＤがそのままパケットクラシファイア（ｐａｃｋｅｔ  ｃｌａｓｓｉｆｉｅｒ：パケット分類情報）として用いられるため、フローＩＤにデータパケットのヘッダ情報が含まれていなければならず、この制限が、ＭＮのハンドオーバ時におけるスムーズなＱｏＳ経路変更を困難にしている。さらに、端末が１つのセッションに対し、複数のＩＰアドレスや複数のポート番号を用いて通信を行っている場合（例えば、端末がマルチホーム状態の場合）や、セッションの途中でＩＰアドレスやポート番号に変更が生じる場合に、ＱｏＳ経路の管理は非常に困難なものとなってしまう場合がある。
【発明の開示】
【００２８】  上記問題に鑑み、本発明は、移動端末がハンドオーバを行う際に、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることを第１の目的とする。
【００２９】  また、本発明では、端末が１つのセッションに対し、複数のＩＰアドレスや複数のポート番号を用いて通信を行っている場合や、セッションの途中でＩＰアドレスやポート番号に変更が生じる場合において、経路（特に、ＱｏＳ経路）の管理を容易にすることを第２の目的とする。
【００３０】  上記目的を達成するため、本発明の通信システムは、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な通信システムであって、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続し、前記第１アクセスルータが構成する第１サブネットで取得する第１アドレスを使用して通信を行う移動可能な移動端末と、
前記通信ネットワークに接続されており、前記移動端末の通信相手となる通信相手端末と、
前記移動端末が、前記複数のアクセスルータのうちの１つである第２アクセスルータに接続した場合に前記第２アクセスルータが構成する第２サブネットで取得する第２アドレスを使用せずに、前記第１アクセスルータに接続している前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路が確立された状態で、前記第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始することが可能な前記通信ネットワーク内に存在する通信ノードとを有している。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信ノードが、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることが可能となる。
【００３１】  さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、前記第２アクセスルータの近隣に存在している。
この構成により、移動端末がハンドオーバ後に第２アクセスルータに接続した場合に、この第２アクセスルータの近隣に存在する通信ノードを経由した経路の設定が可能となる。
【００３２】  さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信し、前記トリガ情報に基づいて前記第２経路を確立する処理を開始するように構成されている。
この構成により、プロキシとして機能する通信ノードは、この第２経路の確立処理に必要な情報や、その開始タイミングなどを把握することが可能となる。
【００３３】  さらに、本発明の通信システムは、上記の通信システムに加えて、前記移動端末が、前記トリガ情報を前記通信ノードに送信するように構成されている。
この構成により、移動端末が、第２経路の確立開始処理を開始させる指示を行うとともに、第２経路の確立に必要な情報を、プロキシとして機能する通信ノードに送信することが可能となる。
【００３４】  さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、自ノードを一方の終端とする前記第２経路を確立するように構成されている。
この構成により、移動端末のアドレスを用いずに、プロキシとして機能する通信ノードのアドレスを使用して、第２経路を確立することが可能となる。
【００３５】  さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードは、前記移動端末が前記第２サブネットに移動して割り当てられた第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始するように構成されている。
この構成により、プロキシとして機能する通信ノードが、移動端末の新たなアドレスを取得した場合には、そのアドレスに基づく第３経路の確立が開始されるようになる。
【００３６】  さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている。
この構成により、プロキシとして機能する通信ノードが、ＱｏＳ保証などの付加的サービスが提供されないヘッダを有するパケットに対して、カプセル化を行うことで、付加的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセル化が行われることによって、適切なあて先にパケットが到達可能となる。
【００３７】  さらに、本発明の通信システムは、上記の通信システムに加えて、前記第２経路の終端が前記通信ノード及び前記通信相手端末であり、前記通信相手端末が、前記移動端末にパケットを送信する際に前記通信ノードのアドレスをあて先アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記通信相手端末から前記移動端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている。
この構成により、通信相手端末（ＣＮ）が、ＱｏＳ保証などの付加的サービスが提供されないヘッダを有するパケットに対して、カプセル化を行うことで、付加的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセル化が行われることによって、適切なあて先にパケットが到達可能となる。
【００３８】  さらに、本発明の通信システムは、上記の通信システムに加えて、前記第２経路の終端が前記第２アクセスルータの近隣に存在する前記通信ノード及び前記通信相手端末の近隣に存在する相手側近隣通信ノードであり、前記相手側近隣通信ノードが、前記通信相手端末から前記移動端末へのパケットを転送する際に前記通信ノードのアドレスをあて先アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記通信相手端末から前記移動端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている。
この構成により、通信相手端末（ＣＮ）の近隣に存在する相手側近隣通信ノードが、ＱｏＳ保証などの付加的サービスが提供されないヘッダを有するパケットに対して、カプセル化を行うことで、付加的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセル化が行われることによって、適切なあて先にパケットが到達可能となる。また、通信相手端末（ＣＮ）が、付加的サービス機能やカプセル化機能を実装していない場合でも、伝送されるパケットは付加的サービスを受けることが可能となる。
【００３９】  さらに、本発明の通信システムは、上記の通信システムに加えて、前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第１サブネットに接続している状態で使用されていた前記第１経路、及び前記通信ノードによって確立された前記第２経路が削除されるように構成されている。
この構成により、ハンドオーバ前の状態からハンドオーバ後の状態に移行する際に、余分な情報（無駄なリソース予約など）が残らないようにすることが可能となる。
【００４０】  さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、自ノードと前記通信相手端末との間の経路上の中間通信ノードに、前記第２経路を確立する処理を行う際に送受信されるシグナリングメッセージのルーティングのためのステートを導入する処理を開始するように構成されている。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信ノードが、ハンドオーバ後における経路の再設定のうち、シグナリングメッセージのルーティングのためのステート確立処理を経路の一部に対して迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることが可能となる。
【００４１】  さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、前記中間通信ノードに対して、自ノードのアドレス及び前記通信相手端末のアドレスにより構成された識別情報を送信し、前記中間通信ノードが、前記識別情報を保持して、前記識別情報を有するシグナリングメッセージを特定するように構成されている。
この構成により、移動端末に対してハンドオーバ後に割り当てられるアドレスを取得する前に、プロキシとして機能する通信ノードは、通信相手端末との間におけるシグナリングメッセージのルーティングのためのステート確立処理を開始することが可能となる。
【００４２】  さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードは、前記移動端末が前記第２サブネットに移動して割り当てられた第２アドレスを取得した場合に、前記第２経路に係る付加的サービスを提供するための情報を含むシグナリングメッセージを送信し、前記中間通信ノードが、前記シグナリングメッセージのルーティングのためのステートを使用して、前記シグナリングメッセージの伝送を行うように構成されている。
この構成により、移動端末のハンドオーバ後に割り当てられるアドレスを取得する前に確立されたシグナリングメッセージのルーティングのためのステートを利用して、付加的サービスを提供するための情報を含むシグナリングメッセージを伝送することが可能となり、新たな経路（特に、ＱｏＳ経路）を迅速に確立することが可能となる。
【００４３】  さらに、本発明の通信システムは、上記の通信システムに加えて、前記付加的サービスがＱｏＳ保証である場合に適用される。
【００４４】  また、上記目的を達成するため、本発明のリソース管理装置によれば、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な前記通信ネットワークに存在する通信ノード内のリソース管理装置であって、
前記経路において、付加的サービスを提供するためのリソースを確保するためのリソース確保手段と、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続している前記移動端末と、前記通信ネットワークに接続されており前記移動端末の通信相手となる通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信するトリガ受信手段と、
前記トリガ受信手段で前記トリガ情報を受信した場合、前記トリガ情報に基づいて、前記第１アクセスルータとは異なる第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始するメッセージを生成するメッセージ生成手段とを有している。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信ノードが、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることが可能となる。
【００４５】  さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記メッセージには、前記移動端末の代理として経路設定を行う旨を示す情報が付加されている。
この構成により、上記のメッセージに係るリソース予約が、プロキシによるものであることを、経路上の各ＱＮＥに対して明示することが可能となる。
【００４６】  さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記第２アクセスルータの近隣に存在する前記通信ノード内に配置されている。
この構成により、移動端末がハンドオーバ後に第２アクセスルータに接続した場合に、この第２アクセスルータの近隣に存在する通信ノードを経由した経路の設定が可能となる。
【００４７】  さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記トリガ情報に、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスが少なくとも含まれている。
この構成により、プロキシとして機能する通信ノードは、この第２経路の確立処理に必要な情報や、その開始タイミングなどを把握することが可能となる。
【００４８】  さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移動端末から前記トリガ情報を受信する。
この構成により、移動端末が、第２経路の確立開始処理を開始させる指示を行うとともに、第２経路の確立に必要な情報を、プロキシとして機能する通信ノードに送信することが可能となる。
【００４９】  さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記通信ノードを一方の終端とする前記第２経路を確立するように構成されている。
この構成により、移動端末のアドレスを用いずに、プロキシとして機能する通信ノードのアドレスを使用して、第２経路を確立することが可能となる。
【００５０】  さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移動端末が前記第２サブネットに移動して割り当てられた前記第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始するように構成されている。
この構成により、プロキシとして機能する通信ノードが、移動端末の新たなアドレスを取得した場合には、そのアドレスに基づく第３経路の確立が開始されるようになる。
【００５１】  さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている。
この構成により、プロキシとして機能する通信ノードが、ＱｏＳ保証などの付加的サービスが提供されないヘッダを有するパケットに対して、カプセル化を行うことで、付加的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセル化が行われることによって、適切なあて先にパケットが到達可能となる。
【００５２】  さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第２経路を削除するためのメッセージを送信するように構成されている。
この構成により、ハンドオーバ前の状態からハンドオーバ後の状態に移行する際に、余分な情報（無駄なリソース予約など）が残らないようにすることが可能となる。
【００５３】  さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記付加的サービスが、ＱｏＳ保証である場合に適用可能である。
【００５４】  また、上記目的を達成するため、本発明のリソース管理方法は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な前記通信ネットワークに存在する通信ノードで行われるリソース管理方法であって、
前記経路において、付加的サービスを提供するためのリソースを確保するためのリソース確保ステップと、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続している前記移動端末と、前記通信ネットワークに接続されており前記移動端末の通信相手となる通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信するトリガ受信ステップと、
前記トリガ受信ステップで前記トリガ情報を受信した場合、前記トリガ情報に基づいて、前記第１アクセスルータとは異なる第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始するメッセージを生成するメッセージ生成ステップとを有している。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信ノードが、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることが可能となる。
【００５５】  さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記メッセージには、前記移動端末の代理として経路設定を行う旨を示す情報が付加されている。
この構成により、上記のメッセージに係るリソース予約が、プロキシによるものであることを、経路上の各ＱＮＥに対して明示することが可能となる。
【００５６】  さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記第２アクセスルータの近隣に存在する前記通信ノード内に配置されている。
この構成により、移動端末がハンドオーバ後に第２アクセスルータに接続した場合に、この第２アクセスルータの近隣に存在する通信ノードを経由した経路の設定が可能となる。
【００５７】  さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記トリガ情報に、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスが少なくとも含まれている。
この構成により、プロキシとして機能する通信ノードは、この第２経路の確立処理に必要な情報や、その開始タイミングなどを把握することが可能となる。
【００５８】  さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移動端末から前記トリガ情報を受信する。
この構成により、移動端末が、第２経路の確立開始処理を開始させる指示を行うとともに、第２経路の確立に必要な情報を、プロキシとして機能する通信ノードに送信することが可能となる。
【００５９】  さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記通信ノードを一方の終端とする前記第２経路を確立する。
この構成により、移動端末のアドレスを用いずに、プロキシとして機能する通信ノードのアドレスを使用して、第２経路を確立することが可能となる。
【００６０】  さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移動端末が前記第２サブネットに移動して割り当てられた前記第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始する。
この構成により、プロキシとして機能する通信ノードが、移動端末の新たなアドレスを取得した場合には、そのアドレスに基づく第３経路の確立が開始されるようになる。
【００６１】  さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化ステップを有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化ステップにおいてカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるようにしている。
この構成により、プロキシとして機能する通信ノードが、ＱｏＳ保証などの付加的サービスが提供されないヘッダを有するパケットに対して、カプセル化を行うことで、付加的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセル化が行われることによって、適切なあて先にパケットが到達可能となる。
【００６２】  さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第２経路を削除するためのメッセージを送信する。
この構成により、ハンドオーバ前の状態からハンドオーバ後の状態に移行する際に、余分な情報（無駄なリソース予約など）が残らないようにすることが可能となる。
【００６３】  さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記付加的サービスが、ＱｏＳ保証である場合に適用される。
【００６４】  また、上記目的を達成するため、本発明の通信管理装置は、シグナリングメッセージをルーティングする機能を有する第１ユニットと、提供する付加的サービスに関する情報を管理するための機能を有する第２ユニットとにより構成された通信プロトコルを使用して２つの通信ノード間で行われる通信において、前記２つの通信ノード間の経路上に存在し、前記２つの通信ノード間で伝送されるデータパケットに対して前記付加的サービスを提供する通信ノード内の通信管理装置であって、
前記第１ユニットが、前記２つの通信ノード間の経路の一部であって、自ノードを含んだ任意の両端点を有する前記経路の一部において伝送される前記シグナリングメッセージのルーティングのためのステートを管理するステート管理手段を有し、
前記第２ユニットが、前記シグナリングメッセージによって伝送されるフィルタ情報であって、前記付加的サービスを提供する対象となるデータパケットを特定するための前記フィルタ情報を管理するフィルタ情報管理手段を有している。
この構成により、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、経路の管理を容易に行えるようにすることが可能となる。
【００６５】  さらに、本発明の通信管理装置は、上記の通信管理装置に加えて、前記ステートが、前記任意の両端点のアドレスを有し、前記フィルタ情報が、前記２つの通信ノードのアドレスを有している。
この構成により、シグナリングメッセージのルーティングのための情報、及び付加的サービスを提供するデータパケットを特定するための情報のそれぞれに関して、異なるアドレスが設定できるようになり、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、特に、ルーティングのためのステートの確立処理を柔軟に行えるようにすることが可能となる。
【００６６】  さらに、本発明の通信管理装置は、上記の通信管理装置に加えて、前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層に配置されている。
この構成により、フローＩＤとフィルタ情報とを分けて別々に管理し、シグナリングメッセージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存性を緩和することが可能となる。また、ＮＳＩＳにおいて、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、特に、ルーティングのためのステートの確立処理を柔軟に行えるようにすることが可能となる。
【００６７】  また、上記目的を達成するため、本発明の通信管理方法は、シグナリングメッセージをルーティングする機能を有する第１ユニットと、提供する付加的サービスに関する情報を管理するための機能を有する第２ユニットとにより構成された通信プロトコルを使用して２つの通信ノード間で行われる通信において、前記２つの通信ノード間の経路上に存在し、前記２つの通信ノード間で伝送されるデータパケットに対して前記付加的サービスを提供する通信ノードで行われる通信管理方法であって、
前記第１ユニットが、前記２つの通信ノード間の経路の一部であって、自ノードを含んだ任意の両端点を有する前記経路の一部において伝送される前記シグナリングメッセージのルーティングのためのステートを管理するステート管理ステップと、
前記第２ユニットが、前記シグナリングメッセージによって伝送されるフィルタ情報であって、前記付加的サービスを提供する対象となるデータパケットを特定するための前記フィルタ情報を管理するフィルタ情報管理ステップとを有している。
この構成により、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、経路の管理を容易に行えるようにすることが可能となる。
【００６８】  さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記ステートが、前記任意の両端点のアドレスを有し、前記フィルタ情報が、前記２つの通信ノードのアドレスを有している。
この構成により、シグナリングメッセージのルーティングのための情報、及び付加的サービスを提供するデータパケットを特定するための情報のそれぞれに関して、異なるアドレスが設定できるようになり、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、特に、ルーティングのためのステートの確立処理を柔軟に行えるようにすることが可能となる。
【００６９】  さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層に配置されている。
この構成により、フローＩＤとフィルタ情報とを分けて別々に管理し、シグナリングメッセージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存性を緩和することが可能となる。また、ＮＳＩＳにおいて、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、特に、ルーティングのためのステートの確立処理を柔軟に行えるようにすることが可能となる。
【００７０】  さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第１及び第２ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されている。
この構成により、フローＩＤとフィルタ情報とを分けて別々に管理し、シグナリングメッセージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存性を緩和することが可能となる。
【００７１】  さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層の任意の機能が参照可能なＮＳＬＰ共通部に配置されている。
この構成により、フローＩＤとフィルタ情報とを分けて別々に管理し、シグナリングメッセージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存性を緩和することが可能となる。
【００７２】  さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層の特定の機能部に配置されていて、前記特定の機能部から前記ＮＳＬＰ層の任意の機能部に、前記フィルタ情報の一部又は全部が渡されるように構成されている。
この構成により、フローＩＤとフィルタ情報とを分けて別々に管理し、シグナリングメッセージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存性を緩和することが可能となる。
【００７３】  本発明は、上記の構成を有しており、移動端末がハンドオーバ後に接続するサブネットにおいて使用するアドレス（ＮＣｏＡ）を用いずに、ハンドオーバ後の移動端末が送信元又はあて先に設定されたパケットに対して、付加的サービス（特に、ＱｏＳ）を提供することによって、移動端末のＮＣｏＡの生成タイミングや取得機構などに影響されない、スムーズな経路（特に、ＱｏＳ経路）の確立が実現可能となる。
【００７４】  また、本発明は、上記の構成を有しており、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することにより、移動端末のＮＣｏＡの生成タイミングや取得機構などに影響されない、スムーズな経路（特に、ＱｏＳ経路）の確立が実現可能となるとともに、さらには、複数のＩＰアドレスや複数のポート番号を用いて通信を行っている場合や、セッションの途中でＩＰアドレスやポート番号に変更が生じる場合においても、経路（特に、ＱｏＳ経路）の管理を容易にすることを可能にする。
【図面の簡単な説明】
【００７５】
【図１】本発明の第１の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ経路の状態を模式的に示す図
【図２】本発明の第１の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路を確立した状態を模式的に示す図
【図３】本発明の第１の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図
【図４】本発明の第１の実施の形態におけるＱＮＥの一構成例を示す図
【図５】本発明の第１の実施の形態における動作例を示すシーケンスチャート
【図６】本発明の第２の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ経路の状態を模式的に示す図
【図７】本発明の第２の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路を確立した状態を模式的に示す図
【図８】本発明の第２の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図
【図９】本発明の第２の実施の形態における動作例を示すシーケンスチャート
【図１０】従来の技術におけるＮＳＩＳのプロトコル構成を説明するための模式図
【図１１】従来の技術におけるＮＳＩＳのノードであるＮＥやＱＮＥが「隣り合う」という概念を説明するための模式図
【図１２】本発明の第３の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ予約の状態及びルーティングのためのステート内に含まれるフローＩＤの状態を模式的に示す図
【図１３】本発明の第３の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路上にルーティングのためのステートを確立した状態を、この中に含まれるフローＩＤを示すことにより模式的に示す図
【図１４】本発明の第３の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図
【図１５】本発明の第３の実施の形態において、データパケットの送信方向がｕｐｌｉｎｋ方向の場合の動作例を示すシーケンスチャート
【図１６】本発明の第３の実施の形態において、データパケットの送信方向がｄｏｗｎｌｉｎｋ方向の場合の動作例を示すシーケンスチャート
【図１７】本発明の第３の実施の形態において、ＱＮＥ内でフィルタ情報及びフローＩＤを管理する主体を模式的に示す図
【図１８】本発明の第３の実施の形態において、データ経路上にＮＡＴＦＷが存在しており、データパケットの送信方向がｕｐｌｉｎｋ方向の場合の動作例を示すシーケンスチャート
【発明を実施するための最良の形態】
【００７６】  以下、図面を参照しながら、本発明の第１〜第３の実施の形態について説明する。なお、まず、本発明の第１の実施の形態では、データの流れ方向が、移動を行うＭＮから、その通信相手であるＣＮに向かう方向（以下、ｕｐｌｉｎｋ方向と呼ぶ）の場合について説明を行い、続いて、本発明の第２の実施の形態では、データの流れ方向が、ＣＮからＭＮに向かう方向（以下、ｄｏｗｎｌｉｎｋ方向と呼ぶ）の場合について説明を行う。【００７７】  ＜第１の実施の形態＞
以下、本発明の第１の実施の形態について説明する。まず、図１〜３を参照しながら、本発明の第１の実施の形態に係る概要について説明する。図１は、本発明の第１の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ経路の状態を模式的に示す図である。また、図２は、本発明の第１の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路を確立した状態を模式的に示す図である。また、図３は、本発明の第１の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図である。【００７８】  図１〜３には、無線通信によりＡＲ（Ａｃｃｅｓｓ  Ｒｏｕｔｅｒ）に接続してＣＮ１２１との通信を行うＭＮ１０１と、ＭＮ１０１の通信相手となるＣＮ１２１と、サブネット１０３を形成するＡＲ１０５と、サブネット１０７を形成するＡＲ１０９と、ＭＮ１０１とＣＮ１２１との間における経路上に存在し、ＭＮ１０１とＣＮ１２１との間で伝送されるパケットに関してＱｏＳ保証を行うＱｏＳ認識機能（ＱｏＳ−ａｗａｒｅ）を有するＱＮＥ１１１、１１３、１１５、１１７、１１９、１２３、１２５とが図示されている。【００７９】  なお、ＭＮ１０１がサブネット１０３に存在している場合（すなわち、ＭＮ１０１がＡＲ１０５に接続している場合）、ＭＮ１０１からＣＮ１２１へのｕｐｌｉｎｋ方向の経路１２７上には、ＡＲ１０５、ＱＮＥ１１１、ＱＮＥ１１３、ＱＮＥ１１５、ＱＮＥ１１７、ＱＮＥ１１９が存在しており、ＭＮ１０１がサブネット１０７に存在している場合（すなわち、ＭＮ１０１がＡＲ１０９に接続している場合）、ＭＮ１０１からＣＮ１２１へのｕｐｌｉｎｋ方向の経路１２９上には、ＡＲ１０９、ＱＮＥ１２３、ＱＮＥ１２５、ＱＮＥ１１５、ＱＮＥ１１７、ＱＮＥ１１９が存在しているものとする。なお、経路１２７と経路１２９とは一部が重複しており、経路１２７と経路１２９とのＣＲＮ（Ｃｒｏｓｓｏｖｅｒ  Ｎｏｄｅ：クロスオーバノード）をＱＮＥ１１５とする。【００８０】  図１において、ＭＮ１０１からＣＮ１２１に送信されるデータパケットは、経路１２７を経由して伝送される。このとき、経路１２７上のすべてのＱＮＥ１１１、１１３、１１５、１１７、１１９は、ＭＮ１０１からＣＮ１２１に送信されるデータパケットに関するＱｏＳステートを有している。すなわち、各ＱＮＥ１１１、１１３、１１５、１１７、１１９は、少なくとも送信元アドレス（ｓｏｕｒｃｅ  ａｄｄｒｅｓｓ）及びあて先アドレス（ｄｅｓｔｉｎａｔｉｏｎ  ａｄｄｒｅｓｓ）の情報を含む識別情報（この情報をフィルタ情報（ｆｉｌｔｅｒ）と呼ぶ）と、このフィルタ情報に対応するリソース予約情報（ｒｅｓｏｕｒｃｅ）とが関連付けているＱｏＳステートを保持しており、ＭＮ１０１からＣＮ１２１に送信されるデータパケットのヘッダ（特に、送信元アドレス及びあて先アドレス）を参照してフィルタ情報を特定し、対応するリソース予約情報に基づくＱｏＳ保証を行うように構成されている。なお、上述した非特許文献４、６、７などの現在のフローＩＤは、データパケットの送信元アドレス及びあて先アドレスを含む情報に���り構成されていると記載されており、このフローＩＤを上記のフィルタ情報として利用することも可能である。また、フィルタ情報は、フローＩＤとは異なる情報であってもよい。【００８１】  なお、図１に図示されているように、経路１２７のフィルタ情報（ＭＮ１０１がサブネット１０３から割り当てられているＩＰアドレス（ｃＣｏＡ：ｃｕｒｒｅｎｔ  Ｃａｒｅ−ｏｆ  Ａｄｄｒｅｓｓ）が送信元アドレスとして含まれているとともに、ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれているフィルタ情報）をｆｉｌｔｅｒＡとし、ｆｉｌｔｅｒＡに対応するリソース予約情報をｒｅｓｏｕｒｃｅＡとする。【００８２】  ＭＮ１０１は、サブネット１０７に移動する可能性があり、プロキシ１２３に対して予測経路（経路１２９）、又は予測経路の一部の確立を所望している。なお、ＭＮ１０１がサブネット１０７に移動する前に、プロキシ１２３によって予測経路、又は予測経路の一部が確立されることで、ＭＮ１０１が実際にサブネット１０７に移動した後に、より迅速にＭＮ１０１からＣＮ１２１へのＱｏＳ経路が確立され、ハンドオーバによるＱｏＳ保証の中断時間を短縮することが可能となる。【００８３】  ＱＮＥ（プロキシ）１２３が予測経路を確立するための何らかのトリガを受けた場合には、ＱＮＥ（プロキシ）１２３とＣＲＮ（ここではＱＮＥ１１５）との間でＱｏＳ経路が確立される。この新たな経路が確立された場合には、ＱＮＥ（プロキシ）１２３や、ＱＮＥ（プロキシ）１２３とＱＮＥ１１５との間の各中間ＱＮＥ（例えば、ＱＮＥ１２５）は、新たなＱｏＳステートを有することになる。すなわち、図２に図示されているように、ＱＮＥ（プロキシ）１２３やＱＮＥ１２５では、ＱＮＥ（プロキシ）１２３のＩＰアドレスが送信元アドレスとして含まれているとともに、ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれているフィルタ情報（ｆｌｔｅｒＢ）に対して、ｆｉｌｔｅｒＡと同一のリソース予約情報であるｒｅｓｏｕｒｃｅＡが設定される。【００８４】  一方、ＱＮＥ１１５とＣＮ１２１との間の経路上のＱＮＥに関しては、新たなフィルタ情報（上記のｆｉｌｔｅｒＢ）が、現在のフィルタ情報（ｆｉｌｔｅｒＡ）に追加される。これにより、図２に図示されているように、ＱＮＥ１１５や、ＱＮＥ１１５とＣＮ１２１との間の各中間ＱＮＥ（例えば、ＱＮＥ１１７、１１９）は、ｆｉｌｔｅｒＡ及びｆｉｌｔｅｒＢに対してｒｅｓｏｕｒｃｅＡが設定されたＱｏＳステートを有することになり、ｆｌｔｅｒＢによって定義されるデータトラフィックには、ｆｉｌｔｅｒＡによって定義されるデータトラフィックのために予約されたｒｅｓｏｕｒｃｅＡが使用可能となる。なお、例えば、同一セッションＩＤを有する２つのフィルタ情報（ｆｉｌｔｅｒＡ及びｆｉｌｔｅｒＢ）によりどちらか一方が削除されてしまうなど、従来行われている処理によって本発明に係る動作に不具合が生じる可能性があるため、例えば、ｆｉｌｔｅｒＢに係るＲＥＳＥＲＶＥメッセージには、プロキシによるＱｏＳ経路の確立であることを示す特別なフラグ（「プロキシフラグ」）が付加されることが望ましい。【００８５】  以上のように、ＭＮ１０１がサブネット１０７��の移動を行う前に（あるいは、ＭＮ１０１のサブネット１０７への移動とは無関係に）、ＱＮＥ（プロキシ）１２３は、ＭＮ１０１のＮＣｏＡ（ＭＮ１０１がサブネット１０７に移動した後に割り当てられる新たなＣｏＡ）を用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路の一部（ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路）に係るリソース予約を行うことが可能となる（図２に図示されている状態）。【００８６】  そして、ＭＮ１０１がＮＣｏＡを取得した場合（実際にサブネット１０７に移動してＮＣｏＡを取得するか、あるいはサブネット１０３に接続した状態でＮＣｏＡを取得した場合）には、図３に図示されているように、経路１２９上の各中間ＱＮＥ（ＱＮＥ１２３、１２５、１１５、１１７、１１９）において、ＭＮ１０１のＮＣｏＡが送信元アドレスとして含まれているとともに、ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれている新たなフィルタ情報（ｆｉｌｔｅｒＣ）がｆｉｌｔｅｒＡ又はｆｉｌｔｅｒＢに追加されることによって、ＱｏＳ経路の更新が行われる。なお、ＭＮ１０１がサブネット１０７に移動した場合には、ｆｉｌｔｅｒＡに関しては、能動的（削除を指示するメッセージの送信などによる）又は受動的（タイムアウトなどによる）に削除されることが望ましい。また、フローＩＤとは異なる情報としてフィルタ情報が存在する場合には、フローＩＤは、データパケットの送信元アドレス／あて先アドレスに依存するものでなくてもよい。例えば、図３でプロキシ１２３がｆｉｌｔｅｒＣに関するリソース予約を行う際、経路１２９全体に使われるフローＩＤは「送信元＝ＱＮＥ（プロキシ）１２３、あて先＝ＣＮ１２１」を含んでいてもよく、またＭＮ１０１からＱＮＥ（プロキシ）１２３までの経路に関しては「送信元＝ＱＮＥ（プロキシ）１２３、あて先＝ＭＮ１０１」を含むフローＩＤ、ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路に関しては「送信元＝ＱＮＥ（プロキシ）１２３、あて先＝ＣＮ１２１」を含むフローＩＤをそれぞれ用いて、２つの経路として扱ってもよい。【００８７】  例えば、ＭＮ１０１がサブネット１０７に移動してＮＣｏＡを取得した後に、ＮＣｏＡに関するＱｏＳ経路の更新が完了（ｆｉｌｔｅｒＣに関するリソース予約が完了）する前までは、ＭＮ１０１からＣＮ１２１あてに送信されるデータパケットは、ＱＮＥ（プロキシ）１２３によって、ｆｉｌｔｅｒＢの情報を含むアウタヘッダ（送信元アドレスをＱＮＥ（プロキシ）１２３のＩＰアドレスとし、あて先アドレスをＣＮ１２１のＩＰアドレスとするヘッダ）が付加されて、カプセル化される。このカプセル化されたデータパケットはｆｉｌｔｅｒＢによって識別され、各中間ＱＮＥにおいて、ｒｅｓｏｕｒｃｅＡに基づくＱｏＳ保証が行われて伝送され、ｆｉｌｔｅｒＢによって識別される経路の最終ＱＮＥによって脱カプセル化される。なお、この最終ＱＮＥはＣＮ１２１であることが望ましいが、ＣＮ１２１がＱＮＥではない場合には、その他のＱＮＥ（例えば、経路上において、ＣＮ１２１の最も近くに存在するＱＮＥ１１９）であってもよい。【００８８】  最終ＱＮＥは、ｆｉｌｔｅｒＢで特定されるヘッダを持��パケットが到達した際には、脱カプセル化を行ってインナパケットを取り出す。ＣＮ１２１が最終ＱＮＥの場合にはそのインナパケットを取得し、ＱＮＥ１１９が最終ＱＮＥの場合にはそのインナパケットをＣＮ１２１に向けて転送する。なお、経路全体にわたってＱｏＳ予約が行われるようにするための方法としては、例えばＩＰｖ４最小カプセル化など、上述のパケットのカプセル化方法以外にも存在することは、当業者にとって明白であり、任意のパケットのカプセル化方法を本発明に適用することが可能である。また、本発明は、他の種類のカプセル化やトンネリング機構においても良好に動作する。【００８９】  このように、ＭＮ１０１のＮＣｏＡが設定されているｆｉｌｔｅｒＣに関するリソース予約が完了するまでは、データパケットのカプセル化が行われ、ＱＮＥ（プロキシ）１２３のＩＰアドレスが送信元アドレスとして設定されているｆｉｌｔｅｒＢによって、カプセル化されたデータパケットのＱｏＳ保証が行われるように構成されており、ＭＮ１０１のＮＣｏＡを用いてリソース予約が行われるまでのＱｏＳ保証の中断時間を低減することが可能となる。【００９０】  また、ｆｉｌｔｅｒＣのＱｏＳの更新に成功した後（すなわち、ｆｉｌｔｅｒＣが経路１２９上のすべてのＱＮＥに導入された後）は、ＱＮＥ（プロキシ）１２３は、ｆｉｌｔｅｒＢのデータパケットの生成（ｆｉｌｔｅｒＡのデータパケットのカプセル化）を終了する。そして、ｆｉｌｔｅｒＡやｆｉｌｔｅｒＢは能動的又は受動的に削除され、最終的にｆｉｌｔｅｒＣに関するＱｏＳステートのみが残り、サブネット１０７に接続しているＭＮ１０１からＣＮ１２１への経路１２９において、ＭＮ１０１からＣＮ１２１へのデータパケットに対するＱｏＳ保証が行われる。【００９１】  次に、図４を参照しながら、本発明の第１の実施の形態におけるＱＮＥの構成について説明する。図４は、本発明の第１の実施の形態におけるＱＮＥの一構成例を示す図である。図４に示すＱＮＥは、受信手段１１、送信手段１３、トリガ検出手段１５、メッセージ生成・処理手段１７、フィルタリング手段１９、カプセル化／脱カプセル化手段２１、ＱｏＳ情報格納手段２３を有している。【００９２】  受信手段１１及び送信手段１３は、パケットの受信及びパケットの送信を行うための手段である。また、トリガ検出手段１５は、例えばＭＮ１０１から受信する、予測経路を確立するための何らかのトリガに係る処理を行うための手段である。なお、受信したトリガ情報は、例えば、フィルタ情報ごとに関連付けられてＱｏＳ情報格納手段２３に格納される。また、トリガ検出手段１５からメッセージ生成・処理手段１７に対して、トリガ情報の受信イベントが発生した旨を示す情報や、トリガ情報自体が供給される。【００９３】  また、メッセージ生成・処理手段１７は、トリガ情報に含まれるＭＮ１０１とＣＮ１２１との間のＱｏＳ経路で用いられているセッションＩＤや、ＱＳｐｅｃ情報や、ＣＮ１２１のＩＰアドレスなどの情報に基づいて、データ経路上の各通信ノードの調査や、実際のリソース予約などを行うためのメッセージを生成するための手段である。また、他の通信ノードから受信したメッセージに関しても、このメッ���ージ生成・処理手段１７において処理が行われ、リソース予約などを行うための情報（セッションＩＤやフィルタ情報、ＱＳｐｅｃなどの情報）は、ＱｏＳ情報格納手段２３に格納される。【００９４】  また、フィルタリング手段１９は、受信パケットのヘッダ（特に、フィルタ情報に対応するパケットの送信元アドレス及びあて先アドレス）を参照して、受信パケットに対して、ＱｏＳ情報格納手段２３に格納されているＱｏＳ情報（ＱｏＳステート）に基づくパケットのフィルタリングを行う手段であり、このフィルタリングによって、各パケットに対するリソースが確保されるように構成されている。また、カプセル化／脱カプセル化手段２１は、必要に応じて、送信パケットのカプセル化や、受信パケットの脱カプセル化を行う手段である。【００９５】  なお、後述の具体例（図５のシーケンスチャートを参照）から分かるように、トリガ検出手段１５はＱＮＥ１２３においてのみ必要であり、その他のＱＮＥには実装されている必要はない。また、カプセル化／脱カプセル化手段２１は、例えば、ＱＮＥ１２３にカプセル化手段、ＣＮ１２１に脱カプセル化手段がそれぞれ実装されていればよく、その他のＱＮＥには、カプセル化／脱カプセル化手段２１が特に実装される必要はない。【００９６】  次に、図５を参照しながら、本発明の第１の実施の形態における動作について説明する。図５は、本発明の第１の実施の形態における動作例を示すシーケンスチャートである。なお、ここでは具体例として、ＮＳＩＳのＱｏＳ  ＮＳＬＰで定義されているメッセージであるＱＵＥＲＹメッセージやＲＥＳＥＲＶＥメッセージに、さらに本発明の動作に必要な情報を付加した場合について説明する。【００９７】  図５において、まず、ＱＮＥ（プロキシ）１２３は、予測経路を確立するためのトリガを受け取る（ステップＳ２０１）。なお、このトリガには、例えば、ＭＮ１０１とＣＮ１２１との間のＱｏＳ経路で用いられているセッションＩＤ、ＱＳｐｅｃ情報、ＣＮ１２１（又は経路の最終ＱＮＥであるＱＮＲ（ＱｏＳ  ＮＳＩＳ  Ｒｅｓｐｏｎｄｅｒ））のＩＰアドレスなど、予測経路を確立するために必要な情報が含まれている。また、ＱＮＥ（プロキシ）１２３が受信するトリガの送信元は任意のＱＮＥであってよいが、移動を行う可能性のあるＭＮ１０１や、その通信相手ノードであるＣＮ１２１、ＭＮ１０１やＣＮ１２１からの要求に応じて、ＭＮ１０１やＣＮ１２１の代理として機能するＱＮＥが送信元となることが好適である。なお、この場合、ＭＮ１０１やＣＮ１２１、代理となるＱＮＥは、トリガのあて先に使用するＱＮＥ（プロキシ）１２３のＩＰアドレスを把握する必要があるが、この把握方法は、特に限定されるものではない。【００９８】  トリガを受け取ったＱＮＥ（プロキシ）１２３は、即座に、このトリガに対応したＱＵＥＲＹメッセージをＣＮ１２１に向かって送信する（ステップＳ２０３）。このＱＵＥＲＹメッセージには、例えば、セッションＩＤとＱＳｐｅｃ情報とが含まれている。ＱＵＥＲＹメッセージは、経路１２９上においてＱＮＥ（プロキシ）１２３に隣接するＱＮＥ１２５に到達する。ＱＮＥ１２５は、このＱＵＥＲＹメッセージに基づいて通常のＱＵＥＲＹ処理（例えば、ＱＵＥＲＹメッセージに含まれているセッションＩＤのリソース予約状況の確認処理など）を行うとともに、次の隣接するＱＮＥ（ＱＮＥ１１５）にＱＵＥＲＹメッセージを送信する（ステップＳ２０５）。ＱＮＥ１１５は、ＱＵＥＲＹメッセージを受信すると、ＱＵＥＲＹメッセージ内のセッションＩＤや、隣接するＱＮＥの変化を検出するための情報として使われるＳＩＩ（Ｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ）を比較することによって、自身がＣＲＮであることを認識する（ステップＳ２０７）。【００９９】  ＱＮＥ１１５は、新たな予約を行うために、「プロキシフラグ」が付加された受信者始動ＲＥＳＥＲＶＥメッセージ（ｒｅｃｅｉｖｅｒ−ｉｎｉｔｉａｔｅｄ  ＲＥＳＥＲＶＥ  ｍｅｓｓａｇｅ）をＱＮＥ１２３に送信する（ステップＳ２０９）。この予約におけるフィルタ情報には、送信元アドレスとしてＱＮＥ（プロキシ）１２３のＩＰアドレスが含まれている（図２のｆｉｌｔｅｒＢに対応）。なお、ステップＳ２０９においてＱＮＥ１１５から送信されたＲＥＳＥＲＶＥメッセージは、ＱＮＥ１２３まで伝送され（ステップＳ２１１）、各ＱＮＥ（ＱＮＥ１２３、１２５）において、ＲＥＳＥＲＶＥメッセージに含まれているフィルタ情報やＱＳｐｅｃに基づいて、フィルタ／リソースの組が生成されて予約が行われる。なお、ＱＮＥ１１５においても同様に、フィルタ／リソース（図２のｆｉｌｔｅｒＢ／ｒｅｓｏｕｒｃｅＡ）の組が生成されて予約が行われる。【０１００】  また、ステップＳ２０９における受信者始動ＲＥＳＥＲＶＥメッセージの送信と同時に、ＱＮＥ１１５は「プロキシフラグ」が付加された送信者主導のＲＥＳＥＲＶＥメッセージ（ｓｅｎｄｅｒ−ｉｎｉｔｉａｔｅｄ  ＲＥＳＥＲＶＥ  ｍｅｓｓａｇｅ：図５ではＲＥＳＥＲＶＥ（ａｄｄ）と記載）をＣＮ１２１に送信する（ステップＳ２１３）。この予約におけるフィルタ情報には、送信元アドレスとしてＱＮＥ（プロキシ）１２３のＩＰアドレスが含まれている（図２のｆｉｌｔｅｒＢに対応）。ステップＳ２１３においてＱＮＥ１１５から送信されたＲＥＳＥＲＶＥメッセージは、ＣＮ１２１まで伝送され（ステップＳ２１３、Ｓ２１５、Ｓ２１７）、各ＱＮＥ（ＱＮＥ１１７、１１９）において、このフィルタ情報が、ＭＮ１０１からＣＮ１２１へのデータパケットに現在使用されている現在のフィルタ／リソース（図１のｆｉｌｔｅｒＡ／ｒｅｓｏｕｒｃｅＡ）の組に追加される。【０１０１】  ここで、ＭＮ１０１がサブネット１０７に移動したとする（ステップＳ２１９）。ＱＮＥ（プロキシ）１２３はＭＮ１０１の移動を検出し、ＭＮ１０１のＮＣｏＡを取得した場合（ステップＳ２２１）には、受信者始動ＲＥＳＥＲＶＥメッセージをＭＮ１０１に送信する（ステップＳ２２３）。このＲＥＳＥＲＶＥメッセージに関するフィルタ情報には、送信元アドレスとしてＭＮ１０１のＮＣｏＡが含まれている。【０１０２】  また、ＱＮＥ（プロキシ）１２３は、ＣＮ１２１あてのデータパケットをＭＮ１０１から受信した場合には、送信元アドレスがＱＮＥ（プロキシ）１２３のアドレスに設定されたアウタヘッダ（あて先アドレスは、ＣＮ１２１のアドレス）を付加す���ことによって、ＭＮ１０１からのデータパケットのカプセル化を開始する（ステップＳ２２５）。カプセル化されたデータパケットは、その送信元アドレスがＱＮＥ（プロキシ）１２３であり、経路１２９上の各ＱＮＥでは、ｆｉｌｔｅｒＢのフィルタ情報に係るＱｏＳ処理が行われ、その結果、ＱｏＳ保証を受けることになる。【０１０３】  一方、ＱＮＥ（プロキシ）１２３は、サブネット１０７への移動後のＭＮ１０１（すなわち、ＭＮ１０１のＮＣｏＡ）に関する予約を行うために、送信者主導のＲＥＳＥＲＶＥメッセージ（図５ではＲＥＳＥＲＶＥ（ａｄｄ）と記載）をＣＮ１２１に送信する（ステップＳ２２７）。この予約におけるフィルタ情報には、送信元アドレスとしてＭＮ１０１のＩＰアドレスが含まれている。そして、各ＱＮＥ（ＱＮＥ１２５、１１５、１１７、１１９）を経由してＲＥＳＥＲＶＥメッセージは伝送されるとともに（ステップＳ２２９、Ｓ２３１、Ｓ２３３、Ｓ２３５）、各ＱＮＥにおいて、このＲＥＳＥＲＶＥメッセージに含まれるフィルタ情報（図３のｆｉｌｔｅｒＣ）が、以前に付加又は生成されたフィルタ情報（図２のｆｉｌｔｅｒＢ）に付加される。【０１０４】  ＲＥＳＥＲＶＥメッセージを受けたＣＮ１２１は、即座にＲＥＳＰＯＮＳＥメッセージをＱＮＥ１２３に向けて送信する（ステップＳ２３７）。このＲＥＳＰＯＮＳＥメッセージは、各ＱＮＥ（１１９、１１７、１１５、１２５）を経由してＱＮＥ（プロキシ）１２３に到達する（ステップＳ２３９、２４１、２４３、２４５）。このＲＥＳＰＯＮＳＥメッセージの受信によって、ＱＮＥ（プロキシ）１２３はＭＮ１０１のＮＣｏＡに係るＱｏＳ経路が確立された旨を認識し、ＱＮＥ（プロキシ）１２３は、データパケットのカプセル化を終了する（ステップＳ２４７）。【０１０５】  さらに、ＱＮＥ１２３は、ステップＳ２０９〜Ｓ２１７で導入されたＱＮＥ（プロキシ）１２３を送信元アドレスとするフィルタ情報（図２のｆｉｌｔｅｒＢ）を削除するために、送信者主導のＲＥＳＥＲＶＥメッセージ（図５ではＲＥＳＥＲＶＥ（ｒｅｍｏｖｅ）と記載）をＣＮ１２１に送信する（ステップＳ２４９、Ｓ２５１、Ｓ２５３、Ｓ２５５、Ｓ２５７）。なお、必ずしもＲＥＳＥＲＶＥメッセージによるフィルタ情報の削除を行う必要はなく、このフィルタ情報は、タイマのタイムアウトによって削除されてもよい。【０１０６】  以上、説明したように、本発明の第１の実施の形態によれば、ＱＮＥ（プロキシ）１２３が、ＭＮ１０１のサブネット１０７において割り当てられるＮＣｏＡを用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路（ＭＮ１０１からＣＮ１２１までの経路）の一部（ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路）に係るリソース予約を行い、ＭＮ１０１からＣＮ１２１までの完全な経路が確立されるまでは、ＱＮＥ（プロキシ）１２３が確立した経路及びＱｏＳステートによってデータパケットが行われることで、ＭＮ１０１がサブネット１０３からサブネット１０７に接続を変更した場合において、ＭＮ１０１からＣＮ１２１に送られるデータパケットのＱｏＳ保証の中断時間を低減することが可能となる。【０１０７】  ＜第２の実施の形態＞
次に、本発明の第２の実施の形態について説明する。まず、図６〜８を参照しながら、本発明の第１の実施の形態に係る概要について説明する。図６は、本発明の第２の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ経路の状態を模式的に示す図である。また、図７は、本発明の第２の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路を確立した状態を模式的に示す図である。また、図８は、本発明の第２の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図である。【０１０８】  図６〜８には、図１〜３と同様に、無線通信によりＡＲに接続してＣＮ１２１との通信を行うＭＮ１０１と、ＭＮ１０１の通信相手となるＣＮ１２１と、サブネット１０３を形成するＡＲ１０５と、サブネット１０７を形成するＡＲ１０９と、ＭＮ１０１とＣＮ１２１との間における経路上に存在し、ＭＮ１０１とＣＮ１２１との間で伝送されるパケットに関してＱｏＳ保証を行うＱｏＳ認識機能（ＱｏＳ−ａｗａｒｅ）を有するＱＮＥ１１１、１１３、１１５、１１７、１１９、１２３、１２５とが図示されている。【０１０９】  なお、ＭＮ１０１がサブネット１０３に存在している場合（すなわち、ＭＮ１０１がＡＲ１０５に接続している場合）、ＣＮ１２１からＭＮ１０１へのｄｏｗｎｌｉｎｋ方向の経路１３７上には、ＱＮＥ１１９、ＱＮＥ１１７、ＱＮＥ１１５、ＱＮＥ１１３、ＱＮＥ１１１、ＡＲ１０５が存在しており、ＭＮ１０１がサブネット１０７に存在している場合（すなわち、ＭＮ１０１がＡＲ１０９に接続している場合）、ＣＮ１２１からＭＮ１０１へのｄｏｗｎｌｉｎｋ方向の経路１３９上には、ＱＮＥ１１９、ＱＮＥ１１７、ＱＮＥ１１５、ＱＮＥ１２５、ＱＮＥ１２３、ＡＲ１０９が存在しているものとする。なお、経路１３７と経路１３９とは一部が重複しており、経路１３７と経路１３９とのＣＲＮをＱＮＥ１１５とする。【０１１０】  図６において、ＣＮ１２１からＭＮ１０１に送信されるデータパケットは、経路１３７を経由して伝送される。このとき、経路１３７上のすべてのＱＮＥ１１１、１１３、１１５、１１７、１１９は、ＣＮ１２１からＭＮ１０１に送信されるデータパケットに関するＱｏＳステートを有している。すなわち、各ＱＮＥ１１１、１１３、１１５、１１７、１１９は、経路１３７のフィルタ情報（ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれているとともに、ＭＮ１０１がサブネット１０３から割り当てられているＩＰアドレス（ｃＣｏＡ）があて先アドレスとして含まれているフィルタ情報）であるｆｉｌｔｅｒＤと、このｆｉｌｔｅｒＤに対応するリソース予約情報であるｒｅｓｏｕｒｃｅＤとが関連付けられているＱｏＳステートを保持しており、ＣＮ１２１からＭＮ１０１に送信されるデータパケットのヘッダ（特に、送信元アドレス及びあて先アドレス）を参照してフィルタ情報（ｆｉｌｔｅｒＤ）を特定し、対応するリソース予約情報（ｒｅｓｏｕｒｃｅＤ）に基づくＱｏＳ保証を行うように構成されている。【０１１１】  ＭＮ１０１は、サブネット１０７に移動する可能性があり、プロ���シ１２３に対して予測経路（経路１３９）、又は予測経路の一部の確立を所望している。なお、ＭＮ１０１がサブネット１０７に移動する前に、プロキシ１２３によって予測経路、又は予測経路の一部が確立されることで、ＭＮ１０１が実際にサブネット１０７に移動した後に、より迅速にＣＮ１２１からＭＮ１０１へのＱｏＳ経路が確立され、ハンドオーバによるＱｏＳ保証の中断時間を短縮することが可能となる。【０１１２】  ＱＮＥ（プロキシ）１２３が予測経路を確立するための何らかのトリガを受けた場合には、ＱＮＥ（プロキシ）１２３とＣＲＮ（ここではＱＮＥ１１５）との間でＱｏＳ経路が確立される。この新たな経路が確立された場合には、ＱＮＥ（プロキシ）１２３や、ＱＮＥ（プロキシ）１２３とＱＮＥ１１５との間の各中間ＱＮＥ（例えば、ＱＮＥ１２５）は、新たなＱｏＳステートを有することになる。すなわち、図７に図示されているように、ＱＮＥ（プロキシ）１２３やＱＮＥ１２５では、ＣＮのＩＰアドレスが送信元アドレスとして含まれているとともに、ＱＮＥ（プロキシ）１２３のＩＰアドレスがあて先アドレスとして含まれているフィルタ情報（ｆｉｌｔｅｒＥ）に対して、ｆｉｌｔｅｒＤと同一のリソース予約情報であるｒｅｓｏｕｒｃｅＤが設定される。【０１１３】  一方、ＱＮＥ１１５とＣＮ１２１との間の経路上のＱＮＥに関しては、新たなフィルタ情報（上記のｆｉｌｔｅｒＥ）が現在のフィルタ情報（ｆｉｌｔｅｒＤ）に追加される。これにより、図７に図示されているように、ＱＮＥ１１５や、ＱＮＥ１１５とＣＮ１２１との間の各中間ＱＮＥ（例えば、ＱＮＥ１１７、１１９）は、ｆｉｌｔｅｒＤ及びｆｉｌｔｅｒＥに対してｒｅｓｏｕｒｃｅＤが設定されたＱｏＳステートを有することになり、ｆｉｌｔｅｒＥによって定義されるデータトラフィックには、ｆｉｌｔｅｒＤによって定義されるデータトラフィックのために予約されたｒｅｓｏｕｒｃｅＤが使用可能となる。【０１１４】  以上のように、ＭＮ１０１がサブネット１０７への移動を行う前に（あるいは、ＭＮ１０１のサブネット１０７への移動とは無関係に）、ＱＮＥ（プロキシ）１２３は、ＭＮ１０１のＮＣｏＡ（ＭＮ１０１がサブネット１０７に移動した後に割り当てられる新たなＣｏＡ）を用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路の一部（ＣＮ１２１からＱＮＥ（プロキシ）１２３までの経路）に係るリソース予約を行うことが可能となる（図７に図示されている状態）。【０１１５】  そして、ＭＮ１０１がＮＣｏＡを取得した場合（実際にサブネット１０７に移動してＮＣｏＡを取得するか、あるいはサブネット１０３に接続した状態でＮＣｏＡを取得した場合）には、図８に図示されているように、経路１３９上の各中間ＱＮＥ（ＱＮＥ１２３、１２５、１１５、１１７、１１９）において、ＭＮ１０１のＮＣｏＡが送信元アドレスとして含まれているとともに、ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれている新たなフィルタ情報（ｆｉｌｔｅｒＦ）がｆｉｌｔｅｒＤ又はｆｉｌｔｅｒＥに追加されることによって、ＱｏＳ経路の更新が行われる。なお、ＭＮ１０１がサブネット１０７に移動した場合には、ｆｉｌｔｅｒＤに関して��、能動的又は受動的に削除されることが望ましい。また、フローＩＤとは異なる情報としてフィルタ情報が存在する場合には、フローＩＤは、データパケットの送信元アドレス／あて先アドレスに依存するものでなくてもよい。【０１１６】  例えば、ＭＮ１０１がサブネット１０７に移動してＮＣｏＡを取得した後に、ＮＣｏＡに関するＱｏＳ経路の更新が完了（ｆｉｌｔｅｒＦに関するリソース予約が完了）する前までは、ＣＮ１２１からＭＮ１０１あてに送信されるデータパケットは、ｆｉｌｔｅｒＥの情報を含むアウタヘッダ（送信元アドレスをＣＮ１２１のＩＰアドレスとし、あて先アドレスをＱＮＥ（プロキシ）１２３のＩＰアドレスとするヘッダ）が付加されて、カプセル化される。このカプセル化されたデータパケットはｆｉｌｔｅｒＥによって識別され、各中間ＱＮＥにおいて、ｒｅｓｏｕｒｃｅＤに基づくＱｏＳ保証が行われて伝送され、ＱＮＥ（プロキシ）１２３によって脱カプセル化される。なお、ＣＮ１２１がＱＮＥの場合には、ＣＮ１２１からＭＮ１０１あてに送信されるデータパケットのカプセル化はＣＮ１２１で行われることが望ましいが、その他のＱＮＥ（例えば、経路上において、ＣＮ１２１の最も近くに存在するＱＮＥ１１９）でカプセル化が行われてもよい。【０１１７】  ＱＮＥ（プロキシ）１２３は、ｆｉｌｔｅｒＥで特定されるヘッダを持つパケットが到達した際には、脱カプセル化を行ってインナパケットを取り出し、そのインナパケットをＭＮ１０１に転送する。なお、経路全体にわたってＱｏＳ予約が行われるようにするための方法としては、例えばＩＰｖ４最小カプセル化など、上述のパケットのカプセル化方法以外にも存在することは、当業者にとって明白であり、任意のパケットのカプセル化方法を本発明に適用することが可能である。また、本発明は、他の種類のカプセル化やトンネリング機構においても良好に動作する。【０１１８】  このように、ＭＮ１０１のＮＣｏＡが設定されているｆｉｌｔｅｒＦに関するリソース予約が完了するまでは、データパケットのカプセル化が行われ、ＱＮＥ（プロキシ）１２３のＩＰアドレスがあて先アドレスとして設定されているｆｉｌｔｅｒＥによって、カプセル化されたデータパケットのＱｏＳ保証が行われるように構成されており、ＭＮ１０１のＮＣｏＡを用いてリソース予約が行われるまでのＱｏＳ保証の中断時間を低減することが可能となる。【０１１９】  また、ｆｉｌｔｅｒＦのＱｏＳの更新に成功した後（すなわち、ｆｉｌｔｅｒＦが経路１３９上のすべてのＱＮＥに導入された後）は、ＣＮ１２１は、ｆｉｌｔｅｒＥのデータパケットの生成（ｆｉｌｔｅｒＤのデータパケットのカプセル化）を終了する。そして、ｆｉｌｔｅｒＤやｆｉｌｔｅｒＥは能動的又は受動的に削除され、最終的にｆｉｌｔｅｒＦに関するＱｏＳステートのみが残り、ＣＮ１２１からサブネット１０７に接続しているＭＮ１０１への経路１３９において、ＣＮ１２１からＭＮ１０１へのデータパケットに対するＱｏＳ保証が行われる。【０１２０】  次に、本発明の第２の実施の形態における動作について説明する。図９は、本発明の第２の実施の形態における動作例を示すシーケンスチャートである。なお、ここでは具体例として���上述の本発明の第１の実施の形態と同様に、ＮＳＩＳのＱｏＳ  ＮＳＬＰで定義されているメッセージであるＲＥＳＥＲＶＥメッセージに、さらに本発明の動作に必要な情報を付加した場合について説明する。また、本発明の第２の実施の形態におけるＱＮＥの構成は、上述の本発明の第１の実施の形態におけるＱＮＥの構成（図４参照）と同一であり、ここでは説明を省略する。【０１２１】  図９において、ＱＮＥ（プロキシ）１２３は、ＣＮ１２１から、サブネット１０３に接続しているＭＮ１０１のデータ経路情報（例えば、リソース稼働率など）を取得するとともに、ｄｏｗｎｌｉｎｋ方向のＣＲＮ（ここでは、ＱＮＥ１１５）をあらかじめ特定する（ステップＳ３０１）。なお、例えば、ＱＮＥ（プロキシ）１２３は、上述の非特許文献９、１０などに記載されている方法を使用することによって、これらの情報を取得することが可能である。【０１２２】  そして、ＱＮＥ（プロキシ）１２３は、上述の本発明の第１の実施の形態と同様に、予測経路を確立するための何らかのトリガを受け取る（ステップＳ３０３）。なお、このトリガには、上述の本発明の第１の実施の形態と同様に、例えば、ＭＮ１０１とＣＮ１２１との間のＱｏＳ経路で用いられているセッションＩＤ、ＱＳｐｅｃ情報、ＣＮ１２１（又は経路の最終ＱＮＥであるＱＮＲ）のＩＰアドレスなど、予測経路を確立するために必要な情報が含まれている。【０１２３】  トリガを受け取ったＱＮＥ（プロキシ）１２３は、このトリガに応じて、即座に「プロキシフラグ」が付加された受信者始動ＲＥＳＥＲＶＥメッセージをＣＮ１２１に向かって送信する（ステップＳ３０５）。なお、この予約におけるフィルタ情報には、送信元アドレスとしてＣＮ１２１のＩＰアドレス、あて先アドレスとしてＱＮＥ（プロキシ）１２３のＩＰアドレスが含まれている（図７のｆｉｌｔｅｒＥ）。また、ＱＮＥ（プロキシ）１２３は、このフィルタ情報に対応したフィルタ／リソース（図７のｆｉｌｔｅｒＥ／ｒｅｓｏｕｒｃｅＤ）の組を生成して新たな予約を行う。また、ステップＳ３０７でＱＮＥ１２３からＲＥＳＥＲＶＥメッセージを受けたＱＮＥ１２５も同様に、このフィルタ情報に対応したフィルタ／リソース（図７のｆｉｌｔｅｒＥ／ｒｅｓｏｕｒｃｅＤ）の組を生成して新たな予約を行う。【０１２４】  一方、ＱＮＥ１１７、ＱＮＥ１１９、ＣＮ１２１（ＣＮ１２１がＱＮＥの場合）では、ＲＥＳＥＲＶＥメッセージ（図９では、ＲＥＳＥＲＶＥ（ａｄｄ）と記載）の伝送が行われる（ステップＳ３０９、Ｓ３１１、Ｓ３１３）とともに、このＲＥＳＥＲＶＥメッセージに含まれているフィルタ情報（図７のｆｉｌｔｅｒＥ）が、ＣＮ１２１からＭＮ１０１へのデータパケットに現在使用されている現在のフィルタ／リソース（図６のｆｉｌｔｅｒＤ／ｒｅｓｏｕｒｃｅＤ）の組に追加される。以上の動作により、各ＱＮＥには、図７に図示されているリソース予約情報が設定される。【０１２５】  なお、このＱＮＥ（プロキシ）１２３から送信されるＲＥＳＥＲＶＥメッセージには、ＣＲＮ（ＱＮＥ１１５）以降の経路において上記のようなフィルタ情報の追加処理を行う旨を示す情報が含まれており、ＱＮＥ１１５が、この情報を参照して上���のＱＮＥ（ＱＮＥ１１７）に対して追加処理を指示するＲＥＳＥＲＶＥメッセージを送信してもよい。また、ＱＮＥ１１５は、ＲＥＳＥＲＶＥメッセージを受信した下流のＱＮＥ（ＱＮＥ１２５）が、同一セッションに属する経路１３７とは異なる方向に存在していることから、自らがＣＲＮであることを把握してもよい。また、各ＱＮＥは、リソース予約情報に、受信したＲＥＳＥＲＶＥメッセージのフィルタ情報が属するセッションと同一セッションの他の経路（他のフィルタ情報）を保持している場合には、元々保持しているフィルタ情報に、ＲＥＳＥＲＶＥメッセージのフィルタ情報を追加するように構成されていてもよい。【０１２６】  ここで、ＭＮ１０１がサブネット１０７に移動したとする（ステップＳ３１５）。ＱＮＥ（プロキシ）１２３はＭＮ１０１の移動を検出し、ＭＮ１０１のＮＣｏＡを取得した場合（ステップＳ３２１）には、送信者主導のＲＥＳＥＲＶＥメッセージをＭＮ１０１に送信する（ステップＳ３２３）。このＲＥＳＥＲＶＥメッセージに関するフィルタ情報には、送信元アドレスとしてＣＮ１２１のアドレスが含まれており、あて先アドレスとしてＭＮ１０１のＮＣｏＡが含まれている。【０１２７】  一方、ＣＮ１２１も、例えばＭＮ１０１からのＢＵによって、ＭＮ１０１の移動を検出して、ＭＮ１０１のＮＣｏＡを取得する（ステップＳ３１７）。そして、ＣＮ１２１は、ＭＮ１０１へのデータパケットのカプセル化を開始する（ステップＳ３１９）。このカプセル化では、ＣＮ１２１は、ＭＮ１０１のＮＣｏＡをあて先アドレスとするパケットに、あて先アドレスがＱＮＥ（プロキシ）１２３のアドレスに設定されたアウタヘッダを付加したパケットを生成して送信する。カプセル化されたデータパケットは、そのあて先アドレスがＱＮＥ（プロキシ）１２３であり、経路１２９上の各ＱＮＥでは、ｆｉｌｔｅｒＥのフィルタ情報に係るＱｏＳ処理が行われ、その結果、ＱｏＳ保証を受けることになる。【０１２８】  ステップＳ３２３でＲＥＳＥＲＶＥメッセージを送信した後、ＱＮＥ（プロキシ）１２３は、受信者始動ＲＥＳＥＲＶＥメッセージ（図９では、ＲＥＳＥＲＶＥ（ａｄｄ）と記載）をＣＮ１２１に送信する（ステップＳ３２５）。この予約におけるフィルタ情報には、あて先アドレスとしてＭＮ１０１のＩＰアドレスが含まれている。そして、各ＱＮＥ（ＱＮＥ１２５、１１５、１１７、１１９）を経由してＲＥＳＥＲＶＥメッセージは伝送されるとともに（ステップＳ３２７、Ｓ３２９、Ｓ３３１、Ｓ３３３）、各ＱＮＥにおいて、このＲＥＳＥＲＶＥメッセージに含まれるフィルタ情報（図８のｆｉｌｔｅｒＦ）が、以前に付加又は生成されたフィルタ情報（図７のｆｉｌｔｅｒＥ）に付加される。以上の動作により、各ＱＮＥには、図８に図示されているリソース予約情報が設定される。そして、ＣＮ１２１は、このＲＥＳＥＲＶＥメッセージを受信した場合に、データパケットのカプセル化を終了する（ステップＳ３３５）。【０１２９】  そして、ＣＮ１２１は、ステップＳ３０５〜Ｓ３１３で導入されたＱＮＥ（プロキシ）１２３をあて先アドレスとするフィルタ情報（図７のｆｉｌｔｅｒＥ）を削除するために、送信者主導のＲＥＳＥＲＶＥメッセー��（図９ではＲＥＳＥＲＶＥ（ｒｅｍｏｖｅ）と記載）をＱＮＥ（プロキシ）１２３に送信する（ステップＳ３３７、Ｓ３３９、Ｓ３４１、Ｓ３４３、Ｓ３４５）。なお、必ずしもＲＥＳＥＲＶＥメッセージによるフィルタ情報の削除を行う必要はなく、このフィルタ情報は、タイマのタイムアウトによって削除されてもよい。【０１３０】  以上、説明したように、本発明の第２の実施の形態によれば、ＱＮＥ（プロキシ）１２３が、ＭＮ１０１のサブネット１０７において割り当てられるＮＣｏＡを用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路（ＣＮ１２１からＭＮ１０１までの経路）の一部（ＣＮ１２１からＱＮＥ（プロキシ）１２３までの経路）に係るリソース予約を行い、ＣＮ１２１からＭＮ１０１までの完全な経路が確立されるまでは、ＱＮＥ（プロキシ）１２３が確立した経路及びＱｏＳステートによってデータパケットが行われることで、ＭＮ１０１がサブネット１０３からサブネット１０７に接続を変更した場合において、ＣＮ１２１からＭＮ１０１に送られるデータパケットのＱｏＳ保証の中断時間を低減することが可能となる。【０１３１】  ＜第３の実施の形態＞
次に、本発明の第３の実施の形態について説明する。上述の説明ではフィルタ情報（ｆｉｌｔｅｒ）及びフローＩＤに明確な違いがなされていないが、以下、それぞれを明確に定義した場合の各ＱＮＥの機能や、シグナリングメッセージの処理などについて説明する。【０１３２】  まず、本発明の第３の実施の形態におけるフィルタ情報について説明する。本発明の第３の実施の形態では、フィルタ情報を、各ＱＮＥがパケットクラシファイア（ｐａｃｋｅｔ  ｃｌａｓｓｉｆｉｅｒ）として使用する情報として定義する。フィルタ情報は、ＲＳＶＰにおけるフィルタスペック（ｆｉｌｔｅｒ  ｓｐｅｃ）と同様に、ＱｏＳ予約を行うためのシグナリングメッセージのパラメータとして各ＱＮＥに運ばれる。すなわち、ＮＳＩＳでは、フィルタ情報は、主にＮＳＬＰにて生成され、管理される情報となる。各ＱＮＥは、このフィルタ情報を、要求されているＱｏＳリソースの情報と共に格納することにより、どのデータパケットに対して予約されたＱｏＳリソースを与えるかの区別を行う。そのため、フィルタ情報には、予約されたＱｏＳの保証を受けるデータパケットのヘッダ情報が含まれる。すなわち、フィルタ情報に含まれる情報の例としては、ＲＳＶＰにおけるフィルタスペックと同様に、送信元・あて先ＩＰアドレスや、プロトコル識別子、ポート番号、フローラベル（ＩＰｖ６の場合）、ＳＰＩ（Ｓｅｃｕｒｉｔｙ  Ｐａｒａｍｅｔｅｒｓ  Ｉｎｄｅｘ）（ＩＰＳｅｃでカプセル化されている場合）、ＤＳＣＰ／ＴＯＳ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅｓ  Ｃｏｄｅ  Ｐｏｉｎｔ／Ｔｙｐｅ  ｏｆ  Ｓｅｒｖｉｃｅ）フィールドなどである。【０１３３】  また、フィルタ情報は、１つのＱｏＳ予約に対してフィルタリスト（ｆｉｌｔｅｒ−ｌｉｓｔ）の形を取ってもよい。この場合、１つのＱｏＳ予約に対して、ＱＮＥは、フィルタリスト内のどのフィルタ情報と同じ内容のヘッダを持つデータパケットを受けた場合でも、予約されているリソースを与えることが可能となる。【０１３４】  フィルタリストは、このリストがどのフローやセッションに属するものかを表す識別子（例えば、フローＩＤや、セッションＩＤなど）と共に管理されてもよい。また、同一セッションに属するデータパケットが異なる性質を持つ複数の経路（例えば、モバイルＩＰにおける三角経路と最適化経路や、マルチホーム端末を使った通信における複数の経路など）を用いて送受信される場合には、フローＩＤやセッションＩＤのほかに、これらの複数の経路の種別を識別する識別子（例えば、Ｐａｔｈ  Ｔｙｐｅ  ＩＤ（非特許文献１２参照）など）と共に管理されてもよい。【０１３５】  以下に、フィルタリストの管理方法の一例について説明する。ＱｏＳ予約を行うためのシグナリングメッセージ（例えば、ＮＳＩＳのＲＥＳＥＲＶＥメッセージなど）により運ばれるフィルタリストの与え方の例として、
Ｆｉｌｔｅｒ−Ｌｉｓｔ：：＝〈Ｌｉｓｔ  Ｌｅｎｇｔｈ〉〈Ａｃｔｉｏｎ〉〈Ｆｉｌｔｅｒ〉〈Ｆｉｌｔｅｒ〉・・・；
などが考えられる。ここで、フィルタリストは、〈Ｌｉｓｔ  Ｌｅｎｇｔｈ〉、〈Ａｃｔｉｏｎ〉、及び複数のフィルタ情報（〈Ｆｉｌｔｅｒ〉）を有している。なお、〈Ｌｉｓｔ  Ｌｅｎｇｔｈ〉では、フィルタリストに含まれるフィルタ情報の個数（すなわち、〈Ｆｉｌｔｅｒ〉の個数）が示される。また、〈Ａｃｔｉｏｎ〉では、各ＱＮＥでこのフィルタリストをどのように扱うかを指定する情報が示される。例えば、〈Ａｃｔｉｏｎ〉に含まれる情報としては、「追加（ａｄｄ）」、「削除（ｓｕｂ）」、「置き換え（Ｒｅｐｌａｃｅ）」などが考えられる。例えば、〈Ａｃｔｉｏｎ〉が「追加（Ａｄｄ）」の場合には、そのＱＮＥ上に同一セッションＩＤ及びＰａｔｈ  Ｔｙｐｅ  ＩＤ（存在する場合）に対応する既存のフィルタリストが存在する場合には、そのリストに後続のフィルタ情報〈Ｆｉｌｔｅｒ〉が追加され、存在しない場合には、新たにフィルタリストが作られ、それに対応するリソースが予約される。また、例えば、〈Ａｃｔｉｏｎ〉が「削除（ｓｕｂ）」の場合には、同一セッションＩＤ及びＰａｔｈ  Ｔｙｐｅ  ＩＤ（存在する場合）に対応する既存のフィルタリストから、後続のフィルタ情報〈Ｆｉｌｔｅｒ〉だけが削除される。また、例えば、〈Ａｃｔｉｏｎ〉が「置き換え（Ｒｅｐｌａｃｅ）」の場合には、ＱＮＥ上の同一セッションＩＤ及びＰａｔｈ  Ｔｙｐｅ  ＩＤ（存在する場合）に対応する既存のフィルタリストそのものが置き換えられる。【０１３６】  また、例えば、
Ｆｉｌｔｅｒ−Ｌｉｓｔ：：＝〈Ｌｉｓｔ  Ｌｅｎｇｔｈ〉〈Ａｃｔｉｏｎ〉〈Ｆｉｌｔｅｒ〉〈Ｆｉｌｔｅｒ〉・・・〈Ｌｉｓｔ  Ｌｅｎｇｔｈ〉〈Ａｃｔｉｏｎ〉〈Ｆｉｌｔｅｒ〉〈Ｆｉｌｔｅｒ〉・・・；
という形式を取ることにより、１つのフィルタリストによって、フィルタ情報に係る複数の変更動作を一度に行えるようにすることも可能である。例えば、あるＱＮＥが、セッションＩＤ“３００”、Ｐａｔｈ  Ｔｙｐｅ  ＩＤ“０ｘ００”に対し、３つのフィルタ情報（〈ｆｉｌｔｅｒ１〉、〈ｆｉｌｔｅｒ２〉、〈ｆｉｌｔｅｒ３〉）を含むフィルタリスト
Ｆｉｌｔｅｒ−ｌｉｓｔ：＝〈ｆｉｌｔｅｒ１〉〈ｆｉｌｔｅｒ２〉〈ｆｉｌｔｅｒ３〉；
を格納していた場合、同一セッションＩＤ及びＰａｔｈ  Ｔｙｐｅ  ＩＤを持つＲＥＳＥＲＶＥメッセージを受信し、その中に含まれるフィルタ情報が
Ｆｉｌｔｅｒ−Ｌｉｓｔ：：＝〈２〉〈ａｄｄ〉〈Ｆｉｌｔｅｒ４〉〈Ｆｉｌｔｅｒ５〉〈１〉〈ｓｕｂ〉〈Ｆｉｌｔｅｒ１〉；
であった場合には、このＱＮＥに格納されるフィルタリストは、
Ｆｉｌｔｅｒ−ｌｉｓｔ：＝〈Ｆｉｌｔｅｒ２〉〈Ｆｉｌｔｅｒ３〉〈Ｆｉｌｔｅｒ４〉〈Ｆｉｌｔｅｒ５〉；
に更新される。なお、上記のフィルタリストの形式は一例であり、ＱｏＳ予約を行うためのシグナリングメッセージにおいて、フィルタ情報及びそのフィルタ情報に対して行う処理（ａｃｔｉｏｎ）の情報が明確にできるのであれば、他の形式を取ることや、他の情報を持つことも可能である。【０１３７】  次に、本発明の第３の実施の形態におけるフローＩＤについて説明する。本発明の第３の実施の形態では、フローＩＤは、主にＮＳＩＳの下位層であるＮＴＬＰで管理され、ＮＴＬＰにおいて、シグナリングメッセージがどのフローに属するかを識別するために使われる。フローＩＤとセッションＩＤとの違いは、セッションＩＤはセッションの開始から終了まで変化しないＩＤであるのに対し、フローＩＤは、例えば端末の移動などによる経路変更により、変化してもよいという点にある。また、１つのセッションに対し、複数のフローＩＤが存在してもよい。なお、本発明の第３の実施の形態におけるフローＩＤは、非特許文献１１Ａでは、ＭＲＩ（Ｍｅｓｓａｇｅ  Ｒｏｕｔｉｎｇ  Ｉｎｆｏｒｍａｔｉｏｎ）として位置付けられているものであるが、含まれる情報はこの通りではない。本発明の第３の実施の形態におけるフローＩＤの一例としては、シグナリングメッセージの送信元とあて先のＩＰアドレスを含む情報が考えられる。なお、この場合、本発明の第３の実施の形態におけるフローＩＤには、非特許文献１１Ａで記されているフローＩＤのように必ずしもプロトコル識別子、ポート番号などのフィルタ情報が持つ情報が含まれる必要はない。また、データの送信元・あて先と、シグナリングメッセージの送信元・あて先が異なる場合や、送信元・あて先が同じであっても、ポート番号など他のフィルタ情報が異なる場合で、シグナリングメッセージもデータパケットと同様にＱｏＳ保証を必要とする場合は、シグナリングメッセージのフィルタ情報を、フィルタリストに追加すればよい。【０１３８】  また、図１７は、本発明の第３の実施の形態において、ＱＮＥ内でフィルタ情報及びフローＩＤを管理する主体を模式的に示す図である。上述のように、ＮＳＩＳプロトコル層では、フィルタ情報及びフローＩＤの２つの情報が管理されるが、フィルタ情報（フィルタリスト）は、主にＮＳＩＳの上位層であるＮＳＬＰ層において管理され、フローＩＤは、主にＮＳＩＳの下位層であるＮＴＬＰ層において管理される。なお、フィルタ情報やフローＩＤの管理や生成に関しては、必ずしも、図１７に示されているようにＮＳＬＰ層やＮＴＬＰ層が単独で行う必要はなく、ＮＳＬＰ層とＮＴＬＰ層の間で情報の交換を行ったり、他の層と情報を交換したりすることにより管理・生成が行われてもよい。【０１３９】  このように、ＮＳＩＳプロトコル層において管理される情報を、フィルタ情報及びフローＩＤに明確に分けて定義を行うことにより、各ＱＮＥはデータパケットの送受信を行う端末の情報（例えば、データの送信元・あて先に設定されるＩＰアドレス）を必要とすることなく、シグナリングメッセージを送信することが可能になる。この特性を用いたＱｏＳ経路の早期確立方法を以下に説明する。【０１４０】  なお、ここでは、データパケットの送信される方向がｕｐｌｉｎｋ方向であった場合を例に挙げて説明を行うが、データパケットの送信される方向がｄｏｗｎｌｉｎｋ方向であった場合にも同様の手順を用いることができる。【０１４１】  まず、図１２〜１４を参照しながら、本発明の第３の実施の形態に係る概要について説明する。図１２は、本発明の第３の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ予約の状態及びルーティングのためのステート内に含まれるフローＩＤの状態を模式的に示す図である。また、図１３は、本発明の第３の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路上にルーティングのためのステートを確立した状態を、この中に含まれるフローＩＤを示すことにより模式的に示す図である。また、図１４は、本発明の第３の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図である。【０１４２】  図１２〜１４には、図１〜３と同様に、無線通信によりＡＲに接続してＣＮ１２１との通信を行うＭＮ１０１と、ＭＮ１０１の通信相手となるＣＮ１２１と、サブネット１０３を形成するＡＲ１０５と、サブネット１０７を形成するＡＲ１０９と、ＭＮ１０１とＣＮ１２１との間における経路上に存在し、ＭＮ１０１とＣＮ１２１との間で伝送されるパケットに関してＱｏＳ保証を行うＱｏＳ認識機能（ＱｏＳ−ａｗａｒｅ）を有するＱＮＥ１１１、１１３、１１５、１１７、１１９、１２３、１２５とが図示されている。【０１４３】  なお、ＭＮ１０１がサブネット１０３に存在している場合（すなわち、ＭＮ１０１がＡＲ１０５に接続している場合）、ＭＮ１０１からＣＮ１２１へのｕｐｌｉｎｋ方向の経路１４７上には、ＡＲ１０５、ＱＮＥ１１１、ＱＮＥ１１３、ＱＮＥ１１５、ＱＮＥ１１７、ＱＮＥ１１９が存在しており、ＭＮ１０１がサブネット１０７に存在している場合（すなわち、ＭＮ１０１がＡＲ１０９に接続している場合）、ＭＮ１０１からＣＮ１２１へのｕｐｌｉｎｋ方向の経路１４９上には、ＡＲ１０９、ＱＮＥ１２３、ＱＮＥ１２５、ＱＮＥ１１５、ＱＮＥ１１７、ＱＮＥ１１９が存在しているものとする。なお、経路１４７と経路１４９とは一部が重複しており、経路１４７と経路１４９とのＣＲＮをＱＮＥ１１５とする。【０１４４】  図１２において、ＭＮ１０１からＣＮ１２１に送信されるデータパケットは、経路１４７を経由して伝送される。このとき、経路１４７上のすべてのＱＮＥ１１１、１１３、１１５、１１７、１１９は、ＭＮ１０１からＣＮ１２１に送信されるデータパケットに関するＱｏＳ予約に係るステートを有している。すなわち、各ＱＮＥ１１１、１１３、１１５、１１７、１１９は、経路１４７を通して送られるデータパケットに関するフィルタ情報（ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれているとともに、ＭＮ１０１がサブネット１０３から割り当てられているＩＰアドレス（ｃＣｏＡ）が送信元アドレスとして含まれているフィルタ情報）であるｆｉｌｔｅｒＧを含むフィルタリストと、このフィルタリストに対応するリソース予約情報であるｒｅｓｏｕｒｃｅＧとが関連付けられているＱｏＳ予約に係るステートを保持しており���ＣＮ１２１からＭＮ１０１に送信されるデータパケットのヘッダを参照してフィルタ情報（ｆｉｌｔｅｒＧ）を特定し、対応するリソース予約情報（ｒｅｓｏｕｒｃｅＧ）に基づくＱｏＳ保証を行うように構成されている。【０１４５】  また同時に、各ＱＮＥ１１１、１１３、１１５、１１７、１１９のＮＴＬＰ層では、シグナリングメッセージの識別とルーティングのためのステート（ルーティングステートやメッセージアソシエーション（非特許文献１１Ａ参照））を保持している。このルーティングのためのステート内には、経路１４７におけるシグナリングメッセージの送信元及びあて先を含む情報から作られるフローＩＤが含まれる。今、シグナリングメッセージの送信元をＭＮ１０１（ｃＣｏＡをＸとする）、シグナリングメッセージのあて先をＣＮ１２１（ＩＰアドレスをＹとする）であるとし、各ＱＮＥ１１１、１１３、１１５、１１７、１１９のＮＴＬＰ層がルーティングのためのステートの中に持つフローＩＤを、ｆｌｏｗＸＹとする。【０１４６】  ＭＮ１０１は、サブネット１０７に移動する可能性があり、ＱＮＥ（プロキシ）１２３に対して予測経路（経路１４９）の一部の確立の準備（すなわち、ＱＮＥ（プロキシ）１２３からＣＮ１２１の確立の準備）を所望している。すなわち、ＭＮ１０１は、この経路上の各ＱＮＥに対して、サブネット１０７に移動した後のルーティングのためのステートをあらかじめ保有しておくことを所望している。なお、ＭＮ１０１がサブネット１０７に移動する前に、ＱＮＥ（プロキシ）１２３によって予測経路の一部が準備されることで、ＭＮ１０１が実際にサブネット１０７に移動した後に、より迅速にＣＮ１２１からＭＮ１０１へのＱｏＳ経路が確立され、ハンドオーバによるＱｏＳ保証の中断時間を短縮することが可能となる。その理由は、ルーティングのためのステートの新規確立には複雑な処理が必要になるが、このルーティングのためのステートはいったん確立されてしまえば、このステートを用いてシグナリングメッセージをルーティングすることができるからである。【０１４７】  ＱＮＥ（プロキシ）１２３が予測経路の確立を準備するための何らかのトリガを受けた場合には、ＱＮＥ（プロキシ）１２３は、ＱＮＥ（プロキシ）１２３とＣＮ１２１との間のＱＮＥにおけるルーティングのためのステートの新規確立処理を始動し、その結果、ＱＮＥ（プロキシ）１２３とＣＮ１２１との間のＱＮＥにルーティングのためのステートが保有される。すなわち、図１３に図示されているように、ＱＮＥ（プロキシ）１２３、ＱＮＥ１２５、１１５、１１７、１１９のＮＴＬＰ層では、ＱＮＥ（プロキシ）１２３のＩＰアドレス（Ｚとする）が送信元アドレスとして含まれているとともに、ＣＮ１２１のＩＰアドレス（すなわちＹ）があて先アドレスとして含まれているフローＩＤ（ｆｌｏｗＺＹ）を含むルーティングのためのステートが設定される。なお、経路１４７に関するルーティングのためのステートはそのまま残される。【０１４８】  以上のように、ＭＮ１０１がサブネット１０７への移動を行う前に（あるいは、ＭＮ１０１のサブネット１０７への移動とは無関係に）、ＱＮＥ（プロキシ）１２３は、ＭＮ１０１のＮＣｏＡ（ＭＮ１０��がサブネット１０７に移動した後に割り当てられる新たなＣｏＡ）を用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路の一部（ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路）に係るルーティングのためのステートを確立することが可能である（図１３に図示されている状態）。【０１４９】  そして、ＭＮ１０１がＮＣｏＡを取得した場合（実際にサブネット１０７に移動してＮＣｏＡを取得するか、あるいはサブネット１０３に接続した状態でＮＣｏＡを取得した場合）には、このＭＮ１０１のＮＣｏＡをデータパケットの送信元、ＣＮ１２１のＩＰアドレスをデータパケットのあて先としたフィルタ情報（ｆｉｌｔｅｒＨ）が作成される。そして、図１４に図示されているように、経路１４９上のＱＮＥ（プロキシ）１２３、ＱＮＥ１２５においてはｆｉｌｔｅｒＨを含むフィルタリストが新規で格納されるとともに、ＱＮＥ１１５、１１７、１１９においては、ｆｉｌｔｅｒＨが既存の（同一セッション用の）フィルタリストに追加される。【０１５０】  また、ＭＮ１０１がサブネット１０７に移動した場合には、ＭＮ１０１からＱＮＥ（プロキシ）１２３の間のルーティングのためのステートを確立することにより、ＭＮ１０１からＣＮ１２１までのエンド・ツー・エンドのルーティングのためのステートが確立される。ＭＮ１０１からＱＮＥ（プロキシ）１２３の間のルーティングのためのステートで使われるフローＩＤは、ＱＮＥ（プロキシ）１２３からＣＮ１２１で使われているもの（ｆｌｏｗＺＹ）とは異なり、ＭＮ１０１がサブネット１０７で取得したＮＣｏＡ（Ｗとする）をシグナリングメッセージの送信元、ＱＮＥ（プロキシ）１２３のＩＰアドレス（すなわちＺ）をシグナリングメッセージのあて先としたフローＩＤ（ｆｌｏｗＷＺ）であってよい。また、エンド・ツー・エンドのフローＩＤを統一するため、ＭＮ１０１からＱＮＥ（プロキシ）１２３の間のルーティングのためのステートで使われるフローＩＤは、ＱＮＥ（プロキシ）１２３からＣＮ１２１で使われているもの（ｆｌｏｗＺＹ）であってもよい。【０１５１】  なお、ＭＮ１０１からＱＮＥ（プロキシ）１２３の間のフローＩＤが、ＱＮＥ（プロキシ１２３）からＣＮ１２１で使われているものと異なる場合、ＱＮＥ（プロキシ）１２３において、サブネット１０７上のＭＮ１０１から送信されるシグナリングメッセージに付加されているフローＩＤ（ｆｌｏｗＷＺ）をｆｌｏｗＺＹに付け替えて、ＣＮ１２１に向けて送信するなどの動作が必要である。また、上述のように、経路１４９上に既にシグナリングメッセージのルーティングのためのステートが存在するため、ＱｏＳリソース予約のための動作は、ＱＮＥ（プロキシ）１２３より先では、経路１４９上に新規でＱｏＳ予約のためのシグナリングメッセージを送る場合に比べて迅速に行われ、その結果、ＭＮ１０１のＮＣｏＡを用いてＱｏＳリソース予約が行われるまでのＱｏＳ保証の中断時間を低減することが可能となる。また、ＭＮ１０１がサブネット１０７に移動した後に、移動前に使用されていたフィルタ情報（ｆｉｌｔｅｒＧ）や、経路１４７のルーティングのためのステートに関しては、能動的又は受動的に削除されること��望ましい。【０１５２】  次に、本発明の第３の実施の形態における第１動作例について説明する。図１５は、本発明の第３の実施の形態において、データパケットの送信方向がｕｐｌｉｎｋ方向の場合の動作例を示すシーケンスチャートである。なお、ここでは具体例として、各ＱＮＥにおいてルーティングのためのステートを作るために送信される、フィルタ情報を必要としないメッセージとして、ＮＳＩＳのＱｏＳ  ＮＳＬＰで定義されているメッセージであるＱＵＥＲＹメッセージに、さらに本発明の動作に必要な情報を付加した場合について説明する。また、ＱｏＳリソースを予約するためのメッセージとして、ＮＳＩＳのＱｏＳ  ＮＳＬＰで定義されているメッセージであるＲＥＳＥＲＶＥメッセージに、さらに本発明の動作に必要な情報を付加した場合について説明する。なお、本発明の第３の実施の形態で使用される「ＲＥＳＥＲＶＥメッセージ」や「ＱＵＥＲＹメッセージ」、「ＲＥＳＰＯＮＳＥメッセージ」という用語は、ＮＳＬＰ層で生成される情報（メッセージのペイロード部と呼ぶ）、ＮＴＬＰ層で生成される情報（ヘッダ部と呼ぶ）及びＩＰヘッダ（オプション部分を含む）を含んでいる。【０１５３】  図１５において、まず、ＱＮＥ（プロキシ）１２３は、予測経路を準備するためのトリガを受ける（ステップＳ４０１）。なお、このトリガには、例えば、ＭＮ１０１とＣＮ１２１との間のＱｏＳ経路で用いられているセッションＩＤ、ＣＮ１２１（又は経路の最終ＱＮＥであるＱＮＲ）のＩＰアドレスなど、予測経路を確立するために必要な情報が含まれている。【０１５４】  トリガを受け取ったＱＮＥ（プロキシ）１２３は、このトリガに応じて、即座に、ＮＳＬＰ層においてＱＵＥＲＹメッセージのペイロード部を生成し、ＮＴＬＰ層に受け渡す。ＮＴＬＰ層ではこれを受けて、自身をシグナリングメッセージの送信元、ＣＮ１２１をあて先としたフローＩＤを生成し（ステップＳ４０３）、このフローＩＤをヘッダ部に含むＱＵＥＲＹメッセージを、下位層を経由してＣＮ１２１に向けて送信する（ステップＳ４０５）。なお、このＱＵＥＲＹメッセージは、経路１４９における新規のｄｏｗｎｓｔｒｅａｍ方向（データ送信方向と同じ方向）へのメッセージであるので、このＱＵＥＲＹメッセージのＩＰヘッダにはＱＮＥ用のＲＡＯが付けられる。【０１５５】  ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路上のすべてのＱＮＥ（ＱＮＥ１２５、１１５、１１７、１１９）は、ＱＵＥＲＹメッセージを受信してＩＰヘッダにＲＡＯを発見すると、ＮＳＩＳ層（ＮＳＬＰ層及びＮＴＬＰ層）においてＱＵＥＲＹメッセージの中身を確認して、必要な処理を行う。すなわち、ＱＵＥＲＹメッセージを受信したＱＮＥ１２５、１１５、１１７、１１９は、ＱｏＳＮＳＬＰ層におけるＱＵＥＲＹ処理以外に、ＮＴＬＰ層においてルーティングのためのステートの確立処理（ルーティングステートや、メッセージアソシエーション（要求されている場合）の確立のための処理）を行う（ステップＳ４０７、Ｓ４１１、Ｓ４１５、Ｓ４１９、Ｓ４２３）。その後、各ＱＮＥはＱＵＥＲＹメッセージをＣＮ１２１に向けて送信する（ステップＳ４０９、Ｓ４１３、Ｓ４１７、Ｓ４２１）。そして��ＱＵＥＲＹメッセージがＣＮ１２１に到達すると、このＱＵＥＲＹメッセージに対するＲＥＳＰＯＮＳＥメッセージがＣＮ１２１からＱＮＥ１２３に返される（ステップＳ４２５、Ｓ４２７、Ｓ４２９、Ｓ４３１、Ｓ４３３）。【０１５６】  ここで、ＭＮ１０１がサブネット１０７に移動したとする（ステップＳ４３５）。ＭＮ１０１は、サブネット１０７よりＮＣｏＡを取得すると、ＮＴＬＰ層において、このＮＣｏＡをシグナリングメッセージの送信元、ＱＮＥ（プロキシ）１２３をシグナリングメッセージのあて先としたフローＩＤを生成する（ステップＳ４３７）。また、ＭＮ１０１のＮＳＬＰ層では、自身のＮＣｏＡをデータパケットの送信元、ＣＮ１２１のＩＰアドレスをデータパケットのあて先とした情報を含むフィルタ情報を生成し、このフィルタ情報を追加（ａｄｄ）してＱｏＳリソースを予約するような送信者主導のＲＥＳＥＲＶＥメッセージ（図１５ではＲＥＳＥＲＶＥ（ａｄｄ）と記載）をＱＮＥ（プロキシ）１２３に向けて送信する（ステップＳ４３９）。このＲＥＳＥＲＶＥメッセージは、経路１４９におけるＭＮ１０１からＱＮＥ（プロキシ）１２３に対する新規のｄｏｗｎｓｔｒｅａｍ方向（データ送信方向と同じ方向）へのメッセージであるので、このＲＥＳＥＲＶＥメッセージのＩＰヘッダにはＱＮＥ用のＲＡＯが付けられる。【０１５７】  このＲＥＳＥＲＶＥメッセージを受け取ったＱＮＥ（プロキシ）１２３は、ＮＴＬＰにおいてルーティングのためのステートの確立処理を行う（ステップＳ４４１）とともに、ＮＳＬＰにおいてリソース予約のための処理を行う。また、ＮＴＬＰ層ではセッションＩＤなどの情報から、このＲＥＳＥＲＶＥメッセージをＣＮ１２１に送信する必要があることを認識し、このＲＥＳＥＲＶＥメッセージに含まれるフローＩＤの情報を、ステップＳ４０３で生成されたフローＩＤに変更し、ＣＮ１２１に向けて送信する（ステップＳ４４３）。この際、ＮＴＬＰは、メッセージをＣＮ１２１に向けて送信する必要があるということを、ＮＳＬＰに伝えてもよい。なお、この場合、ルーティングのためのステートは、ＱＮＥ１２３、１２５、１１５、１１７、１１９に既に確立されているので、ＲＥＳＥＲＶＥメッセージにＲＡＯが付加される必要はなく、ＱＮＥ１２３、１２５、１１５、１１７、１１９は、受信したＲＥＳＥＲＶＥメッセージを参照してリソース予約のための処理を行い、迅速にＲＥＳＥＲＶＥメッセージを送信することができる（ステップＳ４４５、Ｓ４４７、Ｓ４４９、Ｓ４５１）。なお、ＭＮ１０１と、ＱＮＥ（プロキシ）１２３との間で使われるフローＩＤは、ＱＮＥ（プロキシ）１２３とＣＮ１２１の間で使われるフローＩＤと同じであってもよい。【０１５８】  次に、本発明の第３の実施の形態の第２動作例について説明する。上述の本発明の第３の実施の形態における第１動作例では、データパケットの送信方向がｕｐｌｉｎｋ方向の場合について説明したが、データパケットの送信方向がｄｏｗｎｌｉｎｋ方向であった場合においても、同様の手順を採ることができる。これについて、図１６を参照しながら説明する。図１６は、本発明の第３の実施の形態において、データパケットの送信方向がｄｏｗｎｌｉｎｋ方��の場合の動作例を示すシーケンスチャートである。【０１５９】  ＱＮＥ（プロキシ）１２３は、予測経路を準備するためのトリガを受け取ると（ステップＳ５０１）、ＣＮ１２１に対して、予測経路準備を依頼する依頼メッセージを送信する（ステップＳ５０３）。なお、予測経路を準備するためのトリガは、ＱＮＥ（プロキシ）１２３ではなく、ＣＮ１２１に直接送られてもよい。この場合、トリガには、ＱＮＥ（プロキシ）１２３のＩＰアドレスなどの情報も含まれている必要がある。【０１６０】  依頼メッセージ又はトリガを受信したＣＮ１２１は、この依頼メッセージ又はトリガに応じて、即座に、ＮＳＬＰ層においてＱＵＥＲＹメッセージのペイロード部を生成し、ＮＴＬＰ層に受け渡す。ＮＴＬＰ層ではこれを受けて、自身をシグナリングメッセージの送信元、ＱＮＥ（プロキシ）１２３をあて先としたフローＩＤを生成し（ステップＳ５０５）、このフローＩＤをヘッダ部に含むＱＵＥＲＹメッセージを、下位層を経由してＱＮＥ（プロキシ）１２３に向けて送信する（ステップＳ５０７）。なお、このＱＵＥＲＹメッセージは、経路１４９における新規のｄｏｗｎｓｔｒｅａｍ方向（データ送信方向と同じ方向）へのメッセージであるので、このＱＵＥＲＹメッセージのＩＰヘッダにはＱＮＥ用のＲＡＯが付けられる。【０１６１】  ＣＮ１２１からＱＮＥ（プロキシ）１２３までの経路上のすべてのＱＮＥ（ＱＮＥ１１９、１１７、１１５、１２５）は、ＱＵＥＲＹメッセージを受信してＩＰヘッダにＲＡＯを発見すると、ＮＳＩＳ層（ＮＳＬＰ層及びＮＴＬＰ層）においてＱＵＥＲＹメッセージの中身を確認して、必要な処理を行う。すなわち、ＱＵＥＲＹメッセージを受信したＱＮＥ１１９、１１７、１１５、１２５は、ＱｏＳ  ＮＳＬＰ層におけるＱＵＥＲＹ処理以外に、ＮＴＬＰ層においてルーティングステートのためのステート確立処理を行う（ステップＳ５０９、Ｓ５１３、Ｓ５１７、Ｓ５２１、Ｓ５２５）。その後、各ＱＮＥは、ＱＵＥＲＹメッセージをＱＮＥ（プロキシ）１２３に向けて送信する（ステップＳ５１１、Ｓ５１５、Ｓ５１９、Ｓ５２３）。【０１６２】  ここで、ＭＮ１０１がサブネット１０７に移動したとする（ステップＳ５２７）。ＱＮＥ（プロキシ）１２３は、ＭＮ１０１の移動を検出し、ＭＮ１０１がサブネット１０７より取得したＮＣｏＡ情報を取得すると、ＮＴＬＰ層において自身のＩＰアドレスをシグナリングメッセージの送信元、ＭＮ１０１のＮＣｏＡをシグナリングメッセージのあて先としたフローＩＤを生成する（ステップＳ５２９）。また、ＱＮＥ（プロキシ）１２３のＮＳＬＰ層は、ＣＮ１２１のＩＰアドレスをデータパケットの送信元、ＭＮ１０１のＮＣｏＡをデータパケットのあて先とした情報を含むフィルタ情報を生成し、このフィルタ情報を追加（ａｄｄ）してＱｏＳリソースを予約するような送信者主導のＲＥＳＥＲＶＥメッセージ（図１６ではＲＥＳＥＲＶＥ（ａｄｄ）と記載）をＭＮ１０１に向けて送信する（ステップＳ５３１）とともに、ＮＴＬＰ層ではＭＮ１０１に転送するデータパケットに対するルーティングのためのステートの確立処理を行う（ステップＳ５３３）。【０１６３】  また、ＱＮＥ（プロキシ）１２３は、受信者��導のＲＥＳＥＲＶＥメッセージ（図１６ではＲＥＳＥＲＶＥ（ａｄｄ）と記載）をＣＮ１２１に向けて送信する（ステップＳ５３５）。なお、ＭＮ１０１に送信されるＲＥＳＥＲＶＥメッセージは、経路１４９におけるＱＮＥ（プロキシ）１２３からＭＮ１０１に対する新規のｄｏｗｎｓｔｒｅａｍ方向（データ送信方向と同じ方向）へのメッセージであるので、このＲＥＳＥＲＶＥメッセージにはＱＮＥ用のＲＡＯが付けられる。しかしながら、ＣＮ１２１に送信されるＲＥＳＥＲＶＥメッセージに関しては、ルーティングのためのステートがＱＮＥ１２３、１２５、１１５、１１７、１１９に既に確立されているので、このＲＥＳＥＲＶＥメッセージにＲＡＯが付加される必要はなく、ＱＮＥ１２５、１１５、１１７、１１９は、受信したＲＥＳＥＲＶＥメッセージを参照してリソース予約のための処理を行い、迅速にＲＥＳＥＲＶＥメッセージを送信することができる（ステップＳ５３７、Ｓ５３９、Ｓ５４１、Ｓ５４３、Ｓ５４５）。なお、ＱＮＥ（プロキシ）１２３とＭＮ１０１の間で使われるフローＩＤは、ＱＮＥ（プロキシ）１２３とＣＮ１２１の間で使われるフローＩＤと同じであってもよい。【０１６４】  以上、説明したように、本発明の第３の実施の形態における第１及び第２動作例によれば、ＱＮＥ（プロキシ）１２３が、ＭＮ１０１のサブネット１０７において割り当てられるＮＣｏＡを用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路（ＭＮ１０１からＣＮ１２１までの経路）の一部（例えば、ＱＮＥ（プロキシ）１２３とＣＮ１２１との間の経路）に係るＱｏＳ予約の準備（特に、ルーティングのためのステートの確立処理）を行うことにより、ＭＮ１０１がサブネット１０３から１０７に接続を変更した場合において、ＣＮ１２１からＭＮ１０１に送られるデータパケットのＱｏＳ保証の中断時間を低減することができる。【０１６５】  また、上述のように、フローＩＤ及びフィルタリストを定義することにより、ＭＮのハンドオーバのケースに限らず、ＱｏＳ経路を容易に管理することができるようになる。【０１６６】  例えば、ＭＮが、１つのセッションに対し複数のＩＰアドレスを用いてＣＮと通信している場合（ＭＮがマルチホーム状態の場合）で、どのＩＰアドレスも同一のサブネット配下のものであった場合を考える。この場合、どのＩＰアドレスが設定されたデータパケットであっても、データパケットが通過する経路は１つなので、各ＱＮＥにおけるＮＴＬＰ層では、ＭＮが持つ複数のＩＰアドレスのうちの１つをフローＩＤのあて先（又は送信元）アドレスとして採用すればよい。なお、パケットクラシファイアとして利用されるフィルタリストは、上述のように複数のフィルタ情報に対応しているので、ＭＮが有する複数のＩＰアドレスのすべてを容易に保持することが可能である。【０１６７】  また、ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を用いたデータのダウンロードなどでは、ダウンロードのスピードを上げるために、クライアントは一度に複数のポートを用いることがある。この場合でも、上述のＭＮが複数のＩＰアドレスを持つ場合と同様に、複数のポート番号のうちの１つをフローＩＤに採用すればよい。��お、フローＩＤが完全にＩＰアドレスの情報のみで作られるような場合には、ＮＴＬＰにおいて、ポート番号を管理する必要はなくなる。また、上述のＭＮが複数のＩＰアドレスを持つ場合と同様に、パケットクラシファイアとして利用されるフィルタリストは、複数のフィルタ情報に対応しているので、複数のポート番号を容易に保持することが可能である。【０１６８】  また、さらに、Ｈ．３２３を用いてＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）用のセッションを張る場合には、この途中のプロセスにおいて、使用されるポート番号が変化する。しかしながら、この場合でも、上述のように、フローＩＤ及びフィルタリストを定義することによって、ＮＴＬＰ側ではポート番号の変化に合わせてフローＩＤの情報を変える必要はなくなり、一方、パケットクラシファイアとして利用されるフィルタリストでは、フィルタ情報の追加・削除が容易に行えるため、ポート番号の変化に柔軟に対応することが可能となる。【０１６９】  次に、本発明の第３の実施の形態の第３動作例について説明する。データ経路（ＭＮ１０１とＣＮ１２１とを結ぶ経路）上にＮＡＴＦＷが存在する場合においても、ＭＮ１０１のハンドオーバ時にＱｏＳ保証の中断時間を低減させるシームレスなＱｏＳ保証を提供することが望ましい。このとき、シームレスなＱｏＳ保証を提供するため、上述の本発明の第３の実施の形態の第１動作例（図１５を参照）や第２動作例（図１６を参照）と同様に、プロキシを利用して、ＮＴＬＰ層においてルーティングのためのステートの確立処理を先に行い、端末のハンドオーバ後にＱｏＳリソース予約を行うとともに、ＮＡＴＦＷのポリシールールの追加や書き換えを行うことが望ましい。【０１７０】  以下、データ経路上のＱＮＥ１１７がＮＡＴＦＷであることを想定して、上述の本発明の第３の実施の形態の第１動作例と同様に、ＭＮ１０１がサブネット１０３からサブネット１０７にハンドオーバを行う際に、ＱＮＥ（プロキシ）１２３が、ＭＮ１０１のサブネット１０７において割り当てられるＮＣｏＡを用いることなく、ＭＮ１０１のハンドオーバ後に使用される経路の一部に係るＱｏＳ予約の準備（特に、ルーティングのためのステートの確立処理）を行う動作について説明する。【０１７１】  図１８は、本発明の第３の実施の形態において、データ経路上にＮＡＴＦＷが存在しており、データパケットの送信方向がｕｐｌｉｎｋ方向の場合の動作例を示すシーケンスチャートである。なお、ここでは、ＱＮＥ１１７がＮＡＴＦＷ機能を持つものとし、ＱＮＥ１１９及びＣＮ１２１がプライベートアドレスを用いるＬＡＮ内に存在するものとする。また、ＭＮ１０１、ＱＮＥ１１７及びＣＮ１２１にはＮＡＴＦＷ  ＮＳＬＰが実装されているものとする。さらに、ＮＡＴＦＷ（ＱＮＥ１１７）には、ＮＳＩＳシグナリングメッセージがこのＮＡＴＦＷを通過できるためのポリシールールが既に設定されているものとする。また、図１５に図示されている第１動作例と同様に、図１８に図示されているシーケンスにおいても、各ＱＮＥにおいてルーティングのためのステートを作るために送信されるメッセージの一例として、ＮＳＩＳのＱｏＳ  ＮＳＬＰで定義されているＱＵＥＲＹメッセージを用���た場合を例に挙げて説明する。【０１７２】  図１８において、まず、ＱＮＥ（プロキシ）１２３は、予測経路を準備するためのトリガを受ける（ステップＳ６０１）。なお、このトリガには、例えば、ＭＮ１０１とＣＮ１２１との間のＱｏＳ経路で用いられているセッションＩＤ、ＣＮ１２１（又は経路の最終ＱＮＥであるＱＮＲ）のＩＰアドレスなど、予測経路を確立するために必要な情報が含まれている。【０１７３】  トリガを受け取ったＱＮＥ（プロキシ）１２３は、このトリガに応じて、即座に、ＮＳＬＰ層においてＱＵＥＲＹメッセージのペイロード部を生成し、ＮＴＬＰ層に受け渡す。ＮＴＬＰ層ではこれを受けて、自身をシグナリングメッセージの送信元、ＣＮ１２１をあて先としたフローＩＤを生成し（ステップＳ６０３）、このフローＩＤをヘッダ部に含むＱＵＥＲＹメッセージを、下位層を経由してＣＮ１２１に向けて送信する（ステップＳ６０５）。なお、このＱＵＥＲＹメッセージは、経路１４９における新規のｄｏｗｎｓｔｒｅａｍ方向（データ送信方向と同じ方向）へのメッセージであるので、このＱＵＥＲＹメッセージのＩＰヘッダにはＱＮＥ用のＲＡＯが付けられる。【０１７４】  ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路上のすべてのＱＮＥ（ＱＮＥ１２５、１１５、１１７、１１９）は、ＱＵＥＲＹメッセージを受信してＩＰヘッダにＲＡＯを発見すると、ＮＳＩＳ層（ＮＳＬＰ層及びＮＴＬＰ層）においてＱＵＥＲＹメッセージの中身を確認して、必要な処理を行う。すなわち、ＱＵＥＲＹメッセージを受信したＱＮＥ１２５、１１５、１１７、１１９は、ＱｏＳ  ＮＳＬＰ層におけるＱＵＥＲＹ処理以外に、ＮＴＬＰ層においてルーティングのためのステートの確立処理（ルーティングステートや、メッセージアソシエーション（要求されている場合）の確立のための処理）を行う（ステップＳ６０７、Ｓ６１１、Ｓ６１５、Ｓ６１９、Ｓ６２３）。その後、各ＱＮＥはＱＵＥＲＹメッセージをＣＮ１２１に向けて送信する（ステップＳ６０９、Ｓ６１３、Ｓ６１７、Ｓ６２１）。そして、ＱＵＥＲＹメッセージがＣＮ１２１に到達すると、このＱＵＥＲＹメッセージに対するＲＥＳＰＯＮＳＥメッセージがＣＮ１２１からＱＮＥ１２３に返される（ステップＳ６２５、Ｓ６２７、Ｓ６２９、Ｓ６３１、Ｓ６３３）。【０１７５】  ここで、ＭＮ１０１がサブネット１０７に移動したとする（ステップＳ６３５）。ＭＮ１０１は、サブネット１０７よりＮＣｏＡを取得すると、ＮＴＬＰ層において、このＮＣｏＡをシグナリングメッセージの送信元、ＱＮＥ（プロキシ）１２３をシグナリングメッセージのあて先としたフローＩＤを生成する（ステップＳ６３７）。また、ＭＮ１０１のＮＳＬＰ層では、自身のＮＣｏＡをデータパケットの送信元、ＣＮ１２１のＩＰアドレスをデータパケットのあて先とした情報を含むフィルタ情報を生成する。また、ＮＡＴＦＷ  ＮＳＬＰ層では、このフィルタ情報を持ったデータパケットがＮＡＴＦＷを通過するためのポリシールールを、ＮＡＴＦＷ（ＱＮＥ１１７）で作成できるようにするパラメータを持ったＣＲＥＡＴＥメッセージ（図１８では、ＣＲＥＡＴＥと記載）を作成する。また、ＱｏＳ  ＮＳＬＰ層では、このフィルタ情��を追加（ａｄｄ）してＱｏＳリソースを予約するような送信者主導のＲＥＳＥＲＶＥメッセージ（図１８ではＲＥＳＥＲＶＥ（ａｄｄ）と記載）を作成する。そして、ＭＮ１０は、上記のＣＲＥＡＴＥメッセージとＲＥＳＥＲＶＥメッセージとを１つのメッセージ（ＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージ）にして、ＱＮＥ（プロキシ）１２３に向けて送信する（ステップＳ６３９）。なお、上記のＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージは、経路１４９におけるＭＮ１０１からＱＮＥ（プロキシ）１２３に対する新規のｄｏｗｎｓｔｒｅａｍ方向（データ送信方向と同じ方向）へのメッセージであるので、ＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージのＩＰヘッダにはＱＮＥ用のＲＡＯが付けられる。【０１７６】  このＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージを受け取ったＱＮＥ（プロキシ）１２３は、ＮＴＬＰにおいてルーティングのためのステートの確立処理を行う（ステップＳ６４１）とともに、ＮＳＬＰにおいてリソース予約のための処理を行う。また、ＮＴＬＰ層ではセッションＩＤなどの情報から、このＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージをＣＮ１２１に送信する必要があることを認識し、このＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージに含まれるフローＩＤの情報を、ステップＳ６０３で生成されたフローＩＤに変更し、ＣＮ１２１に向けて送信する（ステップＳ６４３）。この際、ＮＴＬＰは、メッセージをＣＮ１２１に向けて送信する必要があるということを、ＮＳＬＰに伝えてもよい。なお、この場合、ルーティングのためのステートは、ＱＮＥ１２３、１２５、１１５、１１７、１１９に既に確立されているので、ＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージにＲＡＯが付加される必要はなく、ＱＮＥ１２３、１２５、１１５、１１７、１１９は、受信したＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージのＲＥＳＥＲＶＥ部分を参照してリソース予約のための処理を行い、迅速にＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージを送信することができる（ステップＳ６４５、Ｓ６４７、Ｓ６５１、Ｓ６５３）。また、ＮＡＴＦＷ（ＱＮＥ１１７）においては、このＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージのＣＲＥＡＴＥ部分を参照し、ポリシールールに変更を加える（ステップＳ６４９）。このとき、ポリシールールにデータパケットに対するアドレス変換が含まれていた場合には、フィルタリストに含まれる該当フィルタ情報の内容をプライベートアドレスに対応したものに変更するか、又はプライベートアドレス用のフィルタ情報をリストに追加する。これにより、ＱＮＥ１１７とＱＮＥ１１９の間や、ＱＮＥ１１９とＣＮ１２１の間におけるＲＥＳＥＲＶＥ処理では、プライベートアドレス用にＱｏＳリソースが予約されることとなる。なお、ＭＮ１０１と、ＱＮＥ（プロキシ）１２３との間で使われるフローＩＤは、ＱＮＥ（プロキシ）１２３とＣＮ１２１の間で使われるフローＩＤと同じであってもよい。また、シグナリングメッセージ送信側で、あらかじめプライベートアドレスの情報が分かっていた場合には、このアドレス情報をあらかじめフィルタリスト内に存在させてもよい。この場合、ＮＡＴＦＷ（ＱＮＥ１１７）では、ステップＳ６４９においてフィルタリストの内容を変換する必要はない。【０１７７】  また、ここではＣＲＥＡＴＥとＲＥＳＥＲＶＥを同時に、ＱｏＳシグナリング用のルーティングのためのステートを用いて送信する例を挙げたが、このためには、複数のＮＳＬＰメッセージを同時に（１つのパケットとして）送信することをサポートするよう、ＮＳＩＳの仕様を変更する必要がある。また、ＲＥＳＥＲＶＥメッセージとＣＲＥＡＴＥメッセージは別々に送信されてもよいが、この場合には、ＣＲＥＡＴＥメッセージが、ＲＥＳＥＲＶＥメッセージよりも前に送信されることが必要であり（ステップＳ６４９でＲＥＳＥＲＶＥメッセージ内のフィルタ情報の書き換えが必要な場合があるため）、また、ＮＡＴＦＷシグナリング用のルーティングのためのステートが、ＱｏＳの場合と同様に、ＱＮＥ（プロキシ）１２３を用いてあらかじめ確立されていることが望ましい。【０１７８】  また、ここでは、データパケットの送信方向がｕｐｌｉｎｋ方向の場合について説明したが、データパケットの送信方向がｄｏｗｎｌｉｎｋ方向であった場合においても、図１６に図示されている第２動作例において、ＲＥＳＥＲＶＥメッセージと同時にＣＲＥＡＴＥメッセージを送信することによって同様の手順を採ることができる。【０１７９】  上述の本発明の第３の実施の形態における第３動作例では、ＮＡＴＦＷ（ＱＮＥ１１７）が、ＱｏＳ  ＮＳＬＰとＮＡＴＦＷ  ＮＳＬＰの両方のＮＳＬＰを持っている場合について説明を行った。この場合、フィルタリストはＮＳＬＰ共通部分に存在し、各ＮＳＬＰからフィルタリストを参照できるように構成してもよい。また、各ＮＳＬＰで使用されるフィルタ情報の組み合わせが異なることも考えられるので、この場合にはフィルタリスト内の各フィルタ情報に対し、どのＮＳＬＰで使用されるのかを示す情報（例えばフラグを立てるなど）を与えてもよい。【０１８０】  また、ＮＳＬＰごとにフィルタリストが分けられていてもよい。すなわち、ＱｏＳ  ＮＳＬＰ用フィルタリストやＮＡＴＦＷ  ＮＳＬＰ用フィルタリストなどのような各ＮＳＬＰで必要となるフィルタリストが用意され、各ＮＳＬＰ用フィルタリストがＮＳＬＰ共通部分に置かれる。【０１８１】  また、フィルタリストは各ＮＳＬＰに存在してもよい。この場合、各ＮＳＬＰ間で、直接又はＮＴＬＰを通じて、フィルタリストに関する情報をやり取りすることによって、フィルタリストの内容に整合性を持たせてもよい。例えば、ＮＡＴＦＷノードで〈ｆｉｌｔｅｒＡ〉を〈ｆｉｌｔｅｒＢ〉に書き換える指示を出す内容がＮＡＴＦＷ  ＮＳＬＰに存在した場合、この情報が直接又はＮＴＬＰを通じてＱｏＳ  ＮＳＬＰに送られ、これに従って、ＮＡＴＦＷノードのＱｏＳ  ＮＳＬＰ内のフィルタリストに含まれる〈ｆｉｌｔｅｒＡ〉が〈ｆｉｌｔｅｒＢ〉に書き換えられる。ただし、ＱｏＳ  ＮＳＬＰ内のフィルタリストにあらかじめ〈ｆｉｌｔｅｒＢ〉が存在している場合には、フィルタ情報を書き換える必要ない。【０１８２】  さらに、図１７に図示されているフィルタリストの定義とは異なるが、フィルタリストをＮＴＬＰに存在させるようにしてもよい。フィルタリストがＮＴＬＰに存在する場合は、フィルタリストがＮＳＬＰ共通部分に存在する場��と同様に、フィルタリスト内の各フィルタ情報に対し、どのＮＳＬＰで使用されるのかを示す情報（例えばフラグを立てるなど）が与えられていてもよく、また、ＮＳＬＰごとにフィルタリストが分けられていてもよい。【０１８３】  また、ＮＡＴＦＷノードは、ＮＡＴＦＷ機能を実装しているが、ＱｏＳ機能の実装は必須ではないため、ＮＡＴＦＷ  ＮＳＬＰのみが存在し、ＱｏＳ  ＮＳＬＰが存在しないＮＡＴＦＷノードが存在する場合も考えられる。このようなＮＡＴＦＷノードにおいても、ＮＳＬＰ共通部分やＮＴＬＰにフィルタリストが存在すれば、フィルタ情報の変換（図１８におけるステップＳ６４９の処理）を容易に行うことができる。【０１８４】  また、各ＮＳＬＰにフィルタリストが存在する場合でも、ＮＡＴＦＷノードにおける特別な機能として、ＱｏＳ  ＮＳＬＰが存在しない場合であってもＱｏＳ  ＮＳＬＰ内のフィルタリストの内容をチェックすることができる機能を持たせれば、フィルタ情報の変換は可能となる。また、この場合、ＱｏＳ  ＮＳＬＰメッセージがＮＡＴＦＷノードでインタセプトされるようにする必要がある。ＱｏＳ  ＮＳＬＰメッセージがＮＡＴＦＷノードでインタセプトされるようにするため、ルーティングのためのステート確立以前に送信されるＱｏＳ  ＮＳＬＰメッセージには、例えば、ＮＡＴＦＷ  ＮＳＬＰ用のＲＡＯ、又はＱｏＳ  ＮＳＬＰ及びＮＡＴＦＷ  ＮＳＬＰ共通（又はＮＳＬＰ共通）のＲＡＯ、又はＮＴＬＰを有するＮＥに対するＲＡＯ（すなわち、ＮＴＬＰ用ＲＡＯ）が付加される。【０１８５】  さらに、ＮＡＴＦＷノードが、ＮＴＬＰのみを実装している場合も考えられる。この場合、ＮＴＬＰにフィルタリストが存在すれば、ＮＡＴＦＷノードは、フィルタ情報の変換（図１８におけるステップＳ６４９の処理）を容易に行うことができる。ＮＳＬＰ共通部分や各ＮＳＬＰにフィルタリストが存在する場合でも、ＮＡＴＦＷノードにおける特別な機能として、ＮＳＬＰ共通部分や各ＮＳＬＰに存在するフィルタリストの内容をチェックすることができる機能を持たせれば、フィルタ情報の変換は可能となる。また、この場合、ＱｏＳ  ＮＳＬＰメッセージがＮＡＴＦＷノードでインタセプトされるようにする必要がある。ＱｏＳ  ＮＳＬＰメッセージがＮＡＴＦＷノードでインタセプトされるようにするため、ルーティングのためのステート確立以前に送信されるＱｏＳ  ＮＳＬＰメッセージには、例えば、ＮＴＬＰを有するＮＥに対するＲＡＯ（すなわち、ＮＴＬＰ用ＲＡＯ）が付加される。【０１８６】  また、上述のようにフローＩＤ及びフィルタリストを定義することにより、ＭＮのハンドオーバのケースに限らず、ＮＡＴＦＷノードを経由するデータ経路を容易に管理することが可能となる。【０１８７】  例えば、ＭＮが、１つのセッションに対し複数のＩＰアドレスを用いてＣＮと通信している場合（ＭＮがマルチホーム状態の場合）で、どのＩＰアドレスも同一のサブネット配下のものであった場合を考える。この場合、どのＩＰアドレスが設定されたデータパケットであっても、データパケットが通過する経路は１つなので、各ＮＡＴＦＷ  ＮＳＬＰを持つＮＥにおけるＮＴＬＰ層では、ＭＮが持つ複数のＩＰアドレスのうちの１つをフローＩＤのあて先（又は送信元）アドレスとして採用すればよい。なお、ＮＡＴＦＷにおいてポリシールール作成のために利用されるフィルタリストは、上述のように複数のフィルタ情報に対応しているので、ＭＮが有する複数のＩＰアドレスのすべてを容易に保持することが可能である。【０１８８】  また、ＦＴＰを用いたデータのダウンロードなどでは、ダウンロードのスピードを上げるために、クライアントは一度に複数のポートを用いることがある。この場合でも、上述のＭＮが複数のＩＰアドレスを持つ場合と同様に、複数のポート番号のうちの１つをフローＩＤに採用すればよい。なお、フローＩＤが完全にＩＰアドレスの情報のみで作られるような場合には、ＮＴＬＰにおいて、ポート番号を管理する必要はなくなる。また、上述のＭＮが複数のＩＰアドレスを持つ場合と同様に、ＮＡＴＦＷにおいてポリシールール作成のために利用されるフィルタリストは、複数のフィルタ情報に対応しているので、複数のポート番号を容易に保持することが可能である。【０１８９】  また、さらに、Ｈ．３２３を用いてＶｏＩＰ用のセッションを張る場合には、この途中のプロセスにおいて、使用されるポート番号が変化する。しかしながら、この場合でも、上述のように、フローＩＤ及びフィルタリストを定義することによって、ＮＴＬＰ側ではポート番号の変化に合わせてフローＩＤの情報を変える必要はなくなり、一方、ＮＡＴＦＷにおいてポリシールール作成のために利用されるフィルタリストでは、フィルタ情報の追加・削除が容易に行えるため、ポート番号の変化に柔軟に対応することが可能となる。【０１９０】  また、上述の本発明の第３の実施の形態では、フローＩＤとフィルタ情報とを分けて、別々に管理できるようにすることによって、シグナリングメッセージの通る経路に係る処理を、データパケットの通る経路に係る処理より前に行えるようにしているが、さらに、これを応用して、データパケットの通る経路と、シグナリングメッセージの通る経路とが異なるｏｆｆ−ｐａｔｈシグナリング（Ｐａｔｈ  Ｄｅｃｏｕｐｌｅｄシグナリングとも呼ばれる）を行うことも可能となる。例えば、あるドメインのプロキシや、ポリシー決定ポイント（データ経路上に存在する必要は無い）に直接シグナリングメッセージを送信し、このノードに、フィルタリストの内容を使用した処理（例えば、ポリシールールの作成）を行わせることも可能である。【０１９１】  なお、上述の本発明の第１〜第３の実施の形態では、付加的サービスがＱｏＳ保証である場合について説明したが、その他の付加的サービスに関しても本発明は適用可能である。また、特に、ＱｏＳ保証に関しては、ＮＳＩＳに対して本発明を適用した場合の具体例について説明したが、本発明は、その適用対象がＮＳＩＳに限定されるものではなく、さらに、本発明の機能を持たせるＮＳＩＳのメッセージは、上述の一例に限定されるものではない。【０１９２】  また、上記の本発明の各実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｉｏｎ）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい��なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。【０１９３】  また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。【０１９４】  さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
【産業上の利用可能性】
【０１９５】  本発明は、移動端末がハンドオーバを行う際に、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることが可能であり、通信ネットワーク技術や、パケット伝送に係るリソース管理の技術に適用可能である。さらに、本発明は、移動端末がハンドオーバを行う場合に限らず、端末が１つのセッションに対し、複数のＩＰアドレスや複数のポート番号を用いて通信を行っている場合や、セッションの途中でＩＰアドレスやポート番号に変更が生じる場合においても、経路（特に、ＱｏＳ経路）の管理を容易にすることが可能であり、通信ネットワーク技術や、パケット伝送に係るリソース予約に係るシグナリングメッセージのルーティング管理技術に適用可能である。
【図１】
2006073084.tif 000002
【図２】
2006073084.tif 000003
【図３】
2006073084.tif 000004
【図４】
2006073084.tif 000005
【図５】
2006073084.tif 000006
【図６】
2006073084.tif 000007
【図７】
2006073084.tif 000008
【図８】
2006073084.tif 000009
【図９】
2006073084.tif 000010
【図１０】
2006073084.tif 000011
【図１１】
2006073084.tif 000012
【図１２】
2006073084.tif 000013
【図１３】
2006073084.tif 000014
【図１４】
2006073084.tif 000015
【図１５】
2006073084.tif 000016
【図１６】
2006073084.tif 000017
【図１７】
2006073084.tif 000018
【図１８】
2006073084.tif 000019
【手続補正書】
【提出日】平成19年7月4日(2007.7.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な通信システムであって、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続し、前記第１アクセスルータが構成する第１サブネットで取得する第１アドレスを使用して通信を行う移動可能な移動端末と、
前記通信ネットワークに接続されており、前記移動端末の通信相手となる通信相手端末と、
前記移動端末が、前記複数のアクセスルータのうちの１つである第２アクセスルータに接続した場合に前記第２アクセスルータが構成する第２サブネットで取得する第２アドレスを使用せずに、前記第１アクセスルータに接続している前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路が確立された状態で、前記第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始することが可能な前記通信ネットワーク内に存在する通信ノードとを、
有する通信システム。
【請求項２】
前記通信ノードが、前記第２アクセスルータの近隣に存在する請求項１に記載の通信システム。
【請求項３】
前記通信ノードが、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信し、前記トリガ情報に基づいて前記第２経路を確立する処理を開始するように構成されている請求項１に記載の通信システム。
【請求項４】
前記移動端末が、前記トリガ情報を前記通信ノードに送信するように構成されている請求項３に記載の通信システム。
【請求項５】
前記通信ノードが、自ノードを一方の終端とする前記第２経路を確立するように構成されている請求項１に記載の通信システム。
【請求項６】
前記通信ノードは、前記移動端末が前記第２サブネットに移動して割り当てられた第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始するように構成されている請求項１に記載の通信システム。
【請求項７】
前記通信ノードが、前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている請求項６に記載の通信システム。
【請求項８】
前記第２経路の終端が前記通信ノード及び前記通信相手端末であり、前記通信相手端末が、前記移動端末にパケットを送信する際に前記通信ノードのアドレスをあて先アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記通信相手端末から前記移動端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている請求項６に記載の通信システム。
【請求項９】
前記第２経路の終端が前記第２アクセスルータの近隣に存在する前記通信ノード及び前記通信相手端末の近隣に存在する相手側近隣通信ノードであり、前記相手側近隣通信ノードが、前記通信相手端末から前記移動端末へのパケットを転送する際に前記通信ノードのアドレスをあて先アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記通信相手端末から前記移動端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている請求項６に記載の通信システム。
【請求項１０】
前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第１サブネットに接続している状態で使用されていた前記第１経路、及び前記通信ノードによって確立された前記第２経路が削除されるように構成されている請求項６に記載の通信システム。
【請求項１１】
前記通信ノードが、自ノードと前記通信相手端末との間の経路上の中間通信ノードに、前記第２経路を確立する処理を行う際に送受信されるシグナリングメッセージのルーティングのためのステートを導入する処理を開始するように構成されている請求項１に記載の通信システム。
【請求項１２】
前記通信ノードが、前記中間通信ノードに対して、自ノードのアドレス及び前記通信相手端末のアドレスにより構成された識別情報を送信し、前記中間通信ノードが、前記識別情報を保持して、前記識別情報を有するシグナリングメッセージを特定するように構成されている請求項１１に記載の通信システム。
【請求項１３】
前記通信ノードは、前記移動端末が前記第２サブネットに移動して割り当てられた第２アドレスを取得した場合に、前記第２経路に係る付加的サービスを提供するための情報を含むシグナリングメッセージを送信し、前記中間通信ノードが、前記シグナリングメッセージのルーティングのためのステートを使用して、前記シグナリングメッセージの伝送を行うように構成されている請求項１１に記載の通信システム。
【請求項１４】
前記付加的サービスが、ＱｏＳ保証である請求項１に記載の通信システム。
【請求項１５】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な前記通信ネットワークに存在する通信ノード内のリソース管理装置であって、
前記経路において、付加的サービスを提供するためのリソースを確保するためのリソース確保手段と、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続している前記移動端末と、前記通信ネットワークに接続されており前記移動端末の通信相手となる通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信するトリガ受信手段と、
前記トリガ受信手段で前記トリガ情報を受信した場合、前記トリガ情報に基づいて、前記第１アクセスルータとは異なる第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始するメッセージを生成するメッセージ生成手段とを、
有するリソース管理装置。
【請求項１６】
前記メッセージには、前記移動端末の代理として経路設定を行う旨を示す情報が付加されている請求項１５に記載のリソース管理装置。
【請求項１７】
前記第２アクセスルータの近隣に存在する前記通信ノード内に配置されている請求項１６に記載のリソース管理装置。
【請求項１８】
前記トリガ情報に、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスが少なくとも含まれている請求項１６に記載のリソース管理装置。
【請求項１９】
前記移動端末から前記トリガ情報を受信する請求項１８に記載のリソース管理装置。
【請求項２０】
前記通信ノードを一方の終端とする前記第２経路を確立するように構成されている請求項１６に記載のリソース管理装置。
【請求項２１】
前記移動端末が前記第２サブネットに移動して割り当てられた前記第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始するように構成されている請求項１６に記載のリソース管理装置。
【請求項２２】
前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている請求項２１に記載のリソース管理装置。
【請求項２３】
前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第２経路を削除するためのメッセージを送信するように構成されている請求項２０に記載のリソース管理装置。
【請求項２４】
前記付加的サービスが、ＱｏＳ保証である請求項１５に記載のリソース管理装置。
【請求項２５】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な前記通信ネットワークに存在する通信ノードで行われるリソース管理方法であって、
前記経路において、付加的サービスを提供するためのリソースを確保するためのリソース確保ステップと、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続している前記移動端末と、前記通信ネットワークに接続されており前記移動端末の通信相手となる通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信するトリガ受信ステップと、
前記トリガ受信ステップで前記トリガ情報を受信した場合、前記トリガ情報に基づいて、前記第１アクセスルータとは異なる第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始するメッセージを生成するメッセージ生成ステップとを、
有するリソース管理方法。
【請求項２６】
前記メッセージには、前記移動端末の代理として経路設定を行う旨を示す情報が付加されている請求項２５に記載のリソース管理方法。
【請求項２７】
前記第２アクセスルータの近隣に存在する前記通信ノード内に配置されている請求項２６に記載のリソース管理方法。
【請求項２８】
前記トリガ情報に、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスが少なくとも含まれている請求項２６に記載のリソース管理方法。
【請求項２９】
前記移動端末から前記トリガ情報を受信する請求項２８に記載のリソース管理方法。
【請求項３０】
前記通信ノードを一方の終端とする前記第２経路を確立する請求項２６に記載のリソース管理方法。
【請求項３１】
前記移動端末が前記第２サブネットに移動して割り当てられた前記第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始する請求項２６に記載のリソース管理方法。
【請求項３２】
前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化ステップを有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化ステップにおいてカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられる請求項３１に記載のリソース管理方法。
【請求項３３】
前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第２経路を削除するためのメッセージを送信する請求項３０に記載のリソース管理方法。
【請求項３４】
前記付加的サービスが、ＱｏＳ保証である請求項２５に記載のリソース管理方法。
【請求項３５】
シグナリングメッセージをルーティングする機能を有する第１ユニットと、提供する付加的サービスに関する情報を管理するための機能を有する第２ユニットとにより構成された通信プロトコルを使用して２つの通信ノード間で行われる通信において、前記２つの通信ノード間の経路上に存在し、前記２つの通信ノード間で伝送されるデータパケットに対して前記付加的サービスを提供する通信ノード内の通信管理装置であって、
前記第１ユニットが、前記２つの通信ノード間の経路の一部であって、自ノードを含んだ任意の両端点を有する前記経路の一部において伝送される前記シグナリングメッセージのルーティングのためのステートを管理するステート管理手段を有し、
前記第２ユニットが、前記シグナリングメッセージによって伝送されるフィルタ情報であって、前記付加的サービスを提供する対象となるデータパケットを特定するための前記フィルタ情報を管理するフィルタ情報管理手段を有する通信管理装置。
【請求項３６】
前記ステートが、前記任意の両端点のアドレスを有し、前記フィルタ情報が、前記２つの通信ノードのアドレスを有する請求項３５に記載の通信管理装置。
【請求項３７】
前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層に配置されている請求項３５に記載の通信管理装置。
【請求項３８】
シグナリングメッセージをルーティングする機能を有する第１ユニットと、提供する付加的サービスに関する情報を管理するための機能を有する第２ユニットとにより構成された通信プロトコルを使用して２つの通信ノード間で行われる通信において、前記２つの通信ノード間の経路上に存在し、前記２つの通信ノード間で伝送されるデータパケットに対して前記付加的サービスを提供する通信ノードで行われる通信管理方法であって、
前記第１ユニットが、前記２つの通信ノード間の経路の一部であって、自ノードを含んだ任意の両端点を有する前記経路の一部において伝送される前記シグナリングメッセージのルーティングのためのステートを管理するステート管理ステップと、
前記第２ユニットが、前記シグナリングメッセージによって伝送されるフィルタ情報であって、前記付加的サービスを提供する対象となるデータパケットを特定するための前記フィルタ情報を管理するフィルタ情報管理ステップとを、
有する通信管理方法。
【請求項３９】
前記ステートが、前記任意の両端点のアドレスを有し、前記フィルタ情報が、前記２つの通信ノードのアドレスを有する請求項３８に記載の通信管理方法。
【請求項４０】
前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層に配置されている請求項３８に記載の通信管理方法。
【請求項４１】
前記第１及び第２ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されている請求項３８に記載の通信管理方法。
【請求項４２】
前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層の任意の機能が参照可能なＮＳＬＰ共通部に配置されている請求項３８に記載の通信管理方法。
【請求項４３】
前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層の特定の機能部に配置されていて、前記特定の機能部から前記ＮＳＬＰ層の任意の機能部に、前記フィルタ情報の一部又は全部が渡されるように構成されている請求項３８に記載の通信管理方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システム、リソース管理装置、リソース管理方法、通信管理装置並びに通信管理方法に関し、特に、パケット伝送が行われる通信ネットワークにおける通信システム、リソース管理装置、リソース管理方法、通信管理装置並びに通信管理方法に関する。
【背景技術】
【０００２】
移動端末から無線ネットワークを通じてインターネットなどの通信ネットワークにアクセスするユーザに対して、移動しながらでもシームレスに通信ネットワークの接続を提供できる技術として、次世代インターネットプロトコルであるモバイルＩＰ（Internet Protocol）を利用したものが普及してきている。
【０００３】
一方、ネットワークを利用した通信においては、ＱｏＳ（Quality of Service）保証を始めとしたサービス（本明細書では、こうしたサービスを付加的サービスと呼ぶことにする）が存在しており、こうした付加的サービスを実現するための様々な通信プロトコルが存在している。このような様々な通信プロトコルのうち、ＱｏＳ保証をするためのプロトコルとして、例えば、ＲＳＶＰ（Resource Reservation Protocol）が挙げられる（例えば、下記の非特許文献１参照）。ＲＳＶＰは、データの送信を行う送信側通信端末からデータの受信を行う受信側通信端末への経路（フロー）上における帯域予約を行うことによって、送信側通信端末から受信側通信端末に、データがスムーズに伝送されるようにするものである。
【０００４】
サブネット（サブネットワーク）間のハンドオーバを行うＭＮ（Mobile Node：モバイルノード）に関しては、ハンドオーバ前に受けていたＱｏＳ保証を始めとする付加的サービスを、ハンドオーバ後においても継続して受けられるべきであるという要請があるが、上述したＲＳＶＰは、ＭＮの移動に対して十分には対応していないという問題がある。
【０００５】
この問題を解決するために、現在、ＩＥＴＦ（Internet Engineering Task Force）において、ＮＳＩＳ（Next Step in Signaling）と呼ばれる新しいプロトコルを標準化するための議論が行われている（下記の非特許文献２参照）。このＮＳＩＳは、モバイル環境において、ＱｏＳ保証を始めとする様々な付加的サービスに特に有効であると期待されており、ＮＳＩＳにおいてＱｏＳ保証やモビリティサポートを実現するための要件や実現方法などが記載された文献も存在する（例えば、下記の非特許文献３〜７参照）。以下に、現在ＩＥＴＦのＮＳＩＳワーキンググループでドラフト仕様となっているＮＳＩＳの概要と、ＱｏＳ経路確立の方法を説明する（非特許文献４及び非特許文献７参照）。
【０００６】
図１０には、従来の技術におけるＮＳＩＳのプロトコル構成を説明するために、ＮＳＩＳ及びその下位層のプロトコルスタックが図示されている。ＮＳＩＳプロトコル層はＩＰ及び下位層のすぐ上に位置する。さらにＮＳＩＳプロトコル層は、それぞれの付加的サービスを提供するためのシグナリングメッセージ生成、及びその処理を行うプロトコルであるＮＳＬＰ（NSIS Signaling Layer Protocol）と、ＮＳＬＰのシグナリングメッセージのルーティングを行うＮＴＬＰ（NSIS Transport Layer Protocol）の２層からなる。ＮＳＬＰには、ＱｏＳのためのＮＳＬＰ（ＱｏＳ  ＮＳＬＰ）や、その他のある付加的サービス（サービスＡやサービスＢ）のためのＮＳＬＰ（サービスＡのＮＳＬＰ、サービスＢのＮＳＬＰ）など、様々なＮＳＬＰが存在している。
【０００７】
また、図１１は、従来の技術におけるＮＳＩＳのノードであるＮＥやＱＮＥが「隣り合う」という概念を説明するための模式図である。図１１に示すように、ＮＳＩＳ機能を持ったすべてのノード（ＮＥ：NSIS Entity）には、少なくともＮＴＬＰが実装されている。このＮＴＬＰの上には、ＮＳＬＰが必ずしも存在しなくてもよく、また、１つ以上のＮＳＬＰが存在してもよい。なお、ここでは、特に、ＱｏＳのためのＮＳＬＰを持ったＮＥをＱＮＥ（QoS NSIS Entity）と呼ぶことにする。なお、ＮＥになり得るのは端末やルータである。また、隣り合うＮＥの間には、ＮＥではない複数のルータが存在することもあり得るし、隣り合うＱＮＥの間には、ＮＥではないルータ及びＱｏＳ ＮＳＬＰを持たないＮＥが複数存在することもあり得る。
【０００８】
なお、ＮＳＩＳは、モバイル環境だけでなく通常の静的なネットワークにおける様々な機能も網羅するものであるが、本明細書では、ＮＳＩＳの機能の１つであるモビリティサポートされた付加的サービスの確立を実現する機能に着目し、ＮＳＩＳの実装によって、モビリティサポートされた付加的サービスの確立が実現されるものとする。
【０００９】
また、ＭＮが新たなサブネットワーク（以下、サブネットと呼ぶ）に移動する場合、新たなＱｏＳ経路が、ＭＮとＣＮ（Correspondent Node：通信相手ノード）との間で確立される必要がある。新たなＱｏＳ経路が確立されるまでは、データパケットは必要なＱｏＳ処理を受けられず、ＱｏＳの中断が起こることになる。このＱｏＳの中断は、スムーズかつシームレスなモビリティが実現されるように、最低限に抑えられる必要がある。
【００１０】
こうした問題を扱う１つの方法として、下記の非特許文献８には、ＭＲＳＶＰが提示されている。この非特許文献８では、ＲＳＶＰに変更を加えることによって、モバイルＩＰの三角ルート用のＱｏＳ経路をあらかじめ確立する方法が提案されている。ここでは、「ローカルプロキシエージェント（ＨＡ（Home Agent：ホームエージェント）に相当する）」及び「リモートプロキシエージェント（ＦＡ（Foreign Agent：フォーリンエージェント）に相当する）」が、ＭＮのためのＱｏＳ経路を確立することが可能である。
【００１１】
リモートプロキシエージェントは、ＭＮのＮＣｏＡ（New Care-of Address：新たな気付アドレス）取得した後に、自身とＣＮとの間にＱｏＳ経路のセットアップを行う。続いて、リモートプロキシエージェントとローカルプロキシエージェントとの間（すなわち、ＦＡとＨＡとの間）の経路が新たに確立されて、この経路と、ローカルプロキシエージェントとＣＮとの間（すなわち、ＦＡとＣＮとの間）の経路とが併合される。なお、経路の併合の具体的な方法に関しては説明されていない。
【００１２】
また、ＭＮがサブネット間においてハンドオーバを行う場合、ハンドオーバ前の古い経路の一部とハンドオーバ後の新しい経路の一部とが重複する場合がある。このような場合には、重複経路における２重予約の問題や、経路の変更が困難であることなど、様々な問題が起こり得る。こうした問題を解く方法の１つとして、古い経路と新しい経路とが分岐（クロスオーバ）する位置を特定する方法が挙げられる。この分岐点上に存在する通信ノードはＣＲＮ（Crossover Node：クロスオーバノード）と呼ばれ、このＣＲＮを特定する方法としては、例えば、下記の非特許文献９、１０などに記載されている方法が知られている。
【００１３】
なお、本明細書に記載されているＱｏＳ経路の確立とは、ＱｏＳが保証されるデータパケットが通る経路であって、ＮＴＬＰ層においてシグナリングメッセージをルーティングするためのステートが確立されており、かつＮＳＬＰ層によってＱｏＳ保証のためのリソース予約手続きが完了した状態のことを指す。なお、ＱｏＳ保証のためのリソース予約と、ＮＴＬＰ層のルーティングのためのステートの確立は、同時に行われる場合もあるし、また、ルーティングのためのステートの確立の後に、ＱｏＳ保証のためのリソース予約が行われる場合もある。
【００１４】
また、下記の非特許文献１１Ａによれば、シグナリングメッセージのルーティングのためのステートは、ＮＳＩＳの最初のメッセージが、downstream方向（データパケットが送られる方向）に対して送られる際に確立される。すなわち、あるセッションに対するデータパケットに対してＱｏＳ保証が行われる場合、データパケットが通過する最初のＱＮＥは、ＱｏＳ予約のためのシグナリングメッセージ、又はその準備のためのシグナリングメッセージを、データパケットの受信者に向けて送信する。このとき、このシグナリングメッセージのＮＴＬＰ層に、セッションを識別するセッションＩＤやフローを識別するフローＩＤなどの情報が付けられるほかに、ＩＰ層にはＲＡＯ(Router Alert Option)が付けられる。そして、このシグナリングメッセージが通過しようとするＱＮＥのＩＰ層において、ＲＡＯの存在によりこのシグナリングメッセージはインタセプトされて、ＮＳＩＳ層（ＮＴＬＰ層及びＮＳＬＰ層）に渡され、ＮＳＩＳ層によって、シグナリングメッセージの中身が確認されるようになる。
【００１５】
シグナリングメッセージをインタセプトしたＱＮＥのＮＴＬＰ層では、まず、ルーティングのためのステートとして、フローＩＤやセッションＩＤの情報、及び、このシグナリングメッセージが送信されてきた１つ前の隣り合うＱＮＥのＩＰアドレスの情報を格納する。そして、１つ前の隣り合うＱＮＥに対して、ＮＴＬＰレベルでの返信メッセージを返す。これにより、１つ前のＱＮＥのＮＴＬＰ層は、１つ後ろのＱＮＥのＩＰアドレスを知ることができ、このＩＰアドレスをルーティングのためのステートに書き込むことによって保持する。また、シグナリングメッセージの送受信をセキュアに行いたい場合などには、このほかに、メッセージアソシエーションなどの手順を行い、セキュリティに関するネゴシエーションなどを行う。
【００１６】
一方、ＮＳＬＰ側では、ＮＳＬＰメッセージの中身に応じた処理を行い、この処理が済むと再びＮＴＬＰにより、シグナリングメッセージがあて先（ここでは、データパケットの受信者）に向けて転送される。
【００１７】
こうして、このシグナリングメッセージが所定のあて先に到達することにより、ＮＴＬＰ層にはメッセージのルーティングのためのステートに係る情報が確立される。特に、メッセージアソシエーションが確立された場合には、以後の該当セッションＩＤ、フローＩＤを持つシグナリングメッセージに関しては、ＲＡＯを用いることなく、上述のように確立されたルーティングのためのステートを用いて送受信される。
【００１８】
また、ＮＡＴ（Network Address Translation：ネットワークアドレス変換）やＦＷ（Firewall：ファイアウォール）におけるポリシールールを動的に作成するため、ＮＳＩＳではＮＳＬＰ層の機能の１つとして、ＮＡＴＦＷ ＮＳＬＰ（下記の非特許文献１３参照）が提案されている。
【００１９】
なお、ＮＡＴとは、ＬＡＮ（Local Area Network）内のみで使われるプライベートアドレス情報と、インターネット上で使われるグローバルアドレス情報の変換を行う技術である。なお、アドレス情報にはＩＰアドレスのほかに、ＩＰアドレスとポート番号の組み合わせなども用いられる。どのプライベートアドレス情報と、どのグローバルアドレス情報とを対応させるかという変換情報は、ポリシールールという形でＮＡＴ対応ノード内に保有される。また、ＦＷとは、ＬＡＮ内に通すパケット、又はＬＡＮ内からＬＡＮ外（例えば、インターネット）に送出するパケットをフィルタリングする技術である。なお、フィルタリングには、ＩＰアドレスやポート番号などが用いられる。このフィルタリング情報は、ポリシールールという形でＦＷ対応ノード内に保有される。また、ＮＡＴ及びＦＷの両方の機能が１つのノードに実装される場合も多い。本明細書では、ＮＡＴ及びＦＷの両方の機能をＮＡＴＦＷと呼び、ＮＡＴ及びＦＷの両方の機能を有するノードをＮＡＴＦＷノードと呼ぶ。
【００２０】
ＮＡＴＦＷ ＮＳＬＰの基本動作は、以下の通りである。
（１）データ送信者であるＮＡＴＦＷ ＮＳＬＰ対応ノードが，データ受信者であるＮＡＴＦＷ ＮＳＬＰ対応ノードに対して、ＣＲＥＡＴＥメッセージを送信する。
（２）経路上に存在するＮＡＴＦＷ ＮＳＬＰ対応ノードが、このＣＲＥＡＴＥメッセージをインタセプトする。
（３）このノードがＮＡＴＦＷ機能を持つものであった場合、このＣＲＥＡＴＥメッセージに含まれるパラメータに基づいて、ポリシールールを作成する。
【００２１】
なお、ＣＲＥＡＴＥメッセージに含まれるパラメータとは、対象となるデータパケットのアドレス情報、アクション（例えば、パケットを通す／通さないという処理など）及びアクションに対する補足情報（ライフタイムなど）である。このデータパケットのアドレス情報は、フローＩＤより引用される。
【００２２】
なお、ＱｏＳ ＮＳＬＰの場合と同様に、データ送信者及びデータ受信者がＮＡＴＦＷ ＮＳＬＰ対応ノードではない場合には、データ経路上に存在するＮＡＴＦＷ ＮＳＬＰ対応ノードで、データ送信者（又はデータ受信者）に一番近いノードが、シグナリングメッセージの送信者（又は受信者）となる。また、ＣＲＥＡＴＥメッセージを送信する前提として、ＮＡＴＦＷノードには、ＮＳＩＳメッセージを通すためのポリシールールがあらかじめ作成されていることが定められている。
【００２３】
また、ＮＴＬＰにはフローＩＤが含まれており、このフローＩＤが、ＮＳＬＰレイヤにおいてデータパケットのフィルタリング情報（例えば、ＱｏＳ保証におけるパケットクラシファイア（packet classifier：パケット分類情報）として使用される。データパケットのフィルタリング情報がＮＡＴに対応できるようにするため、非特許文献１１Ｂでは、ＮＡＴがＮＴＬＰ対応であり、かつ、ＮＡＴにおいて、パケットヘッダのアドレス情報の変換と同時にフローＩＤの中身も変換されることが要請されている。
【非特許文献１】R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, "Resource ReSerVation Protocol - Version 1 Functional Specification", RFC 2205, September 1997.
【非特許文献２】NSIS WG（http://www.ietf.org/html.charters/nsis-charter.html）
【非特許文献３】H. Chaskar, Ed, "Requirements of a Quality of Service (QoS) Solution for Mobile IP", RFC3583, September 2003
【非特許文献４】Sven Van den Bosch, Georgios Karagiannis and Andrew McDonald "NSLP for Quality-of-Service signalling", draft-ietf-nsis-qos-nslp-05.txt, October 2004
【非特許文献５】X. Fu, H. Schulzrinne, H. Tschofenig, "Mobility issues in Next Step signaling", draft-fu-nsis-mobility-01.txt, October 2003
【非特許文献６】S. Lee, et. Al., “Applicability Statement of NSIS Protocols in Mobile Environments”, draft-ietf-nsis-applicability-mobility-signaling-00.txt, October 18, 2004
【非特許文献７】R. Hancock (editor), “Next Steps in Signaling: Framework”, draft-ietf-nsis-fw-07.txt, November 1, 2003
【非特許文献８】MRSVP: A. K. TALUKDAR, B.R. BADRINATH and A. ACHARYA, “A Resource Reservation Protocol for an Integrated Service Network with Mobile Hosts”, Wireless Network  7 pp5-19, 2001
【非特許文献９】T. Sanda, T. Ue, “Pre CRN discovery from proxy on candidate new path”, draft-sanda-nsis-mobility-qos-proxy-01.txt, Feruary 2004
【非特許文献１０】三田貴子，上豊樹，荒牧隆，“モビリティをサポートしたシームレスなＱｏＳ経路確立方法に関する提案”，電子情報通信学会モバイルマルチメディア通信（ＭｏＭｕＣ）研究会，Vol.104 No.38, pp59-64，２００４年５月
【非特許文献１１Ａ】H. Schulzrinne, R. Hancock,“GIMPS:  General Internet Messaging Protocol for Signaling”, draft-ietf-nsis-ntlp-05.txt, February 2005
【非特許文献１１Ｂ】H. Schulzrinne, R. Hancock,“GIMPS:  General Internet Messaging Protocol for Signaling”, draft-ietf-nsis-ntlp-07.txt, July 18, 2005
【非特許文献１２】三田貴子 他，“モバイルIPを用いた通信におけるQoSステート管理方法に関する提案”，電子情報通信学会情報ネットワーク（ＩＮ）研究会，vol. 104, no. 564, IN2004-144, pp. 1-6, ２００５年１月
【非特許文献１３】M. Stiemerling, H. Tschofenig and C. Aoun “NAT/Firewall NSIS Signaling Layer Protocol (NSLP)”, draft-ietf-nsis-nslp-natfw-07.txt, July 18, 2005
【発明の開示】
【発明が解決しようとする課題】
【００２４】
従来の技術には、主に、下記の２つの課題（第１及び第２の課題）が存在する。
【００２５】
まず、従来の技術に係る第１の課題について説明する。例えば、上記の非特許文献８に記載されている方法では、ＭＮのためのＱｏＳ経路をあらかじめ確立するために、新たなサブネットワークにおけるプロキシが用いられる。しかしながら、ＭＮのＮＣｏＡを取得した後にのみ、プロキシによってＱｏＳ経路が確立されるが、プロキシは、ＭＮが実際に移動する前にＭＮのＮＣｏＡを取得できない可能性があり、事前にＮＣｏＡを取得する処理によって、スムーズな経路の確立が妨げられてしまう可能性がある。
【００２６】
また、ＱｏＳ経路を確立するための試みが、いくつもの経路にわたって実行される必要があり、ＭＮは、こうしたＱｏＳ経路の確立結果に基づいて、新たな接続ポイントへの移動を決定する場合がある。したがって、ＭＮのＮＣｏＡは、ＱｏＳ経路の確立後に生成される場合もあり、この場合には、プロキシが、ＭＮの新たな接続ポイントとなり得る各接続ポイントにおけるＭＮのＮＣｏＡを取得することは困難である。
【００２７】
次に、従来の技術に係る第２の課題について説明する。ＮＳＩＳの現仕様では、フローＩＤがそのままパケットクラシファイア（packet classifier：パケット分類情報）として用いられるため、フローＩＤにデータパケットのヘッダ情報が含まれていなければならず、この制限が、ＭＮのハンドオーバ時におけるスムーズなＱｏＳ経路変更を困難にしている。さらに、端末が１つのセッションに対し、複数のＩＰアドレスや複数のポート番号を用いて通信を行っている場合（例えば、端末がマルチホーム状態の場合）や、セッションの途中でＩＰアドレスやポート番号に変更が生じる場合に、ＱｏＳ経路の管理は非常に困難なものとなってしまう場合がある。
【００２８】
上記問題に鑑み、本発明は、移動端末がハンドオーバを行う際に、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることを第１の目的とする。
【００２９】
また、本発明では、端末が１つのセッションに対し、複数のＩＰアドレスや複数のポート番号を用いて通信を行っている場合や、セッションの途中でＩＰアドレスやポート番号に変更が生じる場合において、経路（特に、ＱｏＳ経路）の管理を容易にすることを第２の目的とする。
【課題を解決するための手段】
【００３０】
上記目的を達成するため、本発明の通信システムは、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な通信システムであって、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続し、前記第１アクセスルータが構成する第１サブネットで取得する第１アドレスを使用して通信を行う移動可能な移動端末と、
前記通信ネットワークに接続されており、前記移動端末の通信相手となる通信相手端末と、
前記移動端末が、前記複数のアクセスルータのうちの１つである第２アクセスルータに接続した場合に前記第２アクセスルータが構成する第２サブネットで取得する第２アドレスを使用せずに、前記第１アクセスルータに接続している前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路が確立された状態で、前記第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始することが可能な前記通信ネットワーク内に存在する通信ノードとを有している。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信ノードが、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることが可能となる。
【００３１】
さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、前記第２アクセスルータの近隣に存在している。
この構成により、移動端末がハンドオーバ後に第２アクセスルータに接続した場合に、この第２アクセスルータの近隣に存在する通信ノードを経由した経路の設定が可能となる。
【００３２】
さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信し、前記トリガ情報に基づいて前記第２経路を確立する処理を開始するように構成されている。
この構成により、プロキシとして機能する通信ノードは、この第２経路の確立処理に必要な情報や、その開始タイミングなどを把握することが可能となる。
【００３３】
さらに、本発明の通信システムは、上記の通信システムに加えて、前記移動端末が、前記トリガ情報を前記通信ノードに送信するように構成されている。
この構成により、移動端末が、第２経路の確立開始処理を開始させる指示を行うとともに、第２経路の確立に必要な情報を、プロキシとして機能する通信ノードに送信することが可能となる。
【００３４】
さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、自ノードを一方の終端とする前記第２経路を確立するように構成されている。
この構成により、移動端末のアドレスを用いずに、プロキシとして機能する通信ノードのアドレスを使用して、第２経路を確立することが可能となる。
【００３５】
さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードは、前記移動端末が前記第２サブネットに移動して割り当てられた第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始するように構成されている。
この構成により、プロキシとして機能する通信ノードが、移動端末の新たなアドレスを取得した場合には、そのアドレスに基づく第３経路の確立が開始されるようになる。
【００３６】
さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている。
この構成により、プロキシとして機能する通信ノードが、ＱｏＳ保証などの付加的サービスが提供されないヘッダを有するパケットに対して、カプセル化を行うことで、付加的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセル化が行われることによって、適切なあて先にパケットが到達可能となる。
【００３７】
さらに、本発明の通信システムは、上記の通信システムに加えて、前記第２経路の終端が前記通信ノード及び前記通信相手端末であり、前記通信相手端末が、前記移動端末にパケットを送信する際に前記通信ノードのアドレスをあて先アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記通信相手端末から前記移動端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている。
この構成により、通信相手端末（ＣＮ）が、ＱｏＳ保証などの付加的サービスが提供されないヘッダを有するパケットに対して、カプセル化を行うことで、付加的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセル化が行われることによって、適切なあて先にパケットが到達可能となる。
【００３８】
さらに、本発明の通信システムは、上記の通信システムに加えて、前記第２経路の終端が前記第２アクセスルータの近隣に存在する前記通信ノード及び前記通信相手端末の近隣に存在する相手側近隣通信ノードであり、前記相手側近隣通信ノードが、前記通信相手端末から前記移動端末へのパケットを転送する際に前記通信ノードのアドレスをあて先アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記通信相手端末から前記移動端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている。
この構成により、通信相手端末（ＣＮ）の近隣に存在する相手側近隣通信ノードが、ＱｏＳ保証などの付加的サービスが提供されないヘッダを有するパケットに対して、カプセル化を行うことで、付加的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセル化が行われることによって、適切なあて先にパケットが到達可能となる。また、通信相手端末（ＣＮ）が、付加的サービス機能やカプセル化機能を実装していない場合でも、伝送されるパケットは付加的サービスを受けることが可能となる。
【００３９】
さらに、本発明の通信システムは、上記の通信システムに加えて、前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第１サブネットに接続している状態で使用されていた前記第１経路、及び前記通信ノードによって確立された前記第２経路が削除されるように構成されている。
この構成により、ハンドオーバ前の状態からハンドオーバ後の状態に移行する際に、余分な情報（無駄なリソース予約など）が残らないようにすることが可能となる。
【００４０】
さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、自ノードと前記通信相手端末との間の経路上の中間通信ノードに、前記第２経路を確立する処理を行う際に送受信されるシグナリングメッセージのルーティングのためのステートを導入する処理を開始するように構成されている。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信ノードが、ハンドオーバ後における経路の再設定のうち、シグナリングメッセージのルーティングのためのステート確立処理を経路の一部に対して迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることが可能となる。
【００４１】
さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、前記中間通信ノードに対して、自ノードのアドレス及び前記通信相手端末のアドレスにより構成された識別情報を送信し、前記中間通信ノードが、前記識別情報を保持して、前記識別情報を有するシグナリングメッセージを特定するように構成されている。
この構成により、移動端末に対してハンドオーバ後に割り当てられるアドレスを取得する前に、プロキシとして機能する通信ノードは、通信相手端末との間におけるシグナリングメッセージのルーティングのためのステート確立処理を開始することが可能となる。
【００４２】
さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードは、前記移動端末が前記第２サブネットに移動して割り当てられた第２アドレスを取得した場合に、前記第２経路に係る付加的サービスを提供するための情報を含むシグナリングメッセージを送信し、前記中間通信ノードが、前記シグナリングメッセージのルーティングのためのステートを使用して、前記シグナリングメッセージの伝送を行うように構成されている。
この構成により、移動端末のハンドオーバ後に割り当てられるアドレスを取得する前に確立されたシグナリングメッセージのルーティングのためのステートを利用して、付加的サービスを提供するための情報を含むシグナリングメッセージを伝送することが可能となり、新たな経路（特に、ＱｏＳ経路）を迅速に確立することが可能となる。
【００４３】
さらに、本発明の通信システムは、上記の通信システムに加えて、前記付加的サービスがＱｏＳ保証である場合に適用される。
【００４４】
また、上記目的を達成するため、本発明のリソース管理装置によれば、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な前記通信ネットワークに存在する通信ノード内のリソース管理装置であって、
前記経路において、付加的サービスを提供するためのリソースを確保するためのリソース確保手段と、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続している前記移動端末と、前記通信ネットワークに接続されており前記移動端末の通信相手となる通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信するトリガ受信手段と、
前記トリガ受信手段で前記トリガ情報を受信した場合、前記トリガ情報に基づいて、前記第１アクセスルータとは異なる第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始するメッセージを生成するメッセージ生成手段とを有している。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信ノードが、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることが可能となる。
【００４５】
さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記メッセージには、前記移動端末の代理として経路設定を行う旨を示す情報が付加されている。
この構成により、上記のメッセージに係るリソース予約が、プロキシによるものであることを、経路上の各ＱＮＥに対して明示することが可能となる。
【００４６】
さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記第２アクセスルータの近隣に存在する前記通信ノード内に配置されている。
この構成により、移動端末がハンドオーバ後に第２アクセスルータに接続した場合に、この第２アクセスルータの近隣に存在する通信ノードを経由した経路の設定が可能となる。
【００４７】
さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記トリガ情報に、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスが少なくとも含まれている。
この構成により、プロキシとして機能する通信ノードは、この第２経路の確立処理に必要な情報や、その開始タイミングなどを把握することが可能となる。
【００４８】
さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移動端末から前記トリガ情報を受信する。
この構成により、移動端末が、第２経路の確立開始処理を開始させる指示を行うとともに、第２経路の確立に必要な情報を、プロキシとして機能する通信ノードに送信することが可能となる。
【００４９】
さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記通信ノードを一方の終端とする前記第２経路を確立するように構成されている。
この構成により、移動端末のアドレスを用いずに、プロキシとして機能する通信ノードのアドレスを使用して、第２経路を確立することが可能となる。
【００５０】
さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移動端末が前記第２サブネットに移動して割り当てられた前記第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始するように構成されている。
この構成により、プロキシとして機能する通信ノードが、移動端末の新たなアドレスを取得した場合には、そのアドレスに基づく第３経路の確立が開始されるようになる。
【００５１】
さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている。
この構成により、プロキシとして機能する通信ノードが、ＱｏＳ保証などの付加的サービスが提供されないヘッダを有するパケットに対して、カプセル化を行うことで、付加的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセル化が行われることによって、適切なあて先にパケットが到達可能となる。
【００５２】
さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第２経路を削除するためのメッセージを送信するように構成されている。
この構成により、ハンドオーバ前の状態からハンドオーバ後の状態に移行する際に、余分な情報（無駄なリソース予約など）が残らないようにすることが可能となる。
【００５３】
さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記付加的サービスが、ＱｏＳ保証である場合に適用可能である。
【００５４】
また、上記目的を達成するため、本発明のリソース管理方法は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な前記通信ネットワークに存在する通信ノードで行われるリソース管理方法であって、
前記経路において、付加的サービスを提供するためのリソースを確保するためのリソース確保ステップと、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続している前記移動端末と、前記通信ネットワークに接続されており前記移動端末の通信相手となる通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信するトリガ受信ステップと、
前記トリガ受信ステップで前記トリガ情報を受信した場合、前記トリガ情報に基づいて、前記第１アクセスルータとは異なる第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始するメッセージを生成するメッセージ生成ステップとを有している。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信ノードが、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることが可能となる。
【００５５】
さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記メッセージには、前記移動端末の代理として経路設定を行う旨を示す情報が付加されている。
この構成により、上記のメッセージに係るリソース予約が、プロキシによるものであることを、経路上の各ＱＮＥに対して明示することが可能となる。
【００５６】
さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記第２アクセスルータの近隣に存在する前記通信ノード内に配置されている。
この構成により、移動端末がハンドオーバ後に第２アクセスルータに接続した場合に、この第２アクセスルータの近隣に存在する通信ノードを経由した経路の設定が可能となる。
【００５７】
さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記トリガ情報に、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスが少なくとも含まれている。
この構成により、プロキシとして機能する通信ノードは、この第２経路の確立処理に必要な情報や、その開始タイミングなどを把握することが可能となる。
【００５８】
さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移動端末から前記トリガ情報を受信する。
この構成により、移動端末が、第２経路の確立開始処理を開始させる指示を行うとともに、第２経路の確立に必要な情報を、プロキシとして機能する通信ノードに送信することが可能となる。
【００５９】
さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記通信ノードを一方の終端とする前記第２経路を確立する。
この構成により、移動端末のアドレスを用いずに、プロキシとして機能する通信ノードのアドレスを使用して、第２経路を確立することが可能となる。
【００６０】
さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移動端末が前記第２サブネットに移動して割り当てられた前記第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始する。
この構成により、プロキシとして機能する通信ノードが、移動端末の新たなアドレスを取得した場合には、そのアドレスに基づく第３経路の確立が開始されるようになる。
【００６１】
さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化ステップを有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化ステップにおいてカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるようにしている。
この構成により、プロキシとして機能する通信ノードが、ＱｏＳ保証などの付加的サービスが提供されないヘッダを有するパケットに対して、カプセル化を行うことで、付加的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセル化が行われることによって、適切なあて先にパケットが到達可能となる。
【００６２】
さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第２経路を削除するためのメッセージを送信する。
この構成により、ハンドオーバ前の状態からハンドオーバ後の状態に移行する際に、余分な情報（無駄なリソース予約など）が残らないようにすることが可能となる。
【００６３】
さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記付加的サービスが、ＱｏＳ保証である場合に適用される。
【００６４】
また、上記目的を達成するため、本発明の通信管理装置は、シグナリングメッセージをルーティングする機能を有する第１ユニットと、提供する付加的サービスに関する情報を管理するための機能を有する第２ユニットとにより構成された通信プロトコルを使用して２つの通信ノード間で行われる通信において、前記２つの通信ノード間の経路上に存在し、前記２つの通信ノード間で伝送されるデータパケットに対して前記付加的サービスを提供する通信ノード内の通信管理装置であって、
前記第１ユニットが、前記２つの通信ノード間の経路の一部であって、自ノードを含んだ任意の両端点を有する前記経路の一部において伝送される前記シグナリングメッセージのルーティングのためのステートを管理するステート管理手段を有し、
前記第２ユニットが、前記シグナリングメッセージによって伝送されるフィルタ情報であって、前記付加的サービスを提供する対象となるデータパケットを特定するための前記フィルタ情報を管理するフィルタ情報管理手段を有している。
この構成により、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、経路の管理を容易に行えるようにすることが可能となる。
【００６５】
さらに、本発明の通信管理装置は、上記の通信管理装置に加えて、前記ステートが、前記任意の両端点のアドレスを有し、前記フィルタ情報が、前記２つの通信ノードのアドレスを有している。
この構成により、シグナリングメッセージのルーティングのための情報、及び付加的サービスを提供するデータパケットを特定するための情報のそれぞれに関して、異なるアドレスが設定できるようになり、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、特に、ルーティングのためのステートの確立処理を柔軟に行えるようにすることが可能となる。
【００６６】
さらに、本発明の通信管理装置は、上記の通信管理装置に加えて、前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層に配置されている。
この構成により、フローＩＤとフィルタ情報とを分けて別々に管理し、シグナリングメッセージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存性を緩和することが可能となる。また、ＮＳＩＳにおいて、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、特に、ルーティングのためのステートの確立処理を柔軟に行えるようにすることが可能となる。
【００６７】
また、上記目的を達成するため、本発明の通信管理方法は、シグナリングメッセージをルーティングする機能を有する第１ユニットと、提供する付加的サービスに関する情報を管理するための機能を有する第２ユニットとにより構成された通信プロトコルを使用して２つの通信ノード間で行われる通信において、前記２つの通信ノード間の経路上に存在し、前記２つの通信ノード間で伝送されるデータパケットに対して前記付加的サービスを提供する通信ノードで行われる通信管理方法であって、
前記第１ユニットが、前記２つの通信ノード間の経路の一部であって、自ノードを含んだ任意の両端点を有する前記経路の一部において伝送される前記シグナリングメッセージのルーティングのためのステートを管理するステート管理ステップと、
前記第２ユニットが、前記シグナリングメッセージによって伝送されるフィルタ情報であって、前記付加的サービスを提供する対象となるデータパケットを特定するための前記フィルタ情報を管理するフィルタ情報管理ステップとを有している。
この構成により、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、経路の管理を容易に行えるようにすることが可能となる。
【００６８】
さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記ステートが、前記任意の両端点のアドレスを有し、前記フィルタ情報が、前記２つの通信ノードのアドレスを有している。
この構成により、シグナリングメッセージのルーティングのための情報、及び付加的サービスを提供するデータパケットを特定するための情報のそれぞれに関して、異なるアドレスが設定できるようになり、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、特に、ルーティングのためのステートの確立処理を柔軟に行えるようにすることが可能となる。
【００６９】
さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層に配置されている。
この構成により、フローＩＤとフィルタ情報とを分けて別々に管理し、シグナリングメッセージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存性を緩和することが可能となる。また、ＮＳＩＳにおいて、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、特に、ルーティングのためのステートの確立処理を柔軟に行えるようにすることが可能となる。
【００７０】
さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第１及び第２ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されている。
この構成により、フローＩＤとフィルタ情報とを分けて別々に管理し、シグナリングメッセージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存性を緩和することが可能となる。
【００７１】
さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層の任意の機能が参照可能なＮＳＬＰ共通部に配置されている。
この構成により、フローＩＤとフィルタ情報とを分けて別々に管理し、シグナリングメッセージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存性を緩和することが可能となる。
【００７２】
さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層の特定の機能部に配置されていて、前記特定の機能部から前記ＮＳＬＰ層の任意の機能部に、前記フィルタ情報の一部又は全部が渡されるように構成されている。
この構成により、フローＩＤとフィルタ情報とを分けて別々に管理し、シグナリングメッセージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存性を緩和することが可能となる。
【発明の効果】
【００７３】
本発明は、上記の構成を有しており、移動端末がハンドオーバ後に接続するサブネットにおいて使用するアドレス（ＮＣｏＡ）を用いずに、ハンドオーバ後の移動端末が送信元又はあて先に設定されたパケットに対して、付加的サービス（特に、ＱｏＳ）を提供することによって、移動端末のＮＣｏＡの生成タイミングや取得機構などに影響されない、スムーズな経路（特に、ＱｏＳ経路）の確立が実現可能となる。
【００７４】
また、本発明は、上記の構成を有しており、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することにより、移動端末のＮＣｏＡの生成タイミングや取得機構などに影響されない、スムーズな経路（特に、ＱｏＳ経路）の確立が実現可能となるとともに、さらには、複数のＩＰアドレスや複数のポート番号を用いて通信を行っている場合や、セッションの途中でＩＰアドレスやポート番号に変更が生じる場合においても、経路（特に、ＱｏＳ経路）の管理を容易にすることを可能にする。
【発明を実施するための最良の形態】
【００７５】
以下、図面を参照しながら、本発明の第１〜第３の実施の形態について説明する。なお、まず、本発明の第１の実施の形態では、データの流れ方向が、移動を行うＭＮから、その通信相手であるＣＮに向かう方向（以下、uplink方向と呼ぶ）の場合について説明を行い、続いて、本発明の第２の実施の形態では、データの流れ方向が、ＣＮからＭＮに向かう方向（以下、downlink方向と呼ぶ）の場合について説明を行う。
【００７６】
＜第１の実施の形態＞
以下、本発明の第１の実施の形態について説明する。まず、図１〜３を参照しながら、本発明の第１の実施の形態に係る概要について説明する。図１は、本発明の第１の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ経路の状態を模式的に示す図である。また、図２は、本発明の第１の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路を確立した状態を模式的に示す図である。また、図３は、本発明の第１の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図である。
【００７７】
図１〜３には、無線通信によりＡＲ（Access Router）に接続してＣＮ１２１との通信を行うＭＮ１０１と、ＭＮ１０１の通信相手となるＣＮ１２１と、サブネット１０３を形成するＡＲ１０５と、サブネット１０７を形成するＡＲ１０９と、ＭＮ１０１とＣＮ１２１との間における経路上に存在し、ＭＮ１０１とＣＮ１２１との間で伝送されるパケットに関してＱｏＳ保証を行うＱｏＳ認識機能（QoS-aware）を有するＱＮＥ１１１、１１３、１１５、１１７、１１９、１２３、１２５とが図示されている。
【００７８】
なお、ＭＮ１０１がサブネット１０３に存在している場合（すなわち、ＭＮ１０１がＡＲ１０５に接続している場合）、ＭＮ１０１からＣＮ１２１へのuplink方向の経路１２７上には、ＡＲ１０５、ＱＮＥ１１１、ＱＮＥ１１３、ＱＮＥ１１５、ＱＮＥ１１７、ＱＮＥ１１９が存在しており、ＭＮ１０１がサブネット１０７に存在している場合（すなわち、ＭＮ１０１がＡＲ１０９に接続している場合）、ＭＮ１０１からＣＮ１２１へのuplink方向の経路１２９上には、ＡＲ１０９、ＱＮＥ１２３、ＱＮＥ１２５、ＱＮＥ１１５、ＱＮＥ１１７、ＱＮＥ１１９が存在しているものとする。なお、経路１２７と経路１２９とは一部が重複しており、経路１２７と経路１２９とのＣＲＮ（Crossover Node：クロスオーバノード）をＱＮＥ１１５とする。
【００７９】
図１において、ＭＮ１０１からＣＮ１２１に送信されるデータパケットは、経路１２７を経由して伝送される。このとき、経路１２７上のすべてのＱＮＥ１１１、１１３、１１５、１１７、１１９は、ＭＮ１０１からＣＮ１２１に送信されるデータパケットに関するＱｏＳステートを有している。すなわち、各ＱＮＥ１１１、１１３、１１５、１１７、１１９は、少なくとも送信元アドレス（source address）及びあて先アドレス（destination address）の情報を含む識別情報（この情報をフィルタ情報（filter）と呼ぶ）と、このフィルタ情報に対応するリソース予約情報（resource）とが関連付けているＱｏＳステートを保持しており、ＭＮ１０１からＣＮ１２１に送信されるデータパケットのヘッダ（特に、送信元アドレス及びあて先アドレス）を参照してフィルタ情報を特定し、対応するリソース予約情報に基づくＱｏＳ保証を行うように構成されている。なお、上述した非特許文献４、６、７などの現在のフローＩＤは、データパケットの送信元アドレス及びあて先アドレスを含む情報により構成されていると記載されており、このフローＩＤを上記のフィルタ情報として利用することも可能である。また、フィルタ情報は、フローＩＤとは異なる情報であってもよい。
【００８０】
なお、図１に図示されているように、経路１２７のフィルタ情報（ＭＮ１０１がサブネット１０３から割り当てられているＩＰアドレス（ｃＣｏＡ：current Care-of Address）が送信元アドレスとして含まれているとともに、ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれているフィルタ情報）をfilterAとし、filterAに対応するリソース予約情報をresourceAとする。
【００８１】
ＭＮ１０１は、サブネット１０７に移動する可能性があり、プロキシ１２３に対して予測経路（経路１２９）、又は予測経路の一部の確立を所望している。なお、ＭＮ１０１がサブネット１０７に移動する前に、プロキシ１２３によって予測経路、又は予測経路の一部が確立されることで、ＭＮ１０１が実際にサブネット１０７に移動した後に、より迅速にＭＮ１０１からＣＮ１２１へのＱｏＳ経路が確立され、ハンドオーバによるＱｏＳ保証の中断時間を短縮することが可能となる。
【００８２】
ＱＮＥ（プロキシ）１２３が予測経路を確立するための何らかのトリガを受けた場合には、ＱＮＥ（プロキシ）１２３とＣＲＮ（ここではＱＮＥ１１５）との間でＱｏＳ経路が確立される。この新たな経路が確立された場合には、ＱＮＥ（プロキシ）１２３や、ＱＮＥ（プロキシ）１２３とＱＮＥ１１５との間の各中間ＱＮＥ（例えば、ＱＮＥ１２５）は、新たなＱｏＳステートを有することになる。すなわち、図２に図示されているように、ＱＮＥ（プロキシ）１２３やＱＮＥ１２５では、ＱＮＥ（プロキシ）１２３のＩＰアドレスが送信元アドレスとして含まれているとともに、ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれているフィルタ情報（filterB）に対して、filterAと同一のリソース予約情報であるresourceAが設定される。
【００８３】
一方、ＱＮＥ１１５とＣＮ１２１との間の経路上のＱＮＥに関しては、新たなフィルタ情報（上記のfilterB）が、現在のフィルタ情報（filterA）に追加される。これにより、図２に図示されているように、ＱＮＥ１１５や、ＱＮＥ１１５とＣＮ１２１との間の各中間ＱＮＥ（例えば、ＱＮＥ１１７、１１９）は、filterA及びfilterBに対してresourceAが設定されたＱｏＳステートを有することになり、filterBによって定義されるデータトラフィックには、filterAによって定義されるデータトラフィックのために予約されたresourceAが使用可能となる。なお、例えば、同一セッションＩＤを有する２つのフィルタ情報（filterA及びfilterB）によりどちらか一方が削除されてしまうなど、従来行われている処理によって本発明に係る動作に不具合が生じる可能性があるため、例えば、filterBに係るＲＥＳＥＲＶＥメッセージには、プロキシによるＱｏＳ経路の確立であることを示す特別なフラグ（「プロキシフラグ」）が付加されることが望ましい。
【００８４】
以上のように、ＭＮ１０１がサブネット１０７への移動を行う前に（あるいは、ＭＮ１０１のサブネット１０７への移動とは無関係に）、ＱＮＥ（プロキシ）１２３は、ＭＮ１０１のＮＣｏＡ（ＭＮ１０１がサブネット１０７に移動した後に割り当てられる新たなＣｏＡ）を用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路の一部（ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路）に係るリソース予約を行うことが可能となる（図２に図示されている状態）。
【００８５】
そして、ＭＮ１０１がＮＣｏＡを取得した場合（実際にサブネット１０７に移動してＮＣｏＡを取得するか、あるいはサブネット１０３に接続した状態でＮＣｏＡを取得した場合）には、図３に図示されているように、経路１２９上の各中間ＱＮＥ（ＱＮＥ１２３、１２５、１１５、１１７、１１９）において、ＭＮ１０１のＮＣｏＡが送信元アドレスとして含まれているとともに、ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれている新たなフィルタ情報（filterC）がfilterA又はfilterBに追加されることによって、ＱｏＳ経路の更新が行われる。なお、ＭＮ１０１がサブネット１０７に移動した場合には、filterAに関しては、能動的（削除を指示するメッセージの送信などによる）又は受動的（タイムアウトなどによる）に削除されることが望ましい。また、フローＩＤとは異なる情報としてフィルタ情報が存在する場合には、フローＩＤは、データパケットの送信元アドレス／あて先アドレスに依存するものでなくてもよい。例えば、図３でプロキシ１２３がfilterCに関するリソース予約を行う際、経路１２９全体に使われるフローＩＤは「送信元＝ＱＮＥ（プロキシ）１２３、あて先＝ＣＮ１２１」を含んでいてもよく、またＭＮ１０１からＱＮＥ（プロキシ）１２３までの経路に関しては「送信元＝ＱＮＥ（プロキシ）１２３、あて先＝ＭＮ１０１」を含むフローＩＤ、ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路に関しては「送信元＝ＱＮＥ（プロキシ）１２３、あて先＝ＣＮ１２１」を含むフローＩＤをそれぞれ用いて、２つの経路として扱ってもよい。
【００８６】
例えば、ＭＮ１０１がサブネット１０７に移動してＮＣｏＡを取得した後に、ＮＣｏＡに関するＱｏＳ経路の更新が完了（filterCに関するリソース予約が完了）する前までは、ＭＮ１０１からＣＮ１２１あてに送信されるデータパケットは、ＱＮＥ（プロキシ）１２３によって、filterBの情報を含むアウタヘッダ（送信元アドレスをＱＮＥ（プロキシ）１２３のＩＰアドレスとし、あて先アドレスをＣＮ１２１のＩＰアドレスとするヘッダ）が付加されて、カプセル化される。このカプセル化されたデータパケットはfilterBによって識別され、各中間ＱＮＥにおいて、resourceAに基づくＱｏＳ保証が行われて伝送され、filterBによって識別される経路の最終ＱＮＥによって脱カプセル化される。なお、この最終ＱＮＥはＣＮ１２１であることが望ましいが、ＣＮ１２１がＱＮＥではない場合には、その他のＱＮＥ（例えば、経路上において、ＣＮ１２１の最も近くに存在するＱＮＥ１１９）であってもよい。
【００８７】
最終ＱＮＥは、filterBで特定されるヘッダを持つパケットが到達した際には、脱カプセル化を行ってインナパケットを取り出す。ＣＮ１２１が最終ＱＮＥの場合にはそのインナパケットを取得し、ＱＮＥ１１９が最終ＱＮＥの場合にはそのインナパケットをＣＮ１２１に向けて転送する。なお、経路全体にわたってＱｏＳ予約が行われるようにするための方法としては、例えばＩＰｖ４最小カプセル化など、上述のパケットのカプセル化方法以外にも存在することは、当業者にとって明白であり、任意のパケットのカプセル化方法を本発明に適用することが可能である。また、本発明は、他の種類のカプセル化やトンネリング機構においても良好に動作する。
【００８８】
このように、ＭＮ１０１のＮＣｏＡが設定されているfilterCに関するリソース予約が完了するまでは、データパケットのカプセル化が行われ、ＱＮＥ（プロキシ）１２３のＩＰアドレスが送信元アドレスとして設定されているfilterBによって、カプセル化されたデータパケットのＱｏＳ保証が行われるように構成されており、ＭＮ１０１のＮＣｏＡを用いてリソース予約が行われるまでのＱｏＳ保証の中断時間を低減することが可能となる。
【００８９】
また、filterCのＱｏＳの更新に成功した後（すなわち、filterCが経路１２９上のすべてのＱＮＥに導入された後）は、ＱＮＥ（プロキシ）１２３は、filterBのデータパケットの生成（filterAのデータパケットのカプセル化）を終了する。そして、filterAやfilterBは能動的又は受動的に削除され、最終的にfilterCに関するＱｏＳステートのみが残り、サブネット１０７に接続しているＭＮ１０１からＣＮ１２１への経路１２９において、ＭＮ１０１からＣＮ１２１へのデータパケットに対するＱｏＳ保証が行われる。
【００９０】
次に、図４を参照しながら、本発明の第１の実施の形態におけるＱＮＥの構成について説明する。図４は、本発明の第１の実施の形態におけるＱＮＥの一構成例を示す図である。図４に示すＱＮＥは、受信手段１１、送信手段１３、トリガ検出手段１５、メッセージ生成・処理手段１７、フィルタリング手段１９、カプセル化／脱カプセル化手段２１、ＱｏＳ情報格納手段２３を有している。
【００９１】
受信手段１１及び送信手段１３は、パケットの受信及びパケットの送信を行うための手段である。また、トリガ検出手段１５は、例えばＭＮ１０１から受信する、予測経路を確立するための何らかのトリガに係る処理を行うための手段である。なお、受信したトリガ情報は、例えば、フィルタ情報ごとに関連付けられてＱｏＳ情報格納手段２３に格納される。また、トリガ検出手段１５からメッセージ生成・処理手段１７に対して、トリガ情報の受信イベントが発生した旨を示す情報や、トリガ情報自体が供給される。
【００９２】
また、メッセージ生成・処理手段１７は、トリガ情報に含まれるＭＮ１０１とＣＮ１２１との間のＱｏＳ経路で用いられているセッションＩＤや、QSpec情報や、ＣＮ１２１のＩＰアドレスなどの情報に基づいて、データ経路上の各通信ノードの調査や、実際のリソース予約などを行うためのメッセージを生成するための手段である。また、他の通信ノードから受信したメッセージに関しても、このメッセージ生成・処理手段１７において処理が行われ、リソース予約などを行うための情報（セッションＩＤやフィルタ情報、QSpecなどの情報）は、ＱｏＳ情報格納手段２３に格納される。
【００９３】
また、フィルタリング手段１９は、受信パケットのヘッダ（特に、フィルタ情報に対応するパケットの送信元アドレス及びあて先アドレス）を参照して、受信パケットに対して、ＱｏＳ情報格納手段２３に格納されているＱｏＳ情報（ＱｏＳステート）に基づくパケットのフィルタリングを行う手段であり、このフィルタリングによって、各パケットに対するリソースが確保されるように構成されている。また、カプセル化／脱カプセル化手段２１は、必要に応じて、送信パケットのカプセル化や、受信パケットの脱カプセル化を行う手段である。
【００９４】
なお、後述の具体例（図５のシーケンスチャートを参照）から分かるように、トリガ検出手段１５はＱＮＥ１２３においてのみ必要であり、その他のＱＮＥには実装されている必要はない。また、カプセル化／脱カプセル化手段２１は、例えば、ＱＮＥ１２３にカプセル化手段、ＣＮ１２１に脱カプセル化手段がそれぞれ実装されていればよく、その他のＱＮＥには、カプセル化／脱カプセル化手段２１が特に実装される必要はない。
【００９５】
次に、図５を参照しながら、本発明の第１の実施の形態における動作について説明する。図５は、本発明の第１の実施の形態における動作例を示すシーケンスチャートである。なお、ここでは具体例として、ＮＳＩＳのＱｏＳ ＮＳＬＰで定義されているメッセージであるＱＵＥＲＹメッセージやＲＥＳＥＲＶＥメッセージに、さらに本発明の動作に必要な情報を付加した場合について説明する。
【００９６】
図５において、まず、ＱＮＥ（プロキシ）１２３は、予測経路を確立するためのトリガを受け取る（ステップＳ２０１）。なお、このトリガには、例えば、ＭＮ１０１とＣＮ１２１との間のＱｏＳ経路で用いられているセッションＩＤ、QSpec情報、ＣＮ１２１（又は経路の最終ＱＮＥであるＱＮＲ（QoS NSIS Responder））のＩＰアドレスなど、予測経路を確立するために必要な情報が含まれている。また、ＱＮＥ（プロキシ）１２３が受信するトリガの送信元は任意のＱＮＥであってよいが、移動を行う可能性のあるＭＮ１０１や、その通信相手ノードであるＣＮ１２１、ＭＮ１０１やＣＮ１２１からの要求に応じて、ＭＮ１０１やＣＮ１２１の代理として機能するＱＮＥが送信元となることが好適である。なお、この場合、ＭＮ１０１やＣＮ１２１、代理となるＱＮＥは、トリガのあて先に使用するＱＮＥ（プロキシ）１２３のＩＰアドレスを把握する必要があるが、この把握方法は、特に限定されるものではない。
【００９７】
トリガを受け取ったＱＮＥ（プロキシ）１２３は、即座に、このトリガに対応したＱＵＥＲＹメッセージをＣＮ１２１に向かって送信する（ステップＳ２０３）。このＱＵＥＲＹメッセージには、例えば、セッションＩＤとQSpec情報とが含まれている。ＱＵＥＲＹメッセージは、経路１２９上においてＱＮＥ（プロキシ）１２３に隣接するＱＮＥ１２５に到達する。ＱＮＥ１２５は、このＱＵＥＲＹメッセージに基づいて通常のＱＵＥＲＹ処理（例えば、ＱＵＥＲＹメッセージに含まれているセッションＩＤのリソース予約状況の確認処理など）を行うとともに、次の隣接するＱＮＥ（ＱＮＥ１１５）にＱＵＥＲＹメッセージを送信する（ステップＳ２０５）。ＱＮＥ１１５は、ＱＵＥＲＹメッセージを受信すると、ＱＵＥＲＹメッセージ内のセッションＩＤや、隣接するＱＮＥの変化を検出するための情報として使われるＳＩＩ（Source Identification Information）を比較することによって、自身がＣＲＮであることを認識する（ステップＳ２０７）。
【００９８】
ＱＮＥ１１５は、新たな予約を行うために、「プロキシフラグ」が付加された受信者始動ＲＥＳＥＲＶＥメッセージ（receiver-initiated RESERVE message）をＱＮＥ１２３に送信する（ステップＳ２０９）。この予約におけるフィルタ情報には、送信元アドレスとしてＱＮＥ（プロキシ）１２３のＩＰアドレスが含まれている（図２のfilterBに対応）。なお、ステップＳ２０９においてＱＮＥ１１５から送信されたＲＥＳＥＲＶＥメッセージは、ＱＮＥ１２３まで伝送され（ステップＳ２１１）、各ＱＮＥ（ＱＮＥ１２３、１２５）において、ＲＥＳＥＲＶＥメッセージに含まれているフィルタ情報やQSpecに基づいて、フィルタ／リソースの組が生成されて予約が行われる。なお、ＱＮＥ１１５においても同様に、フィルタ／リソース（図２のfilterB/resourceA）の組が生成されて予約が行われる。
【００９９】
また、ステップＳ２０９における受信者始動ＲＥＳＥＲＶＥメッセージの送信と同時に、ＱＮＥ１１５は「プロキシフラグ」が付加された送信者主導のＲＥＳＥＲＶＥメッセージ（sender-initiated RESERVE message：図５ではRESERVE(add)と記載）をＣＮ１２１に送信する（ステップＳ２１３）。この予約におけるフィルタ情報には、送信元アドレスとしてＱＮＥ（プロキシ）１２３のＩＰアドレスが含まれている（図２のfilterBに対応）。ステップＳ２１３においてＱＮＥ１１５から送信されたＲＥＳＥＲＶＥメッセージは、ＣＮ１２１まで伝送され（ステップＳ２１３、Ｓ２１５、Ｓ２１７）、各ＱＮＥ（ＱＮＥ１１７、１１９）において、このフィルタ情報が、ＭＮ１０１からＣＮ１２１へのデータパケットに現在使用されている現在のフィルタ／リソース（図１のfilterA/resourceA）の組に追加される。
【０１００】
ここで、ＭＮ１０１がサブネット１０７に移動したとする（ステップＳ２１９）。ＱＮＥ（プロキシ）１２３はＭＮ１０１の移動を検出し、ＭＮ１０１のＮＣｏＡを取得した場合（ステップＳ２２１）には、受信者始動ＲＥＳＥＲＶＥメッセージをＭＮ１０１に送信する（ステップＳ２２３）。このＲＥＳＥＲＶＥメッセージに関するフィルタ情報には、送信元アドレスとしてＭＮ１０１のＮＣｏＡが含まれている。
【０１０１】
また、ＱＮＥ（プロキシ）１２３は、ＣＮ１２１あてのデータパケットをＭＮ１０１から受信した場合には、送信元アドレスがＱＮＥ（プロキシ）１２３のアドレスに設定されたアウタヘッダ（あて先アドレスは、ＣＮ１２１のアドレス）を付加することによって、ＭＮ１０１からのデータパケットのカプセル化を開始する（ステップＳ２２５）。カプセル化されたデータパケットは、その送信元アドレスがＱＮＥ（プロキシ）１２３であり、経路１２９上の各ＱＮＥでは、filterBのフィルタ情報に係るＱｏＳ処理が行われ、その結果、ＱｏＳ保証を受けることになる。
【０１０２】
一方、ＱＮＥ（プロキシ）１２３は、サブネット１０７への移動後のＭＮ１０１（すなわち、ＭＮ１０１のＮＣｏＡ）に関する予約を行うために、送信者主導のＲＥＳＥＲＶＥメッセージ（図５ではRESERVE(add)と記載）をＣＮ１２１に送信する（ステップＳ２２７）。この予約におけるフィルタ情報には、送信元アドレスとしてＭＮ１０１のＩＰアドレスが含まれている。そして、各ＱＮＥ（ＱＮＥ１２５、１１５、１１７、１１９）を経由してＲＥＳＥＲＶＥメッセージは伝送されるとともに（ステップＳ２２９、Ｓ２３１、Ｓ２３３、Ｓ２３５）、各ＱＮＥにおいて、このＲＥＳＥＲＶＥメッセージに含まれるフィルタ情報（図３のfilterC）が、以前に付加又は生成されたフィルタ情報（図２のfilterB）に付加される。
【０１０３】
ＲＥＳＥＲＶＥメッセージを受けたＣＮ１２１は、即座にＲＥＳＰＯＮＳＥメッセージをＱＮＥ１２３に向けて送信する（ステップＳ２３７）。このＲＥＳＰＯＮＳＥメッセージは、各ＱＮＥ（１１９、１１７、１１５、１２５）を経由してＱＮＥ（プロキシ）１２３に到達する（ステップＳ２３９、２４１、２４３、２４５）。このＲＥＳＰＯＮＳＥメッセージの受信によって、ＱＮＥ（プロキシ）１２３はＭＮ１０１のＮＣｏＡに係るＱｏＳ経路が確立された旨を認識し、ＱＮＥ（プロキシ）１２３は、データパケットのカプセル化を終了する（ステップＳ２４７）。
【０１０４】
さらに、ＱＮＥ１２３は、ステップＳ２０９〜Ｓ２１７で導入されたＱＮＥ（プロキシ）１２３を送信元アドレスとするフィルタ情報（図２のfilterB）を削除するために、送信者主導のＲＥＳＥＲＶＥメッセージ（図５ではRESERVE(remove)と記載）をＣＮ１２１に送信する（ステップＳ２４９、Ｓ２５１、Ｓ２５３、Ｓ２５５、Ｓ２５７）。なお、必ずしもＲＥＳＥＲＶＥメッセージによるフィルタ情報の削除を行う必要はなく、このフィルタ情報は、タイマのタイムアウトによって削除されてもよい。
【０１０５】
以上、説明したように、本発明の第１の実施の形態によれば、ＱＮＥ（プロキシ）１２３が、ＭＮ１０１のサブネット１０７において割り当てられるＮＣｏＡを用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路（ＭＮ１０１からＣＮ１２１までの経路）の一部（ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路）に係るリソース予約を行い、ＭＮ１０１からＣＮ１２１までの完全な経路が確立されるまでは、ＱＮＥ（プロキシ）１２３が確立した経路及びＱｏＳステートによってデータパケットが行われることで、ＭＮ１０１がサブネット１０３からサブネット１０７に接続を変更した場合において、ＭＮ１０１からＣＮ１２１に送られるデータパケットのＱｏＳ保証の中断時間を低減することが可能となる。
【０１０６】
＜第２の実施の形態＞
次に、本発明の第２の実施の形態について説明する。まず、図６〜８を参照しながら、本発明の第１の実施の形態に係る概要について説明する。図６は、本発明の第２の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ経路の状態を模式的に示す図である。また、図７は、本発明の第２の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路を確立した状態を模式的に示す図である。また、図８は、本発明の第２の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図である。
【０１０７】
図６〜８には、図１〜３と同様に、無線通信によりＡＲに接続してＣＮ１２１との通信を行うＭＮ１０１と、ＭＮ１０１の通信相手となるＣＮ１２１と、サブネット１０３を形成するＡＲ１０５と、サブネット１０７を形成するＡＲ１０９と、ＭＮ１０１とＣＮ１２１との間における経路上に存在し、ＭＮ１０１とＣＮ１２１との間で伝送されるパケットに関してＱｏＳ保証を行うＱｏＳ認識機能（QoS-aware）を有するＱＮＥ１１１、１１３、１１５、１１７、１１９、１２３、１２５とが図示されている。
【０１０８】
なお、ＭＮ１０１がサブネット１０３に存在している場合（すなわち、ＭＮ１０１がＡＲ１０５に接続している場合）、ＣＮ１２１からＭＮ１０１へのdownlink方向の経路１３７上には、ＱＮＥ１１９、ＱＮＥ１１７、ＱＮＥ１１５、ＱＮＥ１１３、ＱＮＥ１１１、ＡＲ１０５が存在しており、ＭＮ１０１がサブネット１０７に存在している場合（すなわち、ＭＮ１０１がＡＲ１０９に接続している場合）、ＣＮ１２１からＭＮ１０１へのdownlink方向の経路１３９上には、ＱＮＥ１１９、ＱＮＥ１１７、ＱＮＥ１１５、ＱＮＥ１２５、ＱＮＥ１２３、ＡＲ１０９が存在しているものとする。なお、経路１３７と経路１３９とは一部が重複しており、経路１３７と経路１３９とのＣＲＮをＱＮＥ１１５とする。
【０１０９】
図６において、ＣＮ１２１からＭＮ１０１に送信されるデータパケットは、経路１３７を経由して伝送される。このとき、経路１３７上のすべてのＱＮＥ１１１、１１３、１１５、１１７、１１９は、ＣＮ１２１からＭＮ１０１に送信されるデータパケットに関するＱｏＳステートを有している。すなわち、各ＱＮＥ１１１、１１３、１１５、１１７、１１９は、経路１３７のフィルタ情報（ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれているとともに、ＭＮ１０１がサブネット１０３から割り当てられているＩＰアドレス（ｃＣｏＡ）があて先アドレスとして含まれているフィルタ情報）であるfilterDと、このfilterDに対応するリソース予約情報であるresourceDとが関連付けられているＱｏＳステートを保持しており、ＣＮ１２１からＭＮ１０１に送信されるデータパケットのヘッダ（特に、送信元アドレス及びあて先アドレス）を参照してフィルタ情報（filterD）を特定し、対応するリソース予約情報（resourceD）に基づくＱｏＳ保証を行うように構成されている。
【０１１０】
ＭＮ１０１は、サブネット１０７に移動する可能性があり、プロキシ１２３に対して予測経路（経路１３９）、又は予測経路の一部の確立を所望している。なお、ＭＮ１０１がサブネット１０７に移動する前に、プロキシ１２３によって予測経路、又は予測経路の一部が確立されることで、ＭＮ１０１が実際にサブネット１０７に移動した後に、より迅速にＣＮ１２１からＭＮ１０１へのＱｏＳ経路が確立され、ハンドオーバによるＱｏＳ保証の中断時間を短縮することが可能となる。
【０１１１】
ＱＮＥ（プロキシ）１２３が予測経路を確立するための何らかのトリガを受けた場合には、ＱＮＥ（プロキシ）１２３とＣＲＮ（ここではＱＮＥ１１５）との間でＱｏＳ経路が確立される。この新たな経路が確立された場合には、ＱＮＥ（プロキシ）１２３や、ＱＮＥ（プロキシ）１２３とＱＮＥ１１５との間の各中間ＱＮＥ（例えば、ＱＮＥ１２５）は、新たなＱｏＳステートを有することになる。すなわち、図７に図示されているように、ＱＮＥ（プロキシ）１２３やＱＮＥ１２５では、ＣＮのＩＰアドレスが送信元アドレスとして含まれているとともに、ＱＮＥ（プロキシ）１２３のＩＰアドレスがあて先アドレスとして含まれているフィルタ情報（filterE）に対して、filterDと同一のリソース予約情報であるresourceDが設定される。
【０１１２】
一方、ＱＮＥ１１５とＣＮ１２１との間の経路上のＱＮＥに関しては、新たなフィルタ情報（上記のfilterE）が現在のフィルタ情報（filterD）に追加される。これにより、図７に図示されているように、ＱＮＥ１１５や、ＱＮＥ１１５とＣＮ１２１との間の各中間ＱＮＥ（例えば、ＱＮＥ１１７、１１９）は、filterD及びfilterEに対してresourceDが設定されたＱｏＳステートを有することになり、filterEによって定義されるデータトラフィックには、filterDによって定義されるデータトラフィックのために予約されたresourceDが使用可能となる。
【０１１３】
以上のように、ＭＮ１０１がサブネット１０７への移動を行う前に（あるいは、ＭＮ１０１のサブネット１０７への移動とは無関係に）、ＱＮＥ（プロキシ）１２３は、ＭＮ１０１のＮＣｏＡ（ＭＮ１０１がサブネット１０７に移動した後に割り当てられる新たなＣｏＡ）を用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路の一部（ＣＮ１２１からＱＮＥ（プロキシ）１２３までの経路）に係るリソース予約を行うことが可能となる（図７に図示されている状態）。
【０１１４】
そして、ＭＮ１０１がＮＣｏＡを取得した場合（実際にサブネット１０７に移動してＮＣｏＡを取得するか、あるいはサブネット１０３に接続した状態でＮＣｏＡを取得した場合）には、図８に図示されているように、経路１３９上の各中間ＱＮＥ（ＱＮＥ１２３、１２５、１１５、１１７、１１９）において、ＭＮ１０１のＮＣｏＡが送信元アドレスとして含まれているとともに、ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれている新たなフィルタ情報（filterF）がfilterD又はfilterEに追加されることによって、ＱｏＳ経路の更新が行われる。なお、ＭＮ１０１がサブネット１０７に移動した場合には、filterDに関しては、能動的又は受動的に削除されることが望ましい。また、フローＩＤとは異なる情報としてフィルタ情報が存在する場合には、フローＩＤは、データパケットの送信元アドレス／あて先アドレスに依存するものでなくてもよい。
【０１１５】
例えば、ＭＮ１０１がサブネット１０７に移動してＮＣｏＡを取得した後に、ＮＣｏＡに関するＱｏＳ経路の更新が完了（filterFに関するリソース予約が完了）する前までは、ＣＮ１２１からＭＮ１０１あてに送信されるデータパケットは、filterEの情報を含むアウタヘッダ（送信元アドレスをＣＮ１２１のＩＰアドレスとし、あて先アドレスをＱＮＥ（プロキシ）１２３のＩＰアドレスとするヘッダ）が付加されて、カプセル化される。このカプセル化されたデータパケットはfilterEによって識別され、各中間ＱＮＥにおいて、resourceDに基づくＱｏＳ保証が行われて伝送され、ＱＮＥ（プロキシ）１２３によって脱カプセル化される。なお、ＣＮ１２１がＱＮＥの場合には、ＣＮ１２１からＭＮ１０１あてに送信されるデータパケットのカプセル化はＣＮ１２１で行われることが望ましいが、その他のＱＮＥ（例えば、経路上において、ＣＮ１２１の最も近くに存在するＱＮＥ１１９）でカプセル化が行われてもよい。
【０１１６】
ＱＮＥ（プロキシ）１２３は、filterEで特定されるヘッダを持つパケットが到達した際には、脱カプセル化を行ってインナパケットを取り出し、そのインナパケットをＭＮ１０１に転送する。なお、経路全体にわたってＱｏＳ予約が行われるようにするための方法としては、例えばＩＰｖ４最小カプセル化など、上述のパケットのカプセル化方法以外にも存在することは、当業者にとって明白であり、任意のパケットのカプセル化方法を本発明に適用することが可能である。また、本発明は、他の種類のカプセル化やトンネリング機構においても良好に動作する。
【０１１７】
このように、ＭＮ１０１のＮＣｏＡが設定されているfilterFに関するリソース予約が完了するまでは、データパケットのカプセル化が行われ、ＱＮＥ（プロキシ）１２３のＩＰアドレスがあて先アドレスとして設定されているfilterEによって、カプセル化されたデータパケットのＱｏＳ保証が行われるように構成されており、ＭＮ１０１のＮＣｏＡを用いてリソース予約が行われるまでのＱｏＳ保証の中断時間を低減することが可能となる。
【０１１８】
また、filterFのＱｏＳの更新に成功した後（すなわち、filterFが経路１３９上のすべてのＱＮＥに導入された後）は、ＣＮ１２１は、filterEのデータパケットの生成（filterDのデータパケットのカプセル化）を終了する。そして、filterDやfilterEは能動的又は受動的に削除され、最終的にfilterFに関するＱｏＳステートのみが残り、ＣＮ１２１からサブネット１０７に接続しているＭＮ１０１への経路１３９において、ＣＮ１２１からＭＮ１０１へのデータパケットに対するＱｏＳ保証が行われる。
【０１１９】
次に、本発明の第２の実施の形態における動作について説明する。図９は、本発明の第２の実施の形態における動作例を示すシーケンスチャートである。なお、ここでは具体例として、上述の本発明の第１の実施の形態と同様に、ＮＳＩＳのＱｏＳ ＮＳＬＰで定義されているメッセージであるＲＥＳＥＲＶＥメッセージに、さらに本発明の動作に必要な情報を付加した場合について説明する。また、本発明の第２の実施の形態におけるＱＮＥの構成は、上述の本発明の第１の実施の形態におけるＱＮＥの構成（図４参照）と同一であり、ここでは説明を省略する。
【０１２０】
図９において、ＱＮＥ（プロキシ）１２３は、ＣＮ１２１から、サブネット１０３に接続しているＭＮ１０１のデータ経路情報（例えば、リソース稼働率など）を取得するとともに、downlink方向のＣＲＮ（ここでは、ＱＮＥ１１５）をあらかじめ特定する（ステップＳ３０１）。なお、例えば、ＱＮＥ（プロキシ）１２３は、上述の非特許文献９、１０などに記載されている方法を使用することによって、これらの情報を取得することが可能である。
【０１２１】
そして、ＱＮＥ（プロキシ）１２３は、上述の本発明の第１の実施の形態と同様に、予測経路を確立するための何らかのトリガを受け取る（ステップＳ３０３）。なお、このトリガには、上述の本発明の第１の実施の形態と同様に、例えば、ＭＮ１０１とＣＮ１２１との間のＱｏＳ経路で用いられているセッションＩＤ、QSpec情報、ＣＮ１２１（又は経路の最終ＱＮＥであるＱＮＲ）のＩＰアドレス など、予測経路を確立するために必要な情報が含まれている。
【０１２２】
トリガを受け取ったＱＮＥ（プロキシ）１２３は、このトリガに応じて、即座に「プロキシフラグ」が付加された受信者始動ＲＥＳＥＲＶＥメッセージをＣＮ１２１に向かって送信する（ステップＳ３０５）。なお、この予約におけるフィルタ情報には、送信元アドレスとしてＣＮ１２１のＩＰアドレス、あて先アドレスとしてＱＮＥ（プロキシ）１２３のＩＰアドレスが含まれている（図７のfilterE）。また、ＱＮＥ（プロキシ）１２３は、このフィルタ情報に対応したフィルタ／リソース（図７のfilterE/resourceD）の組を生成して新たな予約を行う。また、ステップＳ３０７でＱＮＥ１２３からＲＥＳＥＲＶＥメッセージを受けたＱＮＥ１２５も同様に、このフィルタ情報に対応したフィルタ／リソース（図７のfilterE/resourceD）の組を生成して新たな予約を行う。
【０１２３】
一方、ＱＮＥ１１７、ＱＮＥ１１９、ＣＮ１２１（ＣＮ１２１がＱＮＥの場合）では、ＲＥＳＥＲＶＥメッセージ（図９では、RESERVE(add)と記載）の伝送が行われる（ステップＳ３０９、Ｓ３１１、Ｓ３１３）とともに、このＲＥＳＥＲＶＥメッセージに含まれているフィルタ情報（図７のfilterE）が、ＣＮ１２１からＭＮ１０１へのデータパケットに現在使用されている現在のフィルタ／リソース（図６のfilterD/resourceD）の組に追加される。以上の動作により、各ＱＮＥには、図７に図示されているリソース予約情報が設定される。
【０１２４】
なお、このＱＮＥ（プロキシ）１２３から送信されるＲＥＳＥＲＶＥメッセージには、ＣＲＮ（ＱＮＥ１１５）以降の経路において上記のようなフィルタ情報の追加処理を行う旨を示す情報が含まれており、ＱＮＥ１１５が、この情報を参照して上流のＱＮＥ（ＱＮＥ１１７）に対して追加処理を指示するＲＥＳＥＲＶＥメッセージを送信してもよい。また、ＱＮＥ１１５は、ＲＥＳＥＲＶＥメッセージを受信した下流のＱＮＥ（ＱＮＥ１２５）が、同一セッションに属する経路１３７とは異なる方向に存在していることから、自らがＣＲＮであることを把握してもよい。また、各ＱＮＥは、リソース予約情報に、受信したＲＥＳＥＲＶＥメッセージのフィルタ情報が属するセッションと同一セッションの他の経路（他のフィルタ情報）を保持している場合には、元々保持しているフィルタ情報に、ＲＥＳＥＲＶＥメッセージのフィルタ情報を追加するように構成されていてもよい。
【０１２５】
ここで、ＭＮ１０１がサブネット１０７に移動したとする（ステップＳ３１５）。ＱＮＥ（プロキシ）１２３はＭＮ１０１の移動を検出し、ＭＮ１０１のＮＣｏＡを取得した場合（ステップＳ３２１）には、送信者主導のＲＥＳＥＲＶＥメッセージをＭＮ１０１に送信する（ステップＳ３２３）。このＲＥＳＥＲＶＥメッセージに関するフィルタ情報には、送信元アドレスとしてＣＮ１２１のアドレスが含まれており、あて先アドレスとしてＭＮ１０１のＮＣｏＡが含まれている。
【０１２６】
一方、ＣＮ１２１も、例えばＭＮ１０１からのＢＵによって、ＭＮ１０１の移動を検出して、ＭＮ１０１のＮＣｏＡを取得する（ステップＳ３１７）。そして、ＣＮ１２１は、ＭＮ１０１へのデータパケットのカプセル化を開始する（ステップＳ３１９）。このカプセル化では、ＣＮ１２１は、ＭＮ１０１のＮＣｏＡをあて先アドレスとするパケットに、あて先アドレスがＱＮＥ（プロキシ）１２３のアドレスに設定されたアウタヘッダを付加したパケットを生成して送信する。カプセル化されたデータパケットは、そのあて先アドレスがＱＮＥ（プロキシ）１２３であり、経路１２９上の各ＱＮＥでは、filterEのフィルタ情報に係るＱｏＳ処理が行われ、その結果、ＱｏＳ保証を受けることになる。
【０１２７】
ステップＳ３２３でＲＥＳＥＲＶＥメッセージを送信した後、ＱＮＥ（プロキシ）１２３は、受信者始動ＲＥＳＥＲＶＥメッセージ（図９では、RESERVE(add)と記載）をＣＮ１２１に送信する（ステップＳ３２５）。この予約におけるフィルタ情報には、あて先アドレスとしてＭＮ１０１のＩＰアドレスが含まれている。そして、各ＱＮＥ（ＱＮＥ１２５、１１５、１１７、１１９）を経由してＲＥＳＥＲＶＥメッセージは伝送されるとともに（ステップＳ３２７、Ｓ３２９、Ｓ３３１、Ｓ３３３）、各ＱＮＥにおいて、このＲＥＳＥＲＶＥメッセージに含まれるフィルタ情報（図８のfilterF）が、以前に付加又は生成されたフィルタ情報（図７のfilterE）に付加される。以上の動作により、各ＱＮＥには、図８に図示されているリソース予約情報が設定される。そして、ＣＮ１２１は、このＲＥＳＥＲＶＥメッセージを受信した場合に、データパケットのカプセル化を終了する（ステップＳ３３５）。
【０１２８】
そして、ＣＮ１２１は、ステップＳ３０５〜Ｓ３１３で導入されたＱＮＥ（プロキシ）１２３をあて先アドレスとするフィルタ情報（図７のfilterE）を削除するために、送信者主導のＲＥＳＥＲＶＥメッセージ（図９ではRESERVE(remove)と記載）をＱＮＥ（プロキシ）１２３に送信する（ステップＳ３３７、Ｓ３３９、Ｓ３４１、Ｓ３４３、Ｓ３４５）。なお、必ずしもＲＥＳＥＲＶＥメッセージによるフィルタ情報の削除を行う必要はなく、このフィルタ情報は、タイマのタイムアウトによって削除されてもよい。
【０１２９】
以上、説明したように、本発明の第２の実施の形態によれば、ＱＮＥ（プロキシ）１２３が、ＭＮ１０１のサブネット１０７において割り当てられるＮＣｏＡを用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路（ＣＮ１２１からＭＮ１０１までの経路）の一部（ＣＮ１２１からＱＮＥ（プロキシ）１２３までの経路）に係るリソース予約を行い、ＣＮ１２１からＭＮ１０１までの完全な経路が確立されるまでは、ＱＮＥ（プロキシ）１２３が確立した経路及びＱｏＳステートによってデータパケットが行われることで、ＭＮ１０１がサブネット１０３からサブネット１０７に接続を変更した場合において、ＣＮ１２１からＭＮ１０１に送られるデータパケットのＱｏＳ保証の中断時間を低減することが可能となる。
【０１３０】
＜第３の実施の形態＞
次に、本発明の第３の実施の形態について説明する。上述の説明ではフィルタ情報（filter）及びフローＩＤに明確な違いがなされていないが、以下、それぞれを明確に定義した場合の各ＱＮＥの機能や、シグナリングメッセージの処理などについて説明する。
【０１３１】
まず、本発明の第３の実施の形態におけるフィルタ情報について説明する。本発明の第３の実施の形態では、フィルタ情報を、各ＱＮＥがパケットクラシファイア（packet classifier）として使用する情報として定義する。フィルタ情報は、ＲＳＶＰにおけるフィルタスペック（filter spec）と同様に、ＱｏＳ予約を行うためのシグナリングメッセージのパラメータとして各ＱＮＥに運ばれる。すなわち、ＮＳＩＳでは、フィルタ情報は、主にＮＳＬＰにて生成され、管理される情報となる。各ＱＮＥは、このフィルタ情報を、要求されているＱｏＳリソースの情報と共に格納することにより、どのデータパケットに対して予約されたＱｏＳリソースを与えるかの区別を行う。そのため、フィルタ情報には、予約されたＱｏＳの保証を受けるデータパケットのヘッダ情報が含まれる。すなわち、フィルタ情報に含まれる情報の例としては、ＲＳＶＰにおけるフィルタスペックと同様に、送信元・あて先ＩＰアドレスや、プロトコル識別子、ポート番号、フローラベル（ＩＰｖ６の場合）、ＳＰＩ（Security Parameters Index）（ＩＰＳｅｃでカプセル化されている場合）、ＤＳＣＰ／ＴＯＳ（Differentiated Services Code Point/Type of Service）フィールドなどである。
【０１３２】
また、フィルタ情報は、１つのＱｏＳ予約に対してフィルタリスト（filter-list）の形を取ってもよい。この場合、１つのＱｏＳ予約に対して、ＱＮＥは、フィルタリスト内のどのフィルタ情報と同じ内容のヘッダを持つデータパケットを受けた場合でも、予約されているリソースを与えることが可能となる。
【０１３３】
フィルタリストは、このリストがどのフローやセッションに属するものかを表す識別子（例えば、フローＩＤや、セッションＩＤなど）と共に管理されてもよい。また、同一セッションに属するデータパケットが異なる性質を持つ複数の経路（例えば、モバイルＩＰにおける三角経路と最適化経路や、マルチホーム端末を使った通信における複数の経路など）を用いて送受信される場合には、フローＩＤやセッションＩＤのほかに、これらの複数の経路の種別を識別する識別子（例えば、Path Type ID（非特許文献１２参照）など）と共に管理されてもよい。
【０１３４】
以下に、フィルタリストの管理方法の一例について説明する。ＱｏＳ予約を行うためのシグナリングメッセージ（例えば、ＮＳＩＳのＲＥＳＥＲＶＥメッセージなど）により運ばれるフィルタリストの与え方の例として、
Filter-List ::= <List Length> <Action> <Filter> <Filter> ・・・;
などが考えられる。ここで、フィルタリストは、<List Length>、<Action>、及び複数のフィルタ情報（<Filter>）を有している。なお、<List Length>では、フィルタリストに含まれるフィルタ情報の個数（すなわち、<Filter>の個数）が示される。また、<Action>では、各ＱＮＥでこのフィルタリストをどのように扱うかを指定する情報が示される。例えば、<Action>に含まれる情報としては、「追加（add）」、「削除（sub）」、「置き換え（Replace）」などが考えられる。例えば、<Action>が「追加（Add）」の場合には、そのＱＮＥ上に同一セッションＩＤ及びPath Type ID（存在する場合）に対応する既存のフィルタリストが存在する場合には、そのリストに後続のフィルタ情報<Filter>が追加され、存在しない場合には、新たにフィルタリストが作られ、それに対応するリソースが予約される。また、例えば、<Action>が「削除（sub）」の場合には、同一セッションＩＤ及びPath Type ID（存在する場合）に対応する既存のフィルタリストから、後続のフィルタ情報<Filter>だけが削除される。また、例えば、<Action>が「置き換え（Replace）」の場合には、ＱＮＥ上の同一セッションＩＤ及びPath Type ID（存在する場合）に対応する既存のフィルタリストそのものが置き換えられる。
【０１３５】
また、例えば、
Filter-List ::= <List Length> <Action> <Filter> <Filter> ・・・ <List Length> <Action> <Filter> <Filter> ・・・;
という形式を取ることにより、１つのフィルタリストによって、フィルタ情報に係る複数の変更動作を一度に行えるようにすることも可能である。例えば、あるＱＮＥが、セッションＩＤ“300”、Path Type ID“0x00”に対し、３つのフィルタ情報（<filter1>、<filter2>、<filter3>）を含むフィルタリスト
Filter-list := <filter1> <filter2> <filter3>;
を格納していた場合、同一セッションＩＤ及びPath Type IDを持つＲＥＳＥＲＶＥメッセージを受信し、その中に含まれるフィルタ情報が
Filter-List ::= <2> <add> <filter4> <filter5> <1> <sub> <filter1>;
であった場合には、このＱＮＥに格納されるフィルタリストは、
Filter-list := <filter2> <filter3> <filter4> <filter5>;
に更新される。なお、上記のフィルタリストの形式は一例であり、ＱｏＳ予約を行うためのシグナリングメッセージにおいて、フィルタ情報及びそのフィルタ情報に対して行う処理（action）の情報が明確にできるのであれば、他の形式を取ることや、他の情報を持つことも可能である。
【０１３６】
次に、本発明の第３の実施の形態におけるフローＩＤについて説明する。本発明の第３の実施の形態では、フローＩＤは、主にＮＳＩＳの下位層であるＮＴＬＰで管理され、ＮＴＬＰにおいて、シグナリングメッセージがどのフローに属するかを識別するために使われる。フローＩＤとセッションＩＤとの違いは、セッションＩＤはセッションの開始から終了まで変化しないＩＤであるのに対し、フローＩＤは、例えば端末の移動などによる経路変更により、変化してもよいという点にある。また、１つのセッションに対し、複数のフローＩＤが存在してもよい。なお、本発明の第３の実施の形態におけるフローＩＤは、非特許文献１１Ａでは、ＭＲＩ(Message Routing Information)として位置付けられているものであるが、含まれる情報はこの通りではない。本発明の第３の実施の形態におけるフローＩＤの一例としては、シグナリングメッセージの送信元とあて先のＩＰアドレスを含む情報が考えられる。なお、この場合、本発明の第３の実施の形態におけるフローＩＤには、非特許文献１１Ａで記されているフローＩＤのように必ずしもプロトコル識別子、ポート番号などのフィルタ情報が持つ情報が含まれる必要はない。また、データの送信元・あて先と、シグナリングメッセージの送信元・あて先が異なる場合や、送信元・あて先が同じであっても、ポート番号など他のフィルタ情報が異なる場合で、シグナリングメッセージもデータパケットと同様にＱｏＳ保証を必要とする場合は、シグナリングメッセージのフィルタ情報を、フィルタリストに追加すればよい。
【０１３７】
また、図１７は、本発明の第３の実施の形態において、ＱＮＥ内でフィルタ情報及びフローＩＤを管理する主体を模式的に示す図である。上述のように、ＮＳＩＳプロトコル層では、フィルタ情報及びフローＩＤの２つの情報が管理されるが、フィルタ情報（フィルタリスト）は、主にＮＳＩＳの上位層であるＮＳＬＰ層において管理され、フローＩＤは、主にＮＳＩＳの下位層であるＮＴＬＰ層において管理される。なお、フィルタ情報やフローＩＤの管理や生成に関しては、必ずしも、図１７に示されているようにＮＳＬＰ層やＮＴＬＰ層が単独で行う必要はなく、ＮＳＬＰ層とＮＴＬＰ層の間で情報の交換を行ったり、他の層と情報を交換したりすることにより管理・生成が行われてもよい。
【０１３８】
このように、ＮＳＩＳプロトコル層において管理される情報を、フィルタ情報及びフローＩＤに明確に分けて定義を行うことにより、各ＱＮＥはデータパケットの送受信を行う端末の情報（例えば、データの送信元・あて先に設定されるＩＰアドレス）を必要とすることなく、シグナリングメッセージを送信することが可能になる。この特性を用いたＱｏＳ経路の早期確立方法を以下に説明する。
【０１３９】
なお、ここでは、データパケットの送信される方向がuplink方向であった場合を例に挙げて説明を行うが、データパケットの送信される方向がdownlink方向であった場合にも同様の手順を用いることができる。
【０１４０】
まず、図１２〜１４を参照しながら、本発明の第３の実施の形態に係る概要について説明する。図１２は、本発明の第３の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ予約の状態及びルーティングのためのステート内に含まれるフローＩＤの状態を模式的に示す図である。また、図１３は、本発明の第３の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路上にルーティングのためのステートを確立した状態を、この中に含まれるフローＩＤを示すことにより模式的に示す図である。また、図１４は、本発明の第３の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図である。
【０１４１】
図１２〜１４には、図１〜３と同様に、無線通信によりＡＲに接続してＣＮ１２１との通信を行うＭＮ１０１と、ＭＮ１０１の通信相手となるＣＮ１２１と、サブネット１０３を形成するＡＲ１０５と、サブネット１０７を形成するＡＲ１０９と、ＭＮ１０１とＣＮ１２１との間における経路上に存在し、ＭＮ１０１とＣＮ１２１との間で伝送されるパケットに関してＱｏＳ保証を行うＱｏＳ認識機能（QoS-aware）を有するＱＮＥ１１１、１１３、１１５、１１７、１１９、１２３、１２５とが図示されている。
【０１４２】
なお、ＭＮ１０１がサブネット１０３に存在している場合（すなわち、ＭＮ１０１がＡＲ１０５に接続している場合）、ＭＮ１０１からＣＮ１２１へのuplink方向の経路１４７上には、ＡＲ１０５、ＱＮＥ１１１、ＱＮＥ１１３、ＱＮＥ１１５、ＱＮＥ１１７、ＱＮＥ１１９が存在しており、ＭＮ１０１がサブネット１０７に存在している場合（すなわち、ＭＮ１０１がＡＲ１０９に接続している場合）、ＭＮ１０１からＣＮ１２１へのuplink方向の経路１４９上には、ＡＲ１０９、ＱＮＥ１２３、ＱＮＥ１２５、ＱＮＥ１１５、ＱＮＥ１１７、ＱＮＥ１１９が存在しているものとする。なお、経路１４７と経路１４９とは一部が重複しており、経路１４７と経路１４９とのＣＲＮをＱＮＥ１１５とする。
【０１４３】
図１２において、ＭＮ１０１からＣＮ１２１に送信されるデータパケットは、経路１４７を経由して伝送される。このとき、経路１４７上のすべてのＱＮＥ１１１、１１３、１１５、１１７、１１９は、ＭＮ１０１からＣＮ１２１に送信されるデータパケットに関するＱｏＳ予約に係るステートを有している。すなわち、各ＱＮＥ１１１、１１３、１１５、１１７、１１９は、経路１４７を通して送られるデータパケットに関するフィルタ情報（ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれているとともに、ＭＮ１０１がサブネット１０３から割り当てられているＩＰアドレス（ｃＣｏＡ）が送信元アドレスとして含まれているフィルタ情報）であるfilterGを含むフィルタリストと、このフィルタリストに対応するリソース予約情報であるresourceGとが関連付けられているＱｏＳ予約に係るステートを保持しており、ＣＮ１２１からＭＮ１０１に送信されるデータパケットのヘッダを参照してフィルタ情報（filterG）を特定し、対応するリソース予約情報（resourceG）に基づくＱｏＳ保証を行うように構成されている。
【０１４４】
また同時に、各ＱＮＥ１１１、１１３、１１５、１１７、１１９のＮＴＬＰ層では、シグナリングメッセージの識別とルーティングのためのステート（ルーティングステートやメッセージアソシエーション（非特許文献１１Ａ参照））を保持している。このルーティングのためのステート内には、経路１４７におけるシグナリングメッセージの送信元及びあて先を含む情報から作られるフローＩＤが含まれる。今、シグナリングメッセージの送信元をＭＮ１０１（ｃＣｏＡをＸとする）、シグナリングメッセージのあて先をＣＮ１２１（ＩＰアドレスをＹとする）であるとし、各ＱＮＥ１１１、１１３、１１５、１１７、１１９のＮＴＬＰ層がルーティングのためのステートの中に持つフローＩＤを、flowXYとする。
【０１４５】
ＭＮ１０１は、サブネット１０７に移動する可能性があり、ＱＮＥ（プロキシ）１２３に対して予測経路（経路１４９）の一部の確立の準備（すなわち、ＱＮＥ（プロキシ）１２３からＣＮ１２１の確立の準備）を所望している。すなわち、ＭＮ１０１は、この経路上の各ＱＮＥに対して、サブネット１０７に移動した後のルーティングのためのステートをあらかじめ保有しておくことを所望している。なお、ＭＮ１０１がサブネット１０７に移動する前に、ＱＮＥ（プロキシ）１２３によって予測経路の一部が準備されることで、ＭＮ１０１が実際にサブネット１０７に移動した後に、より迅速にＣＮ１２１からＭＮ１０１へのＱｏＳ経路が確立され、ハンドオーバによるＱｏＳ保証の中断時間を短縮することが可能となる。その理由は、ルーティングのためのステートの新規確立には複雑な処理が必要になるが、このルーティングのためのステートはいったん確立されてしまえば、このステートを用いてシグナリングメッセージをルーティングすることができるからである。
【０１４６】
ＱＮＥ（プロキシ）１２３が予測経路の確立を準備するための何らかのトリガを受けた場合には、ＱＮＥ（プロキシ）１２３は、ＱＮＥ（プロキシ）１２３とＣＮ１２１との間のＱＮＥにおけるルーティングのためのステートの新規確立処理を始動し、その結果、ＱＮＥ（プロキシ）１２３とＣＮ１２１との間のＱＮＥにルーティングのためのステートが保有される。すなわち、図１３に図示されているように、ＱＮＥ（プロキシ）１２３、ＱＮＥ１２５、１１５、１１７、１１９のＮＴＬＰ層では、ＱＮＥ（プロキシ）１２３のＩＰアドレス（Ｚとする）が送信元アドレスとして含まれているとともに、ＣＮ１２１のＩＰアドレス（すなわちＹ）があて先アドレスとして含まれているフローＩＤ（flowZY）を含むルーティングのためのステートが設定される。なお、経路１４７に関するルーティングのためのステートはそのまま残される。
【０１４７】
以上のように、ＭＮ１０１がサブネット１０７への移動を行う前に（あるいは、ＭＮ１０１のサブネット１０７への移動とは無関係に）、ＱＮＥ（プロキシ）１２３は、ＭＮ１０１のＮＣｏＡ（ＭＮ１０１がサブネット１０７に移動した後に割り当てられる新たなＣｏＡ）を用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路の一部（ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路）に係るルーティングのためのステートを確立することが可能である（図１３に図示されている状態）。
【０１４８】
そして、ＭＮ１０１がＮＣｏＡを取得した場合（実際にサブネット１０７に移動してＮＣｏＡを取得するか、あるいはサブネット１０３に接続した状態でＮＣｏＡを取得した場合）には、このＭＮ１０１のＮＣｏＡをデータパケットの送信元、ＣＮ１２１のＩＰアドレスをデータパケットのあて先としたフィルタ情報 （filterH）が作成される。そして、図１４に図示されているように、経路１４９上のＱＮＥ（プロキシ）１２３、ＱＮＥ１２５においてはfilterHを含むフィルタリストが新規で格納されるとともに、ＱＮＥ１１５、１１７、１１９においては、filterHが既存の（同一セッション用の）フィルタリストに追加される。
【０１４９】
また、ＭＮ１０１がサブネット１０７に移動した場合には、ＭＮ１０１からＱＮＥ（プロキシ）１２３の間のルーティングのためのステートを確立することにより、ＭＮ１０１からＣＮ１２１までのエンド・ツー・エンドのルーティングのためのステートが確立される。ＭＮ１０１からＱＮＥ（プロキシ）１２３の間のルーティングのためのステートで使われるフローＩＤは、ＱＮＥ（プロキシ）１２３からＣＮ１２１で使われているもの（flowZY）とは異なり、ＭＮ１０１がサブネット１０７で取得したＮＣｏＡ（Ｗとする）をシグナリングメッセージの送信元、ＱＮＥ（プロキシ）１２３のＩＰアドレス（すなわちＺ）をシグナリングメッセージのあて先としたフローＩＤ（flowWZ）であってよい。また、エンド・ツー・エンドのフローＩＤを統一するため、ＭＮ１０１からＱＮＥ（プロキシ）１２３の間のルーティングのためのステートで使われるフローＩＤは、ＱＮＥ（プロキシ）１２３からＣＮ１２１で使われているもの（flowZY）であってもよい。
【０１５０】
なお、ＭＮ１０１からＱＮＥ（プロキシ）１２３の間のフローＩＤが、ＱＮＥ（プロキシ１２３）からＣＮ１２１で使われているものと異なる場合、ＱＮＥ（プロキシ）１２３において、サブネット１０７上のＭＮ１０１から送信されるシグナリングメッセージに付加されているフローＩＤ（flowWZ）をflowZYに付け替えて、ＣＮ１２１に向けて送信するなどの動作が必要である。また、上述のように、経路１４９上に既にシグナリングメッセージのルーティングのためのステートが存在するため、ＱｏＳリソース予約のための動作は、ＱＮＥ（プロキシ）１２３より先では、経路１４９上に新規でＱｏＳ予約のためのシグナリングメッセージを送る場合に比べて迅速に行われ、その結果、ＭＮ１０１のＮＣｏＡを用いてＱｏＳリソース予約が行われるまでのＱｏＳ保証の中断時間を低減することが可能となる。また、ＭＮ１０１がサブネット１０７に移動した後に、移動前に使用されていたフィルタ情報（filterG）や、経路１４７のルーティングのためのステートに関しては、能動的又は受動的に削除されることが望ましい。
【０１５１】
次に、本発明の第３の実施の形態における第１動作例について説明する。図１５は、本発明の第３の実施の形態において、データパケットの送信方向がuplink方向の場合の動作例を示すシーケンスチャートである。なお、ここでは具体例として、各ＱＮＥにおいてルーティングのためのステートを作るために送信される、フィルタ情報を必要としないメッセージとして、ＮＳＩＳのＱｏＳ ＮＳＬＰで定義されているメッセージであるＱＵＥＲＹメッセージに、さらに本発明の動作に必要な情報を付加した場合について説明する。また、ＱｏＳリソースを予約するためのメッセージとして、ＮＳＩＳのＱｏＳ ＮＳＬＰで定義されているメッセージであるＲＥＳＥＲＶＥメッセージに、さらに本発明の動作に必要な情報を付加した場合について説明する。なお、本発明の第３の実施の形態で使用される「ＲＥＳＥＲＶＥメッセージ」や「ＱＵＥＲＹメッセージ」、「ＲＥＳＰＯＮＳＥメッセージ」という用語は、ＮＳＬＰ層で生成される情報（メッセージのペイロード部と呼ぶ）、ＮＴＬＰ層で生成される情報（ヘッダ部と呼ぶ）及びＩＰヘッダ（オプション部分を含む）を含んでいる。
【０１５２】
図１５において、まず、ＱＮＥ（プロキシ）１２３は、予測経路を準備するためのトリガを受ける（ステップＳ４０１）。なお、このトリガには、例えば、ＭＮ１０１とＣＮ１２１との間のＱｏＳ経路で用いられているセッションＩＤ、ＣＮ１２１（又は経路の最終ＱＮＥであるＱＮＲ）のＩＰアドレスなど、予測経路を確立するために必要な情報が含まれている。
【０１５３】
トリガを受け取ったＱＮＥ（プロキシ）１２３は、このトリガに応じて、即座に、ＮＳＬＰ層においてＱＵＥＲＹメッセージのペイロード部を生成し、ＮＴＬＰ層に受け渡す。ＮＴＬＰ層ではこれを受けて、自身をシグナリングメッセージの送信元、ＣＮ１２１をあて先としたフローＩＤを生成し（ステップＳ４０３）、このフローＩＤをヘッダ部に含むＱＵＥＲＹメッセージを、下位層を経由してＣＮ１２１に向けて送信する（ステップＳ４０５）。なお、このＱＵＥＲＹメッセージは、経路１４９における新規のdownstream方向（データ送信方向と同じ方向）へのメッセージであるので、このＱＵＥＲＹメッセージのＩＰヘッダにはＱＮＥ用のＲＡＯが付けられる。
【０１５４】
ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路上のすべてのＱＮＥ（ＱＮＥ１２５、１１５、１１７、１１９）は、ＱＵＥＲＹメッセージを受信してＩＰヘッダにＲＡＯを発見すると、ＮＳＩＳ層（ＮＳＬＰ層及びＮＴＬＰ層）においてＱＵＥＲＹメッセージの中身を確認して、必要な処理を行う。すなわち、ＱＵＥＲＹメッセージを受信したＱＮＥ１２５、１１５、１１７、１１９は、ＱｏＳ ＮＳＬＰ層におけるＱＵＥＲＹ処理以外に、ＮＴＬＰ層においてルーティングのためのステートの確立処理（ルーティングステートや、メッセージアソシエーション（要求されている場合）の確立のための処理）を行う（ステップＳ４０７、Ｓ４１１、Ｓ４１５、Ｓ４１９、Ｓ４２３）。その後、各ＱＮＥはＱＵＥＲＹメッセージをＣＮ１２１に向けて送信する（ステップＳ４０９、Ｓ４１３、Ｓ４１７、Ｓ４２１）。そして、ＱＵＥＲＹメッセージがＣＮ１２１に到達すると、このＱＵＥＲＹメッセージに対するＲＥＳＰＯＮＳＥメッセージがＣＮ１２１からＱＮＥ１２３に返される（ステップＳ４２５、Ｓ４２７、Ｓ４２９、Ｓ４３１、Ｓ４３３）。
【０１５５】
ここで、ＭＮ１０１がサブネット１０７に移動したとする（ステップＳ４３５）。ＭＮ１０１は、サブネット１０７よりＮＣｏＡを取得すると、ＮＴＬＰ層において、このＮＣｏＡをシグナリングメッセージの送信元、ＱＮＥ（プロキシ）１２３をシグナリングメッセージのあて先としたフローＩＤを生成する（ステップＳ４３７）。また、ＭＮ１０１のＮＳＬＰ層では、自身のＮＣｏＡをデータパケットの送信元、ＣＮ１２１のＩＰアドレスをデータパケットのあて先とした情報を含むフィルタ情報を生成し、このフィルタ情報を追加（add）してＱｏＳリソースを予約するような送信者主導のＲＥＳＥＲＶＥメッセージ（図１５ではRESERVE(add)と記載）をＱＮＥ（プロキシ）１２３に向けて送信する（ステップＳ４３９）。このＲＥＳＥＲＶＥメッセージは、経路１４９におけるＭＮ１０１からＱＮＥ（プロキシ）１２３に対する新規のdownstream方向（データ送信方向と同じ方向）へのメッセージであるので、このＲＥＳＥＲＶＥメッセージのＩＰヘッダにはＱＮＥ用のＲＡＯが付けられる。
【０１５６】
このＲＥＳＥＲＶＥメッセージを受け取ったＱＮＥ（プロキシ）１２３は、ＮＴＬＰにおいてルーティングのためのステートの確立処理を行う（ステップＳ４４１）とともに、ＮＳＬＰにおいてリソース予約のための処理を行う。また、ＮＴＬＰ層ではセッションＩＤなどの情報から、このＲＥＳＥＲＶＥメッセージをＣＮ１２１に送信する必要があることを認識し、このＲＥＳＥＲＶＥメッセージに含まれるフローＩＤの情報を、ステップＳ４０３で生成されたフローＩＤに変更し、ＣＮ１２１に向けて送信する（ステップＳ４４３）。この際、ＮＴＬＰは、メッセージをＣＮ１２１に向けて送信する必要があるということを、ＮＳＬＰに伝えてもよい。なお、この場合、ルーティングのためのステートは、ＱＮＥ１２３、１２５、１１５、１１７、１１９に既に確立されているので、ＲＥＳＥＲＶＥメッセージにＲＡＯが付加される必要はなく、ＱＮＥ１２３、１２５、１１５、１１７、１１９は、受信したＲＥＳＥＲＶＥメッセージを参照してリソース予約のための処理を行い、迅速にＲＥＳＥＲＶＥメッセージを送信することができる（ステップＳ４４５、Ｓ４４７、Ｓ４４９、Ｓ４５１）。なお、ＭＮ１０１と、ＱＮＥ（プロキシ）１２３との間で使われるフローＩＤは、ＱＮＥ（プロキシ）１２３とＣＮ１２１の間で使われるフローＩＤと同じであってもよい。
【０１５７】
次に、本発明の第３の実施の形態の第２動作例について説明する。上述の本発明の第３の実施の形態における第１動作例では、データパケットの送信方向がuplink方向の場合について説明したが、データパケットの送信方向がdownlink方向であった場合においても、同様の手順を採ることができる。これについて、図１６を参照しながら説明する。図１６は、本発明の第３の実施の形態において、データパケットの送信方向がdownlink方向の場合の動作例を示すシーケンスチャートである。
【０１５８】
ＱＮＥ（プロキシ）１２３は、予測経路を準備するためのトリガを受け取ると（ステップＳ５０１）、ＣＮ１２１に対して、予測経路準備を依頼する依頼メッセージを送信する（ステップＳ５０３）。なお、予測経路を準備するためのトリガは、ＱＮＥ（プロキシ）１２３ではなく、ＣＮ１２１に直接送られてもよい。この場合、トリガには、ＱＮＥ（プロキシ）１２３のＩＰアドレスなどの情報も含まれている必要がある。
【０１５９】
依頼メッセージ又はトリガを受信したＣＮ１２１は、この依頼メッセージ又はトリガに応じて、即座に、ＮＳＬＰ層においてＱＵＥＲＹメッセージのペイロード部を生成し、ＮＴＬＰ層に受け渡す。ＮＴＬＰ層ではこれを受けて、自身をシグナリングメッセージの送信元、ＱＮＥ（プロキシ）１２３をあて先としたフローＩＤを生成し（ステップＳ５０５）、このフローＩＤをヘッダ部に含むＱＵＥＲＹメッセージを、下位層を経由してＱＮＥ（プロキシ）１２３に向けて送信する（ステップＳ５０７）。なお、このＱＵＥＲＹメッセージは、経路１４９における新規のdownstream方向（データ送信方向と同じ方向）へのメッセージであるので、このＱＵＥＲＹメッセージのＩＰヘッダにはＱＮＥ用のＲＡＯが付けられる。
【０１６０】
ＣＮ１２１からＱＮＥ(プロキシ)１２３までの経路上のすべてのＱＮＥ（ＱＮＥ１１９、１１７、１１５、１２５）は、ＱＵＥＲＹメッセージを受信してＩＰヘッダにＲＡＯを発見すると、ＮＳＩＳ層（ＮＳＬＰ層及びＮＴＬＰ層）においてＱＵＥＲＹメッセージの中身を確認して、必要な処理を行う。すなわち、ＱＵＥＲＹメッセージを受信したＱＮＥ１１９、１１７、１１５、１２５は、ＱｏＳ ＮＳＬＰ層におけるＱＵＥＲＹ処理以外に、ＮＴＬＰ層においてルーティングステートのためのステート確立処理を行う（ステップＳ５０９、Ｓ５１３、Ｓ５１７、Ｓ５２１、Ｓ５２５）。その後、各ＱＮＥは、ＱＵＥＲＹメッセージをＱＮＥ（プロキシ）１２３に向けて送信する（ステップＳ５１１、Ｓ５１５、Ｓ５１９、Ｓ５２３）。
【０１６１】
ここで、ＭＮ１０１がサブネット１０７に移動したとする（ステップＳ５２７）。ＱＮＥ（プロキシ）１２３は、ＭＮ１０１の移動を検出し、ＭＮ１０１がサブネット１０７より取得したＮＣｏＡ情報を取得すると、ＮＴＬＰ層において自身のＩＰアドレスをシグナリングメッセージの送信元、ＭＮ１０１のＮＣｏＡをシグナリングメッセージのあて先としたフローＩＤを生成する（ステップＳ５２９）。また、ＱＮＥ（プロキシ）１２３のＮＳＬＰ層は、ＣＮ１２１のＩＰアドレスをデータパケットの送信元、ＭＮ１０１のＮＣｏＡをデータパケットのあて先とした情報を含むフィルタ情報を生成し、このフィルタ情報を追加（add）してＱｏＳリソースを予約するような送信者主導のＲＥＳＥＲＶＥメッセージ（図１６ではRESERVE(add)と記載）をＭＮ１０１に向けて送信する（ステップＳ５３１）とともに、ＮＴＬＰ層ではＭＮ１０１に転送するデータパケットに対するルーティングのためのステートの確立処理を行う（ステップＳ５３３）。
【０１６２】
また、ＱＮＥ（プロキシ）１２３は、受信者主導のＲＥＳＥＲＶＥメッセージ（図１６ではRESERVE(add)と記載）をＣＮ１２１に向けて送信する（ステップＳ５３５）。なお、ＭＮ１０１に送信されるＲＥＳＥＲＶＥメッセージは、経路１４９におけるＱＮＥ（プロキシ）１２３からＭＮ１０１に対する新規のdownstream方向（データ送信方向と同じ方向）へのメッセージであるので、このＲＥＳＥＲＶＥメッセージにはＱＮＥ用のＲＡＯが付けられる。しかしながら、ＣＮ１２１に送信されるＲＥＳＥＲＶＥメッセージに関しては、ルーティングのためのステートがＱＮＥ１２３、１２５、１１５、１１７、１１９に既に確立されているので、このＲＥＳＥＲＶＥメッセージにＲＡＯが付加される必要はなく、ＱＮＥ１２５、１１５、１１７、１１９は、受信したＲＥＳＥＲＶＥメッセージを参照してリソース予約のための処理を行い、迅速にＲＥＳＥＲＶＥメッセージを送信することができる（ステップＳ５３７、Ｓ５３９、Ｓ５４１、Ｓ５４３、Ｓ５４５）。なお、ＱＮＥ（プロキシ）１２３とＭＮ１０１の間で使われるフローＩＤは、ＱＮＥ（プロキシ）１２３とＣＮ１２１の間で使われるフローＩＤと同じであってもよい。
【０１６３】
以上、説明したように、本発明の第３の実施の形態における第１及び第２動作例によれば、ＱＮＥ（プロキシ）１２３が、ＭＮ１０１のサブネット１０７において割り当てられるＮＣｏＡを用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路（ＭＮ１０１からＣＮ１２１までの経路）の一部（例えば、ＱＮＥ（プロキシ）１２３とＣＮ１２１との間の経路）に係るＱｏＳ予約の準備（特に、ルーティングのためのステートの確立処理）を行うことにより、ＭＮ１０１がサブネット１０３から１０７に接続を変更した場合において、ＣＮ１２１からＭＮ１０１に送られるデータパケットのＱｏＳ保証の中断時間を低減することができる。
【０１６４】
また、上述のように、フローＩＤ及びフィルタリストを定義することにより、ＭＮのハンドオーバのケースに限らず、ＱｏＳ経路を容易に管理することができるようになる。
【０１６５】
例えば、ＭＮが、１つのセッションに対し複数のＩＰアドレスを用いてＣＮと通信している場合（ＭＮがマルチホーム状態の場合）で、どのＩＰアドレスも同一のサブネット配下のものであった場合を考える。この場合、どのＩＰアドレスが設定されたデータパケットであっても、データパケットが通過する経路は１つなので、各ＱＮＥにおけるＮＴＬＰ層では、ＭＮが持つ複数のＩＰアドレスのうちの１つをフローＩＤのあて先（又は送信元）アドレスとして採用すればよい。なお、パケットクラシファイアとして利用されるフィルタリストは、上述のように複数のフィルタ情報に対応しているので、ＭＮが有する複数のＩＰアドレスのすべてを容易に保持することが可能である。
【０１６６】
また、ＦＴＰ（File Transfer Protocol）を用いたデータのダウンロードなどでは、ダウンロードのスピードを上げるために、クライアントは一度に複数のポートを用いることがある。この場合でも、上述のＭＮが複数のＩＰアドレスを持つ場合と同様に、複数のポート番号のうちの１つをフローＩＤに採用すればよい。なお、フローＩＤが完全にＩＰアドレスの情報のみで作られるような場合には、ＮＴＬＰにおいて、ポート番号を管理する必要はなくなる。また、上述のＭＮが複数のＩＰアドレスを持つ場合と同様に、パケットクラシファイアとして利用されるフィルタリストは、複数のフィルタ情報に対応しているので、複数のポート番号を容易に保持することが可能である。
【０１６７】
また、さらに、Ｈ．３２３を用いてＶｏＩＰ（Voice over IP）用のセッションを張る場合には、この途中のプロセスにおいて、使用されるポート番号が変化する。しかしながら、この場合でも、上述のように、フローＩＤ及びフィルタリストを定義することによって、ＮＴＬＰ側ではポート番号の変化に合わせてフローＩＤの情報を変える必要はなくなり、一方、パケットクラシファイアとして利用されるフィルタリストでは、フィルタ情報の追加・削除が容易に行えるため、ポート番号の変化に柔軟に対応することが可能となる。
【０１６８】
次に、本発明の第３の実施の形態の第３動作例について説明する。データ経路（ＭＮ１０１とＣＮ１２１とを結ぶ経路）上にＮＡＴＦＷが存在する場合においても、ＭＮ１０１のハンドオーバ時にＱｏＳ保証の中断時間を低減させるシームレスなＱｏＳ保証を提供することが望ましい。このとき、シームレスなＱｏＳ保証を提供するため、上述の本発明の第３の実施の形態の第１動作例（図１５を参照）や第２動作例（図１６を参照）と同様に、プロキシを利用して、ＮＴＬＰ層においてルーティングのためのステートの確立処理を先に行い、端末のハンドオーバ後にＱｏＳリソース予約を行うとともに、ＮＡＴＦＷのポリシールールの追加や書き換えを行うことが望ましい。
【０１６９】
以下、データ経路上のＱＮＥ１１７がＮＡＴＦＷであることを想定して、上述の本発明の第３の実施の形態の第１動作例と同様に、ＭＮ１０１がサブネット１０３からサブネット１０７にハンドオーバを行う際に、ＱＮＥ（プロキシ）１２３が、ＭＮ１０１のサブネット１０７において割り当てられるＮＣｏＡを用いることなく、ＭＮ１０１のハンドオーバ後に使用される経路の一部に係るＱｏＳ予約の準備（特に、ルーティングのためのステートの確立処理）を行う動作について説明する。
【０１７０】
図１８は、本発明の第３の実施の形態において、データ経路上にＮＡＴＦＷが存在しており、データパケットの送信方向がuplink方向の場合の動作例を示すシーケンスチャートである。なお、ここでは、ＱＮＥ１１７がＮＡＴＦＷ機能を持つものとし、ＱＮＥ１１９及びＣＮ１２１がプライベートアドレスを用いるＬＡＮ内に存在するものとする。また、ＭＮ１０１、ＱＮＥ１１７及びＣＮ１２１にはＮＡＴＦＷ ＮＳＬＰが実装されているものとする。さらに、ＮＡＴＦＷ（ＱＮＥ１１７）には、ＮＳＩＳシグナリングメッセージがこのＮＡＴＦＷを通過できるためのポリシールールが既に設定されているものとする。また、図１５に図示されている第１動作例と同様に、図１８に図示されているシーケンスにおいても、各ＱＮＥにおいてルーティングのためのステートを作るために送信されるメッセージの一例として、ＮＳＩＳのＱｏＳ ＮＳＬＰで定義されているＱＵＥＲＹメッセージを用いた場合を例に挙げて説明する。
【０１７１】
図１８において、まず、ＱＮＥ（プロキシ）１２３は、予測経路を準備するためのトリガを受ける（ステップＳ６０１）。なお、このトリガには、例えば、ＭＮ１０１とＣＮ１２１との間のＱｏＳ経路で用いられているセッションＩＤ、ＣＮ１２１（又は経路の最終ＱＮＥであるＱＮＲ）のＩＰアドレスなど、予測経路を確立するために必要な情報が含まれている。
【０１７２】
トリガを受け取ったＱＮＥ（プロキシ）１２３は、このトリガに応じて、即座に、ＮＳＬＰ層においてＱＵＥＲＹメッセージのペイロード部を生成し、ＮＴＬＰ層に受け渡す。ＮＴＬＰ層ではこれを受けて、自身をシグナリングメッセージの送信元、ＣＮ１２１をあて先としたフローＩＤを生成し（ステップＳ６０３）、このフローＩＤをヘッダ部に含むＱＵＥＲＹメッセージを、下位層を経由してＣＮ１２１に向けて送信する（ステップＳ６０５）。なお、このＱＵＥＲＹメッセージは、経路１４９における新規のdownstream方向（データ送信方向と同じ方向）へのメッセージであるので、このＱＵＥＲＹメッセージのＩＰヘッダにはＱＮＥ用のＲＡＯが付けられる。
【０１７３】
ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路上のすべてのＱＮＥ（ＱＮＥ１２５、１１５、１１７、１１９）は、ＱＵＥＲＹメッセージを受信してＩＰヘッダにＲＡＯを発見すると、ＮＳＩＳ層（ＮＳＬＰ層及びＮＴＬＰ層）においてＱＵＥＲＹメッセージの中身を確認して、必要な処理を行う。すなわち、ＱＵＥＲＹメッセージを受信したＱＮＥ１２５、１１５、１１７、１１９は、ＱｏＳ ＮＳＬＰ層におけるＱＵＥＲＹ処理以外に、ＮＴＬＰ層においてルーティングのためのステートの確立処理（ルーティングステートや、メッセージアソシエーション（要求されている場合）の確立のための処理）を行う（ステップＳ６０７、Ｓ６１１、Ｓ６１５、Ｓ６１９、Ｓ６２３）。その後、各ＱＮＥはＱＵＥＲＹメッセージをＣＮ１２１に向けて送信する（ステップＳ６０９、Ｓ６１３、Ｓ６１７、Ｓ６２１）。そして、ＱＵＥＲＹメッセージがＣＮ１２１に到達すると、このＱＵＥＲＹメッセージに対するＲＥＳＰＯＮＳＥメッセージがＣＮ１２１からＱＮＥ１２３に返される（ステップＳ６２５、Ｓ６２７、Ｓ６２９、Ｓ６３１、Ｓ６３３）。
【０１７４】
ここで、ＭＮ１０１がサブネット１０７に移動したとする（ステップＳ６３５）。ＭＮ１０１は、サブネット１０７よりＮＣｏＡを取得すると、ＮＴＬＰ層において、このＮＣｏＡをシグナリングメッセージの送信元、ＱＮＥ（プロキシ）１２３をシグナリングメッセージのあて先としたフローＩＤを生成する（ステップＳ６３７）。また、ＭＮ１０１のＮＳＬＰ層では、自身のＮＣｏＡをデータパケットの送信元、ＣＮ１２１のＩＰアドレスをデータパケットのあて先とした情報を含むフィルタ情報を生成する。また、ＮＡＴＦＷ ＮＳＬＰ層では、このフィルタ情報を持ったデータパケットがＮＡＴＦＷを通過するためのポリシールールを、ＮＡＴＦＷ（ＱＮＥ１１７）で作成できるようにするパラメータを持ったＣＲＥＡＴＥメッセージ（図１８では、CREATEと記載）を作成する。また、ＱｏＳ ＮＳＬＰ層では、このフィルタ情報を追加（add）してＱｏＳリソースを予約するような送信者主導のＲＥＳＥＲＶＥメッセージ（図１８ではRESERVE(add)と記載）を作成する。そして、ＭＮ１０は、上記のＣＲＥＡＴＥメッセージとＲＥＳＥＲＶＥメッセージとを１つのメッセージ（ＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージ）にして、ＱＮＥ（プロキシ）１２３に向けて送信する（ステップＳ６３９）。なお、上記のＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージは、経路１４９におけるＭＮ１０１からＱＮＥ（プロキシ）１２３に対する新規のdownstream方向（データ送信方向と同じ方向）へのメッセージであるので、ＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージのＩＰヘッダにはＱＮＥ用のＲＡＯが付けられる。
【０１７５】
このＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージを受け取ったＱＮＥ（プロキシ）１２３は、ＮＴＬＰにおいてルーティングのためのステートの確立処理を行う（ステップＳ６４１）とともに、ＮＳＬＰにおいてリソース予約のための処理を行う。また、ＮＴＬＰ層ではセッションＩＤなどの情報から、このＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージをＣＮ１２１に送信する必要があることを認識し、このＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージに含まれるフローＩＤの情報を、ステップＳ６０３で生成されたフローＩＤに変更し、ＣＮ１２１に向けて送信する（ステップＳ６４３）。この際、ＮＴＬＰは、メッセージをＣＮ１２１に向けて送信する必要があるということを、ＮＳＬＰに伝えてもよい。なお、この場合、ルーティングのためのステートは、ＱＮＥ１２３、１２５、１１５、１１７、１１９に既に確立されているので、ＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージにＲＡＯが付加される必要はなく、ＱＮＥ１２３、１２５、１１５、１１７、１１９は、受信したＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージのＲＥＳＥＲＶＥ部分を参照してリソース予約のための処理を行い、迅速にＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージを送信することができる（ステップＳ６４５、Ｓ６４７、Ｓ６５１、Ｓ６５３）。また、ＮＡＴＦＷ（ＱＮＥ１１７）においては、このＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージのＣＲＥＡＴＥ部分を参照し、ポリシールールに変更を加える（ステップＳ６４９）。このとき、ポリシールールにデータパケットに対するアドレス変換が含まれていた場合には、フィルタリストに含まれる該当フィルタ情報の内容をプライベートアドレスに対応したものに変更するか、又はプライベートアドレス用のフィルタ情報をリストに追加する。これにより、ＱＮＥ１１７とＱＮＥ１１９の間や、ＱＮＥ１１９とＣＮ１２１の間におけるＲＥＳＥＲＶＥ処理では、プライベートアドレス用にＱｏＳリソースが予約されることとなる。なお、ＭＮ１０１と、ＱＮＥ（プロキシ）１２３との間で使われるフローＩＤは、ＱＮＥ（プロキシ）１２３とＣＮ１２１の間で使われるフローＩＤと同じであってもよい。また、シグナリングメッセージ送信側で、あらかじめプライベートアドレスの情報が分かっていた場合には、このアドレス情報をあらかじめフィルタリスト内に存在させてもよい。この場合、ＮＡＴＦＷ（ＱＮＥ１１７）では、ステップＳ６４９においてフィルタリストの内容を変換する必要はない。
【０１７６】
また、ここではＣＲＥＡＴＥとＲＥＳＥＲＶＥを同時に、ＱｏＳシグナリング用のルーティングのためのステートを用いて送信する例を挙げたが、このためには、複数のＮＳＬＰメッセージを同時に（１つのパケットとして）送信することをサポートするよう、ＮＳＩＳの仕様を変更する必要がある。また、ＲＥＳＥＲＶＥメッセージとＣＲＥＡＴＥメッセージは別々に送信されてもよいが、この場合には、ＣＲＥＡＴＥメッセージが、ＲＥＳＥＲＶＥメッセージよりも前に送信されることが必要であり（ステップＳ６４９でＲＥＳＥＲＶＥメッセージ内のフィルタ情報の書き換えが必要な場合があるため）、また、ＮＡＴＦＷシグナリング用のルーティングのためのステートが、ＱｏＳの場合と同様に、ＱＮＥ（プロキシ）１２３を用いてあらかじめ確立されていることが望ましい。
【０１７７】
また、ここでは、データパケットの送信方向がuplink方向の場合について説明したが、データパケットの送信方向がdownlink方向であった場合においても、図１６に図示されている第２動作例において、ＲＥＳＥＲＶＥメッセージと同時にＣＲＥＡＴＥメッセージを送信することによって同様の手順を採ることができる。
【０１７８】
上述の本発明の第３の実施の形態における第３動作例では、ＮＡＴＦＷ（ＱＮＥ１１７）が、ＱｏＳ ＮＳＬＰとＮＡＴＦＷ ＮＳＬＰの両方のＮＳＬＰを持っている場合について説明を行った。この場合、フィルタリストはＮＳＬＰ共通部分に存在し、各ＮＳＬＰからフィルタリストを参照できるように構成してもよい。また、各ＮＳＬＰで使用されるフィルタ情報の組み合わせが異なることも考えられるので、この場合にはフィルタリスト内の各フィルタ情報に対し、どのＮＳＬＰで使用されるのかを示す情報（例えばフラグを立てるなど）を与えてもよい。
【０１７９】
また、ＮＳＬＰごとにフィルタリストが分けられていてもよい。すなわち、ＱｏＳ ＮＳＬＰ用フィルタリストやＮＡＴＦＷ ＮＳＬＰ用フィルタリストなどのような各ＮＳＬＰで必要となるフィルタリストが用意され、各ＮＳＬＰ用フィルタリストがＮＳＬＰ共通部分に置かれる。
【０１８０】
また、フィルタリストは各ＮＳＬＰに存在してもよい。この場合、各ＮＳＬＰ間で、直接又はＮＴＬＰを通じて、フィルタリストに関する情報をやり取りすることによって、フィルタリストの内容に整合性を持たせてもよい。例えば、ＮＡＴＦＷノードで<filterA>を<filterB>に書き換える指示を出す内容がＮＡＴＦＷ ＮＳＬＰに存在した場合、この情報が直接又はＮＴＬＰを通じてＱｏＳ ＮＳＬＰに送られ、これに従って、ＮＡＴＦＷノードのＱｏＳ ＮＳＬＰ内のフィルタリストに含まれる<filterA>が<filterB>に書き換えられる。ただし、ＱｏＳ ＮＳＬＰ内のフィルタリストにあらかじめ<filterB>が存在している場合には、フィルタ情報を書き換える必要ない。
【０１８１】
さらに、図１７に図示されているフィルタリストの定義とは異なるが、フィルタリストをＮＴＬＰに存在させるようにしてもよい。フィルタリストがＮＴＬＰに存在する場合は、フィルタリストがＮＳＬＰ共通部分に存在する場合と同様に、フィルタリスト内の各フィルタ情報に対し、どのＮＳＬＰで使用されるのかを示す情報（例えばフラグを立てるなど）が与えられていてもよく、また、ＮＳＬＰごとにフィルタリストが分けられていてもよい。
【０１８２】
また、ＮＡＴＦＷノードは、ＮＡＴＦＷ機能を実装しているが、ＱｏＳ機能の実装は必須ではないため、ＮＡＴＦＷ ＮＳＬＰのみが存在し、ＱｏＳ ＮＳＬＰが存在しないＮＡＴＦＷノードが存在する場合も考えられる。このようなＮＡＴＦＷノードにおいても、ＮＳＬＰ共通部分やＮＴＬＰにフィルタリストが存在すれば、フィルタ情報の変換（図１８におけるステップＳ６４９の処理）を容易に行うことができる。
【０１８３】
また、各ＮＳＬＰにフィルタリストが存在する場合でも、ＮＡＴＦＷノードにおける特別な機能として、ＱｏＳ ＮＳＬＰが存在しない場合であってもＱｏＳ ＮＳＬＰ内のフィルタリストの内容をチェックすることができる機能を持たせれば、フィルタ情報の変換は可能となる。また、この場合、ＱｏＳ ＮＳＬＰメッセージがＮＡＴＦＷノードでインタセプトされるようにする必要がある。ＱｏＳ ＮＳＬＰメッセージがＮＡＴＦＷノードでインタセプトされるようにするため、ルーティングのためのステート確立以前に送信されるＱｏＳ ＮＳＬＰメッセージには、例えば、ＮＡＴＦＷ ＮＳＬＰ用のＲＡＯ、又はＱｏＳ ＮＳＬＰ及びＮＡＴＦＷ ＮＳＬＰ共通（又はＮＳＬＰ共通）のＲＡＯ、又はＮＴＬＰを有するＮＥに対するＲＡＯ（すなわち、ＮＴＬＰ用ＲＡＯ）が付加される。
【０１８４】
さらに、ＮＡＴＦＷノードが、ＮＴＬＰのみを実装している場合も考えられる。この場合、ＮＴＬＰにフィルタリストが存在すれば、ＮＡＴＦＷノードは、フィルタ情報の変換（図１８におけるステップＳ６４９の処理）を容易に行うことができる。ＮＳＬＰ共通部分や各ＮＳＬＰにフィルタリストが存在する場合でも、ＮＡＴＦＷノードにおける特別な機能として、ＮＳＬＰ共通部分や各ＮＳＬＰに存在するフィルタリストの内容をチェックすることができる機能を持たせれば、フィルタ情報の変換は可能となる。また、この場合、ＱｏＳ ＮＳＬＰメッセージがＮＡＴＦＷノードでインタセプトされるようにする必要がある。ＱｏＳ ＮＳＬＰメッセージがＮＡＴＦＷノードでインタセプトされるようにするため、ルーティングのためのステート確立以前に送信されるＱｏＳ ＮＳＬＰメッセージには、例えば、ＮＴＬＰを有するＮＥに対するＲＡＯ（すなわち、ＮＴＬＰ用ＲＡＯ）が付加される。
【０１８５】
また、上述のようにフローＩＤ及びフィルタリストを定義することにより、ＭＮのハンドオーバのケースに限らず、ＮＡＴＦＷノードを経由するデータ経路を容易に管理することが可能となる。
【０１８６】
例えば、ＭＮが、１つのセッションに対し複数のＩＰアドレスを用いてＣＮと通信している場合（ＭＮがマルチホーム状態の場合）で、どのＩＰアドレスも同一のサブネット配下のものであった場合を考える。この場合、どのＩＰアドレスが設定されたデータパケットであっても、データパケットが通過する経路は１つなので、各ＮＡＴＦＷ ＮＳＬＰを持つＮＥにおけるＮＴＬＰ層では、ＭＮが持つ複数のＩＰアドレスのうちの１つをフローＩＤのあて先（又は送信元）アドレスとして採用すればよい。なお、ＮＡＴＦＷにおいてポリシールール作成のために利用されるフィルタリストは、上述のように複数のフィルタ情報に対応しているので、ＭＮが有する複数のＩＰアドレスのすべてを容易に保持することが可能である。
【０１８７】
また、ＦＴＰを用いたデータのダウンロードなどでは、ダウンロードのスピードを上げるために、クライアントは一度に複数のポートを用いることがある。この場合でも、上述のＭＮが複数のＩＰアドレスを持つ場合と同様に、複数のポート番号のうちの１つをフローＩＤに採用すればよい。なお、フローＩＤが完全にＩＰアドレスの情報のみで作られるような場合には、ＮＴＬＰにおいて、ポート番号を管理する必要はなくなる。また、上述のＭＮが複数のＩＰアドレスを持つ場合と同様に、ＮＡＴＦＷにおいてポリシールール作成のために利用されるフィルタリストは、複数のフィルタ情報に対応しているので、複数のポート番号を容易に保持することが可能である。
【０１８８】
また、さらに、Ｈ．３２３を用いてＶｏＩＰ用のセッションを張る場合には、この途中のプロセスにおいて、使用されるポート番号が変化する。しかしながら、この場合でも、上述のように、フローＩＤ及びフィルタリストを定義することによって、ＮＴＬＰ側ではポート番号の変化に合わせてフローＩＤの情報を変える必要はなくなり、一方、ＮＡＴＦＷにおいてポリシールール作成のために利用されるフィルタリストでは、フィルタ情報の追加・削除が容易に行えるため、ポート番号の変化に柔軟に対応することが可能となる。
【０１８９】
また、上述の本発明の第３の実施の形態では、フローＩＤとフィルタ情報とを分けて、別々に管理できるようにすることによって、シグナリングメッセージの通る経路に係る処理を、データパケットの通る経路に係る処理より前に行えるようにしているが、さらに、これを応用して、データパケットの通る経路と、シグナリングメッセージの通る経路とが異なるoff-pathシグナリング（Path Decoupledシグナリングとも呼ばれる）を行うことも可能となる。例えば、あるドメインのプロキシや、ポリシー決定ポイント（データ経路上に存在する必要は無い）に直接シグナリングメッセージを送信し、このノードに、フィルタリストの内容を使用した処理（例えば、ポリシールールの作成）を行わせることも可能である。
【０１９０】
なお、上述の本発明の第１〜第３の実施の形態では、付加的サービスがＱｏＳ保証である場合について説明したが、その他の付加的サービスに関しても本発明は適用可能である。また、特に、ＱｏＳ保証に関しては、ＮＳＩＳに対して本発明を適用した場合の具体例について説明したが、本発明は、その適用対象がＮＳＩＳに限定されるものではなく、さらに、本発明の機能を持たせるＮＳＩＳのメッセージは、上述の一例に限定されるものではない。
【０１９１】
また、上記の本発明の各実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０１９２】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
【０１９３】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
【産業上の利用可能性】
【０１９４】
本発明は、移動端末がハンドオーバを行う際に、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることが可能であり、通信ネットワーク技術や、パケット伝送に係るリソース管理の技術に適用可能である。さらに、本発明は、移動端末がハンドオーバを行う場合に限らず、端末が１つのセッションに対し、複数のＩＰアドレスや複数のポート番号を用いて通信を行っている場合や、セッションの途中でＩＰアドレスやポート番号に変更が生じる場合においても、経路（特に、ＱｏＳ経路）の管理を容易にすることが可能であり、通信ネットワーク技術や、パケット伝送に係るリソース予約に係るシグナリングメッセージのルーティング管理技術に適用可能である。
【図面の簡単な説明】
【０１９５】
【図１】本発明の第１の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ経路の状態を模式的に示す図
【図２】本発明の第１の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路を確立した状態を模式的に示す図
【図３】本発明の第１の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図
【図４】本発明の第１の実施の形態におけるＱＮＥの一構成例を示す図
【図５】本発明の第１の実施の形態における動作例を示すシーケンスチャート
【図６】本発明の第２の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ経路の状態を模式的に示す図
【図７】本発明の第２の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路を確立した状態を模式的に示す図
【図８】本発明の第２の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図
【図９】本発明の第２の実施の形態における動作例を示すシーケンスチャート
【図１０】従来の技術におけるＮＳＩＳのプロトコル構成を説明するための模式図
【図１１】従来の技術におけるＮＳＩＳのノードであるＮＥやＱＮＥが「隣り合う」という概念を説明するための模式図
【図１２】本発明の第３の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ予約の状態及びルーティングのためのステート内に含まれるフローＩＤの状態を模式的に示す図
【図１３】本発明の第３の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路上にルーティングのためのステートを確立した状態を、この中に含まれるフローＩＤを示すことにより模式的に示す図
【図１４】本発明の第３の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図
【図１５】本発明の第３の実施の形態において、データパケットの送信方向がuplink方向の場合の動作例を示すシーケンスチャート
【図１６】本発明の第３の実施の形態において、データパケットの送信方向がdownlink方向の場合の動作例を示すシーケンスチャート
【図１７】本発明の第３の実施の形態において、ＱＮＥ内でフィルタ情報及びフローＩＤを管理する主体を模式的に示す図
【図１８】本発明の第３の実施の形態において、データ経路上にＮＡＴＦＷが存在しており、データパケットの送信方向がuplink方向の場合の動作例を示すシーケンスチャート
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2006073084.tif 000020
【図２】
2006073084.tif 000021
【図３】
2006073084.tif 000022
【図４】
2006073084.tif 000023
【図５】
2006073084.tif 000024
【図６】
2006073084.tif 000025
【図７】
2006073084.tif 000026
【図８】
2006073084.tif 000027
【図９】
2006073084.tif 000028
【図１０】
2006073084.tif 000029
【図１１】
2006073084.tif 000030
【図１２】
2006073084.tif 000031
【図１３】
2006073084.tif 000032
【図１４】
2006073084.tif 000033
【図１５】
2006073084.tif 000034
【図１６】
2006073084.tif 000035
【図１７】
2006073084.tif 000036
【図１８】
2006073084.tif 000037
【国際調査報告】
2006073084.tif 000038
2006073084.tif 000039
2006073084.tif 000040
2006073084.tif 000041
2006073084.tif 000042
2006073084.tif 000043
2006073084.tif 000044