JPWO2006073084A1

JPWO2006073084A1 - 通信システム、リソース管理装置、リソース管理方法、通信管理装置並びに通信管理方法

Info

Publication number: JPWO2006073084A1
Application number: JP2006550786A
Authority: JP
Inventors: 貴子堀; ホンチェン; 上　豊樹; 豊樹上; チジェファン
Original assignee: Panasonic Corp; Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp; Panasonic Holdings Corp
Priority date: 2005-01-07
Filing date: 2005-12-27
Publication date: 2008-06-12
Also published as: WO2006073084A1; EP1835667A1; US20080137625A1

Abstract

移動端末がハンドオーバを行う際に、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることを目的とする。例えば、ＭＮ１０１が、新たな接続先（ＡＲ１０９）におけるアドレス（ＮＣｏＡ）を取得していない状態で、ＱＮＥ（プロキシ）１２３に対して、新たな接続先に接続した場合に使用するＱｏＳ経路の確立処理の開始を要求する。ＱＮＥ（プロキシ）は、自ノードとＣＮ１２１との間のリソース予約を行い、その結果、ＱＮＥ（ＣＲＮ）１１５より上流では、ＭＮがＡＲ１０５に接続している状態で使用されている経路情報（ｆｉｌｔｅｒＡ）に、新たな経路情報（ｆｉｌｔｅｒＢ）が関連付けられる。ＭＮが移動後に実際の新たなＣｏＡを使用してＱｏＳ経路の更新を行うまでの間は、データパケットは、プロキシノードによってカプセル化されて、経路情報（ｆｉｌｔｅｒＢ）に基づいて伝送される。

Description

本発明は、通信システム、リソース管理装置、リソース管理方法、通信管理装置並びに通信管理方法に関し、特に、パケット伝送が行われる通信ネットワークにおける通信システム、リソース管理装置、リソース管理方法、通信管理装置並びに通信管理方法に関する。

移動端末から無線ネットワークを通じてインターネットなどの通信ネットワークにアクセスするユーザに対して、移動しながらでもシームレスに通信ネットワークの接続を提供できる技術として、次世代インターネットプロトコルであるモバイルＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）を利用したものが普及してきている。

一方、ネットワークを利用した通信においては、ＱｏＳ（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）保証を始めとしたサービス（本明細書では、こうしたサービスを付加的サービスと呼ぶことにする）が存在しており、こうした付加的サービスを実現するための様々な通信プロトコルが存在している。このような様々な通信プロトコルのうち、ＱｏＳ保証をするためのプロトコルとして、例えば、ＲＳＶＰ（ＲｅｓｏｕｒｃｅＲｅｓｅｒｖａｔｉｏｎＰｒｏｔｏｃｏｌ）が挙げられる（例えば、下記の非特許文献１参照）。ＲＳＶＰは、データの送信を行う送信側通信端末からデータの受信を行う受信側通信端末への経路（フロー）上における帯域予約を行うことによって、送信側通信端末から受信側通信端末に、データがスムーズに伝送されるようにするものである。

サブネット（サブネットワーク）間のハンドオーバを行うＭＮ（ＭｏｂｉｌｅＮｏｄｅ：モバイルノード）に関しては、ハンドオーバ前に受けていたＱｏＳ保証を始めとする付加的サービスを、ハンドオーバ後においても継続して受けられるべきであるという要請があるが、上述したＲＳＶＰは、ＭＮの移動に対して十分には対応していないという問題がある。

この問題を解決するために、現在、ＩＥＴＦ（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ）において、ＮＳＩＳ（ＮｅｘｔＳｔｅｐｉｎＳｉｇｎａｌｉｎｇ）と呼ばれる新しいプロトコルを標準化するための議論が行われている（下記の非特許文献２参照）。このＮＳＩＳは、モバイル環境において、ＱｏＳ保証を始めとする様々な付加的サービスに特に有効であると期待されており、ＮＳＩＳにおいてＱｏＳ保証やモビリティサポートを実現するための要件や実現方法などが記載された文献も存在する（例えば、下記の非特許文献３〜７参照）。以下に、現在ＩＥＴＦのＮＳＩＳワーキンググループでドラフト仕様となっているＮＳＩＳの概要と、ＱｏＳ経路確立の方法を説明する（非特許文献４及び非特許文献７参照）。

図１０には、従来の技術におけるＮＳＩＳのプロトコル構成を説明するために、ＮＳＩＳ及びその下位層のプロトコルスタックが図示されている。ＮＳＩＳプロトコル層はＩＰ及び下位層のすぐ上に位置する。さらにＮＳＩＳプロトコル層は、それぞれの付加的サービスを提供するためのシグナリングメッセージ生成、及びその処理を行うプロトコルであるＮＳＬＰ（ＮＳＩＳＳｉｇｎａｌｉｎｇＬａｙｅｒＰｒｏｔｏｃｏｌ）と、ＮＳＬＰのシグナリングメッセージのルーティングを行うＮＴＬＰ（ＮＳＩＳＴｒａｎｓｐｏｒｔＬａｙｅｒＰｒｏｔｏｃｏｌ）の２層からなる。ＮＳＬＰには、ＱｏＳのためのＮＳＬＰ（ＱｏＳＮＳＬＰ）や、その他のある付加的サービス（サービスＡやサービスＢ）のためのＮＳＬＰ（サービスＡのＮＳＬＰ、サービスＢのＮＳＬＰ）など、様々なＮＳＬＰが存在している。

また、図１１は、従来の技術におけるＮＳＩＳのノードであるＮＥやＱＮＥが「隣り合う」という概念を説明するための模式図である。図１１に示すように、ＮＳＩＳ機能を持ったすべてのノード（ＮＥ：ＮＳＩＳＥｎｔｉｔｙ）には、少なくともＮＴＬＰが実装されている。このＮＴＬＰの上には、ＮＳＬＰが必ずしも存在しなくてもよく、また、１つ以上のＮＳＬＰが存在してもよい。なお、ここでは、特に、ＱｏＳのためのＮＳＬＰを持ったＮＥをＱＮＥ（ＱｏＳＮＳＩＳＥｎｔｉｔｙ）と呼ぶことにする。なお、ＮＥになり得るのは端末やルータである。また、隣り合うＮＥの間には、ＮＥではない複数のルータが存在することもあり得るし、隣り合うＱＮＥの間には、ＮＥではないルータ及びＱｏＳＮＳＬＰを持たないＮＥが複数存在することもあり得る。

なお、ＮＳＩＳは、モバイル環境だけでなく通常の静的なネットワークにおける様々な機能も網羅するものであるが、本明細書では、ＮＳＩＳの機能の１つであるモビリティサポートされた付加的サービスの確立を実現する機能に着目し、ＮＳＩＳの実装によって、モビリティサポートされた付加的サービスの確立が実現されるものとする。

また、ＭＮが新たなサブネットワーク（以下、サブネットと呼ぶ）に移動する場合、新たなＱｏＳ経路が、ＭＮとＣＮ（ＣｏｒｒｅｓｐｏｎｄｅｎｔＮｏｄｅ：通信相手ノード）との間で確立される必要がある。新たなＱｏＳ経路が確立されるまでは、データパケットは必要なＱｏＳ処理を受けられず、ＱｏＳの中断が起こることになる。このＱｏＳの中断は、スムーズかつシームレスなモビリティが実現されるように、最低限に抑えられる必要がある。

こうした問題を扱う１つの方法として、下記の非特許文献８には、ＭＲＳＶＰが提示されている。この非特許文献８では、ＲＳＶＰに変更を加えることによって、モバイルＩＰの三角ルート用のＱｏＳ経路をあらかじめ確立する方法が提案されている。ここでは、「ローカルプロキシエージェント（ＨＡ（ＨｏｍｅＡｇｅｎｔ：ホームエージェント）に相当する）」及び「リモートプロキシエージェント（ＦＡ（ＦｏｒｅｉｇｎＡｇｅｎｔ：フォーリンエージェント）に相当する）」が、ＭＮのためのＱｏＳ経路を確立することが可能である。

リモートプロキシエージェントは、ＭＮのＮＣｏＡ（ＮｅｗＣａｒｅ−ｏｆＡｄｄｒｅｓｓ：新たな気付アドレス）取得した後に、自身とＣＮとの間にＱｏＳ経路のセットアップを行う。続いて、リモートプロキシエージェントとローカルプロキシエージェントとの間（すなわち、ＦＡとＨＡとの間）の経路が新たに確立されて、この経路と、ローカルプロキシエージェントとＣＮとの間（すなわち、ＦＡとＣＮとの間）の経路とが併合される。なお、経路の併合の具体的な方法に関しては説明されていない。

また、ＭＮがサブネット間においてハンドオーバを行う場合、ハンドオーバ前の古い経路の一部とハンドオーバ後の新しい経路の一部とが重複する場合がある。このような場合には、重複経路における２重予約の問題や、経路の変更が困難であることなど、様々な問題が起こり得る。こうした問題を解く方法の１つとして、古い経路と新しい経路とが分岐（クロスオーバ）する位置を特定する方法が挙げられる。この分岐点上に存在する通信ノードはＣＲＮ（ＣｒｏｓｓｏｖｅｒＮｏｄｅ：クロスオーバノード）と呼ばれ、このＣＲＮを特定する方法としては、例えば、下記の非特許文献９、１０などに記載されている方法が知られている。

なお、本明細書に記載されているＱｏＳ経路の確立とは、ＱｏＳが保証されるデータパケットが通る経路であって、ＮＴＬＰ層においてシグナリングメッセージをルーティングするためのステートが確立されており、かつＮＳＬＰ層によってＱｏＳ保証のためのリソース予約手続きが完了した状態のことを指す。なお、ＱｏＳ保証のためのリソース予約と、ＮＴＬＰ層のルーティングのためのステートの確立は、同時に行われる場合もあるし、また、ルーティングのためのステートの確立の後に、ＱｏＳ保証のためのリソース予約が行われる場合もある。

また、下記の非特許文献１１Ａによれば、シグナリングメッセージのルーティングのためのステートは、ＮＳＩＳの最初のメッセージが、ｄｏｗｎｓｔｒｅａｍ方向（データパケットが送られる方向）に対して送られる際に確立される。すなわち、あるセッションに対するデータパケットに対してＱｏＳ保証が行われる場合、データパケットが通過する最初のＱＮＥは、ＱｏＳ予約のためのシグナリングメッセージ、又はその準備のためのシグナリングメッセージを、データパケットの受信者に向けて送信する。このとき、このシグナリングメッセージのＮＴＬＰ層に、セッションを識別するセッションＩＤやフローを識別するフローＩＤなどの情報が付けられるほかに、ＩＰ層にはＲＡＯ（ＲｏｕｔｅｒＡｌｅｒｔＯｐｔｉｏｎ）が付けられる。そして、このシグナリングメッセージが通過しようとするＱＮＥのＩＰ層において、ＲＡＯの存在によりこのシグナリングメッセージはインタセプトされて、ＮＳＩＳ層（ＮＴＬＰ層及びＮＳＬＰ層）に渡され、ＮＳＩＳ層によって、シグナリングメッセージの中身が確認されるようになる。

シグナリングメッセージをインタセプトしたＱＮＥのＮＴＬＰ層では、まず、ルーティングのためのステートとして、フローＩＤやセッションＩＤの情報、及び、このシグナリングメッセージが送信されてきた１つ前の隣り合うＱＮＥのＩＰアドレスの情報を格納する。そして、１つ前の隣り合うＱＮＥに対して、ＮＴＬＰレベルでの返信メッセージを返す。これにより、１つ前のＱＮＥのＮＴＬＰ層は、１つ後ろのＱＮＥのＩＰアドレスを知ることができ、このＩＰアドレスをルーティングのためのステートに書き込むことによって保持する。また、シグナリングメッセージの送受信をセキュアに行いたい場合などには、このほかに、メッセージアソシエーションなどの手順を行い、セキュリティに関するネゴシエーションなどを行う。

一方、ＮＳＬＰ側では、ＮＳＬＰメッセージの中身に応じた処理を行い、この処理が済むと再びＮＴＬＰにより、シグナリングメッセージがあて先（ここでは、データパケットの受信者）に向けて転送される。

こうして、このシグナリングメッセージが所定のあて先に到達することにより、ＮＴＬＰ層にはメッセージのルーティングのためのステートに係る情報が確立される。特に、メッセージアソシエーションが確立された場合には、以後の該当セッションＩＤ、フローＩＤを持つシグナリングメッセージに関しては、ＲＡＯを用いることなく、上述のように確立されたルーティングのためのステートを用いて送受信される。

また、ＮＡＴ（ＮｅｔｗｏｒｋＡｄｄｒｅｓｓＴｒａｎｓｌａｔｉｏｎ：ネットワークアドレス変換）やＦＷ（Ｆｉｒｅｗａｌｌ：ファイアウォール）におけるポリシールールを動的に作成するため、ＮＳＩＳではＮＳＬＰ層の機能の１つとして、ＮＡＴＦＷＮＳＬＰ（下記の非特許文献１３参照）が提案されている。

なお、ＮＡＴとは、ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）内のみで使われるプライベートアドレス情報と、インターネット上で使われるグローバルアドレス情報の変換を行う技術である。なお、アドレス情報にはＩＰアドレスのほかに、ＩＰアドレスとポート番号の組み合わせなども用いられる。どのプライベートアドレス情報と、どのグローバルアドレス情報とを対応させるかという変換情報は、ポリシールールという形でＮＡＴ対応ノード内に保有される。また、ＦＷとは、ＬＡＮ内に通すパケット、又はＬＡＮ内からＬＡＮ外（例えば、インターネット）に送出するパケットをフィルタリングする技術である。なお、フィルタリングには、ＩＰアドレスやポート番号などが用いられる。このフィルタリング情報は、ポリシールールという形でＦＷ対応ノード内に保有される。また、ＮＡＴ及びＦＷの両方の機能が１つのノードに実装される場合も多い。本明細書では、ＮＡＴ及びＦＷの両方の機能をＮＡＴＦＷと呼び、ＮＡＴ及びＦＷの両方の機能を有するノードをＮＡＴＦＷノードと呼ぶ。

ＮＡＴＦＷＮＳＬＰの基本動作は、以下の通りである。
（１）データ送信者であるＮＡＴＦＷＮＳＬＰ対応ノードが，データ受信者であるＮＡＴＦＷＮＳＬＰ対応ノードに対して、ＣＲＥＡＴＥメッセージを送信する。
（２）経路上に存在するＮＡＴＦＷＮＳＬＰ対応ノードが、このＣＲＥＡＴＥメッセージをインタセプトする。
（３）このノードがＮＡＴＦＷ機能を持つものであった場合、このＣＲＥＡＴＥメッセージに含まれるパラメータに基づいて、ポリシールールを作成する。

なお、ＣＲＥＡＴＥメッセージに含まれるパラメータとは、対象となるデータパケットのアドレス情報、アクション（例えば、パケットを通す／通さないという処理など）及びアクションに対する補足情報（ライフタイムなど）である。このデータパケットのアドレス情報は、フローＩＤより引用される。

なお、ＱｏＳＮＳＬＰの場合と同様に、データ送信者及びデータ受信者がＮＡＴＦＷＮＳＬＰ対応ノードではない場合には、データ経路上に存在するＮＡＴＦＷＮＳＬＰ対応ノードで、データ送信者（又はデータ受信者）に一番近いノードが、シグナリングメッセージの送信者（又は受信者）となる。また、ＣＲＥＡＴＥメッセージを送信する前提として、ＮＡＴＦＷノードには、ＮＳＩＳメッセージを通すためのポリシールールがあらかじめ作成されていることが定められている。

また、ＮＴＬＰにはフローＩＤが含まれており、このフローＩＤが、ＮＳＬＰレイヤにおいてデータパケットのフィルタリング情報（例えば、ＱｏＳ保証におけるパケットクラシファイア（ｐａｃｋｅｔｃｌａｓｓｉｆｉｅｒ：パケット分類情報）として使用される。データパケットのフィルタリング情報がＮＡＴに対応できるようにするため、非特許文献１１Ｂでは、ＮＡＴがＮＴＬＰ対応であり、かつ、ＮＡＴにおいて、パケットヘッダのアドレス情報の変換と同時にフローＩＤの中身も変換されることが要請されている。
Ｒ．Ｂｒａｄｅｎ，Ｌ．Ｚｈａｎｇ，Ｓ．Ｂｅｒｓｏｎ，Ｓ．ＨｅｒｚｏｇａｎｄＳ．Ｊａｍｉｎ，″ＲｅｓｏｕｒｃｅＲｅＳｅｒＶａｔｉｏｎＰｒｏｔｏｃｏｌ−Ｖｅｒｓｉｏｎ１ＦｕｎｃｔｉｏｎａｌＳｐｅｃｉｆｉｃａｔｉｏｎ″，ＲＦＣ２２０５，Ｓｅｐｔｅｍｂｅｒ１９９７．ＮＳＩＳＷＧ（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ．ｃｈａｒｔｅｒｓ／ｎｓｉｓ−ｃｈａｒｔｅｒ．ｈｔｍｌ）Ｈ．Ｃｈａｓｋａｒ，Ｅｄ，″ＲｅｑｕｉｒｅｍｅｎｔｓｏｆａＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ（ＱｏＳ）ＳｏｌｕｔｉｏｎｆｏｒＭｏｂｉｌｅＩＰ″，ＲＦＣ３５８３，Ｓｅｐｔｅｍｂｅｒ２００３ＳｖｅｎＶａｎｄｅｎＢｏｓｃｈ，ＧｅｏｒｇｉｏｓＫａｒａｇｉａｎｎｉｓａｎｄＡｎｄｒｅｗＭｃＤｏｎａｌｄ″ＮＳＬＰｆｏｒＱｕａｌｉｔｙ−ｏｆ−Ｓｅｒｖｉｃｅｓｉｇｎａｌｌｉｎｇ″，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｑｏｓ−ｎｓｌｐ−０５．ｔｘｔ，Ｏｃｔｏｂｅｒ２００４Ｘ．Ｆｕ，Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ，Ｈ．Ｔｓｃｈｏｆｅｎｉｇ，″ＭｏｂｉｌｉｔｙｉｓｓｕｅｓｉｎＮｅｘｔＳｔｅｐｓｉｇｎａｌｉｎｇ″，ｄｒａｆｔ−ｆｕ−ｎｓｉｓ−ｍｏｂｉｌｉｔｙ−０１．ｔｘｔ，Ｏｃｔｏｂｅｒ２００３Ｓ．Ｌｅｅ，ｅｔ．Ａｌ．，"ＡｐｐｌｉｃａｂｉｌｉｔｙＳｔａｔｅｍｅｎｔｏｆＮＳＩＳＰｒｏｔｏｃｏｌｓｉｎＭｏｂｉｌｅＥｎｖｉｒｏｎｍｅｎｔｓ"，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ａｐｐｌｉｃａｂｉｌｉｔｙ−ｍｏｂｉｌｉｔｙ−ｓｉｇｎａｌｉｎｇ−００．ｔｘｔ，Ｏｃｔｏｂｅｒ１８，２００４Ｒ．Ｈａｎｃｏｃｋ（ｅｄｉｔｏｒ），"ＮｅｘｔＳｔｅｐｓｉｎＳｉｇｎａｌｉｎｇ：Ｆｒａｍｅｗｏｒｋ"，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｆｗ−０７．ｔｘｔ，Ｎｏｖｅｍｂｅｒ１，２００３ＭＲＳＶＰ：Ａ．Ｋ．ＴＡＬＵＫＤＡＲ，Ｂ．Ｒ．ＢＡＤＲＩＮＡＴＨａｎｄＡ．ＡＣＨＡＲＹＡ，"ＡＲｅｓｏｕｒｃｅＲｅｓｅｒｖａｔｉｏｎＰｒｏｔｏｃｏｌｆｏｒａｎＩｎｔｅｇｒａｔｅｄＳｅｒｖｉｃｅＮｅｔｗｏｒｋｗｉｔｈＭｏｂｉｌｅＨｏｓｔｓ"，ＷｉｒｅｌｅｓｓＮｅｔｗｏｒｋ７ｐｐ５−１９，２００１Ｔ．Ｓａｎｄａ，Ｔ．Ｕｅ，"ＰｒｅＣＲＮｄｉｓｃｏｖｅｒｙｆｒｏｍｐｒｏｘｙｏｎｃａｎｄｉｄａｔｅｎｅｗｐａｔｈ"，ｄｒａｆｔ−ｓａｎｄａ−ｎｓｉｓ−ｍｏｂｉｌｉｔｙ−ｑｏｓ−ｐｒｏｘｙ−０１．ｔｘｔ，Ｆｅｒｕａｒｙ２００４三田貴子，上豊樹，荒牧隆，"モビリティをサポートしたシームレスなＱｏＳ経路確立方法に関する提案"，電子情報通信学会モバイルマルチメディア通信（ＭｏＭｕＣ）研究会，Ｖｏｌ．１０４Ｎｏ．３８，ｐｐ５９−６４，２００４年５月Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ，Ｒ．Ｈａｎｃｏｃｋ，"ＧＩＭＰＳ：ＧｅｎｅｒａｌＩｎｔｅｒｎｅｔＭｅｓｓａｇｉｎｇＰｒｏｔｏｃｏｌｆｏｒＳｉｇｎａｌｉｎｇ"，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｎｔｌｐ−０５．ｔｘｔ，Ｆｅｂｒｕａｒｙ２００５Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ，Ｒ．Ｈａｎｃｏｃｋ，"ＧＩＭＰＳ：ＧｅｎｅｒａｌＩｎｔｅｒｎｅｔＭｅｓｓａｇｉｎｇＰｒｏｔｏｃｏｌｆｏｒＳｉｇｎａｌｉｎｇ"，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｎｔｌｐ−０７．ｔｘｔ，Ｊｕｌｙ１８，２００５三田貴子他，"モバイルＩＰを用いた通信におけるＱｏＳステート管理方法に関する提案"，電子情報通信学会情報ネットワーク（ＩＮ）研究会，ｖｏｌ．１０４，ｎｏ．５６４，ＩＮ２００４−１４４，ｐｐ．１−６，２００５年１月Ｍ．Ｓｔｉｅｍｅｒｌｉｎｇ，Ｈ．ＴｓｃｈｏｆｅｎｉｇａｎｄＣ．Ａｏｕｎ"ＮＡＴ／ＦｉｒｅｗａｌｌＮＳＩＳＳｉｇｎａｌｉｎｇＬａｙｅｒＰｒｏｔｏｃｏｌ（ＮＳＬＰ）"，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｎｓｌｐ−ｎａｔｆｗ−０７．ｔｘｔ，Ｊｕｌｙ１８，２００５

