JPH1127316A - ネットワークの通信品質制御システム - Google Patents

Abstract

(57)【要約】 【課題】 インターネットにおいて、要求順序に拘束さ
れることなく、アプリケーションの実行を適切に且つ効
果的に制御して、有効なＱＯＳ保証を実現する。 【解決手段】 ＴＣＣ１は、インターネット７上のＱＣ
Ａ内で動作するアプリケーションにおけるサービス品質
を監視し、適切に制御すべく各アプリケーションに対す
る制御情報を生成する。ＴＣＣ１は、ＱＣＡ内のリソー
スの利用状況をチェックして常時把握し、アプリケーシ
ョンからのリソースの要求に対して、所定の優先度に従
ってリソース配分を制御することにより、各アプリケー
ションの実行優先度を制御したり、ネットワークの過負
荷を防止しあるいは負荷を平滑化したりする。ＴＣＢ３
は、アプリケーションシステム４，５で実行されるアプ
リケーションのサービス品質に関する要求内容をＴＣＣ
１に供給するとともに、該ＴＣＣ１から与えられる制御
情報に基づいて各アプリケーションの動作を制御する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、ネットワークに
おける通信サービスの品質を保証するための技術に係
り、特に通信プロトコルとしてＩＰ（Internet Protoco
l〜インターネットプロトコル）を用いるＩＰネットワ
ークにおけるマルチメディア情報通信処理システムの通
信品質保証に好適なネットワークの通信品質制御システ
ムに関する。

【０００２】

【従来の技術】インターネット回線の高速化及びマルチ
メディアパソコン（パーソナルコンピュータ〜Personal
Computer、すなわちＰＣ）の普及に伴い、トランザク
ションデータだけでなくオーディオ（音声）、静止画、
及び動画等のいわゆるマルチメディアを転送するマルチ
メディア通信サービスが可能となってきた。

【０００３】このような状況において、企業がインター
ネットをビジネスに利用したいとする要求が高まってき
ている。ビジネスで利用されるネットワークには高い品
質と信頼性が求められる。

【０００４】しかし、インターネットにおける主たる通
信プロトコルであるＴＣＰ／ＩＰ（Transmission Contr
ol Protocol/Internet Protocol）は、その特徴に起因
して、通信サービスにおいて必ずしも高い品質を提供で
きていない。ＴＣＰ／ＩＰは、ＯＳＩ（Open Systems I
nterconnection〜開放型システム間相互接続）モデルに
おけるトランスポート層に対応するプロトコルとしてＴ
ＣＰ（Transmission Control Protpcol）を用い、ＯＳ
Ｉモデルにおけるネットワーク層に対応するプロトコル
としてＩＰを用いる方式である。このＩＰをネットワー
ク層のプロトコルとして用いるネットワーク、つまりＩ
Ｐネットワークは、インターネット等を含む。

【０００５】このＴＣＰ／ＩＰを用いるインターネット
が高い品質を提供できない最大の理由は、ネットワーク
層のプロトコルであるＩＰがベストエフォート（best e
ffort〜最善努力）のプロトコルであり、通信サービス
の品質を保証していないためである。すなわち、ＩＰ
は、アプリケーションプログラム（ＡＰ：ApplicationP
rogram〜以下、単に「アプリケーション」と称する）の
ためのベストエフォート、つまり相手への情報転送に最
善を尽くし、転送情報自体については十分な品質を保証
していない。このため、インターネットに関しビジネス
の利用に耐え得るようなＱＯＳを保証したいという要求
がある。

【０００６】そこで、最近、インターネットにおけるＱ
ＯＳ（通信サービスの品質）の保証のための様々な議論
と試みがなされている。

【０００７】〔ＱＯＳ保証の考え方〕ＱＯＳという観点
におけるインターネットの特徴を、プロトコル、パケッ
ト交換及びルーティングについてそれぞれ列挙すると、
次の通りである。

【０００８】〈プロトコル〉 (1) インターネットのネットワーク層のプロトコルであ
るＩＰは、ベストエフォートのプロトコルであり、アプ
リケーションのために相手への情報転送に最善をつく
す。しかし、このＩＰでは、情報転送に最善をつくすこ
とから、ネットワークの状態によって通信パケットの順
序が入れ替わったり、通信帯域が充分に確保できないと
きは、通信情報がバッファに保留されたり、あるいは通
信パケットが紛失してしまったりすることもある。した
がって、ネットワークサービスという観点では、着実に
情報が転送されなかったり、予想以上の遅延が発生した
りすることが起こり得る。

【０００９】(2) トランスポート層のプロトコルとして
は、ＴＣＰの他にＵＤＰ（User Datagram Protocol）が
使用されることもある。トランスポート層のプロトコル
であるＵＤＰはコネクションレス型のデータグラム配送
を実現するものであり、情報が相手先へ確実に到達する
ことを保証しない。このため、ＵＤＰは、転送における
遅延を低減することは可能であるが、信頼性を提供する
ものではない。

【００１０】(3) ＵＤＰと同様にトランスポート層の
プロトコルであるＴＣＰは、ＵＤＰとは対照的にコネク
ションオリエンテッドなプロトコルであり、信頼性を提
供する。しかしながら、ＴＣＰは、信頼性を提供するこ
との代償として処理上のオーバヘッドがある。

【００１１】〈パケット交換〉上述したベストエフォー
トであることと関連するが、インターネットはパケット
による情報通信であるため、トラフィックの状況によっ
ては、ネットワークのルータ内にパケットが滞留するこ
とがある。このため、高度のリアルタイム性（実時間
性）が要求されるリアルタイム通信には、インターネッ
トは不向きである。

【００１２】〈ルーティング（経路制御）〉送信側ノー
ドと受信側ノードとの間には、パケットの転送ルートを
制御する複数のルータが存在する。これらのルータは、
隣接するルータ相互間で情報を交換し合うことにより他
ノードへの経路つまりルートを定めている。すなわち、
ネットワークの接続形態によって、情報転送ルートがあ
らかじめ一意に定まってしまう。しかし、一部のアプリ
ケーションにおいては、動的にルートを変更して、スル
ープット、遅延、あるいはエラーレートに関するユーザ
の様々な要求を満たすようにすることが望まれつつあ
る。

【００１３】次に、サービスタイプ別のＱＯＳについて
検討する。ここでは、インターネット上のサービスが要
求するＱＯＳを、ネットワークが提供する伝送品質及び
信頼性等をあらわすパラメータの組み合わせによって定
義する。これらのパラメータは次の通りである。 (a) 遅延の平均及び遅延の分散（ジッタ） (b) 単位当たりのデータ量（帯域）及びその分散 (c) データロス率及び分散

