(57)【要約】【課題】　ネットワークシステムにおいて、フローの間でリソースの予約を動的に調整する。【解決手段】　複数のルータにより少なくとも一台の送信端末に接続される受信端末を備えるネットワークにおいて、その受信端末が、フローを制御するモジュールと、リソース予約処理モジュールと、部分リソース予約処理モジュールと、動的調整アルゴリズムを備えた動的調整モジュールとを有し、リソース予約処理モジュールにより複数のデータフローの予約がルータ上で生成することができ、部分リソース予約処理モジュールにより部分予約をルータ上に維持することができ、動的調整アルゴリズムにより、各ルータ上で起こるボトルネックを補償するようにフロー予約配分を最適とすることができるようにネットワークシステムが構成されている。【選択図】　　　図１
2004147334.tif 000002
【特許請求の範囲】
【請求項１】
　マルチホップにより少なくとも一台の送信端末に接続される受信端末を具備し
　前記受信端末がフローを制御するモジュールを有し、
　当該モジュールが端末セッションにおける少なくとも一つのアプリケーションセッションの相対的な重要度を指定し、アプリケーションセッションにおける複数のデータフローを指定し、
　前記受信端末がリソース予約処理モジュールを有し、
　当該リソース予約処理モジュールが、受信端末と送信端末との間の端末セッションの間、複数のデータフローの予約をホップ上で生成することができ、
　前記受信端末が部分リソース予約処理モジュールを有し、
　当該部分リソース予約処理モジュールが、前記ホップ上で部分予約を維持することができ、
　前記受信端末が、動的調整アルゴリズムを備えた動的調整モジュールを有し、
　当該動的調整アルゴリズムが、各ホップ上で起こるボトルネックを補償するようにフロー予約配分を最適とすることができる
　ことを特徴とするネットワークシステム。
【請求項２】
　受信端末と接続している複数のルータにおいて、複数のパケットフローについてリソースを予約する過程と、
　前記ルータから前記受信端末に、各データフローにおけるボトルネックを示すフィードバックメッセージを送信する過程と、
　前記受信端末について、所定の基準に基づき、パケットフローの最適な予約配分を決定する過程と
　リソース予約更新メッセージを生成し、ボトルネックを有する前記ルータに当該更新メッセージを送信し、当該ルータにおいてそのボトルネックを補償するようにパケットフローを調整する過程と
　を有する、データネットワークにおけるデータフローを調整する方法。
【請求項３】
　少なくとも一台の送信端末と接続された受信端末を具備し、
　前記受信端末が複数のルータにより各送信端末と接続し、
　前記受信端末が当該受信端末と前記送信端末との間の複数のパケットフローを端末セッションのために予約することができ、
　前記受信端末が当該受信端末と前記送信端末との間のパケットフローについて部分予約を生成することができ、
　前記ルータがボトルネック表示を生成し、各パケットフローを所定の水準のＱｏＳに適合させることができない場合に前記受信端末に当該表示を送信することができ、
　前記受信端末が、動的リソース予約アルゴリズムを有する経路を最適化するモジュールを具備し、当該モジュールが同一端末セッションのパケットフローの最適なリソース配分を再計算する
　ことに特徴があるパケット交換ネットワーク。
【請求項４】
　受信端末と送信端末との間のデータネットワークにおけるデータフローの制御方法において、
　複数のデータフローリソースを、複数のデータフローを有する端末セッションについて、前記受信端末および前記送信端末に接続している複数のルータにおいて、予約する過程と、
　各ルータについてフィードバックメッセージを生成し、当該ルータにボトルネックが生じた場合に当該メッセージを前記受信端末に送信する過程と、　パケットフローの予約が最適に配分されるように動的調整アルゴリズムを利用してフロー予約配分が最適となるように前記ルータにおけるパケットフローを調整する過程と
　を有するデータフローの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、全体として、データネットワークにおけるリソース予約に関する。特に、複数のデータフローを有する受信端末で使用されるリソース動的予約プロトコルに関する。
【背景技術】
【０００２】
　近年、モバイルコンピューティングの急増が見られ、また、さまざまな新しい無線通信技術の急速な台頭も見られる。いつでもどこでもどんな形ででもユビキタスにネットワークに接続したい人々の欲求に応じるように、種類の異なる通信システム、通信用途（以下、アプリケーションとも称する）、通信装置、および通信事業者が多数存在している。これらの数は、現在も増加している。
　当分の間、この異種混在状況は解消されないと思われる。なぜなら、通信用途毎に必要とされる条件が異なり、あまねく最適な解決方法を見出すことが困難であるからである。また、市場獲得に熱心なあまり、競合関係にある組織が互換性のない通信システムを発売してしまうからである。
　そこで、次世代移動通信システムにおいて成功を収めるためには、このような異種混在環境において継ぎ目のないシームレスなサービスを提供できることが鍵となる。
【０００３】
　サービスに継ぎ目を感じさせないようにするためには、主として、位置情報サービス技術、サービスを検出する技術、および、サービスを組合わせる技術の重要性が増大している。新しいこれらの技術には、さらに多くの機能と利便性とをユーザに提供できる可能性がある。
　しかし、これらのサービスを十分に普及させるためには、アプリケーションを使用している間のサービス品質（以下、ＱｏＳと称する）を保証するという重要な課題を、まず解決しなければならない。
　ＱｏＳをサポートするフレームワークの一つに、インテグレイテッドサービス（以下IntServと称する）がある。IntServは、接続指向（connection-oriented）のフレームワークであり、データ転送前におけるＱｏＳ経路の設定に依存する性質を有する。
　しかし、ＲＳＶＰ（Resource reSerVation Protocol）プロトコル等のIntServフレームワークにおける従来のプロトコルは、ユビキタスな移動環境において様々な問題を示す。
　また、この従来のプロトコルによれば、ＱｏＳの要件に適合させるために、新しいアプリケーションサービスに広範囲な修正が必要となる。
【０００４】
　ＲＳＶＰ プロトコルは、現在のところ、IntServフレームワークをサポートするＩＰネットワークの標準的プロトコルである。コアネットワークでＱｏＳ機構が使用されていても、サービスの品質を保証して提供するためには、エッジルータにおいて予約制御あるいはアドミッション制御が必要となることが良く理解されている。ＲＳＶＰプロトコルあるいはその派生プロトコルは、特定用途のデータストリームについて特有のＱｏＳをＩＰネットワークに要求する際に、ホストノードがよく使うシグナリングプロトコルである。このプロトコルは、ルータがストリームの経路に沿った全てのノードにＱｏＳ要求を配信し、要求されるサービスを設定・維持するためにも使用される。
　ＲＳＶＰプロトコルは、フロー仕様、経路制御（Routing）、アドミッション制御、ポリシー制御、およびパケットスケジューリング等のIntServフレームワークの他の構成要素と密接に連携動作する。
　ＲＳＶＰはユニキャストおよびマルチキャストの両タイプのデータフローをサポートする。ＲＳＶＰは受信端末から開始される予約プロトコルであり、種類の異なる受信端末を容易に収容することができ、マルチキャストのグループメンバーシップを容易に変更することができる。ＲＳＶＰプロトコルでは異なる予約方法が提供されているので、帯域の使用率が向上し、同一のマルチキャストグループの異なる送信端末からのデータフローを多重化することができる。ＲＳＶＰプロトコルでは、中間に位置するルータ（以下、中間ルータと称する）は、経路変更や障害からある時間経過後に自動的に終了する「ソフト状態」を利用して、経路変更や障害を適切に処理する。
【０００５】
　上記とは別に、MＲＳＶＰ、ＲＳＶＰ-A、および、ＲＳＶＰシグナリングプロトコルを変更した他のプロトコルがある。
　ＲＳＶＰが、端末の移動を考慮することなく、受信端末から開始されるアルゴリズムにより設計されているので、端末の移動をサポートするＭＲＳＶＰおよびその関連プロトコルが提案されている。これらのプロトコルは、アプリケーションがおそらく移動するであろう別の基地局において事前にリソースの予約を設定することに基づいて動作する。
　受信端末ベースの予約プロトコルとは別に、ＳＲＰ、ＹＥＳＳＩＲ等の送信端末ベースの予約プロトコルも提案されている。ＳＲＰは、限界を超えることのないように受け入れることのできる予約を末端のシステムに推定させることにより、ＲＳＶＰのスケーラビリティの問題を解決しようとするものである。したがって、中間ルータは、フロー毎の状態を維持する必要がなく、自身のリソースの使われ方を計測することにより、負荷を制御してサービスを提供することができる。ＹＥＳＳＩＲは、１−パスシグナリングを利用し、部分予約ができる軽量プロトコルである。
【０００６】
　予約の信号方式に関連して考慮しなければならない設計課題がある。これらの課題には、スケーラビリティ要因、信号処理のオーバーヘッド、部分予約、および予約の再試行法等がある。
　信号方式のスケーラビリティに多大な影響を及ぼす要因は、プロトコル自体の複雑さ、ＱｏＳ状態の管理効率、および信号方式の構成の単純さが挙げられる。
　一般に、エンドユーザのところにおける柔軟さとメッセージの信号処理のオーバーヘッドとは二律背反するものである。ＲＳＶＰは、予約処理を完了するために、送信端末からの経路メッセージと受信端末からの予約メッセージとを必要とする２−パスのプロトコルである。YESSIRは１パスプロトコルであり、予約をするためには、送信端末が各受信端末にフロー仕様メッセージを送出することだけが必要である。
【０００７】
　ＲＳＶＰにおいて予約要求が拒絶されると、要求メッセージはルータで廃棄され「遮断状態」が作られる。続くリフレッシュサイクルの間、予約のための再試行が制限される。
　一方、ＹＥＳＳＩＲ等のプロトコルでは部分予約をすることができるので、できるだけ多くのホップを、すなわちルータを予約しようとする。この結果、うまくいかなかった予約要求は、依然として、下りフローに転送されることになる。また、部分予約では、エンドユーザにより当初要求されたＱｏＳが提供されることがないので、リンクのない状態における予約法、あるいは予約がうまくいかなかった状態からの回復法が課題として重要である。
【０００８】
　このように設計課題の選択が違っていても、既存のシグナリングプロトコルには、送信元アドレス、送信先アドレス、送信元ポート、送信先ポート、およびプロトコルのタイプからなる５個のタプルにより識別される単一のフローに基づいて予約がおこなわれる、という共通の特徴がある。ＦＴＰあるいは電子メール等の従来からある大部分のインターネットアプリケーションでは、サーバーとクライアントとの間に存在する通信フローは、一つだけである。ビデオ会議等の、より複雑なアプリケーションでは、映像、音声、あるいは文字情報を送信しようとして、複数の通信フローが同時にオープンすることはあるが、これらの複数の通信フローの全てが同一の接続ピアおよび同一のネットワークリンクを共有しているので、これらの予約プロトコルは、この複数の通信フローを単一のフローとして取り扱うことができる。これら全ての適用事例（scenario）において、フローに基づいた予約プロトコルがうまく機能する。
【０００９】
　上記のような単一のフローに基づいた事例とは別に、全く異なるネットワークに位置し、計算能力および通信能力の点で非常に異なる通信ピアと通信する、複数のデータフローを有するような用途がある。この事例をよく理解するために、オンラインゲームの事例について、以下、簡潔に説明する。
【００１０】
　通常のオンラインゲームの設定では、人々は、ゲームサーバにログオンして、他のプレーヤーとインタラクティブにゲームをおこなう。複数のプレーヤーからなるチームが作られ、他のチームと競いあうこともよくおこなわれる。プレーを効果よくおこなうためには、各プレーヤーがチームの他のメンバーと、コミュニケーションをよくとる必要がある。したがって、良質な通信回線（channel）が必要となる。
　プレーヤーが助けを求め、行動を一致させ、指令を交換するためには、音声回線で十分に役立つかもしれないが、他のプレーヤーの画像を捉えたり、地図を共有したり、現に起きている事象を瞬時に把握するためには、映像回線が役立つことになる。さらに多くの通信回線を追加することにより、さらに多くの機能をゲームアプリケーションに統合することができるであろう。
【００１１】
　上記の事例では、複数のデータフローが同一の送信元と同一の送信先を共用している。一方、本発明におけるアプリケーションは、異なる通信ピアおよび異なるネットワークリンクを備える複数のデータフローを有することができる。したがって、各データフローの予約を個別に取り扱いながら、アプリケーション全体としてより良く動作するように調整しなければならない。
【００１２】
　位置情報サービス技術、サービスを検出する技術、および、サービスを組合わせる技術等の新技術が、サービスの動的探索、サービスの動的組合わせおよびサービスの動的提供のために使用されるような複雑な事例では、アプリケーションのフローは、その構成（configuration）および通信ピアを動的に変化させることができる。また、無線回線の回線を制限することができる上に、移動通信端末の処理能力が有限であることにより、同一の端末で動作するアプリケーションも、競合してネットワークおよび端末から有限のサービスを受けている。
【００１３】
　従来のリソース予約プロトコルは、これら全ての高度なアプリケーション事例において、もはや適用することができない。以下簡潔に説明する。
　ユーザにより、これらのアプリケーションが一つあるいは複数のタスクを完了するように同時に選択される場合には、ユーザの体感性能を最大とするためのタスクの時間管理法が共通する課題となる。例えば、既存のオペレーティングシステムの時間管理機能により取り扱われるタスク終了時間の管理法が課題となる。この課題を別の側面から見てみると、通信のボトルネックが顕著となるときの、各アプリケーションあるいはアプリケーションの各フローによる通信リソースの使用の調整法が課題となる。
【００１４】
　リソース予約プロトコルはネットワークレイヤーで動作するので、予約の基本となるグラニュラリティはフローである。５個のタプルによりフローは指定される。アプリケーションレイヤーにおいて基本となる単位（granularity）は、一つ一つのアプリケーションタスクである。ＦＴＰや電子メール等の古い多くのアプリケーションは、通信にネットワークのフローを一つだけ利用する。一方、マルチメディア通信を用いたアプリケーションでは、一つのタスクを完了するために複数のフローを取り扱うことができる。特に、多数の多様な単機能サービスを動的に統合することによりユーザに幅広いサービスを提供するというサービス組合わせ技法が使用されるときには、一つのアプリケーションセッションには、複数のアドレスからくるデータフローが含まれることがある。
【００１５】
　同一の端末で動作するアプリケーションの中における各アプリケーションの相対的な重要性は、現在の使用者の嗜好により変化する。この事例において、これらのアプリケーションの間で通信リソースを動的に調整する方法は、未解決の問題である。また、複数のフローを扱うアプリケーションがあると、動的配置をサポートすることが必須となる。
【００１６】
　効率的かつ柔軟に予約ができるように、従来の予約シグナリングプロトコルを注意して修正する必要がある。本発明をよりよく理解することができるように、固有の問題ではなく、これらの枠組みに共通する課題について以下説明をする。明確に説明するために、アプリケーションセッションを、一つ以上の通信フローを有するアプリケーションと定義する。端末セッションを、特定の一端末で動作し、通信リソースを競合して取りあう複数のアプリケーションセッションからなる組合わせと定義する。一般に、アプリケーションセッションは、端末セッションの部分集合である。そこで、しばしば端末セッションが単にセッションと略称される。
【００１７】
　以上、全体を通して説明してきたように、現状の予約プロトコルはネットワークのフローの水準に基づいている。一つのアプリケーションの性能は、同一のセッションの全てのフローについての全体としての性能に依存している。したがって、セッションに属するフローに優先的な取扱いを受けるものと、不利に取り扱われるものがあると、アプリケーションの性能は極度に劣化する。同一の端末セッションの複数のアプリケーションセッションの全てが、複数のデータフローを有すると、それらのフローはより大きなフローの集合を形成する。
【００１８】
　現状の予約プロトコルも、同一のセッションの複数のフローの予約の間で協調動作はしていない。なぜなら、現状の予約プロトコルはフローに基づいているので、各フローが個別に取り扱われるからである。あるフローの予約に失敗すると、後に再試行されるか、より少ない数のフローが要求される（部分予約される）かのいずれかの方法がとられる。
【００１９】
　ＲＳＶＰあるいはその派生形は、複数の送信端末および複数の受信端末が同一のマルチキャストアドレスを共有していると仮定しているので、一意に予約を指定でき、異なる送信端末の間で予約を共有することができ、異なる受信端末からの要求を中間ルータにおいて一つにまとめることができる。ここに述べるアプリケーションセッションは、相互に関連のない複数の送信端末を予約する複数のフローを有する。したがって、マルチキャストツリーを形成することは容易ではなく、既存のプロトコルをこの事例に直接移行（migrate）させることはできない。
【００２０】
　現状のプロトコルは、アプリケーションセッションの構成を動的に調整する際に、効率良くサポートすることもできない。ＲＳＶＰは、受信端末ベースの予約メッセージを利用して、受信端末の加入や離脱を動的に おこなうことができる。しかし、この事例においても、一つのアプリケーションセッションが複数のユニキャストフローを有しているので、アプリケーションセッションの動的な構成と予約はＲＳＶＰタイプのプロトコルでは取り扱うことができない。
【非特許文献１】タルクダー・Ａ．（Talukdar, A.），バドリナス・Ｂ．Ｒ．（Badrinath, B.R.），アチャラ・Ａ．（Acharya, A.），「MRSVP：移動ホストとの統合サービスネットワークのためのリソース予約プロトコル（A Resource Reservation Protocol for an Integrated Services Network with Mobile Hosts.）」，ＡＣＴＳ移動機サミット９８予稿集（Proc. of ACTS Mobile Summit 98），１９９８年６月
【非特許文献２】アルメスバーガ・Ｗ．（Almesberger, W.），フェラーリ・Ｔ．（Ferrari, T.），ル・ボウデック・Ｊ．Ｙ．（Le Boudec, J.Y.），「ＳＲＰ：インターネットのためのスケーラブルリソース予約プロトコル（SRP: a Scalable Resource Reservation Protocol for the Internet,）」，スイス連邦工科大学ローザンヌ・テクニカルレポート（Tech. Rep. SSC/1998/009, EPFL, Lausanne, Switzerland），ＳＳＣ／１９９８／００９，１９９８年３月
【非特許文献３】パン・Ｐ．（Pan, P.），シュルツリン・Ｈ．（Schulzrinne, H.）「ＹＥＳＳＩＲ：インターネットのための単純な予約機構（YESSIR: A Simple Reservation Mechanism for the Internet,）」，ＮＯＳＳＤＡＶ１９９７（ケンブリッジ，イングランド）（NOSSDAV 1997, Cambridge, England），１９９７年７月
【非特許文献４】ブラーデン・Ｒ．（Braden, R），ツァーン・Ｌ．（Zhang, L.），ヘルツォーク・Ｓ．（Herzog, S.），ジェイミン・Ｓ．（Jamin, S.），「リソース予約プロトコル（ＲＳＶＰ）（Resource ReSerVation Protocol (RSVP),）」，ＲＦＣ２２０５，１９９７年９月，インターネット＜ＵＲＬ： http://www.ietf.org/rfc/rfc2205.txt＞
【発明の開示】
【課題を解決するための手段】
【００２１】
　本発明は、ネットワークシステムの実施形態を開示する。このネットワークシステムは、マルチホップ、すなわちルータにより送信端末に接続された受信端末を備える。受信端末はリソース予約処理モジュールを備え、このモジュールが、受信端末と送信端末との間のアプリケーションセッションの間、ユニキャストパケットフローの複数の予約を各ホップで生成することができる。受信端末は、また、部分リソース予約モジュールを備え、このモジュールが、部分予約をホップ上に生成維持することができる。受信端末はまた、動的調整アルゴリズムを有する動的調整モジュールを備え、このモジュールにより、各ホップで起こるボトルネックを補償するように最適な予約よりも少なく予約がおこなわれる。
【００２２】
　次に、本発明は、データネットワークにおけるデータフローの調整方法の実施形態を開示する。この実施形態は、受信端末と接続された複数のルータにおける複数のパケットフローのためにリソースを予約する過程と、ルータから受信端末に各データフローにおけるボトルネックを表示するフィードバックメッセージを送信する過程と、受信端末について所定の基準に基づいて、最適となるリソース配分を決定する過程と、データフローをルータにおいて調整するリソース予約更新メッセージをボトルネックを補償するためにボトルネックを有するルータに送信する過程とを有する。
【００２３】
　背景技術のところで既に述べたように、ルータにおけるリソース予約を支援する現状の方式（scheme）は、同一のアプリケーションセッションからＱｏＳ水準の異なる複数のデータフローを必要とする新たなアプリケーション類型についての情報がないので、セッションベースの予約における問題を解決しない。本発明は、既存の予約の枠組みを適応させることにより、アプリケーションセッションベース予約プロトコルのこの問題を解決している。
【００２４】
　端末ベースのリソース予約プロトコルは、端末とアプリケーションにセッションベースのリソース予約を提供する。本発明によれば、 同一のアプリケーションセッションからの、あるいは同一の端末上の複数のアプリケーションセッションからの複数のデータフローについて予約がまとめて行われるので、アプリケーション性能およびユーザの体感性能を最適とすることができる。これとは対照的に、従来のリソース予約プロトコルは各フローを個別に取り扱われるので、端末セッション（あるいはアプリケーションセッション）の総合性能を補償することができない。
【００２５】
　本発明の好適実施形態によれば、複数のデータフロー間の相互作用に適するシグナリングプロトコルと動的予約モジュールとのインターフェースが提供される。
一般的な動的予約調整アルゴリズムをまず議論した後に、同一の端末あるいは同一のアプリケーションセッションにおいて競合するフローのボトルネックの位置およびフローの組み合わせを有する 新規インターフェースが決定される。本発明によれば、末端のホストは、同一のセッション複数のフローに共通するボトルネックをラーンして、アプリケーションに特有の基準に基づいて、これらのフロー間でリソースを動的に調整することにより最適な性能を得ることができる。
【００２６】
　また、本発明の目的と有利な効果は、発明の好適実施形態が明確に示されている添付の図面を参照した以後の記載から明らかとなろう。
【発明を実施するための最良の形態】
【００２７】
　図１を参照して、本発明に係る実施形態におけるデータネットワーク１００で使用される、端末ベースのリソース予約プロトコルを説明する。
　データネットワーク１００には、第１のアクセスネットワークと接続された受信端末（あるいは受信ホスト）１０２が含まれる。図１に示される第１のアクセスネットワークは無線アクセスネットワークであり、アクセスネットワークのサーバ１０８に接続され、無線タワーの上などに設置される基地局１０６を含んでいる。アクセスネットワークのサーバ１０８は、少なくとも一つのルータ１１０と接続している。ルータ１１０は、第２のアクセスネットワークと１１２と接続していて、このネットワーク１１２は、通常、第１のアクセスネットワークと同一の構成要素とアプリケーションを備えている。第２のアクセスネットワークは受信端末１１４と接続している。
【００２８】
　データネットワーク１００は、図１では例示する目的で、無線データネットワークとして示されている。データネットワーク１００は、本発明の別の実施形態において有線データネットワーク となることもある。第１のアクセスネットワーク１０４および第２のアクセスネットワーク１１２は、有線ネットワークでも無線ネットワークでも良い。また、送信端末１０２および受信端末１１４は、無線ホストであっても固定のホストであっても良い。特許請求の範囲で特に述べていない限り、図１に無線アクセスネットワークが示されていることをもって、本発明を制限するものと解釈してはならない。
【００２９】
　図１および図２をまとめて参照して、受信端末１１４で動作しているアプリケーションセッション２００、あるいは、端末セッション２０１からの複数のデータフローに対して特定のＱｏＳを要求する際に受信端末１１４が使用する端末ベースのリソース予約プロトコルを説明する。ルータ１１０は、要求されたＱｏＳの水準の状態を達成および維持するために、データフローの経路に沿った全てのノードあるいはルータ１１０に予約要求メッセージを、リソース予約プロトコルにしたがって送信する。端末ベースのリソース予約プロトコルは、ルータ１１０に 単一方向のデータフローとなるようなリソースを要求する。送信端末１０２は、受信端末１１４から論理的に別のものである。一つの受信端末１１４は複数の送信端末１０２と同時に接続することができる。
【００３０】
　セッション２０１に対する予約要求メッセージは、受信端末１１４により生成され、データパスに沿ったルータ１１０のリソース予約プロトコル処理モジュール２０２に渡される。リソース予約プロトコル処理モジュール２０２は、予約要求メッセージを生成するために使用される。プロトコルメッセージにより、受信端末１１４から送信端末１０２までの逆向きのデータパスに沿った全ルータ１１０に予約要求メッセージが送られる。受信端末１１４のリソース予約プロトコルモジュール２０２が、予約要求メッセージの生成を担い、ルータ１１０のリソース予約プロトコル処理モジュール２０２が、データパスに沿った全ホップ、すなわちルータ１１０への予約要求メッセージの転送を担っている。
【００３１】
　データフローに対するＱｏＳは、受信端末１１４およびルータ１１０に一組の転送量制御モジュールを配置させることによって実装されている。転送量制御モジュールはデータフローについて、接続の設定および維持、ならびにＱｏＳの設定おっよび維持を担っている。転送量制御モジュールは、一般的に、パケット分類モジュール２０４、アドミッション制御モジュール２０６、およびパケットスケジューラ２０８を有する。各受信端末１１４およびルータ１１０は、転送量制御モジュールを備えていることが好ましい。
【００３２】
　パケット分類モジュール２０４は、各パケットについてＱｏＳのクラスを決定する。パケット分類モジュール２０４が、各パケットの経路の決定を担うようにしても良い。パケットスケジューラ２０８が決められたＱｏＳを達成する。予約設定の間、予約要求メッセージが、受信端末１１４およびルータ１１０のアドミッション制御モジュール２０６およびポリシー制御モジュール２１０に渡される。アドミッション制御モジュール２１０は、要求された水準のＱｏＳを提供するために利用できるリソースをノードが十分に備えているかを決定する。ポリシー制御モジュール２１０は、利用者がルータ１１０においてＱｏＳ予約をする管理許可を有するかどうかを判断する。両方の検査を通ると、要求されたＱｏＳを得るために、パケット分類モジュール２０４およびパケットスケジューラモジュール２０８にパラメータが設定される。検査を通ることができないと、誤り通知がルータ１１０から受信端末１１４に送信される。
【００３３】
　端末ベースのリソース予約プロトコルは複数のタイプのメッセージを有する。各受信端末１１４は、予約要求を生成し、上流の送信端末１０２に送信する。予約要求は、データパケットが送信端末１０２まで移動する逆の経路にしたがって移動する。予約要求メッセージはデータパスに沿った各ルータ１１０において予約状態を生成する。その後、予約メッセージが送信端末１０２に送信されるので、送信端末１０２は、データパスに沿った第１のホップに対して適切な転送制御パラメータを設定することができる。
【００３４】
　予約メッセージには、フロー仕様（flowspec）オブジェクトとフィルター仕様が含まれていることが好ましい。フロー仕様オブジェクトは、２組の数字パラメータを含む。第１の数字パラメータはRSPECと称し、要求された所望のＱｏＳの水準を画定する。第２の数字パラメータはTSPEC と称し、データフローの転送特性を示す。フロー仕様により画定されるＱｏＳで受信するデータパケットの集合は、フィルター仕様およびセッション仕様により画定される。フロー仕様は、ルータ１１０のパケットスケジューラモジュール２０８でパラメータを設定する際に使用される。フィルター仕様は、ルータ１１０のパケット分類モジュール２０４でパラメータを設定する際に使用される。
【００３５】
　予約要求メッセージは、データ経路１１０に沿った各ホップ、すなわちルータ１１０において、アドミッション制御モジュール２０６およびポリシー制御モジュール２０８に渡される。 アドミッション制御モジュール２０６あるいはポリシー制御モジュール２０８がこの要求を認めることができない場合、エラーメッセージが生成され、受信端末１１４に送信される。両方のモジュールで要求が認められると、ルータ１１０は、フィルター仕様により画定されるデータパケットを選択するようにパケット分類モジュールを設定し、フロー仕様により画定される要求されているＱｏＳの水準を提供するように適切なリンク層とともに動作する。ルータ１１０は、予約要求メッセージを送信端末１０２までのアップストリームに転送することも担っている。
【００３６】
　ＲＳＶＰのような端末ベースの予約プロトコルは、４種の基本メッセージをサポートする。４種の基本メッセージは、予約要求メッセージ、経路メッセージ、エラーおよび確認応答メッセージ、および破棄メッセージである。各送信端末１０２は、経路メッセージを生成し、ルーティングプロトコルにより提供されたユニキャストあるいはマルチキャストデータルートに沿ったダウンストリームに送信する。経路メッセージはデータパスに沿った各ルータ１１０における経路状態を格納している。経路状態は、前となるホップノード、すなわちルータ１１０のユニキャストＩＰアドレスを少なくとも含んでいて、ホップ一つずつ予約方向に、予約メッセージの経路を定める際に使用される。
【００３７】
　送信される全てのメッセージは、データフローを識別するセッションオブジェクトを含んでいる。セッションオブジェクトは、データフローの送信先ＩＰアドレス、プロトコルＩＤ、および送信先ポート番号を含んでいる。各データソースは、定期的に、経路メッセージを送出して、送信端末１０２から受信端末１１４までの経路に沿ったルータ１１０における経路状態を設定する。
【００３８】
　３個のエラーおよび確認応答メッセージが、通常、予約プロトコルと共に使用される。これらのメッセージには、経路エラーメッセージ、予約要求エラーメッセージ、および予約要求確認応答メッセージが含まれる。経路エラーメッセージは経路エラーがあると生成され、ホップ毎荷に経路が決定される。予約要求エラーメッセージは予約要求に起因して生成され、受信端末１１４まで伝達される。エラーメッセージには、アドミッションができない旨の表示、帯域が利用できない表示、サービス提供がない旨の表示、 およびフロー仕様の誤り等の情報が含まれていることが好ましい。予約要求メッセージに予約確認オブジェクトが含まれていると、予約要求確認応答メッセージが送信される。破棄メッセージは、イニシエーションの場所からダウンストリームにあるすべてのルータ１１０から経路と予約状態を解除する。
【００３９】
　本発明の好適実施形態において、各端末セッション２０１は一つあるいは複数のアプリケーションセッション２００を有する。この複数のアプリケーションセッション間の相対的な重要性や重み付けは動的に変化するものである。各アプリケーションセッション２００も、ユニキャスト転送による、あるいはマルチキャストツリーに申し込むことによる複数の弾力性のあるフローを有している。現在のネットワーク転送負荷に基づいて予約が異なる水準（level）で行えるように、各フローは、階層毎に（by layers）あるいは、順送りに符号化される。また、受信端末１１４は特定用途の性能を最適化する基準および端末性能を全体としての高める基準を知ることができる。一つの端末セッション２０１に複数のフローが含まれ、このうちいくつかのフローの予約がデータパスに沿ったボトルネックにおいて競合すると、このことが受信端末１１４に通知され、受信端末１１４は、個別の基準に従って各フローの予約要求を調整する。シグナリングプロトコルはボトルネックの位置およびボトルネックを共有するフローに関する情報を収集し、この情報を受信端末１１４に転送する。
【００４０】
　コアデータネットワーク１００も、ＱｏＳをサポートすることができなければならない。なぜなら、エンドツーエンドのＱｏＳは最弱リンクと同一となるからであり、もしコアデータネットワーク１００が単なるベストエフォートサービスに基づくものならば、エンドツーエンドのＱｏＳ を保証するために制御できるものがないからである。コアデータネットワーク １００はＱｏＳ能力が備わっているので、ＲＳＶＰ等の接続志向のリソース予約プロトコルを使用することができる。ＲＳＶＰプロトコルにはスケーラビリティの問題があるけれども通信回線の混雑の起こりにくい末端のネットワークにおいてならばＲＳＶＰプロトコルを利用できる。特に、通常の無線アクセスネットワークの場合、無線リンクは帯域が狭くデータのロスが多いので、無線リンクはボトルネックとなってもスケーラビリティが主要な問題とはなりそうにない。
【００４１】
　本発明は、動的予約モジュールと予約シグナリングプロトコルとのインターフェースを受信端末１１４に提供する。上述したように、統合サービスフレームワークは、パケット分類モジュール２０４、アドミッション制御モジュール２０６、パケットスケジューラモジュール２０８、およびポリシー制御モジュール２１０等の、複数の相互に関係するモジュールを含む。分類モジュール２０４は、送信元が送信する転送量、リソース、および、データネットワーク１００がデータ転送について公約しているサービスの詳細が記載されたサービス契約を有する。シグナリングモジュール 、すなわち経路制御処理モジュール２１２は、 データパスに沿ってホップして進むために使用されるプロトコルを提供し、ルータ１１０に予約状態をインストールするために使用できる。
【００４２】
　ルータ１１０におけるアドミッション制御モジュール２０６は、送信元の使用を監視することにより予約要求を受理するかどうかを決定する。ポリシー制御モジュール２１０は、データフローが予約をする権限が与えられているかを決定し、ポリシーに基づく他の決定をするために使用される。データフローによる予約がポリシー制御モジュールあるいはアドミッション制御モジュールでうまくいかないと、予約要求は各ルータ１１０により拒絶される。リソース予約の最後に、パケットスケジューラモジュール２０８によりパケットスケジューリングが行われる。パケットスケジューラモジュール２０８が、各ルータ１１０において出力ポートの準備ができると、送信するパケットを選択することによりリソースの割り当てをおこなう。
【００４３】
　先に述べたように、複数のデータフローの中から予約要求メッセージを受信端末１１４が動的に調整する、セッションベースの予約を実現するためには、さらに情報を収集しなければならない。以下、受信端末１１４における動的予約調整モジュール２１４に含まれる動的予約調整アルゴリズムの詳細を説明する。このアルゴリズムは、データパスに沿ったルータ１１０に送信される予約要求メッセージに含まれる情報を調整し、したがって、複数のデータフローの中で予約を調整するために使用される。
【００４４】
　動的予約調整アルゴリズムは受信端末１１４では動作するが、中間ルータ１１０では動作しない。なぜなら、アプリケーションセッション２００だけが、各データフローの相対的な重要性および同格のフローについての全体としてのボトルネックを判断することができるからである。受信端末１１４は、自身の基準に基づいて柔軟に、異なる動的予約調整アルゴリズムを実装することができる。この基準は、２階層のモジュール、すなわち、端末における異なるアプリケーションの相対的な重要性を指定する端末セッションモジュール、および、アプリケーションセッションの複数のフローの相対的な重要性を指定するアプリケーションモジュールにより特定される
【００４５】
　本発明における好適な動的予約調整アルゴリズムを以下に説明する。ここで、まず、アプリケーションセッションＳがni個のサブフローSi, i ∈ [ １, …,ni ]を有すると仮定する。次に、全てのサブフローSi,について、階層（layering）帯域要件が存在し、Ri１ <=Ri２ …<=Rij,j ∈ [ １, …,nij ]が成立すると仮定する。第３に、各ボトルネ
ック Li に対して、ボトルネックLiを共有するとともに予約ELiをおこなうアプリケーションセッションＳの部分集合SLi が存在すると仮定する。最後に、動的予約調整アルゴリズムが、全てのボトルネックLiに対してRmj < ELi , m ∈  SLiの条件の下、アプリケーションセッション２００の性能関数F（S１, S２, .., Sni）を最適とするように、サブフローSiの配分を決定すると仮定する。
　課題をこのように定式化すれば、性能関数F（S１, S２, .., Sni）.の選択に応じて、各同格なデータフローへの予約の最適な割り当ては、本実施形態とは異なる線形、あるいは非線形計画法を利用して見つけることもできる。
【００４６】
　動的予約調整アルゴリズムを解析することにより、さらに３個の追加情報が必要であることが判明した。この追加情報は、１）各個別データフロー階層情報、すなわち帯域の調整能力（つまりRijの性質）、２） ボトルネックを共有している同格のフローの組み合わせ（つまりSLiの性質）、および、３）中間ルータ１１０ですでに行われた予約（つまりEliの性質）である。
【００４７】
　階層情報についての情報を同時に取得することができるように、アプリケーションセッション２００は、データサービスが追加される前に、図示されていないアプリケーションサーバからサービスについての情報を入手しなければならない。したがって、シグナリングプロトコルに関して、Rijについての情報はオフラインで取得できるものと考えられる。つまり、パート２および３の情報のみが、シグナリングプロトコルにより収集される必要がある。シグナリングプロトコルは、この情報を効率よく収集する方法と、部分予約状態を更新するためにこの情報を利用する方法に特化している。
【００４８】
　図２を参照してされに説明する。受信端末も部分リソース予約モジュール２１６を有していることが好ましい。部分リソース予約モジュール２１６は、ルータ１１０で行われた部分リソース予約を生成・維持するために利用される。部分リソース予約は、各ルータ１１０が経験するボトルネックを補償するために利用できるパケットのサブフロー に対するものである。動的予約調整モジュール２１４は、部分リソース予約モジュール２１６から、ユニキャストパケットフローが補償される必要があることおよび所定のＱｏＳ水準を維持するためにしなければならない補償量についての情報を得る。
【００４９】
　好適なシグナリングプロトコルは、受信端末ベースの予約プロトコルであり、ＲＳＶＰを修正して、部分予約能力と、新しい予約で更新する能力と、ボトルネックのフィードバック能力とを統合するものである。端末セッション２０１は、ユニキャストのピアとの通信、あるいは、ＲＳＶＰが動作しているマルチキャストグループへの参加のためにＲＳＶＰシグナリングプロトコルを各々利用している、複数のユニキャストデータフローを有していると考えられている。リソース予約がうまくいくときは、通常のＲＳＶＰプロトコルと同様に予約がおこなわれる。しかし、データフローがうまくいかないときは、本発明によれば、ボトルネックについての必要な情報が収集され、受信端末１１４にこの情報が与えられる。それから、受信端末１１４に配置された動的予約調整アルゴリズムに基づいて、最適なサブフロー予約が計算され、各ルータ１１０において既存の部分予約および完全予約が更新される。アプリケーションセッション２００により既に予約されている中で予約更新が実行され、更新が終了して通常の状態となる。
【００５０】
　新しいシグナリングプロトコルによれば、同一の端末セッション２０１の複数のデータフローに対して共通するセッションＩＤが与えられる。共通セッションＩＤは、ＲＳＶＰヘッダーのＲＳＶＰオブジェクトか、あるいはＩＰ拡張フィールドのいずれかによって運ばれても良い。 中間ルータ１１０において予約が認められると、通常の５タプル（送信元アドレス、送信先アドレス、送信元ポート、送信先ポート、およびプロトコルのタイプ）およびセッションＩＤの両方が記憶される。その後、アドミッション制御に失敗する予約があると、このルータ１１０を通過し、同一のセッションＩＤを共有する全てのデータフローについての情報 が受信端末１１４に返送される。このように、ボトルネックの位置、競合するフローの組み合わせおよびルータ１１０において既に予約されているリソースについて受信端末１１４が知ることになる。
【００５１】
　本発明によれば、ルータ１１０において部分予約も可能である。ＲＳＶＰは通常、部分予約をサポートしていないので、あるルータ１１０において予約要求に失敗すると、ルータ１１０は、単に失敗通知を返信し、データフローに「封鎖状態」とフラグをつける。 後に、ソフト状態が終了すると、ダウンストリームにおけるルータ１１０で既にされている 予約が収集される。同格のデータフローの中における最適な予約配分を計算するために、 データフローに沿ったすべてのボトルネックが検出される必要があり、利用することができるリソースがルータ１１０で予約されなければならない。部分予約をサポートすることしているので、本発明によれば、アドミッション局所制御過程において予約要求がうまくいかない場合でも、予約要求がアップストリームに流れることができる。このように、より上流のルータ１１０において予約済みであるから、必要なこれらの情報を収集することができ、同時に、更新手続きが高速化される。
【００５２】
　本発明によれば、予約について複数の選択肢がある。ＲＳＶＰは予約過程においてＴＳＰＥＣのみをサポートする。ＲＳＶＰによれば、失敗通知を受信すると、受信端末１１４が予約要求を調整することが要求されている。更新時間を減少するために、本発明によれば、現在の負荷に基づいて可能で最大な予約をできるように、ルータ１１０は予約要求メッセージに複数のＴＳＰＥＣを含めることができる。この場合、予約されるリソースの情報および同格のフロー情報があれば、それらが含まれるようにエラーあるいは障害メッセージが生成され、受信端末１１４に送信される。ルータ１１０において無駄になるリソースを削減するために、中間ルータは、時間の短いタイマーを利用して未更新の状態を収集することができる。好適実施形態において、予約端（送信端か合流端のいずれか）によって生成されたこの中間ルータ１１０に対する確認応答メッセージが、予約の状態を調べるために利用される。
【００５３】
　本発明によれば、各ルータ１１０について、予約更新フェーズが存在する。ルータ１１０において部分予約がサポートされ、積極的に予約が行われるので、予約更新フェーズが必要となる。全ての予約がうまくいくと、更新フェーズが省略され、本プロトコルはＲＳＶＰと同様に働く。障害やエラーが生じると、予約の更新が行われなければならない。続いてその詳細を説明する。データフロー最適配置が計算された後、更新フェーズにおけるメッセージにより配置に関連する情報が送出される。同格のフローが同一のボトルネックを共有していると、予約されたりソースがこれらのフローの間で再配分される。リソースが既に利用できているので、この再配分の過程は必ずうまくいくことが補償されている。
【００５４】
　以上説明してきたように、本発明によれば，動的リソース予約調整アルゴリズムを備えた受信端末１１４が提供される。 本発明に係るプロトコルによれば、動的リソース予約調整アルゴリズムに関連する情報が入力され、その出力を利用して、各ルータ１１０における最適なリソース予約が実現される。こうして、データパスに沿ったルータ１１０においてボトルネックが生じた時に、各ルータ１１０において予約されたリソースを動的に調整することができる。
【００５５】
　本発明の別の実施形態は、ルータ１１０からのデータフローに対する加入および離脱の修正された手続きを提供する。データフローがアプリケーションセッション２００、すなわち端末セッション２０１に加入するか、あるいはこれから離脱する場合には、取扱いがＲＳＶＰのものとは同一ではない。なぜなら、ここにおけるセッションはマルチキャストツリーではないからである。データフローがアプリケーションセッション２００に加入しようとする際、データフローがルータ１１０に個別に予約要求をする。予約要求に成功しても、別のデータフローの予約は影響を受けない。予約がうまくいかないと受信端末１１４は各ルータ１１０から与えられるフィードバックメッセージを利用して最適配置を再計算し、影響を受けるデータフローに更新メッセージを送出する。こうして、サービスの中断が最小の程度まで減少する。
【００５６】
　データフローが端末セッション２０１を離脱すると、このデータフローによる予約はルータ１１０に返されることになる。受信端末１１４は、ボトルネックを除き、データフロー全体のトポロジーを知ることはないので、同一のアプリケーションセッション２００における、このデータフローと同格のフローは、このリソースを要求することはできない。このことは明らかに問題となる。なぜなら、より良い性能を得るためには、フローが自身の予約を同格のフローにすすんで与えるからである。フローは、アプリケーションセッション２００から同格のフローが離脱しても、そのリソースを取り戻すことができない。したがって、寿命の長いデータフローの有する予約は連続的に減少していく。
【００５７】
この課題を部分的に解決するために、同一のアプリケーションセッション２００の他のデータフローがルータ１１０を通っているときは、中間ルータ１１０が破棄メッセージを受信してデータフローから対応するリソースが解放されても、リソースはルータ１１０に直ちに戻されることはない。このリソースはアプリケーションセッション２００のために、ある程度の時間、予約される。したがって、この後、アプリケーションセッション２００にデータフローが加わる際に、この加わるデータフローは、同格のデータフローから帯域幅を要求することなく、リソースを戻すように要求することができる。予約バンクとは「ソフト状態」であり、アプリケーションセッション２００により使用されていないと、ルータ１１０により所定の時間間隔で収集される。また、移動による変化がフローにあってもその移動が局所的なものに留まるときは、新しい経路と古い経路とが共通のリンクを共有することがあるので、アプリケーションセッション２００のリソースバンクによれば、新しいデータフローの予約がうまくいく可能性が増すという理由からも、このように取り扱うほうが良い。
【００５８】
　図３は、受信端末１１４が、アプリケーションセッション２００に対するデータフロー構成の更新をする際の過程を示すフローチャートである。受信端末１１４はデータフローの離脱、データフローの加入、あるいはデータフローの変形等の変化がおきたかどうかを判断する（ステップ３００）。変化がないときは、予約更新メッセージが生成されルータ１１０に送出されるが、各ルータ１１０においてなんら予約に変化が生じるものではない（ステップ３０２）。
【００５９】
　データフローに変化があると、変化したデータフローに対して受信端末１１４が新しい予約メッセージを生成し、アップストリームの各ルータ１１０に送信する（ステップ３０４）。 受信端末１１４は、データパスに沿ったルータ１１０からの全てのフィードバックメッセージを収集する（ステップ３０６）。フィードバックメッセージには、各ルータ１１０における予約要求の成功／失敗／単なるタイムアウトを示している。フィードメッセージには、予約要求メッセージがうまく通らなかったデータパスに沿ったルータ１１０におけるボトルネックについても含まれていることが好ましい。受信端末１１４は、ルータ１１０からのフィードバックメッセージに含まれる情報を利用して、エンド・ツー・エンドのデータパスのどこにボトルネックが存在しているかを決定して、ボトルマップの位置を示すボトルマップ地図を作成する（ステップ３０８）。動的リソース予約調整アルゴリズムを使用することにより、受信端末１１４は、最適データフロー予約を計算して、アプリケーションセッション２００からの 各データフローに必要とされるＱｏｓをルータ１１０において充足させる。 この計算に基づいて、受信端末１１４はリソース予約更新メッセージを生成し、アップストリームの各ルータ１１０に送信する。リソース予約更新メッセージにより、エンド・ツー・エンドパスにおける既知のボトルネックに基づいてルータ１１０におけるリソース予約が調整される。
【００６０】
　図４は、ルータ１１０が実行する処理過程を示すフローチャートである。ルータ１１０は、受信端末１１４から送信されたリソース予約要求を受信する（ステップ４００）。ルータ１１０は、リソース要求に適合できるかどうかを判断する（ステップ４０２）。ルータ１１０が適合できるときは、要求されたリソースがルータ１１０で予約される（ステップ４０４）。 ルータ１１０が適合できないときは、ルータ１１０は、データフローに対する許容最大リソースを、すなわち利用できる帯域幅を決定して、予約要求に部分予約の印を付ける（ステップ４０６）。ルータ１１０は、セッションＩＤを利用して、同一の端末セッション２０１のサブフローを検出して、障害フィードバックメッセージを生成する（ステップ４０８）。
【００６１】
　ルータ１１０は、アプリケーションセッション２００の既存のデータフロー予約と予約要求を一体にすることができるかを判断する（ステップ４１０）。統合することができるときは、ステップ４１２に進んで、ルータ１１０は確認応答メッセージを生成して、受信端末１１４に送信する。統合することができないときは、ステップ４１４に進んで、ルータ１１０は予約要求を上流の次にあたるルータ１１０に送る。
【００６２】
　既存のプロトコルの利点を組み合わせて本アプリケーション事例にうまく適合させることによって、本発明は、効率的かつ強力なシグナルプロトコルを提供する。本発明によれば、シグナリングのオーバーヘッドが少なくなり、アプリケーションの性能が最適化され、無線アクセスネットワークに最適化されていて、ＲＳＶＰ等の既存の予約プロトコルに必要な修正は最小限ですむ。
【００６３】
　従来のＲＳＶＰは、１−パスのプロトコルであり、予約がうまくいけば良いが、予約がうまくいかないと遅延が長くなるという特性を有する。
本発明は、予約がうまくいけば１−パスであり、予約がうまくいかないと２−パスとなるアルゴリズムを利用する。第１のデータパケットに更新情報を相乗りさせることにより、本発明は１−パスとなるように、さらに最適化することができる。
【００６４】
　端末セッション２０１において一つ以上のサブフローが変化しても、各サブフローについて予約を繰り返す必要はない。このことにより、オーバーヘッドが減少し、以前うまく行った予約を再予約するときに失敗する可能性が減少する。このことにより、新しく付け加わった、あるいは新しく変化したサブフローの予約がうまく行く可能性も増大する。
【００６５】
　本発明は、無線による最後のホップがボトルネックになりがちな無線アクセスネットワークに適している。また、本発明は、通信回線が混雑しやすく、シグナリングのスケーラビリティが重要な問題とはならない、地方のＩＳＰ（Internet Service Provider）によるネットワークにも適している。また、本発明は、リソース予約のボトルネックおよびボトルネックにおける競合するピアフローについての知識を強化した、アドミッション制御とシグナリングプロトコルとの間のインターフェースも提供する。
【００６６】
　以上、本発明の実施形態について様々述べてきたが、この他にも実施や実装が可能であること、および、これらの実施形態、実装形態も本発明の範囲に属しうることは、この技術分野における通常の知識を有するものには明白である。したがって、本発明は、特許請求の範囲およびその均等となる範囲を考慮する以外には、制限されることはない。
【図面の簡単な説明】
【００６７】
【図１】本発明に係る実施形態におけるコアデータネットワークを示す図。
【図２】受信端末のアプリケーションモジュール群と、ルータのアプリケーションモジュール群とを示す図。
【図３】受信端末が実行する処理過程を示すフローチャート。
【図４】データパスに沿ったルータが実行する処理過程を示すフローチャート。
【符号の説明】
【００６８】
１００・・・データネットワーク、１０２・・・送信端末、１０４・・・第１のアクセスネットワーク、１０６・・・基地局、１０８・・・サーバ、１１０・・・ルータ、１１２・・・第２のアクセスネットワーク、１１４・・・受信端末、２００・・・アプリケーションセッション、２０１・・・端末セッション、２０２・・・ＲＳＶＰ処理モジュール、２０４・・・パケット分類モジュール、２０６・・・アドミッション制御モジュール、、２０８・・・パケットスケジューラモジュール、２１０・・・ポリシー制御モジュール、２１２・・・経路制御処理モジュール、２１４・・・動的予約調整モジュール、２１６・・・部分リソース予約モジュール
【図１】
2004147334.tif 000003
【図２】
2004147334.tif 000004
【図３】
2004147334.tif 000005
【図４】
2004147334.tif 000006