従来の技術には、主に、下記の２つの課題（第１及び第２の課題）が存在する。

まず、従来の技術に係る第１の課題について説明する。例えば、上記の非特許文献８に記載されている方法では、ＭＮのためのＱｏＳ経路をあらかじめ確立するために、新たなサブネットワークにおけるプロキシが用いられる。しかしながら、ＭＮのＮＣｏＡを取得した後にのみ、プロキシによってＱｏＳ経路が確立されるが、プロキシは、ＭＮが実際に移動する前にＭＮのＮＣｏＡを取得できない可能性があり、事前にＮＣｏＡを取得する処理によって、スムーズな経路の確立が妨げられてしまう可能性がある。

また、ＱｏＳ経路を確立するための試みが、いくつもの経路にわたって実行される必要があり、ＭＮは、こうしたＱｏＳ経路の確立結果に基づいて、新たな接続ポイントへの移動を決定する場合がある。したがって、ＭＮのＮＣｏＡは、ＱｏＳ経路の確立後に生成される場合もあり、この場合には、プロキシが、ＭＮの新たな接続ポイントとなり得る各接続ポイントにおけるＭＮのＮＣｏＡを取得することは困難である。

次に、従来の技術に係る第２の課題について説明する。ＮＳＩＳの現仕様では、フローＩＤがそのままパケットクラシファイア（ｐａｃｋｅｔｃｌａｓｓｉｆｉｅｒ：パケット分類情報）として用いられるため、フローＩＤにデータパケットのヘッダ情報が含まれていなければならず、この制限が、ＭＮのハンドオーバ時におけるスムーズなＱｏＳ経路変更を困難にしている。さらに、端末が１つのセッションに対し、複数のＩＰアドレスや複数のポート番号を用いて通信を行っている場合（例えば、端末がマルチホーム状態の場合）や、セッションの途中でＩＰアドレスやポート番号に変更が生じる場合に、ＱｏＳ経路の管理は非常に困難なものとなってしまう場合がある。

上記問題に鑑み、本発明は、移動端末がハンドオーバを行う際に、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることを第１の目的とする。

また、本発明では、端末が１つのセッションに対し、複数のＩＰアドレスや複数のポート番号を用いて通信を行っている場合や、セッションの途中でＩＰアドレスやポート番号に変更が生じる場合において、経路（特に、ＱｏＳ経路）の管理を容易にすることを第２の目的とする。

上記目的を達成するため、本発明の通信システムは、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な通信システムであって、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続し、前記第１アクセスルータが構成する第１サブネットで取得する第１アドレスを使用して通信を行う移動可能な移動端末と、
前記通信ネットワークに接続されており、前記移動端末の通信相手となる通信相手端末と、
前記移動端末が、前記複数のアクセスルータのうちの１つである第２アクセスルータに接続した場合に前記第２アクセスルータが構成する第２サブネットで取得する第２アドレスを使用せずに、前記第１アクセスルータに接続している前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路が確立された状態で、前記第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始することが可能な前記通信ネットワーク内に存在する通信ノードとを有している。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信ノードが、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることが可能となる。

さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、前記第２アクセスルータの近隣に存在している。
この構成により、移動端末がハンドオーバ後に第２アクセスルータに接続した場合に、この第２アクセスルータの近隣に存在する通信ノードを経由した経路の設定が可能となる。

さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信し、前記トリガ情報に基づいて前記第２経路を確立する処理を開始するように構成されている。
この構成により、プロキシとして機能する通信ノードは、この第２経路の確立処理に必要な情報や、その開始タイミングなどを把握することが可能となる。

さらに、本発明の通信システムは、上記の通信システムに加えて、前記移動端末が、前記トリガ情報を前記通信ノードに送信するように構成されている。
この構成により、移動端末が、第２経路の確立開始処理を開始させる指示を行うとともに、第２経路の確立に必要な情報を、プロキシとして機能する通信ノードに送信することが可能となる。

さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、自ノードを一方の終端とする前記第２経路を確立するように構成されている。
この構成により、移動端末のアドレスを用いずに、プロキシとして機能する通信ノードのアドレスを使用して、第２経路を確立することが可能となる。

さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードは、前記移動端末が前記第２サブネットに移動して割り当てられた第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始するように構成されている。
この構成により、プロキシとして機能する通信ノードが、移動端末の新たなアドレスを取得した場合には、そのアドレスに基づく第３経路の確立が開始されるようになる。

さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている。
この構成により、プロキシとして機能する通信ノードが、ＱｏＳ保証などの付加的サービスが提供されないヘッダを有するパケットに対して、カプセル化を行うことで、付加的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセル化が行われることによって、適切なあて先にパケットが到達可能となる。

さらに、本発明の通信システムは、上記の通信システムに加えて、前記第２経路の終端が前記通信ノード及び前記通信相手端末であり、前記通信相手端末が、前記移動端末にパケットを送信する際に前記通信ノードのアドレスをあて先アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記通信相手端末から前記移動端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている。
この構成により、通信相手端末（ＣＮ）が、ＱｏＳ保証などの付加的サービスが提供されないヘッダを有するパケットに対して、カプセル化を行うことで、付加的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセル化が行われることによって、適切なあて先にパケットが到達可能となる。

さらに、本発明の通信システムは、上記の通信システムに加えて、前記第２経路の終端が前記第２アクセスルータの近隣に存在する前記通信ノード及び前記通信相手端末の近隣に存在する相手側近隣通信ノードであり、前記相手側近隣通信ノードが、前記通信相手端末から前記移動端末へのパケットを転送する際に前記通信ノードのアドレスをあて先アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記通信相手端末から前記移動端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている。
この構成により、通信相手端末（ＣＮ）の近隣に存在する相手側近隣通信ノードが、ＱｏＳ保証などの付加的サービスが提供されないヘッダを有するパケットに対して、カプセル化を行うことで、付加的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセル化が行われることによって、適切なあて先にパケットが到達可能となる。また、通信相手端末（ＣＮ）が、付加的サービス機能やカプセル化機能を実装していない場合でも、伝送されるパケットは付加的サービスを受けることが可能となる。

さらに、本発明の通信システムは、上記の通信システムに加えて、前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第１サブネットに接続している状態で使用されていた前記第１経路、及び前記通信ノードによって確立された前記第２経路が削除されるように構成されている。
この構成により、ハンドオーバ前の状態からハンドオーバ後の状態に移行する際に、余分な情報（無駄なリソース予約など）が残らないようにすることが可能となる。

さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、自ノードと前記通信相手端末との間の経路上の中間通信ノードに、前記第２経路を確立する処理を行う際に送受信されるシグナリングメッセージのルーティングのためのステートを導入する処理を開始するように構成されている。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信ノードが、ハンドオーバ後における経路の再設定のうち、シグナリングメッセージのルーティングのためのステート確立処理を経路の一部に対して迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることが可能となる。

さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードが、前記中間通信ノードに対して、自ノードのアドレス及び前記通信相手端末のアドレスにより構成された識別情報を送信し、前記中間通信ノードが、前記識別情報を保持して、前記識別情報を有するシグナリングメッセージを特定するように構成されている。
この構成により、移動端末に対してハンドオーバ後に割り当てられるアドレスを取得する前に、プロキシとして機能する通信ノードは、通信相手端末との間におけるシグナリングメッセージのルーティングのためのステート確立処理を開始することが可能となる。

さらに、本発明の通信システムは、上記の通信システムに加えて、前記通信ノードは、前記移動端末が前記第２サブネットに移動して割り当てられた第２アドレスを取得した場合に、前記第２経路に係る付加的サービスを提供するための情報を含むシグナリングメッセージを送信し、前記中間通信ノードが、前記シグナリングメッセージのルーティングのためのステートを使用して、前記シグナリングメッセージの伝送を行うように構成されている。
この構成により、移動端末のハンドオーバ後に割り当てられるアドレスを取得する前に確立されたシグナリングメッセージのルーティングのためのステートを利用して、付加的サービスを提供するための情報を含むシグナリングメッセージを伝送することが可能となり、新たな経路（特に、ＱｏＳ経路）を迅速に確立することが可能となる。

さらに、本発明の通信システムは、上記の通信システムに加えて、前記付加的サービスがＱｏＳ保証である場合に適用される。

また、上記目的を達成するため、本発明のリソース管理装置によれば、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な前記通信ネットワークに存在する通信ノード内のリソース管理装置であって、
前記経路において、付加的サービスを提供するためのリソースを確保するためのリソース確保手段と、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続している前記移動端末と、前記通信ネットワークに接続されており前記移動端末の通信相手となる通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信するトリガ受信手段と、
前記トリガ受信手段で前記トリガ情報を受信した場合、前記トリガ情報に基づいて、前記第１アクセスルータとは異なる第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始するメッセージを生成するメッセージ生成手段とを有している。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信ノードが、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることが可能となる。

さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記メッセージには、前記移動端末の代理として経路設定を行う旨を示す情報が付加されている。
この構成により、上記のメッセージに係るリソース予約が、プロキシによるものであることを、経路上の各ＱＮＥに対して明示することが可能となる。

さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記第２アクセスルータの近隣に存在する前記通信ノード内に配置されている。
この構成により、移動端末がハンドオーバ後に第２アクセスルータに接続した場合に、この第２アクセスルータの近隣に存在する通信ノードを経由した経路の設定が可能となる。

さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記トリガ情報に、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスが少なくとも含まれている。
この構成により、プロキシとして機能する通信ノードは、この第２経路の確立処理に必要な情報や、その開始タイミングなどを把握することが可能となる。

さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移動端末から前記トリガ情報を受信する。
この構成により、移動端末が、第２経路の確立開始処理を開始させる指示を行うとともに、第２経路の確立に必要な情報を、プロキシとして機能する通信ノードに送信することが可能となる。

さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記通信ノードを一方の終端とする前記第２経路を確立するように構成されている。
この構成により、移動端末のアドレスを用いずに、プロキシとして機能する通信ノードのアドレスを使用して、第２経路を確立することが可能となる。

さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移動端末が前記第２サブネットに移動して割り当てられた前記第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始するように構成されている。
この構成により、プロキシとして機能する通信ノードが、移動端末の新たなアドレスを取得した場合には、そのアドレスに基づく第３経路の確立が開始されるようになる。

さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている。
この構成により、プロキシとして機能する通信ノードが、ＱｏＳ保証などの付加的サービスが提供されないヘッダを有するパケットに対して、カプセル化を行うことで、付加的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセル化が行われることによって、適切なあて先にパケットが到達可能となる。

さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第２経路を削除するためのメッセージを送信するように構成されている。
この構成により、ハンドオーバ前の状態からハンドオーバ後の状態に移行する際に、余分な情報（無駄なリソース予約など）が残らないようにすることが可能となる。

さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記付加的サービスが、ＱｏＳ保証である場合に適用可能である。

また、上記目的を達成するため、本発明のリソース管理方法は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な前記通信ネットワークに存在する通信ノードで行われるリソース管理方法であって、
前記経路において、付加的サービスを提供するためのリソースを確保するためのリソース確保ステップと、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続している前記移動端末と、前記通信ネットワークに接続されており前記移動端末の通信相手となる通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信するトリガ受信ステップと、
前記トリガ受信ステップで前記トリガ情報を受信した場合、前記トリガ情報に基づいて、前記第１アクセスルータとは異なる第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始するメッセージを生成するメッセージ生成ステップとを有している。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信ノードが、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることが可能となる。

さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記メッセージには、前記移動端末の代理として経路設定を行う旨を示す情報が付加されている。
この構成により、上記のメッセージに係るリソース予約が、プロキシによるものであることを、経路上の各ＱＮＥに対して明示することが可能となる。

さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記第２アクセスルータの近隣に存在する前記通信ノード内に配置されている。
この構成により、移動端末がハンドオーバ後に第２アクセスルータに接続した場合に、この第２アクセスルータの近隣に存在する通信ノードを経由した経路の設定が可能となる。

さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記トリガ情報に、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスが少なくとも含まれている。
この構成により、プロキシとして機能する通信ノードは、この第２経路の確立処理に必要な情報や、その開始タイミングなどを把握することが可能となる。

さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移動端末から前記トリガ情報を受信する。
この構成により、移動端末が、第２経路の確立開始処理を開始させる指示を行うとともに、第２経路の確立に必要な情報を、プロキシとして機能する通信ノードに送信することが可能となる。

さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記通信ノードを一方の終端とする前記第２経路を確立する。
この構成により、移動端末のアドレスを用いずに、プロキシとして機能する通信ノードのアドレスを使用して、第２経路を確立することが可能となる。

さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移動端末が前記第２サブネットに移動して割り当てられた前記第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始する。
この構成により、プロキシとして機能する通信ノードが、移動端末の新たなアドレスを取得した場合には、そのアドレスに基づく第３経路の確立が開始されるようになる。

さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化ステップを有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化ステップにおいてカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるようにしている。
この構成により、プロキシとして機能する通信ノードが、ＱｏＳ保証などの付加的サービスが提供されないヘッダを有するパケットに対して、カプセル化を行うことで、付加的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセル化が行われることによって、適切なあて先にパケットが到達可能となる。

さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第２経路を削除するためのメッセージを送信する。
この構成により、ハンドオーバ前の状態からハンドオーバ後の状態に移行する際に、余分な情報（無駄なリソース予約など）が残らないようにすることが可能となる。

さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記付加的サービスが、ＱｏＳ保証である場合に適用される。

また、上記目的を達成するため、本発明の通信管理装置は、シグナリングメッセージをルーティングする機能を有する第１ユニットと、提供する付加的サービスに関する情報を管理するための機能を有する第２ユニットとにより構成された通信プロトコルを使用して２つの通信ノード間で行われる通信において、前記２つの通信ノード間の経路上に存在し、前記２つの通信ノード間で伝送されるデータパケットに対して前記付加的サービスを提供する通信ノード内の通信管理装置であって、
前記第１ユニットが、前記２つの通信ノード間の経路の一部であって、自ノードを含んだ任意の両端点を有する前記経路の一部において伝送される前記シグナリングメッセージのルーティングのためのステートを管理するステート管理手段を有し、
前記第２ユニットが、前記シグナリングメッセージによって伝送されるフィルタ情報であって、前記付加的サービスを提供する対象となるデータパケットを特定するための前記フィルタ情報を管理するフィルタ情報管理手段を有している。
この構成により、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、経路の管理を容易に行えるようにすることが可能となる。

さらに、本発明の通信管理装置は、上記の通信管理装置に加えて、前記ステートが、前記任意の両端点のアドレスを有し、前記フィルタ情報が、前記２つの通信ノードのアドレスを有している。
この構成により、シグナリングメッセージのルーティングのための情報、及び付加的サービスを提供するデータパケットを特定するための情報のそれぞれに関して、異なるアドレスが設定できるようになり、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、特に、ルーティングのためのステートの確立処理を柔軟に行えるようにすることが可能となる。

さらに、本発明の通信管理装置は、上記の通信管理装置に加えて、前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層に配置されている。
この構成により、フローＩＤとフィルタ情報とを分けて別々に管理し、シグナリングメッセージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存性を緩和することが可能となる。また、ＮＳＩＳにおいて、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、特に、ルーティングのためのステートの確立処理を柔軟に行えるようにすることが可能となる。

また、上記目的を達成するため、本発明の通信管理方法は、シグナリングメッセージをルーティングする機能を有する第１ユニットと、提供する付加的サービスに関する情報を管理するための機能を有する第２ユニットとにより構成された通信プロトコルを使用して２つの通信ノード間で行われる通信において、前記２つの通信ノード間の経路上に存在し、前記２つの通信ノード間で伝送されるデータパケットに対して前記付加的サービスを提供する通信ノードで行われる通信管理方法であって、
前記第１ユニットが、前記２つの通信ノード間の経路の一部であって、自ノードを含んだ任意の両端点を有する前記経路の一部において伝送される前記シグナリングメッセージのルーティングのためのステートを管理するステート管理ステップと、
前記第２ユニットが、前記シグナリングメッセージによって伝送されるフィルタ情報であって、前記付加的サービスを提供する対象となるデータパケットを特定するための前記フィルタ情報を管理するフィルタ情報管理ステップとを有している。
この構成により、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、経路の管理を容易に行えるようにすることが可能となる。

さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記ステートが、前記任意の両端点のアドレスを有し、前記フィルタ情報が、前記２つの通信ノードのアドレスを有している。
この構成により、シグナリングメッセージのルーティングのための情報、及び付加的サービスを提供するデータパケットを特定するための情報のそれぞれに関して、異なるアドレスが設定できるようになり、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、特に、ルーティングのためのステートの確立処理を柔軟に行えるようにすることが可能となる。

さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層に配置されている。
この構成により、フローＩＤとフィルタ情報とを分けて別々に管理し、シグナリングメッセージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存性を緩和することが可能となる。また、ＮＳＩＳにおいて、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することが可能となり、特に、ルーティングのためのステートの確立処理を柔軟に行えるようにすることが可能となる。

さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第１及び第２ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されている。
この構成により、フローＩＤとフィルタ情報とを分けて別々に管理し、シグナリングメッセージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存性を緩和することが可能となる。

さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層の任意の機能が参照可能なＮＳＬＰ共通部に配置されている。
この構成により、フローＩＤとフィルタ情報とを分けて別々に管理し、シグナリングメッセージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存性を緩和することが可能となる。

さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層の特定の機能部に配置されていて、前記特定の機能部から前記ＮＳＬＰ層の任意の機能部に、前記フィルタ情報の一部又は全部が渡されるように構成されている。
この構成により、フローＩＤとフィルタ情報とを分けて別々に管理し、シグナリングメッセージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存性を緩和することが可能となる。

本発明は、上記の構成を有しており、移動端末がハンドオーバ後に接続するサブネットにおいて使用するアドレス（ＮＣｏＡ）を用いずに、ハンドオーバ後の移動端末が送信元又はあて先に設定されたパケットに対して、付加的サービス（特に、ＱｏＳ）を提供することによって、移動端末のＮＣｏＡの生成タイミングや取得機構などに影響されない、スムーズな経路（特に、ＱｏＳ経路）の確立が実現可能となる。

また、本発明は、上記の構成を有しており、付加的サービス（特にＱｏＳ）に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩和することにより、移動端末のＮＣｏＡの生成タイミングや取得機構などに影響されない、スムーズな経路（特に、ＱｏＳ経路）の確立が実現可能となるとともに、さらには、複数のＩＰアドレスや複数のポート番号を用いて通信を行っている場合や、セッションの途中でＩＰアドレスやポート番号に変更が生じる場合においても、経路（特に、ＱｏＳ経路）の管理を容易にすることを可能にする。

本発明の第１の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ経路の状態を模式的に示す図本発明の第１の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路を確立した状態を模式的に示す図本発明の第１の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図本発明の第１の実施の形態におけるＱＮＥの一構成例を示す図本発明の第１の実施の形態における動作例を示すシーケンスチャート本発明の第２の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ経路の状態を模式的に示す図本発明の第２の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路を確立した状態を模式的に示す図本発明の第２の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図本発明の第２の実施の形態における動作例を示すシーケンスチャート従来の技術におけるＮＳＩＳのプロトコル構成を説明するための模式図従来の技術におけるＮＳＩＳのノードであるＮＥやＱＮＥが「隣り合う」という概念を説明するための模式図本発明の第３の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ予約の状態及びルーティングのためのステート内に含まれるフローＩＤの状態を模式的に示す図本発明の第３の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路上にルーティングのためのステートを確立した状態を、この中に含まれるフローＩＤを示すことにより模式的に示す図本発明の第３の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図本発明の第３の実施の形態において、データパケットの送信方向がｕｐｌｉｎｋ方向の場合の動作例を示すシーケンスチャート本発明の第３の実施の形態において、データパケットの送信方向がｄｏｗｎｌｉｎｋ方向の場合の動作例を示すシーケンスチャート本発明の第３の実施の形態において、ＱＮＥ内でフィルタ情報及びフローＩＤを管理する主体を模式的に示す図本発明の第３の実施の形態において、データ経路上にＮＡＴＦＷが存在しており、データパケットの送信方向がｕｐｌｉｎｋ方向の場合の動作例を示すシーケンスチャート

以下、図面を参照しながら、本発明の第１〜第３の実施の形態について説明する。なお、まず、本発明の第１の実施の形態では、データの流れ方向が、移動を行うＭＮから、その通信相手であるＣＮに向かう方向（以下、ｕｐｌｉｎｋ方向と呼ぶ）の場合について説明を行い、続いて、本発明の第２の実施の形態では、データの流れ方向が、ＣＮからＭＮに向かう方向（以下、ｄｏｗｎｌｉｎｋ方向と呼ぶ）の場合について説明を行う。

＜第１の実施の形態＞
以下、本発明の第１の実施の形態について説明する。まず、図１〜３を参照しながら、本発明の第１の実施の形態に係る概要について説明する。図１は、本発明の第１の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ経路の状態を模式的に示す図である。また、図２は、本発明の第１の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路を確立した状態を模式的に示す図である。また、図３は、本発明の第１の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図である。

図１〜３には、無線通信によりＡＲ（ＡｃｃｅｓｓＲｏｕｔｅｒ）に接続してＣＮ１２１との通信を行うＭＮ１０１と、ＭＮ１０１の通信相手となるＣＮ１２１と、サブネット１０３を形成するＡＲ１０５と、サブネット１０７を形成するＡＲ１０９と、ＭＮ１０１とＣＮ１２１との間における経路上に存在し、ＭＮ１０１とＣＮ１２１との間で伝送されるパケットに関してＱｏＳ保証を行うＱｏＳ認識機能（ＱｏＳ−ａｗａｒｅ）を有するＱＮＥ１１１、１１３、１１５、１１７、１１９、１２３、１２５とが図示されている。

なお、ＭＮ１０１がサブネット１０３に存在している場合（すなわち、ＭＮ１０１がＡＲ１０５に接続している場合）、ＭＮ１０１からＣＮ１２１へのｕｐｌｉｎｋ方向の経路１２７上には、ＡＲ１０５、ＱＮＥ１１１、ＱＮＥ１１３、ＱＮＥ１１５、ＱＮＥ１１７、ＱＮＥ１１９が存在しており、ＭＮ１０１がサブネット１０７に存在している場合（すなわち、ＭＮ１０１がＡＲ１０９に接続している場合）、ＭＮ１０１からＣＮ１２１へのｕｐｌｉｎｋ方向の経路１２９上には、ＡＲ１０９、ＱＮＥ１２３、ＱＮＥ１２５、ＱＮＥ１１５、ＱＮＥ１１７、ＱＮＥ１１９が存在しているものとする。なお、経路１２７と経路１２９とは一部が重複しており、経路１２７と経路１２９とのＣＲＮ（ＣｒｏｓｓｏｖｅｒＮｏｄｅ：クロスオーバノード）をＱＮＥ１１５とする。

図１において、ＭＮ１０１からＣＮ１２１に送信されるデータパケットは、経路１２７を経由して伝送される。このとき、経路１２７上のすべてのＱＮＥ１１１、１１３、１１５、１１７、１１９は、ＭＮ１０１からＣＮ１２１に送信されるデータパケットに関するＱｏＳステートを有している。すなわち、各ＱＮＥ１１１、１１３、１１５、１１７、１１９は、少なくとも送信元アドレス（ｓｏｕｒｃｅａｄｄｒｅｓｓ）及びあて先アドレス（ｄｅｓｔｉｎａｔｉｏｎａｄｄｒｅｓｓ）の情報を含む識別情報（この情報をフィルタ情報（ｆｉｌｔｅｒ）と呼ぶ）と、このフィルタ情報に対応するリソース予約情報（ｒｅｓｏｕｒｃｅ）とが関連付けているＱｏＳステートを保持しており、ＭＮ１０１からＣＮ１２１に送信されるデータパケットのヘッダ（特に、送信元アドレス及びあて先アドレス）を参照してフィルタ情報を特定し、対応するリソース予約情報に基づくＱｏＳ保証を行うように構成されている。なお、上述した非特許文献４、６、７などの現在のフローＩＤは、データパケットの送信元アドレス及びあて先アドレスを含む情報により構成されていると記載されており、このフローＩＤを上記のフィルタ情報として利用することも可能である。また、フィルタ情報は、フローＩＤとは異なる情報であってもよい。

なお、図１に図示されているように、経路１２７のフィルタ情報（ＭＮ１０１がサブネット１０３から割り当てられているＩＰアドレス（ｃＣｏＡ：ｃｕｒｒｅｎｔＣａｒｅ−ｏｆＡｄｄｒｅｓｓ）が送信元アドレスとして含まれているとともに、ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれているフィルタ情報）をｆｉｌｔｅｒＡとし、ｆｉｌｔｅｒＡに対応するリソース予約情報をｒｅｓｏｕｒｃｅＡとする。

ＭＮ１０１は、サブネット１０７に移動する可能性があり、プロキシ１２３に対して予測経路（経路１２９）、又は予測経路の一部の確立を所望している。なお、ＭＮ１０１がサブネット１０７に移動する前に、プロキシ１２３によって予測経路、又は予測経路の一部が確立されることで、ＭＮ１０１が実際にサブネット１０７に移動した後に、より迅速にＭＮ１０１からＣＮ１２１へのＱｏＳ経路が確立され、ハンドオーバによるＱｏＳ保証の中断時間を短縮することが可能となる。

ＱＮＥ（プロキシ）１２３が予測経路を確立するための何らかのトリガを受けた場合には、ＱＮＥ（プロキシ）１２３とＣＲＮ（ここではＱＮＥ１１５）との間でＱｏＳ経路が確立される。この新たな経路が確立された場合には、ＱＮＥ（プロキシ）１２３や、ＱＮＥ（プロキシ）１２３とＱＮＥ１１５との間の各中間ＱＮＥ（例えば、ＱＮＥ１２５）は、新たなＱｏＳステートを有することになる。すなわち、図２に図示されているように、ＱＮＥ（プロキシ）１２３やＱＮＥ１２５では、ＱＮＥ（プロキシ）１２３のＩＰアドレスが送信元アドレスとして含まれているとともに、ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれているフィルタ情報（ｆｌｔｅｒＢ）に対して、ｆｉｌｔｅｒＡと同一のリソース予約情報であるｒｅｓｏｕｒｃｅＡが設定される。

一方、ＱＮＥ１１５とＣＮ１２１との間の経路上のＱＮＥに関しては、新たなフィルタ情報（上記のｆｉｌｔｅｒＢ）が、現在のフィルタ情報（ｆｉｌｔｅｒＡ）に追加される。これにより、図２に図示されているように、ＱＮＥ１１５や、ＱＮＥ１１５とＣＮ１２１との間の各中間ＱＮＥ（例えば、ＱＮＥ１１７、１１９）は、ｆｉｌｔｅｒＡ及びｆｉｌｔｅｒＢに対してｒｅｓｏｕｒｃｅＡが設定されたＱｏＳステートを有することになり、ｆｌｔｅｒＢによって定義されるデータトラフィックには、ｆｉｌｔｅｒＡによって定義されるデータトラフィックのために予約されたｒｅｓｏｕｒｃｅＡが使用可能となる。なお、例えば、同一セッションＩＤを有する２つのフィルタ情報（ｆｉｌｔｅｒＡ及びｆｉｌｔｅｒＢ）によりどちらか一方が削除されてしまうなど、従来行われている処理によって本発明に係る動作に不具合が生じる可能性があるため、例えば、ｆｉｌｔｅｒＢに係るＲＥＳＥＲＶＥメッセージには、プロキシによるＱｏＳ経路の確立であることを示す特別なフラグ（「プロキシフラグ」）が付加されることが望ましい。

以上のように、ＭＮ１０１がサブネット１０７への移動を行う前に（あるいは、ＭＮ１０１のサブネット１０７への移動とは無関係に）、ＱＮＥ（プロキシ）１２３は、ＭＮ１０１のＮＣｏＡ（ＭＮ１０１がサブネット１０７に移動した後に割り当てられる新たなＣｏＡ）を用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路の一部（ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路）に係るリソース予約を行うことが可能となる（図２に図示されている状態）。

そして、ＭＮ１０１がＮＣｏＡを取得した場合（実際にサブネット１０７に移動してＮＣｏＡを取得するか、あるいはサブネット１０３に接続した状態でＮＣｏＡを取得した場合）には、図３に図示されているように、経路１２９上の各中間ＱＮＥ（ＱＮＥ１２３、１２５、１１５、１１７、１１９）において、ＭＮ１０１のＮＣｏＡが送信元アドレスとして含まれているとともに、ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれている新たなフィルタ情報（ｆｉｌｔｅｒＣ）がｆｉｌｔｅｒＡ又はｆｉｌｔｅｒＢに追加されることによって、ＱｏＳ経路の更新が行われる。なお、ＭＮ１０１がサブネット１０７に移動した場合には、ｆｉｌｔｅｒＡに関しては、能動的（削除を指示するメッセージの送信などによる）又は受動的（タイムアウトなどによる）に削除されることが望ましい。また、フローＩＤとは異なる情報としてフィルタ情報が存在する場合には、フローＩＤは、データパケットの送信元アドレス／あて先アドレスに依存するものでなくてもよい。例えば、図３でプロキシ１２３がｆｉｌｔｅｒＣに関するリソース予約を行う際、経路１２９全体に使われるフローＩＤは「送信元＝ＱＮＥ（プロキシ）１２３、あて先＝ＣＮ１２１」を含んでいてもよく、またＭＮ１０１からＱＮＥ（プロキシ）１２３までの経路に関しては「送信元＝ＱＮＥ（プロキシ）１２３、あて先＝ＭＮ１０１」を含むフローＩＤ、ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路に関しては「送信元＝ＱＮＥ（プロキシ）１２３、あて先＝ＣＮ１２１」を含むフローＩＤをそれぞれ用いて、２つの経路として扱ってもよい。

例えば、ＭＮ１０１がサブネット１０７に移動してＮＣｏＡを取得した後に、ＮＣｏＡに関するＱｏＳ経路の更新が完了（ｆｉｌｔｅｒＣに関するリソース予約が完了）する前までは、ＭＮ１０１からＣＮ１２１あてに送信されるデータパケットは、ＱＮＥ（プロキシ）１２３によって、ｆｉｌｔｅｒＢの情報を含むアウタヘッダ（送信元アドレスをＱＮＥ（プロキシ）１２３のＩＰアドレスとし、あて先アドレスをＣＮ１２１のＩＰアドレスとするヘッダ）が付加されて、カプセル化される。このカプセル化されたデータパケットはｆｉｌｔｅｒＢによって識別され、各中間ＱＮＥにおいて、ｒｅｓｏｕｒｃｅＡに基づくＱｏＳ保証が行われて伝送され、ｆｉｌｔｅｒＢによって識別される経路の最終ＱＮＥによって脱カプセル化される。なお、この最終ＱＮＥはＣＮ１２１であることが望ましいが、ＣＮ１２１がＱＮＥではない場合には、その他のＱＮＥ（例えば、経路上において、ＣＮ１２１の最も近くに存在するＱＮＥ１１９）であってもよい。

最終ＱＮＥは、ｆｉｌｔｅｒＢで特定されるヘッダを持つパケットが到達した際には、脱カプセル化を行ってインナパケットを取り出す。ＣＮ１２１が最終ＱＮＥの場合にはそのインナパケットを取得し、ＱＮＥ１１９が最終ＱＮＥの場合にはそのインナパケットをＣＮ１２１に向けて転送する。なお、経路全体にわたってＱｏＳ予約が行われるようにするための方法としては、例えばＩＰｖ４最小カプセル化など、上述のパケットのカプセル化方法以外にも存在することは、当業者にとって明白であり、任意のパケットのカプセル化方法を本発明に適用することが可能である。また、本発明は、他の種類のカプセル化やトンネリング機構においても良好に動作する。

このように、ＭＮ１０１のＮＣｏＡが設定されているｆｉｌｔｅｒＣに関するリソース予約が完了するまでは、データパケットのカプセル化が行われ、ＱＮＥ（プロキシ）１２３のＩＰアドレスが送信元アドレスとして設定されているｆｉｌｔｅｒＢによって、カプセル化されたデータパケットのＱｏＳ保証が行われるように構成されており、ＭＮ１０１のＮＣｏＡを用いてリソース予約が行われるまでのＱｏＳ保証の中断時間を低減することが可能となる。

また、ｆｉｌｔｅｒＣのＱｏＳの更新に成功した後（すなわち、ｆｉｌｔｅｒＣが経路１２９上のすべてのＱＮＥに導入された後）は、ＱＮＥ（プロキシ）１２３は、ｆｉｌｔｅｒＢのデータパケットの生成（ｆｉｌｔｅｒＡのデータパケットのカプセル化）を終了する。そして、ｆｉｌｔｅｒＡやｆｉｌｔｅｒＢは能動的又は受動的に削除され、最終的にｆｉｌｔｅｒＣに関するＱｏＳステートのみが残り、サブネット１０７に接続しているＭＮ１０１からＣＮ１２１への経路１２９において、ＭＮ１０１からＣＮ１２１へのデータパケットに対するＱｏＳ保証が行われる。

次に、図４を参照しながら、本発明の第１の実施の形態におけるＱＮＥの構成について説明する。図４は、本発明の第１の実施の形態におけるＱＮＥの一構成例を示す図である。図４に示すＱＮＥは、受信手段１１、送信手段１３、トリガ検出手段１５、メッセージ生成・処理手段１７、フィルタリング手段１９、カプセル化／脱カプセル化手段２１、ＱｏＳ情報格納手段２３を有している。

受信手段１１及び送信手段１３は、パケットの受信及びパケットの送信を行うための手段である。また、トリガ検出手段１５は、例えばＭＮ１０１から受信する、予測経路を確立するための何らかのトリガに係る処理を行うための手段である。なお、受信したトリガ情報は、例えば、フィルタ情報ごとに関連付けられてＱｏＳ情報格納手段２３に格納される。また、トリガ検出手段１５からメッセージ生成・処理手段１７に対して、トリガ情報の受信イベントが発生した旨を示す情報や、トリガ情報自体が供給される。

また、メッセージ生成・処理手段１７は、トリガ情報に含まれるＭＮ１０１とＣＮ１２１との間のＱｏＳ経路で用いられているセッションＩＤや、ＱＳｐｅｃ情報や、ＣＮ１２１のＩＰアドレスなどの情報に基づいて、データ経路上の各通信ノードの調査や、実際のリソース予約などを行うためのメッセージを生成するための手段である。また、他の通信ノードから受信したメッセージに関しても、このメッセージ生成・処理手段１７において処理が行われ、リソース予約などを行うための情報（セッションＩＤやフィルタ情報、ＱＳｐｅｃなどの情報）は、ＱｏＳ情報格納手段２３に格納される。

また、フィルタリング手段１９は、受信パケットのヘッダ（特に、フィルタ情報に対応するパケットの送信元アドレス及びあて先アドレス）を参照して、受信パケットに対して、ＱｏＳ情報格納手段２３に格納されているＱｏＳ情報（ＱｏＳステート）に基づくパケットのフィルタリングを行う手段であり、このフィルタリングによって、各パケットに対するリソースが確保されるように構成されている。また、カプセル化／脱カプセル化手段２１は、必要に応じて、送信パケットのカプセル化や、受信パケットの脱カプセル化を行う手段である。