【００１４】これらに基づくサービスタイプ別のＱＯＳ
の考え方は次の通りである。 〔１〕放送型一方向リアルタイム通信 具体例：ＶＯＤ（Video on Demand〜ビデオオンデマン
ド）、放送型サービス ＱＯＳ：遅延分散（ジッタ）の最小化 〔２〕電話型双方向リアルタイム通信 具体例：電話、ビデオ会議型サービス ＱＯＳ：遅延、ジッタの最小化 〔３〕トランザクション型通信 具体例：トランザクション、検索サービス ＱＯＳ：最大遅延、データロス率の最小化 〔４〕データ転送型バースト通信 具体例：ファイル転送サービス ＱＯＳ：帯域の確保、データロス率の最小化

【００１５】次に、インターネット上のサービスのＱＯ
Ｓ保証について検討する。上述したＱＯＳに関してのイ
ンターネットの特徴、すなわちＱＯＳという観点におけ
るプロトコル、パケット交換及びルーティングについて
のインターネットの特徴から次のことがいえる。

【００１６】〈プロトコルについて〉ＵＤＰ上のアプリ
ケーションについては、信頼性が保証できないためトラ
ンザクション型通信やデータ転送型バースト通信には不
向きである。

【００１７】〈パケット交換について〉パケット交換タ
イプであるため、負荷の状況によってはルータ内にパケ
ットが滞留することがあり、遅延の発生が避けられない
ため、リアルタイム通信には不向きである。

【００１８】〈ルーティングについて〉ルーティングが
システムの構成によって固定若しくは動的に決定されて
いるため、ユーザ自身が様々なアプリケーションに適し
た伝送路を選択することができない。したがって、例え
ば、リアルタイム通信のために高速通信回線を利用し、
同報の時には衛星回線を利用しようというように、サー
ビス種別により回線を使い分けることが不可能である。

【００１９】以上説明した通り、インターネットは通信
サービスのＱＯＳ保証という観点では必ずしも理想的な
ネットワークとはいえない。したがって、インターネッ
トを利用して通信サービスを提供するためには、ＱＯＳ
保証の実現方式が大きな課題となる。そこで、以下にお
いて、インターネット上でのＱＯＳ保証を実現するため
の方式について考察する。

【００２０】〔ＱＯＳ保証の実現方式案〕まず、ＱＯＳ
保証の考え方について検討する。通信サービスにおいて
ＱＯＳを保証する最も理想的な方法は、全トラフイック
をまかなうような高速（大束、つまり大容量）で且つ高
信頼な回線を設置することである。しかしながら、現実
には、コストの点から限られた回線が用いられ、回線速
度及び信頼性に制約があるため、先に説明したパラメー
タである遅延、帯域、及びデータロス率のうちのいずれ
かを犠牲にすることになる。

【００２１】ここで、遅延については、回線容量及びこ
の回線上のトラフィック量によってパラメータの値が決
定される。帯域についてのパラメータは、通信のある時
点における転送可能なトラフィック量を示している。ま
た、信頼性に関係するデータロス率に着目すると、例え
ば回線品質が悪いことに起因してパケット紛失が発生し
たり、高トラフィックに起因してパケット落ちが発生し
たりする場合、プロトコル（ＴＣＰ）又はアプリケーシ
ョンレベルで、転送データの再送などを行うことによ
り、要求するデータロス率を保つことが可能である。但
し、このようにすると、再送処理に係るオーバヘッドに
よって、遅延を発生させることになり、性能を犠牲にす
ることになる。この場合、回線容量が十分に大きければ
高トラフイックによるパケット落ちを回避したり再送処
理に係るオーバヘッドによる遅延時間を短縮することが
できる。

【００２２】上述したように、遅延、帯域及びデータロ
ス率はトレードオフの関係があることから、ここでは問
題を簡単化し、ＱＯＳ保証は遅延の回避や帯域の確保に
より実現することができるものとする。この結果、ＱＯ
Ｓ保証の問題は通信回線の容量とトラフィック量の相関
関係に帰着させることができる。すなわち、ユーザが転
送したいデータ量に対しどの程度の帯域を提供できるか
ということがＱＯＳ保証の基本的な考え方となる。ＱＯ
Ｓ保証のためのメカニズム、すなわちＱＯＳ保証を実現
するために必要な機能及びその内容を図６に示す。

【００２３】第１項の品質要求機能、すなわちシグナリ
ング機能は、ネットワークが提供するＱＯＳ用パラメー
タをアプリケーションが指定したとき、これにしたがっ
てネットワーク構成機器のセットアップを行う機能であ
る。この第１項に関しては、ＲＳＶＰ（Resource Reser
vation Protocol）等によるリソース予約機能を採用す
ることができる。

【００２４】第２項のスケジューリング機能は、アプリ
ケーションの要求値に従いパケットの送出を制御する機
能である。この第２項に関してはインターネットでは、
ルータに各種のパケットスケジューリング機能が組み込
まれることになるが、アプリケーションからのＱＯＳ要
求とパケットレベルでの優先制御を対応付けるための仕
組みが必要である。第３項のＱＯＳルーティング機能
は、ＱＯＳを満たすのに適した通信メディアを選択する
機能である。この第３項については、アプリケーション
が要求するＱＯＳとこれを実現するための通信メディア
との適正な対応付けを明確にする必要がある。これら第
２項及び第３項については今後の検討課題であると考え
られる。

【００２５】第４項の提供品質の調整機能は、限られた
ネットワークリソースを有効且つ適正に提供するため、
アプリケーションにどのようなＱＯＳを提供するかのポ
リシーを反映する機能である。この発明は、主としてこ
の第４項の提供品質の調整機能に係るものである。

【００２６】そこで、ＱＯＳ保証時の問題点について検
討する。アプリケーションが要求するＱＯＳの保証の度
合は、そのときに利用する通信回線のリソースに大きく
依存する。すなわち、複数のアプリケーションが要求す
るリソースの合計が、利用する通信回線のリソース内に
収まる時に限り全アプリケーションが要求するＱＯＳは
満足される。それ以外は、一部のアプリケーションがリ
ソースを独占して他のアプリケーションの要求が全く受
け付けられなかったり、要求以下のリソースで通信を行
ったりするといったいわゆるベストエフォートの状態と
なる。

【００２７】この場合の問題はネットワーク全体で見れ
ばリソースに余裕があるにも関わらず局所的な過負荷の
ために実行できないアプリケーションが発生したり、ア
プリケーション実行の緊急度に差があるにも関わらず原
則的に受け付けの順に実行されるということである。こ
のため、べストエフォートの状態にあっても可能な限り
において、リソースを最大限活用したり、緊急度の高い
アプリケーションの実行を優先したりするなどのメカニ
ズムを取り入れることができることが望ましい。その方
法としては、次の２つが考えられる。 (i) アプリケーションの実行前に、アプリケーションが
予め必要なリソースを予約しておく。 (ii) アプリケーション別に実行優先度を付し、この実
行優先度に従ってリソースを配分する。