なお、後述の具体例（図５のシーケンスチャートを参照）から分かるように、トリガ検出手段１５はＱＮＥ１２３においてのみ必要であり、その他のＱＮＥには実装されている必要はない。また、カプセル化／脱カプセル化手段２１は、例えば、ＱＮＥ１２３にカプセル化手段、ＣＮ１２１に脱カプセル化手段がそれぞれ実装されていればよく、その他のＱＮＥには、カプセル化／脱カプセル化手段２１が特に実装される必要はない。

次に、図５を参照しながら、本発明の第１の実施の形態における動作について説明する。図５は、本発明の第１の実施の形態における動作例を示すシーケンスチャートである。なお、ここでは具体例として、ＮＳＩＳのＱｏＳＮＳＬＰで定義されているメッセージであるＱＵＥＲＹメッセージやＲＥＳＥＲＶＥメッセージに、さらに本発明の動作に必要な情報を付加した場合について説明する。

図５において、まず、ＱＮＥ（プロキシ）１２３は、予測経路を確立するためのトリガを受け取る（ステップＳ２０１）。なお、このトリガには、例えば、ＭＮ１０１とＣＮ１２１との間のＱｏＳ経路で用いられているセッションＩＤ、ＱＳｐｅｃ情報、ＣＮ１２１（又は経路の最終ＱＮＥであるＱＮＲ（ＱｏＳＮＳＩＳＲｅｓｐｏｎｄｅｒ））のＩＰアドレスなど、予測経路を確立するために必要な情報が含まれている。また、ＱＮＥ（プロキシ）１２３が受信するトリガの送信元は任意のＱＮＥであってよいが、移動を行う可能性のあるＭＮ１０１や、その通信相手ノードであるＣＮ１２１、ＭＮ１０１やＣＮ１２１からの要求に応じて、ＭＮ１０１やＣＮ１２１の代理として機能するＱＮＥが送信元となることが好適である。なお、この場合、ＭＮ１０１やＣＮ１２１、代理となるＱＮＥは、トリガのあて先に使用するＱＮＥ（プロキシ）１２３のＩＰアドレスを把握する必要があるが、この把握方法は、特に限定されるものではない。

トリガを受け取ったＱＮＥ（プロキシ）１２３は、即座に、このトリガに対応したＱＵＥＲＹメッセージをＣＮ１２１に向かって送信する（ステップＳ２０３）。このＱＵＥＲＹメッセージには、例えば、セッションＩＤとＱＳｐｅｃ情報とが含まれている。ＱＵＥＲＹメッセージは、経路１２９上においてＱＮＥ（プロキシ）１２３に隣接するＱＮＥ１２５に到達する。ＱＮＥ１２５は、このＱＵＥＲＹメッセージに基づいて通常のＱＵＥＲＹ処理（例えば、ＱＵＥＲＹメッセージに含まれているセッションＩＤのリソース予約状況の確認処理など）を行うとともに、次の隣接するＱＮＥ（ＱＮＥ１１５）にＱＵＥＲＹメッセージを送信する（ステップＳ２０５）。ＱＮＥ１１５は、ＱＵＥＲＹメッセージを受信すると、ＱＵＥＲＹメッセージ内のセッションＩＤや、隣接するＱＮＥの変化を検出するための情報として使われるＳＩＩ（ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｃａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ）を比較することによって、自身がＣＲＮであることを認識する（ステップＳ２０７）。

ＱＮＥ１１５は、新たな予約を行うために、「プロキシフラグ」が付加された受信者始動ＲＥＳＥＲＶＥメッセージ（ｒｅｃｅｉｖｅｒ−ｉｎｉｔｉａｔｅｄＲＥＳＥＲＶＥｍｅｓｓａｇｅ）をＱＮＥ１２３に送信する（ステップＳ２０９）。この予約におけるフィルタ情報には、送信元アドレスとしてＱＮＥ（プロキシ）１２３のＩＰアドレスが含まれている（図２のｆｉｌｔｅｒＢに対応）。なお、ステップＳ２０９においてＱＮＥ１１５から送信されたＲＥＳＥＲＶＥメッセージは、ＱＮＥ１２３まで伝送され（ステップＳ２１１）、各ＱＮＥ（ＱＮＥ１２３、１２５）において、ＲＥＳＥＲＶＥメッセージに含まれているフィルタ情報やＱＳｐｅｃに基づいて、フィルタ／リソースの組が生成されて予約が行われる。なお、ＱＮＥ１１５においても同様に、フィルタ／リソース（図２のｆｉｌｔｅｒＢ／ｒｅｓｏｕｒｃｅＡ）の組が生成されて予約が行われる。

また、ステップＳ２０９における受信者始動ＲＥＳＥＲＶＥメッセージの送信と同時に、ＱＮＥ１１５は「プロキシフラグ」が付加された送信者主導のＲＥＳＥＲＶＥメッセージ（ｓｅｎｄｅｒ−ｉｎｉｔｉａｔｅｄＲＥＳＥＲＶＥｍｅｓｓａｇｅ：図５ではＲＥＳＥＲＶＥ（ａｄｄ）と記載）をＣＮ１２１に送信する（ステップＳ２１３）。この予約におけるフィルタ情報には、送信元アドレスとしてＱＮＥ（プロキシ）１２３のＩＰアドレスが含まれている（図２のｆｉｌｔｅｒＢに対応）。ステップＳ２１３においてＱＮＥ１１５から送信されたＲＥＳＥＲＶＥメッセージは、ＣＮ１２１まで伝送され（ステップＳ２１３、Ｓ２１５、Ｓ２１７）、各ＱＮＥ（ＱＮＥ１１７、１１９）において、このフィルタ情報が、ＭＮ１０１からＣＮ１２１へのデータパケットに現在使用されている現在のフィルタ／リソース（図１のｆｉｌｔｅｒＡ／ｒｅｓｏｕｒｃｅＡ）の組に追加される。

ここで、ＭＮ１０１がサブネット１０７に移動したとする（ステップＳ２１９）。ＱＮＥ（プロキシ）１２３はＭＮ１０１の移動を検出し、ＭＮ１０１のＮＣｏＡを取得した場合（ステップＳ２２１）には、受信者始動ＲＥＳＥＲＶＥメッセージをＭＮ１０１に送信する（ステップＳ２２３）。このＲＥＳＥＲＶＥメッセージに関するフィルタ情報には、送信元アドレスとしてＭＮ１０１のＮＣｏＡが含まれている。

また、ＱＮＥ（プロキシ）１２３は、ＣＮ１２１あてのデータパケットをＭＮ１０１から受信した場合には、送信元アドレスがＱＮＥ（プロキシ）１２３のアドレスに設定されたアウタヘッダ（あて先アドレスは、ＣＮ１２１のアドレス）を付加することによって、ＭＮ１０１からのデータパケットのカプセル化を開始する（ステップＳ２２５）。カプセル化されたデータパケットは、その送信元アドレスがＱＮＥ（プロキシ）１２３であり、経路１２９上の各ＱＮＥでは、ｆｉｌｔｅｒＢのフィルタ情報に係るＱｏＳ処理が行われ、その結果、ＱｏＳ保証を受けることになる。

一方、ＱＮＥ（プロキシ）１２３は、サブネット１０７への移動後のＭＮ１０１（すなわち、ＭＮ１０１のＮＣｏＡ）に関する予約を行うために、送信者主導のＲＥＳＥＲＶＥメッセージ（図５ではＲＥＳＥＲＶＥ（ａｄｄ）と記載）をＣＮ１２１に送信する（ステップＳ２２７）。この予約におけるフィルタ情報には、送信元アドレスとしてＭＮ１０１のＩＰアドレスが含まれている。そして、各ＱＮＥ（ＱＮＥ１２５、１１５、１１７、１１９）を経由してＲＥＳＥＲＶＥメッセージは伝送されるとともに（ステップＳ２２９、Ｓ２３１、Ｓ２３３、Ｓ２３５）、各ＱＮＥにおいて、このＲＥＳＥＲＶＥメッセージに含まれるフィルタ情報（図３のｆｉｌｔｅｒＣ）が、以前に付加又は生成されたフィルタ情報（図２のｆｉｌｔｅｒＢ）に付加される。

ＲＥＳＥＲＶＥメッセージを受けたＣＮ１２１は、即座にＲＥＳＰＯＮＳＥメッセージをＱＮＥ１２３に向けて送信する（ステップＳ２３７）。このＲＥＳＰＯＮＳＥメッセージは、各ＱＮＥ（１１９、１１７、１１５、１２５）を経由してＱＮＥ（プロキシ）１２３に到達する（ステップＳ２３９、２４１、２４３、２４５）。このＲＥＳＰＯＮＳＥメッセージの受信によって、ＱＮＥ（プロキシ）１２３はＭＮ１０１のＮＣｏＡに係るＱｏＳ経路が確立された旨を認識し、ＱＮＥ（プロキシ）１２３は、データパケットのカプセル化を終了する（ステップＳ２４７）。

さらに、ＱＮＥ１２３は、ステップＳ２０９〜Ｓ２１７で導入されたＱＮＥ（プロキシ）１２３を送信元アドレスとするフィルタ情報（図２のｆｉｌｔｅｒＢ）を削除するために、送信者主導のＲＥＳＥＲＶＥメッセージ（図５ではＲＥＳＥＲＶＥ（ｒｅｍｏｖｅ）と記載）をＣＮ１２１に送信する（ステップＳ２４９、Ｓ２５１、Ｓ２５３、Ｓ２５５、Ｓ２５７）。なお、必ずしもＲＥＳＥＲＶＥメッセージによるフィルタ情報の削除を行う必要はなく、このフィルタ情報は、タイマのタイムアウトによって削除されてもよい。

以上、説明したように、本発明の第１の実施の形態によれば、ＱＮＥ（プロキシ）１２３が、ＭＮ１０１のサブネット１０７において割り当てられるＮＣｏＡを用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路（ＭＮ１０１からＣＮ１２１までの経路）の一部（ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路）に係るリソース予約を行い、ＭＮ１０１からＣＮ１２１までの完全な経路が確立されるまでは、ＱＮＥ（プロキシ）１２３が確立した経路及びＱｏＳステートによってデータパケットが行われることで、ＭＮ１０１がサブネット１０３からサブネット１０７に接続を変更した場合において、ＭＮ１０１からＣＮ１２１に送られるデータパケットのＱｏＳ保証の中断時間を低減することが可能となる。

＜第２の実施の形態＞
次に、本発明の第２の実施の形態について説明する。まず、図６〜８を参照しながら、本発明の第１の実施の形態に係る概要について説明する。図６は、本発明の第２の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ経路の状態を模式的に示す図である。また、図７は、本発明の第２の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路を確立した状態を模式的に示す図である。また、図８は、本発明の第２の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図である。

図６〜８には、図１〜３と同様に、無線通信によりＡＲに接続してＣＮ１２１との通信を行うＭＮ１０１と、ＭＮ１０１の通信相手となるＣＮ１２１と、サブネット１０３を形成するＡＲ１０５と、サブネット１０７を形成するＡＲ１０９と、ＭＮ１０１とＣＮ１２１との間における経路上に存在し、ＭＮ１０１とＣＮ１２１との間で伝送されるパケットに関してＱｏＳ保証を行うＱｏＳ認識機能（ＱｏＳ−ａｗａｒｅ）を有するＱＮＥ１１１、１１３、１１５、１１７、１１９、１２３、１２５とが図示されている。

なお、ＭＮ１０１がサブネット１０３に存在している場合（すなわち、ＭＮ１０１がＡＲ１０５に接続している場合）、ＣＮ１２１からＭＮ１０１へのｄｏｗｎｌｉｎｋ方向の経路１３７上には、ＱＮＥ１１９、ＱＮＥ１１７、ＱＮＥ１１５、ＱＮＥ１１３、ＱＮＥ１１１、ＡＲ１０５が存在しており、ＭＮ１０１がサブネット１０７に存在している場合（すなわち、ＭＮ１０１がＡＲ１０９に接続している場合）、ＣＮ１２１からＭＮ１０１へのｄｏｗｎｌｉｎｋ方向の経路１３９上には、ＱＮＥ１１９、ＱＮＥ１１７、ＱＮＥ１１５、ＱＮＥ１２５、ＱＮＥ１２３、ＡＲ１０９が存在しているものとする。なお、経路１３７と経路１３９とは一部が重複しており、経路１３７と経路１３９とのＣＲＮをＱＮＥ１１５とする。

図６において、ＣＮ１２１からＭＮ１０１に送信されるデータパケットは、経路１３７を経由して伝送される。このとき、経路１３７上のすべてのＱＮＥ１１１、１１３、１１５、１１７、１１９は、ＣＮ１２１からＭＮ１０１に送信されるデータパケットに関するＱｏＳステートを有している。すなわち、各ＱＮＥ１１１、１１３、１１５、１１７、１１９は、経路１３７のフィルタ情報（ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれているとともに、ＭＮ１０１がサブネット１０３から割り当てられているＩＰアドレス（ｃＣｏＡ）があて先アドレスとして含まれているフィルタ情報）であるｆｉｌｔｅｒＤと、このｆｉｌｔｅｒＤに対応するリソース予約情報であるｒｅｓｏｕｒｃｅＤとが関連付けられているＱｏＳステートを保持しており、ＣＮ１２１からＭＮ１０１に送信されるデータパケットのヘッダ（特に、送信元アドレス及びあて先アドレス）を参照してフィルタ情報（ｆｉｌｔｅｒＤ）を特定し、対応するリソース予約情報（ｒｅｓｏｕｒｃｅＤ）に基づくＱｏＳ保証を行うように構成されている。

ＭＮ１０１は、サブネット１０７に移動する可能性があり、プロキシ１２３に対して予測経路（経路１３９）、又は予測経路の一部の確立を所望している。なお、ＭＮ１０１がサブネット１０７に移動する前に、プロキシ１２３によって予測経路、又は予測経路の一部が確立されることで、ＭＮ１０１が実際にサブネット１０７に移動した後に、より迅速にＣＮ１２１からＭＮ１０１へのＱｏＳ経路が確立され、ハンドオーバによるＱｏＳ保証の中断時間を短縮することが可能となる。

ＱＮＥ（プロキシ）１２３が予測経路を確立するための何らかのトリガを受けた場合には、ＱＮＥ（プロキシ）１２３とＣＲＮ（ここではＱＮＥ１１５）との間でＱｏＳ経路が確立される。この新たな経路が確立された場合には、ＱＮＥ（プロキシ）１２３や、ＱＮＥ（プロキシ）１２３とＱＮＥ１１５との間の各中間ＱＮＥ（例えば、ＱＮＥ１２５）は、新たなＱｏＳステートを有することになる。すなわち、図７に図示されているように、ＱＮＥ（プロキシ）１２３やＱＮＥ１２５では、ＣＮのＩＰアドレスが送信元アドレスとして含まれているとともに、ＱＮＥ（プロキシ）１２３のＩＰアドレスがあて先アドレスとして含まれているフィルタ情報（ｆｉｌｔｅｒＥ）に対して、ｆｉｌｔｅｒＤと同一のリソース予約情報であるｒｅｓｏｕｒｃｅＤが設定される。

一方、ＱＮＥ１１５とＣＮ１２１との間の経路上のＱＮＥに関しては、新たなフィルタ情報（上記のｆｉｌｔｅｒＥ）が現在のフィルタ情報（ｆｉｌｔｅｒＤ）に追加される。これにより、図７に図示されているように、ＱＮＥ１１５や、ＱＮＥ１１５とＣＮ１２１との間の各中間ＱＮＥ（例えば、ＱＮＥ１１７、１１９）は、ｆｉｌｔｅｒＤ及びｆｉｌｔｅｒＥに対してｒｅｓｏｕｒｃｅＤが設定されたＱｏＳステートを有することになり、ｆｉｌｔｅｒＥによって定義されるデータトラフィックには、ｆｉｌｔｅｒＤによって定義されるデータトラフィックのために予約されたｒｅｓｏｕｒｃｅＤが使用可能となる。

以上のように、ＭＮ１０１がサブネット１０７への移動を行う前に（あるいは、ＭＮ１０１のサブネット１０７への移動とは無関係に）、ＱＮＥ（プロキシ）１２３は、ＭＮ１０１のＮＣｏＡ（ＭＮ１０１がサブネット１０７に移動した後に割り当てられる新たなＣｏＡ）を用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路の一部（ＣＮ１２１からＱＮＥ（プロキシ）１２３までの経路）に係るリソース予約を行うことが可能となる（図７に図示されている状態）。

そして、ＭＮ１０１がＮＣｏＡを取得した場合（実際にサブネット１０７に移動してＮＣｏＡを取得するか、あるいはサブネット１０３に接続した状態でＮＣｏＡを取得した場合）には、図８に図示されているように、経路１３９上の各中間ＱＮＥ（ＱＮＥ１２３、１２５、１１５、１１７、１１９）において、ＭＮ１０１のＮＣｏＡが送信元アドレスとして含まれているとともに、ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれている新たなフィルタ情報（ｆｉｌｔｅｒＦ）がｆｉｌｔｅｒＤ又はｆｉｌｔｅｒＥに追加されることによって、ＱｏＳ経路の更新が行われる。なお、ＭＮ１０１がサブネット１０７に移動した場合には、ｆｉｌｔｅｒＤに関しては、能動的又は受動的に削除されることが望ましい。また、フローＩＤとは異なる情報としてフィルタ情報が存在する場合には、フローＩＤは、データパケットの送信元アドレス／あて先アドレスに依存するものでなくてもよい。

例えば、ＭＮ１０１がサブネット１０７に移動してＮＣｏＡを取得した後に、ＮＣｏＡに関するＱｏＳ経路の更新が完了（ｆｉｌｔｅｒＦに関するリソース予約が完了）する前までは、ＣＮ１２１からＭＮ１０１あてに送信されるデータパケットは、ｆｉｌｔｅｒＥの情報を含むアウタヘッダ（送信元アドレスをＣＮ１２１のＩＰアドレスとし、あて先アドレスをＱＮＥ（プロキシ）１２３のＩＰアドレスとするヘッダ）が付加されて、カプセル化される。このカプセル化されたデータパケットはｆｉｌｔｅｒＥによって識別され、各中間ＱＮＥにおいて、ｒｅｓｏｕｒｃｅＤに基づくＱｏＳ保証が行われて伝送され、ＱＮＥ（プロキシ）１２３によって脱カプセル化される。なお、ＣＮ１２１がＱＮＥの場合には、ＣＮ１２１からＭＮ１０１あてに送信されるデータパケットのカプセル化はＣＮ１２１で行われることが望ましいが、その他のＱＮＥ（例えば、経路上において、ＣＮ１２１の最も近くに存在するＱＮＥ１１９）でカプセル化が行われてもよい。

ＱＮＥ（プロキシ）１２３は、ｆｉｌｔｅｒＥで特定されるヘッダを持つパケットが到達した際には、脱カプセル化を行ってインナパケットを取り出し、そのインナパケットをＭＮ１０１に転送する。なお、経路全体にわたってＱｏＳ予約が行われるようにするための方法としては、例えばＩＰｖ４最小カプセル化など、上述のパケットのカプセル化方法以外にも存在することは、当業者にとって明白であり、任意のパケットのカプセル化方法を本発明に適用することが可能である。また、本発明は、他の種類のカプセル化やトンネリング機構においても良好に動作する。

このように、ＭＮ１０１のＮＣｏＡが設定されているｆｉｌｔｅｒＦに関するリソース予約が完了するまでは、データパケットのカプセル化が行われ、ＱＮＥ（プロキシ）１２３のＩＰアドレスがあて先アドレスとして設定されているｆｉｌｔｅｒＥによって、カプセル化されたデータパケットのＱｏＳ保証が行われるように構成されており、ＭＮ１０１のＮＣｏＡを用いてリソース予約が行われるまでのＱｏＳ保証の中断時間を低減することが可能となる。