【００２８】上述の(i)については、ＲＳＶＰ等のリソ
ース予約機能が存在するが、現在の仕様では送受信ノー
ド間のルート内でリソースの有無を調査し、リソースが
確保できないと予約をすることができないため、上述の
問題に対する有効な解決策となってはいない。また、(i
i)については、図６に示したスケジューリング機能によ
りアプリケーションの実行優先度を制御している例もあ
るが、これについてもルータが複数のアプリケーション
から受け付けたイベント間での制御であり、ネットワー
クの広域にわたるアプリケーションの実行優先度をコン
トロールしているわけではない。これらの問題点を有効
に解決するためには、ネットワーク全体でＱＯＳの制御
を行う必要がある。

【００２９】次に、ここで提案するＱＯＳの調整機能に
ついて検討する。上述したＱＯＳ保証時の問題点に関連
して示したようなネットワーク全体を管理する方法とし
ては、ネットワーク内のある限定された範囲において集
中管理する方式と、各ルータに管理機能を持たせてこれ
らの間で分散管理する方式とが考えられる。これらの方
式における特徴を図７に示しており、この図７を参照し
てネットワーク全体の管理方式を比較する。集中管理方
式は、ネットワーク全体を管理することができるため、
分散管理方式と比較して制御が容易であるということが
長所である。しかしながら、この集中管理方式には、制
御のための負荷が集中する可能性があるという短所があ
る。一方、分散管理方式には、管理箇所それぞれについ
ての処理負荷が小さくて済むという長所がある。しかし
ながら、分散管理方式の短所は、全体を管理するために
分散管理における個々の管理箇所間で常時情報交換する
必要があり制御が複雑となることである。

【００３０】

【発明が解決しようとする課題】上述したように、現
在、インターネットにおいてＱＯＳを保証するための手
法として、リソース、例えば帯域を予約するＲＳＶＰ
（Resource Reservation Protocol）等のリソース予約
プロトコルが開発されている。インターネットでは、基
本的に送受信間のルートはルータによって一意に定めら
れ、ＲＳＶＰ等のリソース予約プロトコルは、基本的
に、送受信ノード間のルートにおけるリソースを予め予
約するものである。

【００３１】したがって、ＲＳＶＰ等のリソース予約プ
ロトコルによるＱＯＳの調整には次のような問題があ
る。 (a) リソースの予約は、基本的に要求の順に行う。この
ため、緊急度の高いアプリケーションの実行を、先に要
求を発したアプリケーションよりも優先させるなどとい
う制御が不可能である。 (b) 複数のアプリケーションの通信ルートが重なった場
合、迂回ルートが存在すればそちらへ転送しリソース競
合を回避できるケースもある。しかしながら、現在のイ
ンターネットにはトラフィックの状態によって通信を迂
回させる機能が設けられていないため、複数のアプリケ
ーションの通信ルートが重複すると、リソースの予約が
できないという事態が発生する。

【００３２】この発明は、上述した事情に鑑みてなされ
たもので、ＩＰプロトコルを用いるネットワークにおい
て、簡単な構成により、別途に設定される優先度に基づ
いて、要求順序に拘束されることなく、アプリケーショ
ンの実行を適切に且つ効果的に制御して、有効なＱＯＳ
保証を実現し得るネットワークの通信品質制御システム
を提供することを目的とする。また、この発明は、アプ
リケーションの実行を適切に且つ効果的に制御して、有
効なＱＯＳ保証を実現し得るネットワークの通信品質制
御システムを提供することを目的とする。

【００３３】

【課題を解決するための手段】上記目的を達成するた
め、この発明の第１の観点によるネットワークの通信品
質制御システムは、ネットワーク上で動作する複数のア
プリケーションにおけるサービス品質を監視し、該サー
ビス品質を適切に制御すべく各アプリケーションに対す
る制御情報を生成するトラフィック制御手段と、前記ネ
ットワークとアプリケーション実行システムとの間に介
在し、該アプリケーション実行システム上で実行される
アプリケーションのサービス品質に関する要求内容を前
記トラフィック制御手段に供給するとともに、前記トラ
フィック制御手段から与えられる制御情報に基づいて前
記アプリケーション実行システム上の前記各アプリケー
ションの動作を制御する補助制御手段と、を具備する。

【００３４】第１の観点にかかるネットワークの通信品
質制御システムにおいて、前記トラフィック制御部は、
ネットワーク上で動作する全アプリケーションのＱＯＳ
を監視し制御するための集中コントロール機能を実現す
る。従って、例えば、アプリケーションの実行優先度を
制御したり、通信ルートを変更したりして、リソースの
有効利用を図ることができる。このにより、ネットワー
ク上でのアプリケーションに対し、ＱＯＳの保証にかか
わるポリシーを統一して付与することができ、アプリケ
ーションの実行優先度に基づき、緊急度の高いアプリケ
ーションの実行を優先させるなどの制御が可能となり、
ネットワークのリソースを有効利用することが可能とな
る。

【００３５】前記トラフィック制御部は、典型的には、
ネットワーク上のリソースの使用状況を監視するリソー
ス監視部、及びアプリケーションからのリソース要求に
対し、アプリケーションの所定の優先度に従ってリソー
スの提供をスケジュールするリソース割付部を含む。

【００３６】この発明の第２の観点によるネットワーク
の通信品質制御システムは、ネットワーク上の所定管理
領域内のリソースの使用状況を監視するリソース監視手
段、及びアプリケーションからのリソース要求に対し、
アプリケーションの所定の優先度に従って前記所定管理
領域内のリソースの提供をスケジュールするリソース割
付手段を含むトラフィック制御手段と、前記ネットワー
クと前記所定管理領域内のアプリケーション実行システ
ムとの間に介在し、該アプリケーション実行システム上
で実行されるアプリケーションからのリソース要求を前
記トラフィック制御手段のリソース割付手段に供給する
リソース要求手段、及び前記トラフィック制御手段のリ
ソース割付手段により提供されるスケジュールに基づい
て前記アプリケーション実行システム上の前記各アプリ
ケーションの動作を制御するアプリケーション制御手段
を含む補助制御手段と、を具備する。

【００３７】第２の観点にかかるネットワークの通信品
質制御システムにおいて、前記トラフィック制御部は、
ネットワーク上の限定された所定管理領域内で実行され
る全アプリケーションのＱＯＳを監視し制御するための
集中コントロール機能を実現する。該トラフィック制御
部は、例えば、アプリケーションの実行優先度を制御し
たり、通信ルートを変更したりして、前記所定管理領域
内のリソースの有効利用を図ることができる。したがっ
て、前記所定管理領域内での全アプリケーションに対
し、ＱＯＳの保証にかかわるポリシーを統一して付与す
ることができ、アプリケーションの実行優先度に基づ
き、緊急度の高いアプリケーションの実行を優先させる
などの制御が可能となり、ネットワークのリソースを有
効利用することが可能となる。

【００３８】前記トラフィック制御部は、典型的には、
ネットワーク上の所定管理領域内のリソースの使用状況
を監視するリソース監視部、及びアプリケーションから
のリソース要求に対し、アプリケーションの所定の優先
度に従って前記所定管理領域内のリソースの提供をスケ
ジュールするリソース割付部を含む。

【００３９】前記リソース要求手段は、アプリケーショ
ンの実行優先度情報を前記トラフィック制御手段のリソ
ース割付手段に通知する手段を含んでいてもよい。

【００４０】前記リソース要求手段は、前記アプリケー
ションからのリソース予約プロトコルによるリソース要
求に基づくリソース予約処理を行うとともに、該予約処
理により得られるリソース予約要求を前記トラフィック
制御手段のリソース割付手段に通知する手段を含み、且
つ前記リソース割付手段は、前記リソース予約要求に基
づくリソース割付が可能である場合には該リソース予約
に基づいてリソースを割り付ける手段を含んでいてもよ
い。

【００４１】前記リソース割付手段は、ルーティングを
変更して通信ルートを迂回制御する手段を含んでいても
よい。

【００４２】前記補助制御手段は、ルータ、ルータに相
当する装置及びそれらの近傍のうちのいずれかに配設さ
れていてもよい。

【００４３】この発明の第３の観点によるネットワーク
の通信品質制御システムは、ネットワーク上の所定管理
領域内のリソースの使用状況を監視するリソース監視手
段と、アプリケーションからのリソース要求に対し、ア
プリケーションの所定の優先度に従って前記所定管理領
域内のリソースの提供をスケジュールするリソース割付
手段と、を含み、前記所定管理領域内の各アプリケーシ
ョンのサービス品質を適切に制御するトラフィック制御
手段を具備する。

【００４４】この構成においても、前記トラフィック制
御部は、ネットワーク上の限定された所定管理領域内で
実行される全アプリケーションのＱＯＳを監視し制御す
るための集中コントロール機能を実現しうる。したがっ
て、前記所定管理領域内での全アプリケーションに対
し、ＱＯＳの保証にかかわるポリシーを統一して付与す
ることができ、アプリケーションの実行優先度に基づ
き、緊急度の高いアプリケーションの実行を優先させる
などの制御が可能となり、ネットワークのリソースを有
効利用することが可能となる。

【００４５】前記リソース割付手段は、リソース予約プ
ロトコルによるアプリケーションからのリソース予約要
求に基づいてリソース割付を行う手段を含んでいてもよ
い。

【００４６】前記リソース割付手段は、ルーティングを
変更して通信ルートを迂回制御する手段を含んでいても
よい。

【００４７】前記ネットワークは、インターネットプロ
トコルを用いるＩＰネットワークであってもよい。

【００４８】前記トラフィック制御手段は、ネットワー
クにおける自律系に対応する領域を管理領域とし、該管
理領域毎に設けられていてもよい。

【００４９】

【発明の実施の形態】以下、この発明の実施の形態を図
面を参照して説明する。図１〜図４を参照して、この発
明の第１の実施の形態に係るネットワークの通信品質制
御システムを説明する。

【００５０】図１は、この発明の第１の実施の形態に係
るネットワークの通信品質制御システムの構成を模式的
に示している。

【００５１】図１に示すネットワークの通信品質制御シ
ステムは、トラフィックコントロールセンタ（以下、
「ＴＣＣ」と称する）１、ルータ２，２′、トラフィッ
クコントロールボックス（以下、「ＴＣＢ」と称する）
３，３′、アプリケーションシステム４，４′及び５，
５′を備えている。ルータ２、ＴＣＢ３、アプリケーシ
ョンシステム４及び５は、ルータ２が所轄するサービス
対象ネットワーク６を構成し、ルータ２′、ＴＣＢ
３′、アプリケーションシステム４′及び５′は、ルー
タ２′が所轄するサービス対象ネットワーク６′を構成
する。ＴＣＣ１とルータ２及び２′は、インターネット
等のＩＰネットワーク７を介して結合されており、ＴＣ
Ｃ１及びサービス対象ネットワーク６，６′を含む領域
が、ＴＣＣ１の制御が及ぶ範囲、すなわちＱＯＳ制御領
域（QOS Control Area〜以下、「ＱＣＡ」と称する）で
ある。

【００５２】ＱＣＡは、例えば自律系（ＡＳ：Autonomo
us System〜以下、「ＡＳ」と称する）又はＡＳに相当
する領域であるとする。図１においては、ＱＣＡ内にＴ
ＣＣ１が管轄する２つのサービス対象ネットワーク６及
び６′を示したが、ＱＣＡ内には、２以上の適宜個数の
サービス対象ネットワーク６，６′等が存在し、ＴＣＣ
１は、これらＱＣＡ内の全てのサービス対象ネットワー
ク６，６′等を管轄する。アプリケーションシステム
４，４′，５，５′等は、それぞれアプリケーションが
実行され得るサーバ及びクライアントシステムのような
パーソナルコンピュータ又はワークステーション等のコ
ンピュータを中心とするシステムであり、サービス対象
ネットワーク６，６′等の内部ネットワークに結合され
ている。

【００５３】図２は、ＴＣＣ１及びサービス対象ネット
ワーク６、すなわちルータ２、ＴＣＢ３、アプリケーシ
ョンシステム４及び５からなる部分を詳細に示してい
る。

【００５４】ＴＣＣ１は、ＩＰネットワーク７上のＱＣ
Ａ内で動作する複数のアプリケーションにおけるサービ
ス品質を監視し、該サービス品質を適切に制御すべく各
アプリケーションに対するトラフィック制御情報を生成
する。アプリケーションは、サービス対象ネットワーク
６等のアプリケーションシステム４又は５等で実行され
る。この場合、ＴＣＣ１は例えばＱＣＡ内のリソースに
よりＱＯＳを管理制御する。

【００５５】すなわち、ＴＣＣ１は、ＱＣＡ内のリソー
スの利用状況をチェックして常時把握しておき、アプリ
ケーションからのリソースの要求に対して、アプリケー
ションの所定の優先度に従ってアプリケーションへのリ
ソース配分を制御する。ＴＣＣ１は、このリソース配分
の制御により、ＱＣＡ内の各アプリケーションの実行優
先度を制御したり、ＱＣＡ内のネットワークの過負荷を
防止しあるいは負荷を平滑化したりする。このため、Ｔ
ＣＣ１は、リソース監視部１１及びリソース割付部１２
を有している。リソース監視部１１は、ＩＰネットワー
ク７上のＱＣＡ内のリソースの使用状況を監視する。リ
ソース割付部１２は、アプリケーションからのリソース
要求に対し、アプリケーションの所定の優先度に従って
ＱＣＡ内のリソースの提供をスケジュールする。