また、ｆｉｌｔｅｒＦのＱｏＳの更新に成功した後（すなわち、ｆｉｌｔｅｒＦが経路１３９上のすべてのＱＮＥに導入された後）は、ＣＮ１２１は、ｆｉｌｔｅｒＥのデータパケットの生成（ｆｉｌｔｅｒＤのデータパケットのカプセル化）を終了する。そして、ｆｉｌｔｅｒＤやｆｉｌｔｅｒＥは能動的又は受動的に削除され、最終的にｆｉｌｔｅｒＦに関するＱｏＳステートのみが残り、ＣＮ１２１からサブネット１０７に接続しているＭＮ１０１への経路１３９において、ＣＮ１２１からＭＮ１０１へのデータパケットに対するＱｏＳ保証が行われる。

次に、本発明の第２の実施の形態における動作について説明する。図９は、本発明の第２の実施の形態における動作例を示すシーケンスチャートである。なお、ここでは具体例として、上述の本発明の第１の実施の形態と同様に、ＮＳＩＳのＱｏＳＮＳＬＰで定義されているメッセージであるＲＥＳＥＲＶＥメッセージに、さらに本発明の動作に必要な情報を付加した場合について説明する。また、本発明の第２の実施の形態におけるＱＮＥの構成は、上述の本発明の第１の実施の形態におけるＱＮＥの構成（図４参照）と同一であり、ここでは説明を省略する。

図９において、ＱＮＥ（プロキシ）１２３は、ＣＮ１２１から、サブネット１０３に接続しているＭＮ１０１のデータ経路情報（例えば、リソース稼働率など）を取得するとともに、ｄｏｗｎｌｉｎｋ方向のＣＲＮ（ここでは、ＱＮＥ１１５）をあらかじめ特定する（ステップＳ３０１）。なお、例えば、ＱＮＥ（プロキシ）１２３は、上述の非特許文献９、１０などに記載されている方法を使用することによって、これらの情報を取得することが可能である。

そして、ＱＮＥ（プロキシ）１２３は、上述の本発明の第１の実施の形態と同様に、予測経路を確立するための何らかのトリガを受け取る（ステップＳ３０３）。なお、このトリガには、上述の本発明の第１の実施の形態と同様に、例えば、ＭＮ１０１とＣＮ１２１との間のＱｏＳ経路で用いられているセッションＩＤ、ＱＳｐｅｃ情報、ＣＮ１２１（又は経路の最終ＱＮＥであるＱＮＲ）のＩＰアドレスなど、予測経路を確立するために必要な情報が含まれている。

トリガを受け取ったＱＮＥ（プロキシ）１２３は、このトリガに応じて、即座に「プロキシフラグ」が付加された受信者始動ＲＥＳＥＲＶＥメッセージをＣＮ１２１に向かって送信する（ステップＳ３０５）。なお、この予約におけるフィルタ情報には、送信元アドレスとしてＣＮ１２１のＩＰアドレス、あて先アドレスとしてＱＮＥ（プロキシ）１２３のＩＰアドレスが含まれている（図７のｆｉｌｔｅｒＥ）。また、ＱＮＥ（プロキシ）１２３は、このフィルタ情報に対応したフィルタ／リソース（図７のｆｉｌｔｅｒＥ／ｒｅｓｏｕｒｃｅＤ）の組を生成して新たな予約を行う。また、ステップＳ３０７でＱＮＥ１２３からＲＥＳＥＲＶＥメッセージを受けたＱＮＥ１２５も同様に、このフィルタ情報に対応したフィルタ／リソース（図７のｆｉｌｔｅｒＥ／ｒｅｓｏｕｒｃｅＤ）の組を生成して新たな予約を行う。

一方、ＱＮＥ１１７、ＱＮＥ１１９、ＣＮ１２１（ＣＮ１２１がＱＮＥの場合）では、ＲＥＳＥＲＶＥメッセージ（図９では、ＲＥＳＥＲＶＥ（ａｄｄ）と記載）の伝送が行われる（ステップＳ３０９、Ｓ３１１、Ｓ３１３）とともに、このＲＥＳＥＲＶＥメッセージに含まれているフィルタ情報（図７のｆｉｌｔｅｒＥ）が、ＣＮ１２１からＭＮ１０１へのデータパケットに現在使用されている現在のフィルタ／リソース（図６のｆｉｌｔｅｒＤ／ｒｅｓｏｕｒｃｅＤ）の組に追加される。以上の動作により、各ＱＮＥには、図７に図示されているリソース予約情報が設定される。

なお、このＱＮＥ（プロキシ）１２３から送信されるＲＥＳＥＲＶＥメッセージには、ＣＲＮ（ＱＮＥ１１５）以降の経路において上記のようなフィルタ情報の追加処理を行う旨を示す情報が含まれており、ＱＮＥ１１５が、この情報を参照して上流のＱＮＥ（ＱＮＥ１１７）に対して追加処理を指示するＲＥＳＥＲＶＥメッセージを送信してもよい。また、ＱＮＥ１１５は、ＲＥＳＥＲＶＥメッセージを受信した下流のＱＮＥ（ＱＮＥ１２５）が、同一セッションに属する経路１３７とは異なる方向に存在していることから、自らがＣＲＮであることを把握してもよい。また、各ＱＮＥは、リソース予約情報に、受信したＲＥＳＥＲＶＥメッセージのフィルタ情報が属するセッションと同一セッションの他の経路（他のフィルタ情報）を保持している場合には、元々保持しているフィルタ情報に、ＲＥＳＥＲＶＥメッセージのフィルタ情報を追加するように構成されていてもよい。

ここで、ＭＮ１０１がサブネット１０７に移動したとする（ステップＳ３１５）。ＱＮＥ（プロキシ）１２３はＭＮ１０１の移動を検出し、ＭＮ１０１のＮＣｏＡを取得した場合（ステップＳ３２１）には、送信者主導のＲＥＳＥＲＶＥメッセージをＭＮ１０１に送信する（ステップＳ３２３）。このＲＥＳＥＲＶＥメッセージに関するフィルタ情報には、送信元アドレスとしてＣＮ１２１のアドレスが含まれており、あて先アドレスとしてＭＮ１０１のＮＣｏＡが含まれている。

一方、ＣＮ１２１も、例えばＭＮ１０１からのＢＵによって、ＭＮ１０１の移動を検出して、ＭＮ１０１のＮＣｏＡを取得する（ステップＳ３１７）。そして、ＣＮ１２１は、ＭＮ１０１へのデータパケットのカプセル化を開始する（ステップＳ３１９）。このカプセル化では、ＣＮ１２１は、ＭＮ１０１のＮＣｏＡをあて先アドレスとするパケットに、あて先アドレスがＱＮＥ（プロキシ）１２３のアドレスに設定されたアウタヘッダを付加したパケットを生成して送信する。カプセル化されたデータパケットは、そのあて先アドレスがＱＮＥ（プロキシ）１２３であり、経路１２９上の各ＱＮＥでは、ｆｉｌｔｅｒＥのフィルタ情報に係るＱｏＳ処理が行われ、その結果、ＱｏＳ保証を受けることになる。

ステップＳ３２３でＲＥＳＥＲＶＥメッセージを送信した後、ＱＮＥ（プロキシ）１２３は、受信者始動ＲＥＳＥＲＶＥメッセージ（図９では、ＲＥＳＥＲＶＥ（ａｄｄ）と記載）をＣＮ１２１に送信する（ステップＳ３２５）。この予約におけるフィルタ情報には、あて先アドレスとしてＭＮ１０１のＩＰアドレスが含まれている。そして、各ＱＮＥ（ＱＮＥ１２５、１１５、１１７、１１９）を経由してＲＥＳＥＲＶＥメッセージは伝送されるとともに（ステップＳ３２７、Ｓ３２９、Ｓ３３１、Ｓ３３３）、各ＱＮＥにおいて、このＲＥＳＥＲＶＥメッセージに含まれるフィルタ情報（図８のｆｉｌｔｅｒＦ）が、以前に付加又は生成されたフィルタ情報（図７のｆｉｌｔｅｒＥ）に付加される。以上の動作により、各ＱＮＥには、図８に図示されているリソース予約情報が設定される。そして、ＣＮ１２１は、このＲＥＳＥＲＶＥメッセージを受信した場合に、データパケットのカプセル化を終了する（ステップＳ３３５）。

そして、ＣＮ１２１は、ステップＳ３０５〜Ｓ３１３で導入されたＱＮＥ（プロキシ）１２３をあて先アドレスとするフィルタ情報（図７のｆｉｌｔｅｒＥ）を削除するために、送信者主導のＲＥＳＥＲＶＥメッセージ（図９ではＲＥＳＥＲＶＥ（ｒｅｍｏｖｅ）と記載）をＱＮＥ（プロキシ）１２３に送信する（ステップＳ３３７、Ｓ３３９、Ｓ３４１、Ｓ３４３、Ｓ３４５）。なお、必ずしもＲＥＳＥＲＶＥメッセージによるフィルタ情報の削除を行う必要はなく、このフィルタ情報は、タイマのタイムアウトによって削除されてもよい。

以上、説明したように、本発明の第２の実施の形態によれば、ＱＮＥ（プロキシ）１２３が、ＭＮ１０１のサブネット１０７において割り当てられるＮＣｏＡを用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路（ＣＮ１２１からＭＮ１０１までの経路）の一部（ＣＮ１２１からＱＮＥ（プロキシ）１２３までの経路）に係るリソース予約を行い、ＣＮ１２１からＭＮ１０１までの完全な経路が確立されるまでは、ＱＮＥ（プロキシ）１２３が確立した経路及びＱｏＳステートによってデータパケットが行われることで、ＭＮ１０１がサブネット１０３からサブネット１０７に接続を変更した場合において、ＣＮ１２１からＭＮ１０１に送られるデータパケットのＱｏＳ保証の中断時間を低減することが可能となる。

＜第３の実施の形態＞
次に、本発明の第３の実施の形態について説明する。上述の説明ではフィルタ情報（ｆｉｌｔｅｒ）及びフローＩＤに明確な違いがなされていないが、以下、それぞれを明確に定義した場合の各ＱＮＥの機能や、シグナリングメッセージの処理などについて説明する。

まず、本発明の第３の実施の形態におけるフィルタ情報について説明する。本発明の第３の実施の形態では、フィルタ情報を、各ＱＮＥがパケットクラシファイア（ｐａｃｋｅｔｃｌａｓｓｉｆｉｅｒ）として使用する情報として定義する。フィルタ情報は、ＲＳＶＰにおけるフィルタスペック（ｆｉｌｔｅｒｓｐｅｃ）と同様に、ＱｏＳ予約を行うためのシグナリングメッセージのパラメータとして各ＱＮＥに運ばれる。すなわち、ＮＳＩＳでは、フィルタ情報は、主にＮＳＬＰにて生成され、管理される情報となる。各ＱＮＥは、このフィルタ情報を、要求されているＱｏＳリソースの情報と共に格納することにより、どのデータパケットに対して予約されたＱｏＳリソースを与えるかの区別を行う。そのため、フィルタ情報には、予約されたＱｏＳの保証を受けるデータパケットのヘッダ情報が含まれる。すなわち、フィルタ情報に含まれる情報の例としては、ＲＳＶＰにおけるフィルタスペックと同様に、送信元・あて先ＩＰアドレスや、プロトコル識別子、ポート番号、フローラベル（ＩＰｖ６の場合）、ＳＰＩ（ＳｅｃｕｒｉｔｙＰａｒａｍｅｔｅｒｓＩｎｄｅｘ）（ＩＰＳｅｃでカプセル化されている場合）、ＤＳＣＰ／ＴＯＳ（ＤｉｆｆｅｒｅｎｔｉａｔｅｄＳｅｒｖｉｃｅｓＣｏｄｅＰｏｉｎｔ／ＴｙｐｅｏｆＳｅｒｖｉｃｅ）フィールドなどである。

また、フィルタ情報は、１つのＱｏＳ予約に対してフィルタリスト（ｆｉｌｔｅｒ−ｌｉｓｔ）の形を取ってもよい。この場合、１つのＱｏＳ予約に対して、ＱＮＥは、フィルタリスト内のどのフィルタ情報と同じ内容のヘッダを持つデータパケットを受けた場合でも、予約されているリソースを与えることが可能となる。

フィルタリストは、このリストがどのフローやセッションに属するものかを表す識別子（例えば、フローＩＤや、セッションＩＤなど）と共に管理されてもよい。また、同一セッションに属するデータパケットが異なる性質を持つ複数の経路（例えば、モバイルＩＰにおける三角経路と最適化経路や、マルチホーム端末を使った通信における複数の経路など）を用いて送受信される場合には、フローＩＤやセッションＩＤのほかに、これらの複数の経路の種別を識別する識別子（例えば、ＰａｔｈＴｙｐｅＩＤ（非特許文献１２参照）など）と共に管理されてもよい。

以下に、フィルタリストの管理方法の一例について説明する。ＱｏＳ予約を行うためのシグナリングメッセージ（例えば、ＮＳＩＳのＲＥＳＥＲＶＥメッセージなど）により運ばれるフィルタリストの与え方の例として、
Ｆｉｌｔｅｒ−Ｌｉｓｔ：：＝〈ＬｉｓｔＬｅｎｇｔｈ〉〈Ａｃｔｉｏｎ〉〈Ｆｉｌｔｅｒ〉〈Ｆｉｌｔｅｒ〉・・・；
などが考えられる。ここで、フィルタリストは、〈ＬｉｓｔＬｅｎｇｔｈ〉、〈Ａｃｔｉｏｎ〉、及び複数のフィルタ情報（〈Ｆｉｌｔｅｒ〉）を有している。なお、〈ＬｉｓｔＬｅｎｇｔｈ〉では、フィルタリストに含まれるフィルタ情報の個数（すなわち、〈Ｆｉｌｔｅｒ〉の個数）が示される。また、〈Ａｃｔｉｏｎ〉では、各ＱＮＥでこのフィルタリストをどのように扱うかを指定する情報が示される。例えば、〈Ａｃｔｉｏｎ〉に含まれる情報としては、「追加（ａｄｄ）」、「削除（ｓｕｂ）」、「置き換え（Ｒｅｐｌａｃｅ）」などが考えられる。例えば、〈Ａｃｔｉｏｎ〉が「追加（Ａｄｄ）」の場合には、そのＱＮＥ上に同一セッションＩＤ及びＰａｔｈＴｙｐｅＩＤ（存在する場合）に対応する既存のフィルタリストが存在する場合には、そのリストに後続のフィルタ情報〈Ｆｉｌｔｅｒ〉が追加され、存在しない場合には、新たにフィルタリストが作られ、それに対応するリソースが予約される。また、例えば、〈Ａｃｔｉｏｎ〉が「削除（ｓｕｂ）」の場合には、同一セッションＩＤ及びＰａｔｈＴｙｐｅＩＤ（存在する場合）に対応する既存のフィルタリストから、後続のフィルタ情報〈Ｆｉｌｔｅｒ〉だけが削除される。また、例えば、〈Ａｃｔｉｏｎ〉が「置き換え（Ｒｅｐｌａｃｅ）」の場合には、ＱＮＥ上の同一セッションＩＤ及びＰａｔｈＴｙｐｅＩＤ（存在する場合）に対応する既存のフィルタリストそのものが置き換えられる。

また、例えば、
Ｆｉｌｔｅｒ−Ｌｉｓｔ：：＝〈ＬｉｓｔＬｅｎｇｔｈ〉〈Ａｃｔｉｏｎ〉〈Ｆｉｌｔｅｒ〉〈Ｆｉｌｔｅｒ〉・・・〈ＬｉｓｔＬｅｎｇｔｈ〉〈Ａｃｔｉｏｎ〉〈Ｆｉｌｔｅｒ〉〈Ｆｉｌｔｅｒ〉・・・；
という形式を取ることにより、１つのフィルタリストによって、フィルタ情報に係る複数の変更動作を一度に行えるようにすることも可能である。例えば、あるＱＮＥが、セッションＩＤ“３００”、ＰａｔｈＴｙｐｅＩＤ“０ｘ００”に対し、３つのフィルタ情報（〈ｆｉｌｔｅｒ１〉、〈ｆｉｌｔｅｒ２〉、〈ｆｉｌｔｅｒ３〉）を含むフィルタリスト
Ｆｉｌｔｅｒ−ｌｉｓｔ：＝〈ｆｉｌｔｅｒ１〉〈ｆｉｌｔｅｒ２〉〈ｆｉｌｔｅｒ３〉；
を格納していた場合、同一セッションＩＤ及びＰａｔｈＴｙｐｅＩＤを持つＲＥＳＥＲＶＥメッセージを受信し、その中に含まれるフィルタ情報が
Ｆｉｌｔｅｒ−Ｌｉｓｔ：：＝〈２〉〈ａｄｄ〉〈Ｆｉｌｔｅｒ４〉〈Ｆｉｌｔｅｒ５〉〈１〉〈ｓｕｂ〉〈Ｆｉｌｔｅｒ１〉；
であった場合には、このＱＮＥに格納されるフィルタリストは、
Ｆｉｌｔｅｒ−ｌｉｓｔ：＝〈Ｆｉｌｔｅｒ２〉〈Ｆｉｌｔｅｒ３〉〈Ｆｉｌｔｅｒ４〉〈Ｆｉｌｔｅｒ５〉；
に更新される。なお、上記のフィルタリストの形式は一例であり、ＱｏＳ予約を行うためのシグナリングメッセージにおいて、フィルタ情報及びそのフィルタ情報に対して行う処理（ａｃｔｉｏｎ）の情報が明確にできるのであれば、他の形式を取ることや、他の情報を持つことも可能である。

次に、本発明の第３の実施の形態におけるフローＩＤについて説明する。本発明の第３の実施の形態では、フローＩＤは、主にＮＳＩＳの下位層であるＮＴＬＰで管理され、ＮＴＬＰにおいて、シグナリングメッセージがどのフローに属するかを識別するために使われる。フローＩＤとセッションＩＤとの違いは、セッションＩＤはセッションの開始から終了まで変化しないＩＤであるのに対し、フローＩＤは、例えば端末の移動などによる経路変更により、変化してもよいという点にある。また、１つのセッションに対し、複数のフローＩＤが存在してもよい。なお、本発明の第３の実施の形態におけるフローＩＤは、非特許文献１１Ａでは、ＭＲＩ（ＭｅｓｓａｇｅＲｏｕｔｉｎｇＩｎｆｏｒｍａｔｉｏｎ）として位置付けられているものであるが、含まれる情報はこの通りではない。本発明の第３の実施の形態におけるフローＩＤの一例としては、シグナリングメッセージの送信元とあて先のＩＰアドレスを含む情報が考えられる。なお、この場合、本発明の第３の実施の形態におけるフローＩＤには、非特許文献１１Ａで記されているフローＩＤのように必ずしもプロトコル識別子、ポート番号などのフィルタ情報が持つ情報が含まれる必要はない。また、データの送信元・あて先と、シグナリングメッセージの送信元・あて先が異なる場合や、送信元・あて先が同じであっても、ポート番号など他のフィルタ情報が異なる場合で、シグナリングメッセージもデータパケットと同様にＱｏＳ保証を必要とする場合は、シグナリングメッセージのフィルタ情報を、フィルタリストに追加すればよい。

また、図１７は、本発明の第３の実施の形態において、ＱＮＥ内でフィルタ情報及びフローＩＤを管理する主体を模式的に示す図である。上述のように、ＮＳＩＳプロトコル層では、フィルタ情報及びフローＩＤの２つの情報が管理されるが、フィルタ情報（フィルタリスト）は、主にＮＳＩＳの上位層であるＮＳＬＰ層において管理され、フローＩＤは、主にＮＳＩＳの下位層であるＮＴＬＰ層において管理される。なお、フィルタ情報やフローＩＤの管理や生成に関しては、必ずしも、図１７に示されているようにＮＳＬＰ層やＮＴＬＰ層が単独で行う必要はなく、ＮＳＬＰ層とＮＴＬＰ層の間で情報の交換を行ったり、他の層と情報を交換したりすることにより管理・生成が行われてもよい。

このように、ＮＳＩＳプロトコル層において管理される情報を、フィルタ情報及びフローＩＤに明確に分けて定義を行うことにより、各ＱＮＥはデータパケットの送受信を行う端末の情報（例えば、データの送信元・あて先に設定されるＩＰアドレス）を必要とすることなく、シグナリングメッセージを送信することが可能になる。この特性を用いたＱｏＳ経路の早期確立方法を以下に説明する。

なお、ここでは、データパケットの送信される方向がｕｐｌｉｎｋ方向であった場合を例に挙げて説明を行うが、データパケットの送信される方向がｄｏｗｎｌｉｎｋ方向であった場合にも同様の手順を用いることができる。

まず、図１２〜１４を参照しながら、本発明の第３の実施の形態に係る概要について説明する。図１２は、本発明の第３の実施の形態における通信システムで、ＭＮが接続するサブセットを変更する前のＱｏＳ予約の状態及びルーティングのためのステート内に含まれるフローＩＤの状態を模式的に示す図である。また、図１３は、本発明の第３の実施の形態における通信システムで、ＭＮのプロキシとなるＱＮＥがＭＮ用に予測経路上にルーティングのためのステートを確立した状態を、この中に含まれるフローＩＤを示すことにより模式的に示す図である。また、図１４は、本発明の第３の実施の形態における通信システムで、ＭＮがサブセットを移動し、ＭＮとＣＮとの間で新たなＱｏＳ経路が確立された状態を模式的に示す図である。

図１２〜１４には、図１〜３と同様に、無線通信によりＡＲに接続してＣＮ１２１との通信を行うＭＮ１０１と、ＭＮ１０１の通信相手となるＣＮ１２１と、サブネット１０３を形成するＡＲ１０５と、サブネット１０７を形成するＡＲ１０９と、ＭＮ１０１とＣＮ１２１との間における経路上に存在し、ＭＮ１０１とＣＮ１２１との間で伝送されるパケットに関してＱｏＳ保証を行うＱｏＳ認識機能（ＱｏＳ−ａｗａｒｅ）を有するＱＮＥ１１１、１１３、１１５、１１７、１１９、１２３、１２５とが図示されている。

なお、ＭＮ１０１がサブネット１０３に存在している場合（すなわち、ＭＮ１０１がＡＲ１０５に接続している場合）、ＭＮ１０１からＣＮ１２１へのｕｐｌｉｎｋ方向の経路１４７上には、ＡＲ１０５、ＱＮＥ１１１、ＱＮＥ１１３、ＱＮＥ１１５、ＱＮＥ１１７、ＱＮＥ１１９が存在しており、ＭＮ１０１がサブネット１０７に存在している場合（すなわち、ＭＮ１０１がＡＲ１０９に接続している場合）、ＭＮ１０１からＣＮ１２１へのｕｐｌｉｎｋ方向の経路１４９上には、ＡＲ１０９、ＱＮＥ１２３、ＱＮＥ１２５、ＱＮＥ１１５、ＱＮＥ１１７、ＱＮＥ１１９が存在しているものとする。なお、経路１４７と経路１４９とは一部が重複しており、経路１４７と経路１４９とのＣＲＮをＱＮＥ１１５とする。

図１２において、ＭＮ１０１からＣＮ１２１に送信されるデータパケットは、経路１４７を経由して伝送される。このとき、経路１４７上のすべてのＱＮＥ１１１、１１３、１１５、１１７、１１９は、ＭＮ１０１からＣＮ１２１に送信されるデータパケットに関するＱｏＳ予約に係るステートを有している。すなわち、各ＱＮＥ１１１、１１３、１１５、１１７、１１９は、経路１４７を通して送られるデータパケットに関するフィルタ情報（ＣＮ１２１のＩＰアドレスがあて先アドレスとして含まれているとともに、ＭＮ１０１がサブネット１０３から割り当てられているＩＰアドレス（ｃＣｏＡ）が送信元アドレスとして含まれているフィルタ情報）であるｆｉｌｔｅｒＧを含むフィルタリストと、このフィルタリストに対応するリソース予約情報であるｒｅｓｏｕｒｃｅＧとが関連付けられているＱｏＳ予約に係るステートを保持しており、ＣＮ１２１からＭＮ１０１に送信されるデータパケットのヘッダを参照してフィルタ情報（ｆｉｌｔｅｒＧ）を特定し、対応するリソース予約情報（ｒｅｓｏｕｒｃｅＧ）に基づくＱｏＳ保証を行うように構成されている。

また同時に、各ＱＮＥ１１１、１１３、１１５、１１７、１１９のＮＴＬＰ層では、シグナリングメッセージの識別とルーティングのためのステート（ルーティングステートやメッセージアソシエーション（非特許文献１１Ａ参照））を保持している。このルーティングのためのステート内には、経路１４７におけるシグナリングメッセージの送信元及びあて先を含む情報から作られるフローＩＤが含まれる。今、シグナリングメッセージの送信元をＭＮ１０１（ｃＣｏＡをＸとする）、シグナリングメッセージのあて先をＣＮ１２１（ＩＰアドレスをＹとする）であるとし、各ＱＮＥ１１１、１１３、１１５、１１７、１１９のＮＴＬＰ層がルーティングのためのステートの中に持つフローＩＤを、ｆｌｏｗＸＹとする。

ＭＮ１０１は、サブネット１０７に移動する可能性があり、ＱＮＥ（プロキシ）１２３に対して予測経路（経路１４９）の一部の確立の準備（すなわち、ＱＮＥ（プロキシ）１２３からＣＮ１２１の確立の準備）を所望している。すなわち、ＭＮ１０１は、この経路上の各ＱＮＥに対して、サブネット１０７に移動した後のルーティングのためのステートをあらかじめ保有しておくことを所望している。なお、ＭＮ１０１がサブネット１０７に移動する前に、ＱＮＥ（プロキシ）１２３によって予測経路の一部が準備されることで、ＭＮ１０１が実際にサブネット１０７に移動した後に、より迅速にＣＮ１２１からＭＮ１０１へのＱｏＳ経路が確立され、ハンドオーバによるＱｏＳ保証の中断時間を短縮することが可能となる。その理由は、ルーティングのためのステートの新規確立には複雑な処理が必要になるが、このルーティングのためのステートはいったん確立されてしまえば、このステートを用いてシグナリングメッセージをルーティングすることができるからである。

ＱＮＥ（プロキシ）１２３が予測経路の確立を準備するための何らかのトリガを受けた場合には、ＱＮＥ（プロキシ）１２３は、ＱＮＥ（プロキシ）１２３とＣＮ１２１との間のＱＮＥにおけるルーティングのためのステートの新規確立処理を始動し、その結果、ＱＮＥ（プロキシ）１２３とＣＮ１２１との間のＱＮＥにルーティングのためのステートが保有される。すなわち、図１３に図示されているように、ＱＮＥ（プロキシ）１２３、ＱＮＥ１２５、１１５、１１７、１１９のＮＴＬＰ層では、ＱＮＥ（プロキシ）１２３のＩＰアドレス（Ｚとする）が送信元アドレスとして含まれているとともに、ＣＮ１２１のＩＰアドレス（すなわちＹ）があて先アドレスとして含まれているフローＩＤ（ｆｌｏｗＺＹ）を含むルーティングのためのステートが設定される。なお、経路１４７に関するルーティングのためのステートはそのまま残される。

以上のように、ＭＮ１０１がサブネット１０７への移動を行う前に（あるいは、ＭＮ１０１のサブネット１０７への移動とは無関係に）、ＱＮＥ（プロキシ）１２３は、ＭＮ１０１のＮＣｏＡ（ＭＮ１０１がサブネット１０７に移動した後に割り当てられる新たなＣｏＡ）を用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路の一部（ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路）に係るルーティングのためのステートを確立することが可能である（図１３に図示されている状態）。

そして、ＭＮ１０１がＮＣｏＡを取得した場合（実際にサブネット１０７に移動してＮＣｏＡを取得するか、あるいはサブネット１０３に接続した状態でＮＣｏＡを取得した場合）には、このＭＮ１０１のＮＣｏＡをデータパケットの送信元、ＣＮ１２１のＩＰアドレスをデータパケットのあて先としたフィルタ情報（ｆｉｌｔｅｒＨ）が作成される。そして、図１４に図示されているように、経路１４９上のＱＮＥ（プロキシ）１２３、ＱＮＥ１２５においてはｆｉｌｔｅｒＨを含むフィルタリストが新規で格納されるとともに、ＱＮＥ１１５、１１７、１１９においては、ｆｉｌｔｅｒＨが既存の（同一セッション用の）フィルタリストに追加される。

また、ＭＮ１０１がサブネット１０７に移動した場合には、ＭＮ１０１からＱＮＥ（プロキシ）１２３の間のルーティングのためのステートを確立することにより、ＭＮ１０１からＣＮ１２１までのエンド・ツー・エンドのルーティングのためのステートが確立される。ＭＮ１０１からＱＮＥ（プロキシ）１２３の間のルーティングのためのステートで使われるフローＩＤは、ＱＮＥ（プロキシ）１２３からＣＮ１２１で使われているもの（ｆｌｏｗＺＹ）とは異なり、ＭＮ１０１がサブネット１０７で取得したＮＣｏＡ（Ｗとする）をシグナリングメッセージの送信元、ＱＮＥ（プロキシ）１２３のＩＰアドレス（すなわちＺ）をシグナリングメッセージのあて先としたフローＩＤ（ｆｌｏｗＷＺ）であってよい。また、エンド・ツー・エンドのフローＩＤを統一するため、ＭＮ１０１からＱＮＥ（プロキシ）１２３の間のルーティングのためのステートで使われるフローＩＤは、ＱＮＥ（プロキシ）１２３からＣＮ１２１で使われているもの（ｆｌｏｗＺＹ）であってもよい。

なお、ＭＮ１０１からＱＮＥ（プロキシ）１２３の間のフローＩＤが、ＱＮＥ（プロキシ１２３）からＣＮ１２１で使われているものと異なる場合、ＱＮＥ（プロキシ）１２３において、サブネット１０７上のＭＮ１０１から送信されるシグナリングメッセージに付加されているフローＩＤ（ｆｌｏｗＷＺ）をｆｌｏｗＺＹに付け替えて、ＣＮ１２１に向けて送信するなどの動作が必要である。また、上述のように、経路１４９上に既にシグナリングメッセージのルーティングのためのステートが存在するため、ＱｏＳリソース予約のための動作は、ＱＮＥ（プロキシ）１２３より先では、経路１４９上に新規でＱｏＳ予約のためのシグナリングメッセージを送る場合に比べて迅速に行われ、その結果、ＭＮ１０１のＮＣｏＡを用いてＱｏＳリソース予約が行われるまでのＱｏＳ保証の中断時間を低減することが可能となる。また、ＭＮ１０１がサブネット１０７に移動した後に、移動前に使用されていたフィルタ情報（ｆｉｌｔｅｒＧ）や、経路１４７のルーティングのためのステートに関しては、能動的又は受動的に削除されることが望ましい。

次に、本発明の第３の実施の形態における第１動作例について説明する。図１５は、本発明の第３の実施の形態において、データパケットの送信方向がｕｐｌｉｎｋ方向の場合の動作例を示すシーケンスチャートである。なお、ここでは具体例として、各ＱＮＥにおいてルーティングのためのステートを作るために送信される、フィルタ情報を必要としないメッセージとして、ＮＳＩＳのＱｏＳＮＳＬＰで定義されているメッセージであるＱＵＥＲＹメッセージに、さらに本発明の動作に必要な情報を付加した場合について説明する。また、ＱｏＳリソースを予約するためのメッセージとして、ＮＳＩＳのＱｏＳＮＳＬＰで定義されているメッセージであるＲＥＳＥＲＶＥメッセージに、さらに本発明の動作に必要な情報を付加した場合について説明する。なお、本発明の第３の実施の形態で使用される「ＲＥＳＥＲＶＥメッセージ」や「ＱＵＥＲＹメッセージ」、「ＲＥＳＰＯＮＳＥメッセージ」という用語は、ＮＳＬＰ層で生成される情報（メッセージのペイロード部と呼ぶ）、ＮＴＬＰ層で生成される情報（ヘッダ部と呼ぶ）及びＩＰヘッダ（オプション部分を含む）を含んでいる。

図１５において、まず、ＱＮＥ（プロキシ）１２３は、予測経路を準備するためのトリガを受ける（ステップＳ４０１）。なお、このトリガには、例えば、ＭＮ１０１とＣＮ１２１との間のＱｏＳ経路で用いられているセッションＩＤ、ＣＮ１２１（又は経路の最終ＱＮＥであるＱＮＲ）のＩＰアドレスなど、予測経路を確立するために必要な情報が含まれている。

トリガを受け取ったＱＮＥ（プロキシ）１２３は、このトリガに応じて、即座に、ＮＳＬＰ層においてＱＵＥＲＹメッセージのペイロード部を生成し、ＮＴＬＰ層に受け渡す。ＮＴＬＰ層ではこれを受けて、自身をシグナリングメッセージの送信元、ＣＮ１２１をあて先としたフローＩＤを生成し（ステップＳ４０３）、このフローＩＤをヘッダ部に含むＱＵＥＲＹメッセージを、下位層を経由してＣＮ１２１に向けて送信する（ステップＳ４０５）。なお、このＱＵＥＲＹメッセージは、経路１４９における新規のｄｏｗｎｓｔｒｅａｍ方向（データ送信方向と同じ方向）へのメッセージであるので、このＱＵＥＲＹメッセージのＩＰヘッダにはＱＮＥ用のＲＡＯが付けられる。

ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路上のすべてのＱＮＥ（ＱＮＥ１２５、１１５、１１７、１１９）は、ＱＵＥＲＹメッセージを受信してＩＰヘッダにＲＡＯを発見すると、ＮＳＩＳ層（ＮＳＬＰ層及びＮＴＬＰ層）においてＱＵＥＲＹメッセージの中身を確認して、必要な処理を行う。すなわち、ＱＵＥＲＹメッセージを受信したＱＮＥ１２５、１１５、１１７、１１９は、ＱｏＳＮＳＬＰ層におけるＱＵＥＲＹ処理以外に、ＮＴＬＰ層においてルーティングのためのステートの確立処理（ルーティングステートや、メッセージアソシエーション（要求されている場合）の確立のための処理）を行う（ステップＳ４０７、Ｓ４１１、Ｓ４１５、Ｓ４１９、Ｓ４２３）。その後、各ＱＮＥはＱＵＥＲＹメッセージをＣＮ１２１に向けて送信する（ステップＳ４０９、Ｓ４１３、Ｓ４１７、Ｓ４２１）。そして、ＱＵＥＲＹメッセージがＣＮ１２１に到達すると、このＱＵＥＲＹメッセージに対するＲＥＳＰＯＮＳＥメッセージがＣＮ１２１からＱＮＥ１２３に返される（ステップＳ４２５、Ｓ４２７、Ｓ４２９、Ｓ４３１、Ｓ４３３）。

ここで、ＭＮ１０１がサブネット１０７に移動したとする（ステップＳ４３５）。ＭＮ１０１は、サブネット１０７よりＮＣｏＡを取得すると、ＮＴＬＰ層において、このＮＣｏＡをシグナリングメッセージの送信元、ＱＮＥ（プロキシ）１２３をシグナリングメッセージのあて先としたフローＩＤを生成する（ステップＳ４３７）。また、ＭＮ１０１のＮＳＬＰ層では、自身のＮＣｏＡをデータパケットの送信元、ＣＮ１２１のＩＰアドレスをデータパケットのあて先とした情報を含むフィルタ情報を生成し、このフィルタ情報を追加（ａｄｄ）してＱｏＳリソースを予約するような送信者主導のＲＥＳＥＲＶＥメッセージ（図１５ではＲＥＳＥＲＶＥ（ａｄｄ）と記載）をＱＮＥ（プロキシ）１２３に向けて送信する（ステップＳ４３９）。このＲＥＳＥＲＶＥメッセージは、経路１４９におけるＭＮ１０１からＱＮＥ（プロキシ）１２３に対する新規のｄｏｗｎｓｔｒｅａｍ方向（データ送信方向と同じ方向）へのメッセージであるので、このＲＥＳＥＲＶＥメッセージのＩＰヘッダにはＱＮＥ用のＲＡＯが付けられる。

このＲＥＳＥＲＶＥメッセージを受け取ったＱＮＥ（プロキシ）１２３は、ＮＴＬＰにおいてルーティングのためのステートの確立処理を行う（ステップＳ４４１）とともに、ＮＳＬＰにおいてリソース予約のための処理を行う。また、ＮＴＬＰ層ではセッションＩＤなどの情報から、このＲＥＳＥＲＶＥメッセージをＣＮ１２１に送信する必要があることを認識し、このＲＥＳＥＲＶＥメッセージに含まれるフローＩＤの情報を、ステップＳ４０３で生成されたフローＩＤに変更し、ＣＮ１２１に向けて送信する（ステップＳ４４３）。この際、ＮＴＬＰは、メッセージをＣＮ１２１に向けて送信する必要があるということを、ＮＳＬＰに伝えてもよい。なお、この場合、ルーティングのためのステートは、ＱＮＥ１２３、１２５、１１５、１１７、１１９に既に確立されているので、ＲＥＳＥＲＶＥメッセージにＲＡＯが付加される必要はなく、ＱＮＥ１２３、１２５、１１５、１１７、１１９は、受信したＲＥＳＥＲＶＥメッセージを参照してリソース予約のための処理を行い、迅速にＲＥＳＥＲＶＥメッセージを送信することができる（ステップＳ４４５、Ｓ４４７、Ｓ４４９、Ｓ４５１）。なお、ＭＮ１０１と、ＱＮＥ（プロキシ）１２３との間で使われるフローＩＤは、ＱＮＥ（プロキシ）１２３とＣＮ１２１の間で使われるフローＩＤと同じであってもよい。

次に、本発明の第３の実施の形態の第２動作例について説明する。上述の本発明の第３の実施の形態における第１動作例では、データパケットの送信方向がｕｐｌｉｎｋ方向の場合について説明したが、データパケットの送信方向がｄｏｗｎｌｉｎｋ方向であった場合においても、同様の手順を採ることができる。これについて、図１６を参照しながら説明する。図１６は、本発明の第３の実施の形態において、データパケットの送信方向がｄｏｗｎｌｉｎｋ方向の場合の動作例を示すシーケンスチャートである。