【００５６】ルータ２等は、サービス対象ネットワーク
６等内のＩＰネットワーク７との結合部に設けられ、サ
ービス対象ネットワーク６等をＩＰネットワーク７に結
合するとともに、パケットの転送ルートを制御する。サ
ービス対象ネットワーク６等のアプリケーションシステ
ム４，５等が通信における送信側ノード及び受信側ノー
ドを構築する。ルータ２等は、隣接するルータ２等の相
互間で情報を交換し合うことにより、他ノードへの通信
ルートを定めている。この場合、ルータ２等はリソース
予約プロトコル例えばＲＳＶＰに対応しているものとす
る。ＲＳＶＰ機能に対応しているルータ２等の場合、送
信側ノード及び受信側ノードのアプリケーションシステ
ム４，５等は、ルータ２等を介して相互間でパスメッセ
ージ及びリザーブメッセージのやりとりを行い、通信ル
ートのリソースを予約する。

【００５７】ＲＳＶＰにおいては、サーバ側は、通信ル
ートのルータを順次介して、パスメッセージによってパ
ス情報や予約用情報をクライアント側に送信する。クラ
イアント側は、送信されたパスメッセージに従って、通
信ルートのルータを逐次介して、リザーブメッセージに
よって通信ルートの品質確保を要求する。このようにし
て、通信パスの帯域リソースが確保される。このような
ＲＳＶＰは、混雑したネットワークでもスムーズな通信
を実現するので、ＴＶ（テレビジョン）会議及びＩＰネ
ットワーク電話等のマルチメディア通信、並びにＥＣ
（Electronic Commerce）等のように確実な送達が必要
な通信に適している。

【００５８】但し、この通信品質制御システムでは、上
述したＲＳＶＰによるルータ２等を介してのリソース予
約機能の一部をＴＣＣ１及びＴＣＢ３等の制御によって
抑制し、リソース予約をＱＯＳを適切に調整すべく制御
することにより、有効なＱＯＳ保証を実現している。

【００５９】ＴＣＢ３等は、例えばＩＰネットワーク７
に結合された各ルータ２等と１以上のアプリケーション
システム４，５等との間に介挿される。ＴＣＢ３等は、
アプリケーションからのリソースの要求を受け付け、ア
プリケーションの代わりにＴＣＣ１との間でリソース要
求のネゴシエーションを行い、その結果をアプリケーシ
ョンに通知するとともに、必要なスケジューリング処理
等を行う。

【００６０】すなわち、ＴＣＢ３は、該アプリケーショ
ンシステム４，５等で実行されるアプリケーションのサ
ービス品質に関する要求内容をＴＣＣ１に供給するとと
もに、該ＴＣＣ１から与えられる制御情報に基づいてア
プリケーションシステム４，５等における各アプリケー
ションの動作を制御する。具体的には、ＴＣＢ３等は、
アプリケーションのＱＯＳ要求をＴＣＣ１に伝達する。
また、ＴＣＢ１は、ＴＣＣ１から通知されたアプリケー
ションに関するＱＯＳ情報を該当するアプリケーション
に通知する。

【００６１】この場合、ＴＣＢ３は、リソース要求部３
１及びアプリケーション制御部３２を有する。リソース
要求部３１は、アプリケーションシステム４，５等で実
行されるアプリケーションからのリソース要求をＴＣＣ
１のリソース割付部１２に供給する。アプリケーション
制御部３２は、リソース割付部１２により提供されるス
ケジュールに基づいてアプリケーションシステム４，５
等における各アプリケーションの動作を制御する。

【００６２】アプリケーションシステム４，５等は、先
に述べたように、サーバシステム又はクライアントシス
テム等に代表されるアプリケーションを実行し得るシス
テムであり、それぞれパーソナルコンピュータ又はワー
クステーション等のコンピュータを中心として構成さ
れ、サービス対象ネットワーク６等の内部ネットワーク
に結合されている。

【００６３】次に、図１及び図２に示したように構成さ
れるネットワークの通信品質制御システムの動作につい
て、図３及び図４に示す処理シーケンスのフローチャー
トを参照しながら説明する。

【００６４】まず、ＱＯＳ保証の要求のためのＱＯＳ要
求シーケンスについて説明する。ＱＯＳ要求シーケンス
のフローチャートを図３に示している。

【００６５】(1) 例えばＴＣＢ３は、そのＴＣＢ３自体
又はそれに接続されているルータ２に隣接している他の
ルータ（例えばルータ２′）あるいは他のＴＣＢ（例え
ばＴＣＢ３′）との間の回線について、回線種別、回線
速度等の回線に関する属性情報を取得保持しているもの
とする（ステップＳ１１）。さらに、ＴＣＢ３は、これ
らの情報についてＴＣＣ１と情報交換することによっ
て、当該ＱＣＡ内のネットワークに関する情報をも予め
取得しているものとする（ステップＳ１２）。

【００６６】(2) 例えばアプリケーションシステム４に
おけるクライアントのアプリケーションは、予めＲＳＶ
Ｐ等のリソース予約プロトコルを用いてＴＣＢ３のリソ
ース要求部３１に対しリソースの予約要求を行う（ステ
ップＳ１３）。

【００６７】(3) ＴＣＢ３は、アプリケーションからの
要求に対し、ルータ２を介して、送信先までリソース予
約プロトコルによるリソースの予約が可能であるか否か
を調べ（ステップＳ１４）、予約可能であれば、要求元
のアプリケーションに対して予約を通知するとともにＴ
ＣＣ１に対しても予約内容を通知する（ステップＳ１
５）。このとき、ＴＣＢ３は、ＴＣＣ１に対して、後述
するアプリケーションの実行優先度も通知して（ステッ
プＳ１６）、処理を終了する。ステップＳ１４におい
て、予約可能でないならば、予約等の通知をせずに、そ
のまま処理を終了する。

【００６８】次に、ＱＯＳを保証するためのＱＯＳ保証
シーケンスについて説明する。ＱＯＳ保証シーケンスの
フローチャートを図４に示している。

【００６９】(1) ＴＣＣ１は、配下のＴＣＢ３等から受
け付けた各アプリケーションに関するリソースの予約状
況を比較評価する（ステップＳ２１）。 (2) ステップＳ２１における比較評価の結果、指定され
た通信ルートにおける各アプリケーションによる要求リ
ソースの総和がそのルートが保有するリソースの総和以
下であれば（ステップＳ２２）、全要求の予約を有効と
し、予約成功として処理を終了する（ステップＳ２
３）。

【００７０】(3) 指定された通信ルートにおける各アプ
リケーションの要求リソースの総和がそのルートが保有
するリソースの総和より多ければ（ステップＳ２２）、
次の処理を行う。 (4) 各アプリケーションの実行優先度を比較し、優先度
の高いアプリケーションからリソースを割り当てていく
（ステップＳ２４）。通信ルートのリソース内に割り当
てられたアプリケーションについては（ステップＳ２
５）、ステップＳ２３に移行して予約成功とし、それ以
外のアプリケーションについては（ステップＳ２５）、
次の処理を行う。

【００７１】(5) 迂回可能なアプリケーションであっ
て、迂回ルートが存在するならば（ステップＳ２６）、
ルーティングの変更を行って、通信ルートを迂回させ
て、変更されたルートについての処理に供し（ステップ
Ｓ２７）、それ以外はアプリケーションのリソース予約
を保証させない（ステップＳ２８）。

【００７２】ここで、上述したステップＳ２４における
優先度比較割り当てに際して用いられるアプリケーショ
ンの優先度付与の方法について説明する。

【００７３】ＴＣＣ１では、ＱＣＡ内すなわちＴＣＣ１
の配下の各アプリケーションからリソースを要求された
とき、リソースの総和とＱＣＡ内の既存の全トラフィッ
クを比較し、リソースの空きの分だけ新規の通信を許可
するものとする。このために、アプリケーションに実行
優先度を付与する。

【００７４】アプリケーションに優先度を付与する方法
としては、ポート番号によって簡易に優先度を定めるよ
うにしてもよいが、より適切なＱＯＳ保証を実現するた
めの優先度の付与の方法としては、次のようなものが考
えられる。

【００７５】(a) 利用者指定タイプ 利用者指定タイプの優先度付与方法においては、利用者
に対応させて基準を設け、利用者に基づいて優先度を決
定する。

【００７６】(b) 時間指定タイプ 時間指定タイプの優先度付与方法においては、アプリケ
ーションを実行したいと思う時間帯を予め予約してお
き、予約した時間帯において、そのアプリケーションに
高い優先度を与える。すなわち、随時、その時間帯を予
約しているアプリケーションの実行を優先させる。

【００７７】(c) トラフィック種別指定タイプ トラフィック種別指定タイプの優先度付与方法において
は、通信内容の種類によって優先度を設定し、例えば、
リアルタイムデータ通信のトランザクションの優先度は
最も高く、ファイルデータ等のバルク転送の優先度は最
も低いといった考え方で、各トラフィックの優先度を設
定する。

【００７８】これら(a) 〜(c) の方法を必要に応じて適
宜組み含わせて利用する。もちろん、これらの一部のみ
を使用してもよく、状況に応じて、選択的に切替えて使
用するようにしてもよい。また、これら以外のタイプの
優先度付与方法により、あるいはそれを組み合わせて、
アプリケーションの実行優先度を規定してもよい。な
お、上述した各手法を組み合わせて使用する場合、組み
合わせられる各手法により決定される優先度相互間の優
先度、又は同一優先度の要求が重複した場合の取り扱い
などを予め決定しておくことが望ましい。

【００７９】なお、上述においては、主として、ルータ
２、ＴＣＢ３及びアプリケーションシステム４を例にと
って説明したが、他のルータ２′等、他のＴＣＢ３′等
又は他のアプリケーションシステム４′，５，５′等に
ついても、ルータ２、ＴＣＢ３及びアプリケーションシ
ステム４の場合と同様である。

【００８０】上述したように、ＱＯＳ保証の集中管理を
ＴＣＣ１によって実現する。ＴＣＣ１は、該ＴＣＣ１が
管轄するＱＣＡ内のリソースの利用状況をチェックしア
プリケーションへのリソース配分を制御することによ
り、ＱＣＡ内のネットワークの過負荷を防止し、負荷を
平滑化する。このために、上述のように、アプリケーシ
ョンが実行前に予めリソースを予約する方法と、ＱＣＡ
内で動作する全アプリケーションに優先度を付与し、該
優先度に従ってリソースを提供する方法とを組み合わせ
ている。すなわち、ＴＣＣ１では、ＴＣＣ１の配下の各
アプリケーションからリソースの予約を要求されたと
き、要求リソースの総和とＱＣＡ内の既存の全トラフィ
ックを比較し、帯域の空いているぶんだけ新規の通信の
ためのリソースの予約を許可する。このために、アプリ
ケーションに実行優先度を付与している。

【００８１】次に、図５を参照して、この発明の第２の
実施の形態に係るネットワークの通信品質制御システム
を説明する。

【００８２】図５は、この発明の第２の実施の形態に係
るネットワークの通信品質制御システムの構成を模式的
に示している。

【００８３】図５に示すネットワークの通信品質制御シ
ステムは、ＩＰネットワーク上に複数のＴＣＣを設け、
これら複数のＴＣＣの各々についてのＱＣＡを設定した
ものでる。図５に示すネットワークの通信品質制御シス
テムは、ＩＰネットワーク７上に、２つのＱＣＡ、すな
わちＱＣＡ−Ａ及びＱＣＡ−Ｂを設定している。ＱＣＡ
−Ａは、ＴＣＣ−Ａ１Ａと、３つのサービス対象ネット
ワーク６Ａ１、６Ａ２及び６Ａ３とを備えており、ＱＣ
Ａ−Ｂは、ＴＣＣ−Ｂ１Ｂと、２つのサービス対象ネッ
トワーク６Ｂ１及び６Ｂ２とを備えている。

【００８４】各サービス対象ネットワーク６Ａ１〜６Ａ
３、６Ｂ１及び６Ｂ２は、それぞれ、図１及び図２に示
したのと同等のルータ、ＴＣＢ及びアプリケーションシ
ステムを有している。ＴＣＣ−Ａ１Ａ及びＴＣＣ−Ｂ１
Ｂは、共に、図１及び図２に示したＴＣＣ１と同様に構
成されている。ＴＣＣ−Ａ１Ａは、配下のサービス対象
ネットワーク６Ａ１〜６Ａ３についてのトラフィックを
制御して、ＱＣＡ−Ａ内のＱＯＳを保証する。ＴＣＣ−
Ｂ１Ｂは、配下のサービス対象ネットワーク６Ｂ１及び
６Ｂ２についてのトラフィックを制御して、ＱＣＡ−Ｂ
内のＱＯＳを保証する。

【００８５】ＴＣＣ−Ａ１Ａは、ＩＰネットワーク７上
のＱＣＡ−Ａ内で動作する複数のアプリケーションにお
けるサービス品質を監視し、該サービス品質を適切に制
御すべく各アプリケーションに対するトラフィック制御
情報を生成する。ＱＣＡ−Ａ内のアプリケーションは、
サービス対象ネットワーク６Ａ１〜６Ａ３のアプリケー
ションシステムで実行される。ＴＣＣ−Ａ１ＡはＱＣＡ
−Ａ内のリソースによりＱＯＳを管理制御する。すなわ
ち、ＴＣＣ−Ａ１Ａは、ＱＣＡ−Ａ内のリソースの利用
状況をチェックして常時把握しておき、ＱＣＡ−Ａ内の
アプリケーションからのリソースの要求に対して、アプ
リケーションへのリソース配分を所定の優先度に従って
制御して、リソースの提供をスケジュールする。ＴＣＣ
−Ａ１Ａは、このリソース配分の制御により、ＱＣＡ−
Ａ内の各アプリケーションの実行優先度を制御したり、
ＱＣＡ−Ａ内のネットワークの過負荷を防止しあるいは
負荷を平滑化したりする。