ＱＮＥ（プロキシ）１２３は、予測経路を準備するためのトリガを受け取ると（ステップＳ５０１）、ＣＮ１２１に対して、予測経路準備を依頼する依頼メッセージを送信する（ステップＳ５０３）。なお、予測経路を準備するためのトリガは、ＱＮＥ（プロキシ）１２３ではなく、ＣＮ１２１に直接送られてもよい。この場合、トリガには、ＱＮＥ（プロキシ）１２３のＩＰアドレスなどの情報も含まれている必要がある。

依頼メッセージ又はトリガを受信したＣＮ１２１は、この依頼メッセージ又はトリガに応じて、即座に、ＮＳＬＰ層においてＱＵＥＲＹメッセージのペイロード部を生成し、ＮＴＬＰ層に受け渡す。ＮＴＬＰ層ではこれを受けて、自身をシグナリングメッセージの送信元、ＱＮＥ（プロキシ）１２３をあて先としたフローＩＤを生成し（ステップＳ５０５）、このフローＩＤをヘッダ部に含むＱＵＥＲＹメッセージを、下位層を経由してＱＮＥ（プロキシ）１２３に向けて送信する（ステップＳ５０７）。なお、このＱＵＥＲＹメッセージは、経路１４９における新規のｄｏｗｎｓｔｒｅａｍ方向（データ送信方向と同じ方向）へのメッセージであるので、このＱＵＥＲＹメッセージのＩＰヘッダにはＱＮＥ用のＲＡＯが付けられる。

ＣＮ１２１からＱＮＥ（プロキシ）１２３までの経路上のすべてのＱＮＥ（ＱＮＥ１１９、１１７、１１５、１２５）は、ＱＵＥＲＹメッセージを受信してＩＰヘッダにＲＡＯを発見すると、ＮＳＩＳ層（ＮＳＬＰ層及びＮＴＬＰ層）においてＱＵＥＲＹメッセージの中身を確認して、必要な処理を行う。すなわち、ＱＵＥＲＹメッセージを受信したＱＮＥ１１９、１１７、１１５、１２５は、ＱｏＳＮＳＬＰ層におけるＱＵＥＲＹ処理以外に、ＮＴＬＰ層においてルーティングステートのためのステート確立処理を行う（ステップＳ５０９、Ｓ５１３、Ｓ５１７、Ｓ５２１、Ｓ５２５）。その後、各ＱＮＥは、ＱＵＥＲＹメッセージをＱＮＥ（プロキシ）１２３に向けて送信する（ステップＳ５１１、Ｓ５１５、Ｓ５１９、Ｓ５２３）。

ここで、ＭＮ１０１がサブネット１０７に移動したとする（ステップＳ５２７）。ＱＮＥ（プロキシ）１２３は、ＭＮ１０１の移動を検出し、ＭＮ１０１がサブネット１０７より取得したＮＣｏＡ情報を取得すると、ＮＴＬＰ層において自身のＩＰアドレスをシグナリングメッセージの送信元、ＭＮ１０１のＮＣｏＡをシグナリングメッセージのあて先としたフローＩＤを生成する（ステップＳ５２９）。また、ＱＮＥ（プロキシ）１２３のＮＳＬＰ層は、ＣＮ１２１のＩＰアドレスをデータパケットの送信元、ＭＮ１０１のＮＣｏＡをデータパケットのあて先とした情報を含むフィルタ情報を生成し、このフィルタ情報を追加（ａｄｄ）してＱｏＳリソースを予約するような送信者主導のＲＥＳＥＲＶＥメッセージ（図１６ではＲＥＳＥＲＶＥ（ａｄｄ）と記載）をＭＮ１０１に向けて送信する（ステップＳ５３１）とともに、ＮＴＬＰ層ではＭＮ１０１に転送するデータパケットに対するルーティングのためのステートの確立処理を行う（ステップＳ５３３）。

また、ＱＮＥ（プロキシ）１２３は、受信者主導のＲＥＳＥＲＶＥメッセージ（図１６ではＲＥＳＥＲＶＥ（ａｄｄ）と記載）をＣＮ１２１に向けて送信する（ステップＳ５３５）。なお、ＭＮ１０１に送信されるＲＥＳＥＲＶＥメッセージは、経路１４９におけるＱＮＥ（プロキシ）１２３からＭＮ１０１に対する新規のｄｏｗｎｓｔｒｅａｍ方向（データ送信方向と同じ方向）へのメッセージであるので、このＲＥＳＥＲＶＥメッセージにはＱＮＥ用のＲＡＯが付けられる。しかしながら、ＣＮ１２１に送信されるＲＥＳＥＲＶＥメッセージに関しては、ルーティングのためのステートがＱＮＥ１２３、１２５、１１５、１１７、１１９に既に確立されているので、このＲＥＳＥＲＶＥメッセージにＲＡＯが付加される必要はなく、ＱＮＥ１２５、１１５、１１７、１１９は、受信したＲＥＳＥＲＶＥメッセージを参照してリソース予約のための処理を行い、迅速にＲＥＳＥＲＶＥメッセージを送信することができる（ステップＳ５３７、Ｓ５３９、Ｓ５４１、Ｓ５４３、Ｓ５４５）。なお、ＱＮＥ（プロキシ）１２３とＭＮ１０１の間で使われるフローＩＤは、ＱＮＥ（プロキシ）１２３とＣＮ１２１の間で使われるフローＩＤと同じであってもよい。

以上、説明したように、本発明の第３の実施の形態における第１及び第２動作例によれば、ＱＮＥ（プロキシ）１２３が、ＭＮ１０１のサブネット１０７において割り当てられるＮＣｏＡを用いることなく、ＭＮ１０１がサブネット１０７に接続した後に使用される経路（ＭＮ１０１からＣＮ１２１までの経路）の一部（例えば、ＱＮＥ（プロキシ）１２３とＣＮ１２１との間の経路）に係るＱｏＳ予約の準備（特に、ルーティングのためのステートの確立処理）を行うことにより、ＭＮ１０１がサブネット１０３から１０７に接続を変更した場合において、ＣＮ１２１からＭＮ１０１に送られるデータパケットのＱｏＳ保証の中断時間を低減することができる。

また、上述のように、フローＩＤ及びフィルタリストを定義することにより、ＭＮのハンドオーバのケースに限らず、ＱｏＳ経路を容易に管理することができるようになる。

例えば、ＭＮが、１つのセッションに対し複数のＩＰアドレスを用いてＣＮと通信している場合（ＭＮがマルチホーム状態の場合）で、どのＩＰアドレスも同一のサブネット配下のものであった場合を考える。この場合、どのＩＰアドレスが設定されたデータパケットであっても、データパケットが通過する経路は１つなので、各ＱＮＥにおけるＮＴＬＰ層では、ＭＮが持つ複数のＩＰアドレスのうちの１つをフローＩＤのあて先（又は送信元）アドレスとして採用すればよい。なお、パケットクラシファイアとして利用されるフィルタリストは、上述のように複数のフィルタ情報に対応しているので、ＭＮが有する複数のＩＰアドレスのすべてを容易に保持することが可能である。

また、ＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）を用いたデータのダウンロードなどでは、ダウンロードのスピードを上げるために、クライアントは一度に複数のポートを用いることがある。この場合でも、上述のＭＮが複数のＩＰアドレスを持つ場合と同様に、複数のポート番号のうちの１つをフローＩＤに採用すればよい。なお、フローＩＤが完全にＩＰアドレスの情報のみで作られるような場合には、ＮＴＬＰにおいて、ポート番号を管理する必要はなくなる。また、上述のＭＮが複数のＩＰアドレスを持つ場合と同様に、パケットクラシファイアとして利用されるフィルタリストは、複数のフィルタ情報に対応しているので、複数のポート番号を容易に保持することが可能である。

また、さらに、Ｈ．３２３を用いてＶｏＩＰ（ＶｏｉｃｅｏｖｅｒＩＰ）用のセッションを張る場合には、この途中のプロセスにおいて、使用されるポート番号が変化する。しかしながら、この場合でも、上述のように、フローＩＤ及びフィルタリストを定義することによって、ＮＴＬＰ側ではポート番号の変化に合わせてフローＩＤの情報を変える必要はなくなり、一方、パケットクラシファイアとして利用されるフィルタリストでは、フィルタ情報の追加・削除が容易に行えるため、ポート番号の変化に柔軟に対応することが可能となる。

次に、本発明の第３の実施の形態の第３動作例について説明する。データ経路（ＭＮ１０１とＣＮ１２１とを結ぶ経路）上にＮＡＴＦＷが存在する場合においても、ＭＮ１０１のハンドオーバ時にＱｏＳ保証の中断時間を低減させるシームレスなＱｏＳ保証を提供することが望ましい。このとき、シームレスなＱｏＳ保証を提供するため、上述の本発明の第３の実施の形態の第１動作例（図１５を参照）や第２動作例（図１６を参照）と同様に、プロキシを利用して、ＮＴＬＰ層においてルーティングのためのステートの確立処理を先に行い、端末のハンドオーバ後にＱｏＳリソース予約を行うとともに、ＮＡＴＦＷのポリシールールの追加や書き換えを行うことが望ましい。

以下、データ経路上のＱＮＥ１１７がＮＡＴＦＷであることを想定して、上述の本発明の第３の実施の形態の第１動作例と同様に、ＭＮ１０１がサブネット１０３からサブネット１０７にハンドオーバを行う際に、ＱＮＥ（プロキシ）１２３が、ＭＮ１０１のサブネット１０７において割り当てられるＮＣｏＡを用いることなく、ＭＮ１０１のハンドオーバ後に使用される経路の一部に係るＱｏＳ予約の準備（特に、ルーティングのためのステートの確立処理）を行う動作について説明する。

図１８は、本発明の第３の実施の形態において、データ経路上にＮＡＴＦＷが存在しており、データパケットの送信方向がｕｐｌｉｎｋ方向の場合の動作例を示すシーケンスチャートである。なお、ここでは、ＱＮＥ１１７がＮＡＴＦＷ機能を持つものとし、ＱＮＥ１１９及びＣＮ１２１がプライベートアドレスを用いるＬＡＮ内に存在するものとする。また、ＭＮ１０１、ＱＮＥ１１７及びＣＮ１２１にはＮＡＴＦＷＮＳＬＰが実装されているものとする。さらに、ＮＡＴＦＷ（ＱＮＥ１１７）には、ＮＳＩＳシグナリングメッセージがこのＮＡＴＦＷを通過できるためのポリシールールが既に設定されているものとする。また、図１５に図示されている第１動作例と同様に、図１８に図示されているシーケンスにおいても、各ＱＮＥにおいてルーティングのためのステートを作るために送信されるメッセージの一例として、ＮＳＩＳのＱｏＳＮＳＬＰで定義されているＱＵＥＲＹメッセージを用いた場合を例に挙げて説明する。

図１８において、まず、ＱＮＥ（プロキシ）１２３は、予測経路を準備するためのトリガを受ける（ステップＳ６０１）。なお、このトリガには、例えば、ＭＮ１０１とＣＮ１２１との間のＱｏＳ経路で用いられているセッションＩＤ、ＣＮ１２１（又は経路の最終ＱＮＥであるＱＮＲ）のＩＰアドレスなど、予測経路を確立するために必要な情報が含まれている。

トリガを受け取ったＱＮＥ（プロキシ）１２３は、このトリガに応じて、即座に、ＮＳＬＰ層においてＱＵＥＲＹメッセージのペイロード部を生成し、ＮＴＬＰ層に受け渡す。ＮＴＬＰ層ではこれを受けて、自身をシグナリングメッセージの送信元、ＣＮ１２１をあて先としたフローＩＤを生成し（ステップＳ６０３）、このフローＩＤをヘッダ部に含むＱＵＥＲＹメッセージを、下位層を経由してＣＮ１２１に向けて送信する（ステップＳ６０５）。なお、このＱＵＥＲＹメッセージは、経路１４９における新規のｄｏｗｎｓｔｒｅａｍ方向（データ送信方向と同じ方向）へのメッセージであるので、このＱＵＥＲＹメッセージのＩＰヘッダにはＱＮＥ用のＲＡＯが付けられる。

ＱＮＥ（プロキシ）１２３からＣＮ１２１までの経路上のすべてのＱＮＥ（ＱＮＥ１２５、１１５、１１７、１１９）は、ＱＵＥＲＹメッセージを受信してＩＰヘッダにＲＡＯを発見すると、ＮＳＩＳ層（ＮＳＬＰ層及びＮＴＬＰ層）においてＱＵＥＲＹメッセージの中身を確認して、必要な処理を行う。すなわち、ＱＵＥＲＹメッセージを受信したＱＮＥ１２５、１１５、１１７、１１９は、ＱｏＳＮＳＬＰ層におけるＱＵＥＲＹ処理以外に、ＮＴＬＰ層においてルーティングのためのステートの確立処理（ルーティングステートや、メッセージアソシエーション（要求されている場合）の確立のための処理）を行う（ステップＳ６０７、Ｓ６１１、Ｓ６１５、Ｓ６１９、Ｓ６２３）。その後、各ＱＮＥはＱＵＥＲＹメッセージをＣＮ１２１に向けて送信する（ステップＳ６０９、Ｓ６１３、Ｓ６１７、Ｓ６２１）。そして、ＱＵＥＲＹメッセージがＣＮ１２１に到達すると、このＱＵＥＲＹメッセージに対するＲＥＳＰＯＮＳＥメッセージがＣＮ１２１からＱＮＥ１２３に返される（ステップＳ６２５、Ｓ６２７、Ｓ６２９、Ｓ６３１、Ｓ６３３）。

ここで、ＭＮ１０１がサブネット１０７に移動したとする（ステップＳ６３５）。ＭＮ１０１は、サブネット１０７よりＮＣｏＡを取得すると、ＮＴＬＰ層において、このＮＣｏＡをシグナリングメッセージの送信元、ＱＮＥ（プロキシ）１２３をシグナリングメッセージのあて先としたフローＩＤを生成する（ステップＳ６３７）。また、ＭＮ１０１のＮＳＬＰ層では、自身のＮＣｏＡをデータパケットの送信元、ＣＮ１２１のＩＰアドレスをデータパケットのあて先とした情報を含むフィルタ情報を生成する。また、ＮＡＴＦＷＮＳＬＰ層では、このフィルタ情報を持ったデータパケットがＮＡＴＦＷを通過するためのポリシールールを、ＮＡＴＦＷ（ＱＮＥ１１７）で作成できるようにするパラメータを持ったＣＲＥＡＴＥメッセージ（図１８では、ＣＲＥＡＴＥと記載）を作成する。また、ＱｏＳＮＳＬＰ層では、このフィルタ情報を追加（ａｄｄ）してＱｏＳリソースを予約するような送信者主導のＲＥＳＥＲＶＥメッセージ（図１８ではＲＥＳＥＲＶＥ（ａｄｄ）と記載）を作成する。そして、ＭＮ１０は、上記のＣＲＥＡＴＥメッセージとＲＥＳＥＲＶＥメッセージとを１つのメッセージ（ＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージ）にして、ＱＮＥ（プロキシ）１２３に向けて送信する（ステップＳ６３９）。なお、上記のＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージは、経路１４９におけるＭＮ１０１からＱＮＥ（プロキシ）１２３に対する新規のｄｏｗｎｓｔｒｅａｍ方向（データ送信方向と同じ方向）へのメッセージであるので、ＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージのＩＰヘッダにはＱＮＥ用のＲＡＯが付けられる。

このＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージを受け取ったＱＮＥ（プロキシ）１２３は、ＮＴＬＰにおいてルーティングのためのステートの確立処理を行う（ステップＳ６４１）とともに、ＮＳＬＰにおいてリソース予約のための処理を行う。また、ＮＴＬＰ層ではセッションＩＤなどの情報から、このＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージをＣＮ１２１に送信する必要があることを認識し、このＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージに含まれるフローＩＤの情報を、ステップＳ６０３で生成されたフローＩＤに変更し、ＣＮ１２１に向けて送信する（ステップＳ６４３）。この際、ＮＴＬＰは、メッセージをＣＮ１２１に向けて送信する必要があるということを、ＮＳＬＰに伝えてもよい。なお、この場合、ルーティングのためのステートは、ＱＮＥ１２３、１２５、１１５、１１７、１１９に既に確立されているので、ＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージにＲＡＯが付加される必要はなく、ＱＮＥ１２３、１２５、１１５、１１７、１１９は、受信したＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージのＲＥＳＥＲＶＥ部分を参照してリソース予約のための処理を行い、迅速にＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージを送信することができる（ステップＳ６４５、Ｓ６４７、Ｓ６５１、Ｓ６５３）。また、ＮＡＴＦＷ（ＱＮＥ１１７）においては、このＣＲＥＡＴＥ及びＲＥＳＥＲＶＥメッセージのＣＲＥＡＴＥ部分を参照し、ポリシールールに変更を加える（ステップＳ６４９）。このとき、ポリシールールにデータパケットに対するアドレス変換が含まれていた場合には、フィルタリストに含まれる該当フィルタ情報の内容をプライベートアドレスに対応したものに変更するか、又はプライベートアドレス用のフィルタ情報をリストに追加する。これにより、ＱＮＥ１１７とＱＮＥ１１９の間や、ＱＮＥ１１９とＣＮ１２１の間におけるＲＥＳＥＲＶＥ処理では、プライベートアドレス用にＱｏＳリソースが予約されることとなる。なお、ＭＮ１０１と、ＱＮＥ（プロキシ）１２３との間で使われるフローＩＤは、ＱＮＥ（プロキシ）１２３とＣＮ１２１の間で使われるフローＩＤと同じであってもよい。また、シグナリングメッセージ送信側で、あらかじめプライベートアドレスの情報が分かっていた場合には、このアドレス情報をあらかじめフィルタリスト内に存在させてもよい。この場合、ＮＡＴＦＷ（ＱＮＥ１１７）では、ステップＳ６４９においてフィルタリストの内容を変換する必要はない。

また、ここではＣＲＥＡＴＥとＲＥＳＥＲＶＥを同時に、ＱｏＳシグナリング用のルーティングのためのステートを用いて送信する例を挙げたが、このためには、複数のＮＳＬＰメッセージを同時に（１つのパケットとして）送信することをサポートするよう、ＮＳＩＳの仕様を変更する必要がある。また、ＲＥＳＥＲＶＥメッセージとＣＲＥＡＴＥメッセージは別々に送信されてもよいが、この場合には、ＣＲＥＡＴＥメッセージが、ＲＥＳＥＲＶＥメッセージよりも前に送信されることが必要であり（ステップＳ６４９でＲＥＳＥＲＶＥメッセージ内のフィルタ情報の書き換えが必要な場合があるため）、また、ＮＡＴＦＷシグナリング用のルーティングのためのステートが、ＱｏＳの場合と同様に、ＱＮＥ（プロキシ）１２３を用いてあらかじめ確立されていることが望ましい。

また、ここでは、データパケットの送信方向がｕｐｌｉｎｋ方向の場合について説明したが、データパケットの送信方向がｄｏｗｎｌｉｎｋ方向であった場合においても、図１６に図示されている第２動作例において、ＲＥＳＥＲＶＥメッセージと同時にＣＲＥＡＴＥメッセージを送信することによって同様の手順を採ることができる。

上述の本発明の第３の実施の形態における第３動作例では、ＮＡＴＦＷ（ＱＮＥ１１７）が、ＱｏＳＮＳＬＰとＮＡＴＦＷＮＳＬＰの両方のＮＳＬＰを持っている場合について説明を行った。この場合、フィルタリストはＮＳＬＰ共通部分に存在し、各ＮＳＬＰからフィルタリストを参照できるように構成してもよい。また、各ＮＳＬＰで使用されるフィルタ情報の組み合わせが異なることも考えられるので、この場合にはフィルタリスト内の各フィルタ情報に対し、どのＮＳＬＰで使用されるのかを示す情報（例えばフラグを立てるなど）を与えてもよい。