【００８６】サービス対象ネットワーク６Ａ１〜６Ａ３
内のＩＰネットワーク７との結合部にはそれぞれルータ
が設けられ、該ルータは、サービス対象ネットワーク６
Ａ１〜６Ａ３をＩＰネットワーク７に結合するととも
に、パケットの転送ルートを制御する。ＴＣＢは、例え
ばＩＰネットワーク７に結合された各ルータ２とアプリ
ケーションシステムとの間に介挿される。ＴＣＢは、ア
プリケーションからのリソースの要求を受け付け、アプ
リケーションの代わりにＴＣＣ−Ａ１Ａとの間でリソー
ス要求のネゴシエーションを行い、その結果をアプリケ
ーションに通知するとともに、必要なスケジューリング
処理等を行う。

【００８７】すなわち、ＴＣＢは、アプリケーションシ
ステムで実行されるアプリケーションのサービス品質に
関する要求内容をＴＣＣ−Ａ１Ａに供給するとともに、
該ＴＣＣ−Ａ１Ａから与えられる制御情報に基づいてア
プリケーションシステムにおける各アプリケーションの
動作を制御する。具体的には、ＴＣＢは、アプリケーシ
ョンのＱＯＳ要求をＴＣＣ−Ａ１Ａに伝達する。また、
ＴＣＢは、ＴＣＣ−Ａ１Ａから通知されたアプリケーシ
ョンに関するＱＯＳ情報を該当するアプリケーションに
通知する。

【００８８】アプリケーションシステムは、先に述べた
ように、サーバシステム又はクライアントシステム等に
代表されるアプリケーションを実行し得るシステムであ
り、サービス対象ネットワーク６Ａ１〜６Ａ３の内部ネ
ットワークに結合されている。

【００８９】サービス対象ネットワーク６Ｂ１及び６Ｂ
２内のＩＰネットワーク７との結合部にはそれぞれルー
タが設けられ、該ルータは、サービス対象ネットワーク
６Ｂ１及び６Ｂ２をＩＰネットワーク７に結合するとと
もに、パケットの転送ルートを制御する。ＴＣＢは、例
えばＩＰネットワーク７に結合された各ルータ２とアプ
リケーションシステムとの間に介挿される。ＴＣＢは、
アプリケーションからのリソースの要求を受け付け、ア
プリケーションの代わりにＴＣＣ−Ｂ１Ｂとの間でリソ
ース要求のネゴシエーションを行い、その結果をアプリ
ケーションに通知するとともに、必要なスケジューリン
グ処理等を行う。

【００９０】すなわち、ＴＣＢは、アプリケーションシ
ステムで実行されるアプリケーションのサービス品質に
関する要求内容をＴＣＣ−Ｂ１Ｂに供給するとともに、
該ＴＣＣ−Ｂ１Ｂから与えられる制御情報に基づいてア
プリケーションシステムにおける各アプリケーションの
動作を制御する。具体的には、ＴＣＢは、アプリケーシ
ョンのＱＯＳ要求をＴＣＣ−Ｂ１Ｂに伝達する。また、
ＴＣＢは、ＴＣＣ−Ｂ１Ｂから通知されたアプリケーシ
ョンに関するＱＯＳ情報を該当するアプリケーションに
通知する。

【００９１】アプリケーションシステムは、先に述べた
ように、サーバシステム又はクライアントシステム等に
代表されるアプリケーションを実行し得るシステムであ
り、サービス対象ネットワーク６Ｂ１及び６Ｂ２の内部
ネットワークに結合されている。

【００９２】ＴＣＣによる管理の範囲すなわちＱＣＡに
ついては、ＩＰネットワーク全体を１個所（すなわち全
世界で１個所）のＴＣＣで管理することは、管理の膨大
さや困難性からみて現実的ではない。図５においては、
例として２個のＱＣＡを設ける構成を示したが、現実に
は、ＩＰネットワーク全体に、さらに多数のＴＣＣを配
置することになる。そして、上述では、制御の容易性か
らＡＳ程度のエリアを想定して、ＱＣＡとしたが、ＡＳ
よりも広範囲の領域をＱＣＡとしたり、ＴＣＣにおい
て、他のＱＣＡとの間にまたがる管理を行うようにして
もよい。

【００９３】このように、複数のＱＣＡの間にまたがっ
た管理を行う場合には、各々のＱＣＡ内に存在するＴＣ
Ｃを総合的に管理する上位のＴＣＣを設けて、ＴＣＣに
階層を持たせるようにしてもよく、あるいはＴＣＣに優
先順位を設定して、制御が競合する場合には優先順位の
高いＴＣＣの動作を優先させるようにしてもよい。

【００９４】また、上述においては、ＴＣＢ３等をルー
タ２等とＱＣＡ内のネットワークとの間に設けるように
したが、ＴＣＢをルータに組み込んだり、ＴＣＢとルー
タとを並列的に設ける構成としたりしてもよい。

【００９５】なお、この発明のネットワークの通信品質
制御システムは、専用のシステムとして構成することな
く、通常のコンピュータシステムを用いて実現すること
ができる。例えば、コンピュータシステムに上述の動作
を実行するためのプログラムを格納した媒体（フロッピ
ーディスク、ＣＤ−ＲＯＭ等）から該プログラムをイン
ストールすることにより、上述の処理を実行するネット
ワークの通信品質制御システムを構築することができ
る。インストールによって、当該プログラムは、コンピ
ュータシステム内のハードディスク等の媒体に格納され
て、ネットワークの通信品質制御システムを構成し、実
行に供される。

【００９６】また、コンピュータにプログラムを供給す
るための媒体は、狭義の記憶媒体に限らず、通信回線、
通信ネットワーク及び通信システムのように、一時的且
つ流動的にプログラム等の情報を保持する通信媒体等を
含む広義の記憶媒体であってもよい。

【００９７】例えば、ＩＰネットワーク等の通信ネット
ワーク上に設けたＦＴＰ（File Transfer Protocol）サ
ーバに当該プログラムを登録し、ＦＴＰクライアントに
ネットワークを介して配信してもよく、通信ネットワー
クの電子掲示板（ＢＢＳ：Bulletin Board System）等
に該プログラムを登録し、これをネットワークを介して
配信してもよい。そして、このプログラムを起動し、Ｏ
Ｓ（Operating System）の制御下において実行すること
により、上述の処理を達成することができる。さらに、
通信ネットワークを介してプログラムを転送しながら起
動実行することによっても、上述の処理を達成すること
ができる。