また、ＮＳＬＰごとにフィルタリストが分けられていてもよい。すなわち、ＱｏＳＮＳＬＰ用フィルタリストやＮＡＴＦＷＮＳＬＰ用フィルタリストなどのような各ＮＳＬＰで必要となるフィルタリストが用意され、各ＮＳＬＰ用フィルタリストがＮＳＬＰ共通部分に置かれる。

また、フィルタリストは各ＮＳＬＰに存在してもよい。この場合、各ＮＳＬＰ間で、直接又はＮＴＬＰを通じて、フィルタリストに関する情報をやり取りすることによって、フィルタリストの内容に整合性を持たせてもよい。例えば、ＮＡＴＦＷノードで〈ｆｉｌｔｅｒＡ〉を〈ｆｉｌｔｅｒＢ〉に書き換える指示を出す内容がＮＡＴＦＷＮＳＬＰに存在した場合、この情報が直接又はＮＴＬＰを通じてＱｏＳＮＳＬＰに送られ、これに従って、ＮＡＴＦＷノードのＱｏＳＮＳＬＰ内のフィルタリストに含まれる〈ｆｉｌｔｅｒＡ〉が〈ｆｉｌｔｅｒＢ〉に書き換えられる。ただし、ＱｏＳＮＳＬＰ内のフィルタリストにあらかじめ〈ｆｉｌｔｅｒＢ〉が存在している場合には、フィルタ情報を書き換える必要ない。

さらに、図１７に図示されているフィルタリストの定義とは異なるが、フィルタリストをＮＴＬＰに存在させるようにしてもよい。フィルタリストがＮＴＬＰに存在する場合は、フィルタリストがＮＳＬＰ共通部分に存在する場合と同様に、フィルタリスト内の各フィルタ情報に対し、どのＮＳＬＰで使用されるのかを示す情報（例えばフラグを立てるなど）が与えられていてもよく、また、ＮＳＬＰごとにフィルタリストが分けられていてもよい。

また、ＮＡＴＦＷノードは、ＮＡＴＦＷ機能を実装しているが、ＱｏＳ機能の実装は必須ではないため、ＮＡＴＦＷＮＳＬＰのみが存在し、ＱｏＳＮＳＬＰが存在しないＮＡＴＦＷノードが存在する場合も考えられる。このようなＮＡＴＦＷノードにおいても、ＮＳＬＰ共通部分やＮＴＬＰにフィルタリストが存在すれば、フィルタ情報の変換（図１８におけるステップＳ６４９の処理）を容易に行うことができる。

また、各ＮＳＬＰにフィルタリストが存在する場合でも、ＮＡＴＦＷノードにおける特別な機能として、ＱｏＳＮＳＬＰが存在しない場合であってもＱｏＳＮＳＬＰ内のフィルタリストの内容をチェックすることができる機能を持たせれば、フィルタ情報の変換は可能となる。また、この場合、ＱｏＳＮＳＬＰメッセージがＮＡＴＦＷノードでインタセプトされるようにする必要がある。ＱｏＳＮＳＬＰメッセージがＮＡＴＦＷノードでインタセプトされるようにするため、ルーティングのためのステート確立以前に送信されるＱｏＳＮＳＬＰメッセージには、例えば、ＮＡＴＦＷＮＳＬＰ用のＲＡＯ、又はＱｏＳＮＳＬＰ及びＮＡＴＦＷＮＳＬＰ共通（又はＮＳＬＰ共通）のＲＡＯ、又はＮＴＬＰを有するＮＥに対するＲＡＯ（すなわち、ＮＴＬＰ用ＲＡＯ）が付加される。

さらに、ＮＡＴＦＷノードが、ＮＴＬＰのみを実装している場合も考えられる。この場合、ＮＴＬＰにフィルタリストが存在すれば、ＮＡＴＦＷノードは、フィルタ情報の変換（図１８におけるステップＳ６４９の処理）を容易に行うことができる。ＮＳＬＰ共通部分や各ＮＳＬＰにフィルタリストが存在する場合でも、ＮＡＴＦＷノードにおける特別な機能として、ＮＳＬＰ共通部分や各ＮＳＬＰに存在するフィルタリストの内容をチェックすることができる機能を持たせれば、フィルタ情報の変換は可能となる。また、この場合、ＱｏＳＮＳＬＰメッセージがＮＡＴＦＷノードでインタセプトされるようにする必要がある。ＱｏＳＮＳＬＰメッセージがＮＡＴＦＷノードでインタセプトされるようにするため、ルーティングのためのステート確立以前に送信されるＱｏＳＮＳＬＰメッセージには、例えば、ＮＴＬＰを有するＮＥに対するＲＡＯ（すなわち、ＮＴＬＰ用ＲＡＯ）が付加される。

また、上述のようにフローＩＤ及びフィルタリストを定義することにより、ＭＮのハンドオーバのケースに限らず、ＮＡＴＦＷノードを経由するデータ経路を容易に管理することが可能となる。

例えば、ＭＮが、１つのセッションに対し複数のＩＰアドレスを用いてＣＮと通信している場合（ＭＮがマルチホーム状態の場合）で、どのＩＰアドレスも同一のサブネット配下のものであった場合を考える。この場合、どのＩＰアドレスが設定されたデータパケットであっても、データパケットが通過する経路は１つなので、各ＮＡＴＦＷＮＳＬＰを持つＮＥにおけるＮＴＬＰ層では、ＭＮが持つ複数のＩＰアドレスのうちの１つをフローＩＤのあて先（又は送信元）アドレスとして採用すればよい。なお、ＮＡＴＦＷにおいてポリシールール作成のために利用されるフィルタリストは、上述のように複数のフィルタ情報に対応しているので、ＭＮが有する複数のＩＰアドレスのすべてを容易に保持することが可能である。

また、ＦＴＰを用いたデータのダウンロードなどでは、ダウンロードのスピードを上げるために、クライアントは一度に複数のポートを用いることがある。この場合でも、上述のＭＮが複数のＩＰアドレスを持つ場合と同様に、複数のポート番号のうちの１つをフローＩＤに採用すればよい。なお、フローＩＤが完全にＩＰアドレスの情報のみで作られるような場合には、ＮＴＬＰにおいて、ポート番号を管理する必要はなくなる。また、上述のＭＮが複数のＩＰアドレスを持つ場合と同様に、ＮＡＴＦＷにおいてポリシールール作成のために利用されるフィルタリストは、複数のフィルタ情報に対応しているので、複数のポート番号を容易に保持することが可能である。

また、さらに、Ｈ．３２３を用いてＶｏＩＰ用のセッションを張る場合には、この途中のプロセスにおいて、使用されるポート番号が変化する。しかしながら、この場合でも、上述のように、フローＩＤ及びフィルタリストを定義することによって、ＮＴＬＰ側ではポート番号の変化に合わせてフローＩＤの情報を変える必要はなくなり、一方、ＮＡＴＦＷにおいてポリシールール作成のために利用されるフィルタリストでは、フィルタ情報の追加・削除が容易に行えるため、ポート番号の変化に柔軟に対応することが可能となる。

また、上述の本発明の第３の実施の形態では、フローＩＤとフィルタ情報とを分けて、別々に管理できるようにすることによって、シグナリングメッセージの通る経路に係る処理を、データパケットの通る経路に係る処理より前に行えるようにしているが、さらに、これを応用して、データパケットの通る経路と、シグナリングメッセージの通る経路とが異なるｏｆｆ−ｐａｔｈシグナリング（ＰａｔｈＤｅｃｏｕｐｌｅｄシグナリングとも呼ばれる）を行うことも可能となる。例えば、あるドメインのプロキシや、ポリシー決定ポイント（データ経路上に存在する必要は無い）に直接シグナリングメッセージを送信し、このノードに、フィルタリストの内容を使用した処理（例えば、ポリシールールの作成）を行わせることも可能である。

なお、上述の本発明の第１〜第３の実施の形態では、付加的サービスがＱｏＳ保証である場合について説明したが、その他の付加的サービスに関しても本発明は適用可能である。また、特に、ＱｏＳ保証に関しては、ＮＳＩＳに対して本発明を適用した場合の具体例について説明したが、本発明は、その適用対象がＮＳＩＳに限定されるものではなく、さらに、本発明の機能を持たせるＮＳＩＳのメッセージは、上述の一例に限定されるものではない。

また、上記の本発明の各実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（ＬａｒｇｅＳｃａｌｅＩｎｔｅｇｒａｔｉｏｎ）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（ＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（ＦｉｅｌｄＰｒｏｇｒａｍｍａｂｌｅＧａｔｅＡｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。

本発明は、移動端末がハンドオーバを行う際に、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の中断時間（特に、ＱｏＳ経路の中断時間）を低減させることが可能であり、通信ネットワーク技術や、パケット伝送に係るリソース管理の技術に適用可能である。さらに、本発明は、移動端末がハンドオーバを行う場合に限らず、端末が１つのセッションに対し、複数のＩＰアドレスや複数のポート番号を用いて通信を行っている場合や、セッションの途中でＩＰアドレスやポート番号に変更が生じる場合においても、経路（特に、ＱｏＳ経路）の管理を容易にすることが可能であり、通信ネットワーク技術や、パケット伝送に係るリソース予約に係るシグナリングメッセージのルーティング管理技術に適用可能である。

移動端末から無線ネットワークを通じてインターネットなどの通信ネットワークにアクセスするユーザに対して、移動しながらでもシームレスに通信ネットワークの接続を提供できる技術として、次世代インターネットプロトコルであるモバイルＩＰ（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方向の場合の動作例を示すシーケンスチャート

Claims

それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な通信システムであって、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続し、前記第１アクセスルータが構成する第１サブネットで取得する第１アドレスを使用して通信を行う移動可能な移動端末と、
前記通信ネットワークに接続されており、前記移動端末の通信相手となる通信相手端末と、
前記移動端末が、前記複数のアクセスルータのうちの１つである第２アクセスルータに接続した場合に前記第２アクセスルータが構成する第２サブネットで取得する第２アドレスを使用せずに、前記第１アクセスルータに接続している前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路が確立された状態で、前記第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始することが可能な前記通信ネットワーク内に存在する通信ノードとを、
有する通信システム。
前記通信ノードが、前記第２アクセスルータの近隣に存在する請求項１に記載の通信システム。
前記通信ノードが、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信し、前記トリガ情報に基づいて前記第２経路を確立する処理を開始するように構成されている請求項１に記載の通信システム。
前記移動端末が、前記トリガ情報を前記通信ノードに送信するように構成されている請求項３に記載の通信システム。
前記通信ノードが、自ノードを一方の終端とする前記第２経路を確立するように構成されている請求項１に記載の通信システム。
前記通信ノードは、前記移動端末が前記第２サブネットに移動して割り当てられた第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始するように構成されている請求項１に記載の通信システム。
前記通信ノードが、前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている請求項６に記載の通信システム。
前記第２経路の終端が前記通信ノード及び前記通信相手端末であり、前記通信相手端末が、前記移動端末にパケットを送信する際に前記通信ノードのアドレスをあて先アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記通信相手端末から前記移動端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている請求項６に記載の通信システム。
前記第２経路の終端が前記第２アクセスルータの近隣に存在する前記通信ノード及び前記通信相手端末の近隣に存在する相手側近隣通信ノードであり、前記相手側近隣通信ノードが、前記通信相手端末から前記移動端末へのパケットを転送する際に前記通信ノードのアドレスをあて先アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記通信相手端末から前記移動端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている請求項６に記載の通信システム。
前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第１サブネットに接続している状態で使用されていた前記第１経路、及び前記通信ノードによって確立された前記第２経路が削除されるように構成されている請求項６に記載の通信システム。
前記通信ノードが、自ノードと前記通信相手端末との間の経路上の中間通信ノードに、前記第２経路を確立する処理を行う際に送受信されるシグナリングメッセージのルーティングのためのステートを導入する処理を開始するように構成されている請求項１に記載の通信システム。
前記通信ノードが、前記中間通信ノードに対して、自ノードのアドレス及び前記通信相手端末のアドレスにより構成された識別情報を送信し、前記中間通信ノードが、前記識別情報を保持して、前記識別情報を有するシグナリングメッセージを特定するように構成されている請求項１１に記載の通信システム。
前記通信ノードは、前記移動端末が前記第２サブネットに移動して割り当てられた第２アドレスを取得した場合に、前記第２経路に係る付加的サービスを提供するための情報を含むシグナリングメッセージを送信し、前記中間通信ノードが、前記シグナリングメッセージのルーティングのためのステートを使用して、前記シグナリングメッセージの伝送を行うように構成されている請求項１１に記載の通信システム。
前記付加的サービスが、ＱｏＳ保証である請求項１に記載の通信システム。
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な前記通信ネットワークに存在する通信ノード内のリソース管理装置であって、
前記経路において、付加的サービスを提供するためのリソースを確保するためのリソース確保手段と、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続している前記移動端末と、前記通信ネットワークに接続されており前記移動端末の通信相手となる通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信するトリガ受信手段と、
前記トリガ受信手段で前記トリガ情報を受信した場合、前記トリガ情報に基づいて、前記第１アクセスルータとは異なる第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始するメッセージを生成するメッセージ生成手段とを、
有するリソース管理装置。
前記メッセージには、前記移動端末の代理として経路設定を行う旨を示す情報が付加されている請求項１５に記載のリソース管理装置。
前記第２アクセスルータの近隣に存在する前記通信ノード内に配置されている請求項１６に記載のリソース管理装置。
前記トリガ情報に、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスが少なくとも含まれている請求項１６に記載のリソース管理装置。
前記移動端末から前記トリガ情報を受信する請求項１８に記載のリソース管理装置。
前記通信ノードを一方の終端とする前記第２経路を確立するように構成されている請求項１６に記載のリソース管理装置。
前記移動端末が前記第２サブネットに移動して割り当てられた前記第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始するように構成されている請求項１６に記載のリソース管理装置。
前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化手段を有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化手段によってカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられるように構成されている請求項２１に記載のリソース管理装置。
前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第２経路を削除するためのメッセージを送信するように構成されている請求項２０に記載のリソース管理装置。
前記付加的サービスが、ＱｏＳ保証である請求項１５に記載のリソース管理装置。
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サービスを提供するための経路を確立することが可能な前記通信ネットワークに存在する通信ノードで行われるリソース管理方法であって、
前記経路において、付加的サービスを提供するためのリソースを確保するためのリソース確保ステップと、
前記複数のアクセスルータのうちの１つである第１アクセスルータに接続している前記移動端末と、前記通信ネットワークに接続されており前記移動端末の通信相手となる通信相手端末との間の通信に対して前記付加的サービスを提供するための第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスを少なくとも含むトリガ情報を受信するトリガ受信ステップと、
前記トリガ受信ステップで前記トリガ情報を受信した場合、前記トリガ情報に基づいて、前記第１アクセスルータとは異なる第２アクセスルータに接続した状態における前記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するための第２経路を確立する処理を開始するメッセージを生成するメッセージ生成ステップとを、
有するリソース管理方法。
前記メッセージには、前記移動端末の代理として経路設定を行う旨を示す情報が付加されている請求項２５に記載のリソース管理方法。
前記第２アクセスルータの近隣に存在する前記通信ノード内に配置されている請求項２６に記載のリソース管理方法。
前記トリガ情報に、前記第１経路を識別するための情報、及び前記第１経路における前記通信相手端末のアドレスが少なくとも含まれている請求項２６に記載のリソース管理方法。
前記移動端末から前記トリガ情報を受信する請求項２８に記載のリソース管理方法。
前記通信ノードを一方の終端とする前記第２経路を確立する請求項２６に記載のリソース管理方法。
前記移動端末が前記第２サブネットに移動して割り当てられた前記第２アドレスを取得し、前記移動端末の前記第２アドレスを一方の終端とする第３経路を確立する処理を開始する請求項２６に記載のリソース管理方法。
前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化ステップを有し、前記第３経路の確立が完了するまでは、前記移動端末から前記通信相手端末への前記パケットを前記カプセル化ステップにおいてカプセル化することで、前記パケットが、前記第２経路に対して提供される前記付加的サービスを受けられる請求項３１に記載のリソース管理方法。
前記移動端末が前記第２サブネットに移動して前記第３経路の確立が完了した場合に、前記第２経路を削除するためのメッセージを送信する請求項３０に記載のリソース管理方法。
前記付加的サービスが、ＱｏＳ保証である請求項２５に記載のリソース管理方法。
シグナリングメッセージをルーティングする機能を有する第１ユニットと、提供する付加的サービスに関する情報を管理するための機能を有する第２ユニットとにより構成された通信プロトコルを使用して２つの通信ノード間で行われる通信において、前記２つの通信ノード間の経路上に存在し、前記２つの通信ノード間で伝送されるデータパケットに対して前記付加的サービスを提供する通信ノード内の通信管理装置であって、
前記第１ユニットが、前記２つの通信ノード間の経路の一部であって、自ノードを含んだ任意の両端点を有する前記経路の一部において伝送される前記シグナリングメッセージのルーティングのためのステートを管理するステート管理手段を有し、
前記第２ユニットが、前記シグナリングメッセージによって伝送されるフィルタ情報であって、前記付加的サービスを提供する対象となるデータパケットを特定するための前記フィルタ情報を管理するフィルタ情報管理手段を有する通信管理装置。
前記ステートが、前記任意の両端点のアドレスを有し、前記フィルタ情報が、前記２つの通信ノードのアドレスを有する請求項３５に記載の通信管理装置。
前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層に配置されている請求項３５に記載の通信管理装置。
シグナリングメッセージをルーティングする機能を有する第１ユニットと、提供する付加的サービスに関する情報を管理するための機能を有する第２ユニットとにより構成された通信プロトコルを使用して２つの通信ノード間で行われる通信において、前記２つの通信ノード間の経路上に存在し、前記２つの通信ノード間で伝送されるデータパケットに対して前記付加的サービスを提供する通信ノードで行われる通信管理方法であって、
前記第１ユニットが、前記２つの通信ノード間の経路の一部であって、自ノードを含んだ任意の両端点を有する前記経路の一部において伝送される前記シグナリングメッセージのルーティングのためのステートを管理するステート管理ステップと、
前記第２ユニットが、前記シグナリングメッセージによって伝送されるフィルタ情報であって、前記付加的サービスを提供する対象となるデータパケットを特定するための前記フィルタ情報を管理するフィルタ情報管理ステップとを、
有する通信管理方法。
前記ステートが、前記任意の両端点のアドレスを有し、前記フィルタ情報が、前記２つの通信ノードのアドレスを有する請求項３８に記載の通信管理方法。
前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層に配置されている請求項３８に記載の通信管理方法。
前記第１及び第２ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されている請求項３８に記載の通信管理方法。
前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層の任意の機能が参照可能なＮＳＬＰ共通部に配置されている請求項３８に記載の通信管理方法。
前記第１ユニットが、ＮＳＩＳにおけるＮＴＬＰ層に配置されており、前記第２ユニットが、ＮＳＩＳにおけるＮＳＬＰ層の特定の機能部に配置されていて、前記特定の機能部から前記ＮＳＬＰ層の任意の機能部に、前記フィルタ情報の一部又は全部が渡されるように構成されている請求項３８に記載の通信管理方法。