【００９８】

【発明の効果】以上説明したように、この発明によれ
ば、ＩＰネットワーク上の所定管理領域内で実行される
全アプリケーションのＱＯＳを監視し制御するための集
中コントロール機能を実現するトラフィック制御部を設
け、例えば、アプリケーションの実行優先度を制御した
り、通信ルートを変更したりして、前記所定管理領域内
のリソースの有効利用を図ることによって、ＩＰネット
ワークにおいて、簡単な構成により、別途に設定される
優先度に基づいて、要求順序に拘束されることなく、ア
プリケーションの実行を適切に且つ効果的に制御して、
有効なＱＯＳ保証を実現し得るネットワークの通信品質
制御システムを提供することができる。

【図面の簡単な説明】

【図１】この発明の第１の実施の形態に係るネットワー
クの通信品質制御システムの構成を模式的に示すブロッ
ク図である。

【図２】図１のネットワークの通信品質制御システムの
要部の詳細な構成を示すブロック図である。

【図３】図１のネットワークの通信品質制御システムに
おけるＱＯＳ（Quality of Service）要求の動作シーケ
ンスを説明するためのフローチャートである。

【図４】図１のネットワークの通信品質制御システムに
おけるＱＯＳ保証の動作シーケンスを説明するためのフ
ローチャートである。

【図５】この発明の第２の実施の形態に係るネットワー
クの通信品質制御システムの構成を模式的に示すブロッ
ク図である。

【図６】ネットワークのＱＯＳ保証のための機能を説明
するための図である。

【図７】ＱＯＳ保証のためのネットワーク全体の管理方
式を比較するための図である。

【符号の説明】

１，１Ａ，１Ｂ トラフィックコントロールセンタ
（ＴＣＣ） ２，２′ ルータ ３，３′ トラフィックコントロールブロック
（ＴＣＢ） ４，４′，５，５′ アプリケーションシステム ６，６′，６Ａ１〜６Ａ３，６Ｂ１，６Ｂ２ サービ
ス対象ネットワーク ７ ＩＰネットワーク

───────────────────────────────────────────────────── フロントページの続き (72)発明者 日下 貴義 東京都江東区豊洲三丁目３番３号 エヌ・ ティ・ティ・データ通信株式会社内

Claims (11)

【特許請求の範囲】
1. 【請求項１】ネットワーク上で動作する複数のアプリケ
   ーションにおけるサービス品質を監視し、該サービス品
   質を制御すべく各アプリケーションに対する制御情報を
   生成するトラフィック制御手段と、 前記ネットワークとアプリケーション実行システムとの
   間に介在し、該アプリケーション実行システム上で実行
   されるアプリケーションのサービス品質に関する要求内
   容を前記トラフィック制御手段に供給するとともに、前
   記トラフィック制御手段から与えられる制御情報に基づ
   いて前記アプリケーション実行システム上の前記各アプ
   リケーションの動作を制御する補助制御手段と、を具備
   することを特徴とするネットワークの通信品質制御シス
   テム。
2. 【請求項２】ネットワーク上の所定管理領域内のリソー
   スの使用状況を監視するリソース監視手段、及びアプリ
   ケーションからのリソース要求に対し、アプリケーショ
   ンの所定の優先度に従って前記所定管理領域内のリソー
   スの提供をスケジュールするリソース割付手段を含むト
   ラフィック制御手段と、 前記ネットワークと前記所定管理領域内のアプリケーシ
   ョン実行システムとの間に介在し、該アプリケーション
   実行システム上で実行されるアプリケーションからのリ
   ソース要求を前記トラフィック制御手段のリソース割付
   手段に供給するリソース要求手段、及び前記トラフィッ
   ク制御手段のリソース割付手段により提供されるスケジ
   ュールに基づいて前記アプリケーション実行システム上
   の前記各アプリケーションの動作を制御するアプリケー
   ション制御手段を含む補助制御手段と、を具備すること
   を特徴とするネットワークの通信品質制御システム。
3. 【請求項３】前記リソース要求手段は、アプリケーショ
   ンの実行優先度情報を前記トラフィック制御手段のリソ
   ース割付手段に通知する手段を含むことを特徴とする請
   求項２に記載のネットワークの通信品質制御システム。
4. 【請求項４】前記リソース要求手段は、前記アプリケー
   ションからのリソース予約プロトコルによるリソースの
   要求に基づくリソースの予約処理を行うとともに、該予
   約処理により得られるリソース予約要求を前記トラフィ
   ック制御手段のリソース割付手段に通知する手段を含
   み、且つ前記リソース割付手段は、前記リソース予約要
   求に基づくリソース割付が可能である場合には該リソー
   ス予約に基づいてリソースを割り付ける手段を含むこと
   を特徴とする請求項２又は３に記載のネットワークの通
   信品質制御システム。
5. 【請求項５】前記リソース割付手段は、ルーティングを
   変更して通信ルートを迂回制御する手段を含むことを特
   徴とする請求項２乃至４のうちのいずれか１項に記載の
   ネットワークの通信品質制御システム。
6. 【請求項６】前記補助制御手段は、ルータ、ルータに相
   当する装置及びそれらの近傍のうちのいずれかに配設さ
   れることを特徴とする請求項１乃至５のうちのいずれか
   １項に記載のネットワークの通信品質制御システム。
7. 【請求項７】ネットワーク上の所定管理領域内のリソー
   スの使用状況を監視するリソース監視手段と、 アプリケーションからのリソース要求に対し、アプリケ
   ーションの所定の優先度に従って前記所定管理領域内の
   リソースの提供をスケジュールするリソース割付手段
   と、 前記所定管理領域内の各アプリケーションのサービス品
   質を適切に制御するトラフィック制御手段と、 を具備することを特徴とするネットワークの通信品質制
   御システム。
8. 【請求項８】前記リソース割付手段は、リソース予約プ
   ロトコルによるアプリケーションからのリソース予約要
   求に基づいてリソース割付を行う手段を含むことを特徴
   とする請求項７に記載のネットワークの通信品質制御シ
   ステム。
9. 【請求項９】前記リソース割付手段は、ルーティングを
   変更して通信ルートを迂回制御する手段を含むことを特
   徴とする請求項７又は８に記載のネットワークの通信品
   質制御システム。
10. 【請求項１０】前記ネットワークは、インターネットプ
    ロトコルを用いるネットワークであることを特徴とする
    請求項１乃至９のうちのいずれか１項に記載のネットワ
    ークの通信品質制御システム。
11. 【請求項１１】前記トラフィック制御手段は、ネットワ
    ークにおける自律系（Autonomous System：ＡＳ）に対
    応する領域を管理領域とし、該管理領域毎に設けられる
    ことを特徴とする請求項１乃至１０のうちのいずれか１
    項に記載のネットワークの通信品質制御システム。