(57)【特許請求の範囲】
【請求項１】
ネットワークと、前記ネットワークに外部網を収容し前記外部網と前記ネットワークとの間で主信号の変換を行う主信号ゲートウェイと、呼設定を行う呼設定サーバと、前記呼設定サーバと前記外部網との間でシグナリングの変換を行うシグナリングゲートウェイとを有するネットワークシステムにおいて使用されるＱｏＳサーバであって、
前記ネットワークの状態を監視するネットワーク監視部と、
前記ネットワーク監視部で取得したネットワーク状態を蓄積するネットワーク状態データベースと、
前記ネットワーク状態を参照し、リソース要求に基づいてアプリケーションへのリソース割当てを計算するリソース割当て計算部と、
リソース割当て情報を保持するリソース割当てデータベースと、
前記リソース割当て情報に基づいて前記ネットワークにリソース割当てを設定するネットワーク設定部と、
を有するＱｏＳサーバ。
【請求項２】
呼設定サーバ内に設けられリソース要求を発するリソース要求部からの前記リソース要求に応じてリソース割当てを実行する請求項１に記載のＱｏＳサーバ。
【請求項３】
主信号ゲートウェイ内に設けられリソース要求を発するリソース要求部からの前記リソース要求に応じてリソース割当てを実行する請求項１に記載のＱｏＳサーバ。
【請求項４】
外部網が接続したネットワークと、前記ネットワークに対するポリシーを決定して前記ネットワークに対してリソース割当てを設定するポリシーサーバとを有するネットワークシステムにおいて使用されるＱｏＳサーバであって、
前記ネットワークの状態を監視するネットワーク監視部と、
前記ネットワーク監視部で取得したネットワーク状態を蓄積するネットワーク状態データベースと、
前記ネットワーク状態を参照し、リソース要求に基づいてアプリケーションへのリソース割当てを計算して前記ポリシーサーバに通知するリソース割当て計算部と、
を有するＱｏＳサーバ。
【請求項５】
ポリシーサーバ内に設けられリソース要求を発するリソース要求部からの前記リソース要求に応じてリソース割当てを実行する請求項４に記載のＱｏＳサーバ。
【請求項６】
外部網に接続するネットワークに対してリソース割当てを設定するＱｏＳサーバであって、
前記ネットワークの状態を監視するネットワーク監視部と、
前記ネットワーク監視部で取得したネットワーク状態を蓄積するネットワーク状態データベースと、
設定情報を保持するユーザ情報データベースと、
前記ネットワーク状態データベースに蓄積されたネットワーク状態と前記ユーザ情報データベースに保持された設定情報とを参照してリソース要求を発生するリソース要求部と、
前記ネットワーク状態を参照し、前記リソース要求に基づいてアプリケーションへのリソース割当てを計算するリソース割当て計算部と、
リソース割当て情報を保持するリソース割当てデータベースと、
前記リソース割当て情報に基づいて前記ネットワークにリソース割当てを設定するネットワーク設定部と、
を有するＱｏＳサーバ。
【請求項７】
ネットワークへの呼の到着前に前もってトラヒックの要求品質、要求リソースを得て、経路、リソース割当てを計算し、経路、リソース割当てを実行する請求項１乃至６いずれか１項に記載のＱｏＳサーバ。
【請求項８】
複数呼のトラヒックの要求品質、要求リソースを得て、経路、リソース割当てを計算し、経路、リソース割当てを実行する請求項１乃至６に記載のＱｏＳサーバ。
【請求項９】
接続呼数がしきい値を越えたときに、追加の複数呼のトラヒックの要求品質、要求リソースを得て、経路、リソース割当てを計算し、経路、リソース割当てを行い、前記しきい値を更新する請求項１乃至６いずれか１項に記載のＱｏＳサーバ。
【請求項１０】
接続呼数がしきい値を下回ったときに、削減された複数呼のトラヒックのリソース解放要求を得て、経路、リソース割当てを解放し、前記しきい値を更新する請求項１乃至６いずれか１項に記載のＱｏＳサーバ。
【請求項１１】
前記リソース要求を保持するユーザ情報データベースをさらに有し、
割当てたリソースに対応するトラヒックを監視し、要求品質が満たされていないことを検出した場合に、前記ユーザ情報データベースを参照して経路、リソース割当てを再計算し、経路、リソース割当てを修正する請求項１乃至５いずれか１項に記載のＱｏＳサーバ。
【請求項１２】
割当てたリソースに対応するトラヒックを監視し、要求品質が満たされていないことを検出した場合に、経路、リソース割当てを再計算し、経路、リソース割当てを修正する請求項６に記載のＱｏＳサーバ。
【請求項１３】
ネットワークと、前記ネットワークに外部網を収容し前記外部網と前記ネットワークとの間で主信号の変換を行う主信号ゲートウェイと、呼設定を行う呼設定サーバと、前記呼設定サーバと前記外部網との間でシグナリングの変換を行うシグナリングゲートウェイとを有するネットワークシステムにおけるリソース割当て制御方法において、
前記ネットワークの状態を監視してネットワーク状態をネットワーク状態データベースに蓄積し、
前記ネットワーク状態データベースに蓄積されたネットワーク状態を参照するとともにリソース要求に基づいて、アプリケーションへのリソース割当てを計算し、
リソース割当て情報をリソース割当てデータベースに保持し、
前記リソース割当てデータベースに保持されたリソース割当て情報に基づいて前記ネットワークにリソース割当てを設定する、リソース割当て制御方法。
【請求項１４】
呼設定サーバからのリソース要求に応じてリソース割当てを実行する請求項１３に記載のリソース割当て制御方法。
【請求項１５】
主信号ゲートウェイからのリソース要求に応じてリソース割当てを実行する請求項１３に記載のリソース割当て制御方法。
【請求項１６】
外部網が接続したネットワークと、前記ネットワークに対するポリシーを決定して前記ネットワークに対してリソース割当てを設定するポリシーサーバとを有するネットワークシステムにおけるリソース割当て制御方法であって、
前記ネットワークの状態を監視してネットワーク状態をネットワーク状態データベースに蓄積し、
前記ネットワーク状態データベースに蓄積されたネットワーク状態を参照するとともにリソース要求に基づいて、アプリケーションへのリソース割当てを計算して前記ポリシーサーバに通知する、リソース割当て制御方法。
【請求項１７】
ポリシーサーバ内においてリソース要求が発生する、請求項１６に記載のリソース割当て制御方法。
【請求項１８】
外部網に接続するネットワークに対してリソース割当てを設定するリソース割当て制御方法であって、
前記ネットワークの状態を監視してネットワーク状態をネットワーク状態データベースに蓄積し、
前記ネットワーク状態データベースに蓄積されたネットワーク状態とユーザ情報データベースに保持された設定情報とを参照してリソース要求を発生し、
前記ネットワーク状態データベースに蓄積されたネットワーク状態を参照し、前記リソース要求に基づいてアプリケーションへのリソース割当てを計算し、
リソース割当て情報をリソース割当てデータベースに保持し、
前記リソース割当てデータベースに保持されたリソース割当て情報に基づいて前記ネットワークにリソース割当てを設定する、リソース割当て制御方法。
【請求項１９】
ネットワークへの呼の到着前に前もってトラヒックの要求品質、要求リソースを得て、経路、リソース割当てを計算し、経路、リソース割当てを実行する請求項１３乃至１８いずれか１項に記載のリソース割当て制御方法。
【請求項２０】
複数呼のトラヒックの要求品質、要求リソースを得て、経路、リソース割当てを計算し、経路、リソース割当てを実行する請求項１３乃至１８に記載のリソース割当て制御方法。
【請求項２１】
接続呼数がしきい値を越えたときに、追加の複数呼のトラヒックの要求品質、要求リソースを得て、経路、リソース割当てを計算し、経路、リソース割当てを行い、前記しきい値を更新する請求項１３乃至１８いずれか１項に記載のリソース割当て制御方法。
【請求項２２】
接続呼数がしきい値を下回ったときに、削減された複数呼のトラヒックのリソース解放要求を得て、経路、リソース割当てを解放し、前記しきい値を更新する請求項１３乃至１８いずれか１項に記載のリソース割当て制御方法。
【請求項２３】
リソース要求をユーザ情報データベースに保持し、
割当てたリソースに対応するトラヒックを監視し、要求品質が満たされていないことを検出した場合に、前記ユーザ情報データベースを参照して経路、リソース割当てを再計算し、経路、リソース割当てを修正する請求項１３乃至１７いずれか１項に記載のリソース割当て制御方法。
【請求項２４】
割当てたリソースに対応するトラヒックを監視し、要求品質が満たされていないことを検出した場合に、経路、リソース割当てを再計算し、経路、リソース割当てを修正する請求項１８に記載のリソース割当て制御方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、インターネット（ｔｈｅ  Ｉｎｔｅｒｎｅｔ）などのネットワークにおいてサービスの品質を維持した通信を行うためのＱｏＳ（Ｑｕａｌｉｔｙｏｆ  Ｓｅｒｖｉｃｅ）サーバ及びリソース割当て制御方法に関し、特に、既存の電話網による通信などをインターネットなどのネットワークに収容するのに適したＱｏＳサーバシ及びリソース割当て制御方法に関する。
【０００２】
【従来の技術】
インターネットは、近年のその急成長により、グローバルで商業性を含んだ通信インフラストラクチャになろうとしている。それにしたがって、インターネットは、従来からあるデータ通信だけでなく、電話網などのその他のあらゆる通信ネットワークのサービス基盤になるものと予想されている。
【０００３】
このような背景に従い、既存電話をインターネットに収容するためのプロトコルとして、ＩＥＴＦ（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）によってＲＦＣ（Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ）２７０５として提案されているＭＧＣＰ（ＭｅｄｉａＧａｔｅｗａｙ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）がある。図７は、ＭＧＣＰが適用されるネットワークシステムの構成を示すブロック図である。
【０００４】
ＭＧＣＰが適用されるネットワークシステムでは、外部網である既存電話網７２４ａ，７２４ｂのシグナリング信号（７５１’，７５４’，７５５’，７５６’，７５７’，７５９’）とパケット化されたシグナリング（７５１，７５４，７５５，７５６，７５７，７５９）との変換を行うシグナリングゲートウェイ７２２ａ，７２２ｂにより、既存電話網７２４ａ，７２４ｂのシグナリング網と、ネットワーク７１０（例えばインターネット）内のコールエージェント７２１とが接続される。同様に、既存電話網７２４ａ，７２４ｂの主信号トランクの音声信号（７６１’，７６２’）とパケット化された音声信号（７６１，７６２）との変換を行うトランクゲートウェイ（主信号ゲートウェイ）７２３ａ，７２３ｂにより、既存電話網７２４ａ，７２４ｂの主信号トランクとネットワーク７１０とが接続される。
【０００５】
図８は、このようなネットワークシステムにおける従来のＭＧＣＰによる呼設定手順を示すフロー図である。ここでは既存電話網７２４ａ側から発呼がなされるものとする。
【０００６】
まず、発呼側のシグナリングゲートウェイ７２２ａからコールエージェント７２１にＩＡＭ（ｉｎｉｔｉａｌａｄｄｒｅｓｓ  ｍｅｓｓａｇｅ）７５１が送られる（ステップ８５１）。するとコールエージェント７２１と発呼側のトランクゲートウェイ７２３ａの間でＣＲＣＸ／ＡＣＫ（ＣｒｅａｔｅＣｏｎｎｅｃｔｉｏｎとその確認（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ））７５２がやり取りされ（ステップ８５２）、その後、コールエージェント７２１と着呼側のトランクゲートウェイ７２３ｂの間でＣＲＣＸ／ＡＣＫ７５３がやり取りされ（ステップ８５３）、コールエージェント７２１から着呼側のシグナリングゲートウェイ７２２ｂに、ＩＡＭ７５４が送られる（ステップ８５４）。その後、着呼側のシグナリングゲートウェイ７２２ｂからコールエージェント７２１にＡＣＭ（ａｄｄｒｅｓｓｃｏｍｐｌｅｔｅ  ｍｅｓｓａｇｅ）７５５が送られ（ステップ８５５）、コールエージェント７２１から発呼側のシグナリングゲートウェイ７２２ａにＡＣＭ７５６が送られる（ステップ８５６）。引き続き、着呼側のシグナリングゲートウェイ７２２ｂからコールエージェント７２１にＡＮＭ（ａｎｓｗｅｒｍｅｓｓａｇｅ）７５７が送られ（ステップ８５７）、コールエージェント７２１と発呼側のトランクゲートウェイ７３２ａの間でＭＤＣＸ／ＡＣＫ（ＭｏｄｉｆｙＣｏｎｎｅｃｔｉｏｎとその確認）７５８がやり取りされ（ステップ８５８）、コールエージェント７２１から発呼側のシグナリングゲートウェイ７２２ａにＡＮＭ７５９が送られる（ステップ８５９）。このようにしてシグナリング信号７５１〜７５９によりトランクゲートウェイ７２３ａ，７２３ｂに呼設定が行われる。その後、音声信号（音声パケット）であるトラヒック７６１が発呼側のトランクゲートウェイ７２３ａからネットワーク７１０に転送され（ステップ８６１）、トラヒック７６２がネットワーク７１０から着呼側のトランクゲートウェイ７２３ｂに転送される（ステップ８６２）。
【０００７】
このように、インターネットは、外部網である既存電話網からの電話通信などは多様なアプリケーションを収容するようになってきている。それにしたがい、異なった特性やサービスレベルすなわちＱｏＳ（Ｑｕａｌｉｔｙｏｆ  Ｓｅｒｖｉｃｅ）の要求を持ったアプリケーショントラヒックを転送する必要が生じてきている。インターネットは、本来、ベストエフォート型のネットワークであるので、ＱｏＳを実現するためには何らかの仕組みが必要である。しかし、上述したＭＧＣＰでは、音声パケットのＱｏＳを実現するメカニズムは考慮されていない。
【０００８】
現在、このようなＱｏＳを提供する技術として、ＩＲＴＦ  ＤＲＡＦＴとしてＩＥＴＦのウェブサイト（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ）から”ｄｒａｆｔ−ｉｅｔｆ−ｍｐｌｓ−ｆｒａｍｅｗｏｒｋ−０５．ｔｘｔ”としてテキスト文書が入手可能なＭＰＬＳ（ＭｕｌｔｉＰｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ，  ＩＥＴＦ  ＲＦＣ２７０２）やＤｉｆｆｓｅｒｖ（ＤｉｆｆｅｒｅｎｔｉａｔｅｄＳｅｒｖｉｃｅ，  ＩＥＴＦ  ＲＦＣ２４７５）などが提案されている。
【０００９】
ＭＰＬＳでは、パケットに固定長のラベルを付与し、ラベルの値に基づいてパケットを転送する。このパケットが転送される経路であるＬＳＰ（ＬａｂｅｌＳｗｉｔｃｈｅｄ  Ｐａｔｈ）を明示的に制御することにより、トラヒックの要求ＱｏＳに基づいた最適経路の提供や、ネットワーク内の経路の負荷分散を行うトラヒックエンジニアリングが可能となる。
【００１０】
Ｄｉｆｆｓｅｒｖでは、Ｄｉｆｆｓｅｒｖドメインの境界のエッジルータにおいて流入パケットをクラス分けし、クラス識別子であるＤＳＣＰ（ＤｉｆｆｓｅｒｖＣｏｄｅ  Ｐｏｉｎｔ）を付与する。そしてドメイン内部のコアルータでは、ＤＳＣＰの値に基づき、クラス別に定義された転送スケジューリングの定義であるＰＨＢ（ＰｅｒＨｏｐ  Ｂｅｈａｖｉｏｒ）にしたがって、転送スケジューリングを行う。これによりトラヒックの個別のフローにＱｏＳ制御を行うのではなく、フローを集合したクラス別にＱｏＳ制御を行うため、大規模なネットワークにおいてもスケーラブルなＱｏＳ提供が可能となる。
【００１１】
これらの技術はユーザトラヒックに対して経路や転送スケジューリングといったＱｏＳリソースを提供するが、ネットワークワイドで見たときに最適なＱｏＳリソース割当てを提供するためには、さらに、ＭＧＣＰのようなアプリケーションからの要求やネットワーク状態を考慮して最適なＱｏＳリソース割当てを計算、提供する別のメカニズムが必要になる。
【００１２】
シグナリングによりアプリケーショントラヒックの呼ごとにＱｏＳリソースを確保するプロトコルであるＲＳＶＰ（ｒｅｓｏｕｒｃｅｒｅｓｅｒｖａｔｉｏｎ  ｐｒｏｔｏｃｏｌ，  ＩＥＴＦ  ＲＦＣ２２０５）に関しては、ネットワークワイドの視点からＱｏＳリソース割当ての制御を行うための呼受付制御のメカニズムが提案されている（ＩＥＴＦＲＦＣ２７５３）。
【００１３】
図９は、ＲＦＣ２７５３に基づく呼受付制御のメカニズムを示すブロック図である。
【００１４】
ネットワーク７１０内には、それぞれ呼受付部９１２ａ〜９１２ｃを有するルータ９１１ａ〜９１１ｃが設けられている。ネットワーク７１０の一端側は、符号９２４ａで示す他のネットワークまたは端末が接続し、他端側は、符号９２４ｂで示す他のネットワークまたは端末が接続している。ルータ９１１ａ〜９１１ｃは、それぞれパケット９５１ａ〜９５１ｃを受け取ってルーティングを行い、パケット９１１ｂ〜９１１ｄとして出力する。呼受付部９１２ａ〜９１２ｃのそれそれは、隣接する他のルータの呼受付部あるいは他のネットワークまたは端末９２４ａ，９２４ｂの間で、シグナリング９１５ａ〜９１５ｄをやり取りする。さらに、ポリシー決定部９１７とポリシーＤＢ（データベース）９１８を有するポリシーサーバ９１３が設けられている。
【００１５】
ここでネットワーク７１０内の各ルータ９１１ａ〜９１１ｃがＲＳＶＰシグナリング９１５ａ〜９１５ｃを受信すると、ルータ９１１ａ〜９１１ｃ内の呼受付部９１２ａ〜９１２ｃは、ポリシーサーバ９１３に対して、呼を受け付けてよいか否かを呼受付可否メッセージ９１６ａ〜９１６ｃによって問い合わせる。ポリシーサーバ９１３では、呼受付可否メッセージ９１６ａ〜９１６ｃを受け取ると、ポリシー決定部９１７がポリシーデータベース９１８内に保持されているポリシー９１９に従い、呼の受付の可否を決定し、その結果をルータ９１１ａ〜９１１ｃの呼受付部９１２ａ〜９１２ｃに返す。
【００１６】
このメカニズムではＲＳＶＰシグナリング９１５ａ〜９１５ｃに示されているアプリケーショントラヒックのＱｏＳ要求、リソース要求と、ポリシーデータベース９１８内に保持されているポリシー９１９により呼受付が決定されるが、最適なリソース割当てを行うためのメカニズムは提案されていない。また、呼到着のたびにリソース割当てを計算するのは呼設定遅延につながるなどの問題がある。
【００１７】
Ｇｏｙａｌらは、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）のシグナリングと綿密に連携を取り、分散管理環境によってリソース割当てを提供するアーキテクチャＤＯＳＡ（ＰａｗａｎＧｏｙａｌ，  ｅｔ  ａｌ．，  ”Ｉｎｔｅｇｒａｔｉｏｎ  ｏｆ  Ｃａｌｌ  Ｓｉｇｎａｌｉｎｇ  ａｎｄ  ＲｅｓｏｕｒｃｅＭａｎａｇｅｍｅｎｔ  ｆｏｅ  ＩＰ  Ｔｅｌｅｐｈｏｎｙ”，  ＩＥＥＥ  Ｎｅｔｗｏｒｋ，  Ｍａｙ  １９９９）を提案している。しかし、このアーキテクチャでは、ＶｏＩＰシグナリングとリソース割当てシーケンスが密に連携しているため、呼ごとのリソース割当てが呼設定遅延の原因になったり、リソース割当てシステムが障害などで機能しなくなったときにＶｏＩＰ自体も機能しなくなったりするという問題がある。また分散管理環境によってリソース割当てを提供するため、ネットワークワイドで見たときに最適なＱｏＳリソース割当てを行うことができない。
【００１８】
Ａｕｋｉａらが提案するＲＡＴＥＳ（Ｐｅｔｒｉ  Ａｕｋｉａ，  ｅｔ  ａｌ．，  ”ＲＡＴＥＳ：Ａ  Ｓｅｒｖｅｒ  ｆｏｒ  ＭＰＬＳ  Ｔｒａｆｆｉｃ  Ｅｎｇｉｎｅｅｒｉｎｇ”，  ＩＥＥＥ  Ｎｅｔｗｏｒｋ，  Ｍａｒｃｈ２０００）は、ポリシーサーバがネットワーク状態収集機能、ルート計算機能等のモジュールと連携を行うアーキテクチャである。しかしながらこのアーキテクチャは、集中制御により分散管理環境での問題を解決しているが、ＶｏＩＰなどのアプリケーションとの連携が考慮されていない。
【００１９】
【発明が解決しようとする課題】
以上説明したように、ＭＧＣＰ自体はＱｏＳへの考慮がなされておらず、また、既存のＱｏＳ技術も、アプリケーションとの連携が十分でなかったり、最適なＱｏＳリソース割当てを行えなかったり、あるいは、呼設定遅延の原因となったりという問題点を抱えている。
【００２０】
本発明の目的は、ＭＧＣＰなどのプロトコルに対して親和性があり、呼設定遅延の原因となることなくアプリケーションとの連携を行えてかつ最適なＱｏＳリソース割当てを行うことができるＱｏＳサーバとそのリソース割当て制御方法とを提供することにある。
【００２１】
【課題を解決するための手段】
本発明の第１のＱｏＳサーバは、ネットワークと、ネットワークに外部網を収容し外部網とネットワークとの間で主信号の変換を行う主信号ゲートウェイと、呼設定を行う呼設定サーバと、呼設定サーバと外部網との間でシグナリングの変換を行うシグナリングゲートウェイとを有するネットワークシステムにおいて使用されるＱｏＳサーバであって、ネットワークの状態を監視するネットワーク監視部と、ネットワーク監視部で取得したネットワーク状態を蓄積するネットワーク状態データベースと、ネットワーク状態を参照し、リソース要求に基づいてアプリケーションへのリソース割当てを計算するリソース割当て計算部と、リソース割当て情報を保持するリソース割当てデータベースと、リソース割当て情報に基づいてネットワークにリソース割当てを設定するネットワーク設定部と、を有する。
【００２２】
本発明の第２のＱｏＳサーバは、外部網が接続したネットワークと、ネットワークに対するポリシーを決定してネットワークに対してリソース割当てを設定するポリシーサーバとを有するネットワークシステムにおいて使用されるＱｏＳサーバであって、ネットワークの状態を監視するネットワーク監視部と、ネットワーク監視部で取得したネットワーク状態を蓄積するネットワーク状態データベースと、ネットワーク状態を参照し、リソース要求に基づいてアプリケーションへのリソース割当てを計算してポリシーサーバに通知するリソース割当て計算部と、を有する。
【００２３】
本発明の第３のＱｏＳサーバは、外部網に接続するネットワークに対してリソース割当てを設定するＱｏＳサーバであって、ネットワークの状態を監視するネットワーク監視部と、ネットワーク監視部で取得したネットワーク状態を蓄積するネットワーク状態データベースと、設定情報を保持するユーザ情報データベースと、ネットワーク状態データベースに蓄積されたネットワーク状態とユーザ情報データベースに保持された設定情報とを参照してリソース要求を発生するリソース要求部と、ネットワーク状態を参照し、リソース要求に基づいてアプリケーションへのリソース割当てを計算するリソース割当て計算部と、リソース割当て情報を保持するリソース割当てデータベースと、リソース割当て情報に基づいてネットワークにリソース割当てを設定するネットワーク設定部と、を有する。
【００２４】
本発明の第１のリソース割当て制御方法は、ネットワークと、ネットワークに外部網を収容し外部網とネットワークとの間で主信号の変換を行う主信号ゲートウェイと、呼設定を行う呼設定サーバと、呼設定サーバと外部網との間でシグナリングの変換を行うシグナリングゲートウェイとを有するネットワークシステムにおけるリソース割当て制御方法において、ネットワークの状態を監視してネットワーク状態をネットワーク状態データベースに蓄積し、ネットワーク状態データベースに蓄積されたネットワーク状態を参照するとともにリソース要求に基づいて、アプリケーションへのリソース割当てを計算し、リソース割当て情報をリソース割当てデータベースに保持し、リソース割当てデータベースに保持されたリソース割当て情報に基づいてネットワークにリソース割当てを設定する。
【００２５】
本発明の第２のリソース割当て制御方法は、外部網が接続したネットワークと、ネットワークに対するポリシーを決定してネットワークに対してリソース割当てを設定するポリシーサーバとを有するネットワークシステムにおけるリソース割当て制御方法であって、ネットワークの状態を監視してネットワーク状態をネットワーク状態データベースに蓄積し、ネットワーク状態データベースに蓄積されたネットワーク状態を参照するとともにリソース要求に基づいて、アプリケーションへのリソース割当てを計算してポリシーサーバに通知する。
【００２６】
本発明の第３のリソース割当て制御方法は、外部網に接続するネットワークに対してリソース割当てを設定するリソース割当て制御方法であって、ネットワークの状態を監視してネットワーク状態をネットワーク状態データベースに蓄積し、ネットワーク状態データベースに蓄積されたネットワーク状態とユーザ情報データベースに保持された設定情報とを参照してリソース要求を発生し、ネットワーク状態データベースに蓄積されたネットワーク状態を参照し、リソース要求に基づいてアプリケーションへのリソース割当てを計算し、リソース割当て情報をリソース割当てデータベースに保持し、リソース割当てデータベースに保持されたリソース割当て情報に基づいてネットワークにリソース割当てを設定する。
【００２７】
本発明では、ＱｏＳサーバが、アプリケーションとのインタフェースを持つことによりアプリケーションの要求ＱｏＳ、要求リソースを得て、さらにネットワークを監視することによりネットワークの網状態、トラヒック状態をフィードバックすることにより、リソース割当てを計算、提供することを特徴とする。これにより、オペレータの設定を介することなく動的なトラヒックエンジニアリングが可能となる。
【００２８】
また、リソース割当てはアプリケーションの呼の到来前にまとまった呼単位で行われるため、リソース割当て処理がアプリケーションの呼設定遅延の原因になることがなく、また、呼設定のシグナリングとリソース割当てのシグナリングは分離しているので、ＱｏＳサーバの障害時でも、アプリケーションは呼設定を続けることができる。
【００２９】
【発明の実施の形態】
次に、本発明の好ましい実施の形態について、図面を参照して説明する。図１は本発明の実施の一形態のＱｏＳサーバを備えたネットワークシステムを示すブロック図である。ここでは、インターネットに代表されるネットワーク１１０において、ＭＧＣＰ（ＩＥＴＦＲＦＣ２７０５）を使用したＶｏＩＰをアプリケーションとした場合のＱｏＳ（サービス品質）制御について説明する。
【００３０】
図７に示した従来のネットワークシステムと同様に、外部網である既存電話網１２４ａ，１２４ｂ間の音声通信をネットワーク１１０を介して転送するために、ネットワーク１１０に呼設定を行うコールエージェント１２１と、コールエージェント１２１と既存電話網１２４ａ，１２４ｂのシグナリング信号を接続するシグナリングゲートウェイ１２２ａ，１２２ｂと、既存電話網１２４ａ，１２４ｂの主信号トランクとネットワーク１１０を接続するトランクゲートウェイ１２３ａ，１２３ｂとが設けられている。さらに、この実施形態では、従来のものと異なって、ネットワーク１１０を設定監視するＱｏＳサーバ１００が設けられている。トランクゲートウェイ１２３ａ，１２３ｂは、主信号を変換する主信号ゲートウェイである。
【００３１】
シグナリングゲートウェイ１２２ａ，１２２ｂは、既存電話網１２４ａ，１２４ｂのシグナリング信号（１５１’，１５４’，１５５’，１５６’，１５７’，１５９’）とパケット化されたシグナリング（１５１，１５４，１５５，１５６，１５７，１５９）との変換を行うことにより、既存電話網１２４ａ，１２４ｂのシグナリング網とコールエージェント１２１とを接続している。同様に、トランクゲートウェイ１２３ａ，１２３ｂは、既存電話網１２４ａ，１２４ｂの主信号トランクの音声信号（１６１’，１６２’）とパケット化された音声信号（１６１，１６２）との変換を行うにより、既存電話網１２４ａ，１２４ｂの主信号トランクをネットワーク１１０に接続している。ここでは、ＱｏＳ制御の対象となるアプリケーションは、既存電話網１２４ａ，１２４ｂとコールエージェント１２１とシグナリングゲートウェイ１２２ａ，１２２ｂとトランクゲートウェイ１２３ａ，１２３ｂから構成されることになる。
【００３２】
呼設定サーバであるコールエージェント１２１には、ＱｏＳサーバ１００にＱｏＳ、リソース要求を行うリソース要求部１０７が装備されている。
【００３３】
ＱｏＳサーバ１００は、アプリケーションからのＱｏＳ、リソース要求に基づいてそのアプリケーションへのリソース割当てを計算するリソース計算部１０１と、リソース割当てをネットワーク１１０に設定するネットワーク設定部１０２と、ネットワーク状態を監視するネットワーク監視部１０３と、リソース割当て情報を保持するリソース割当てデータベース（ＤＢ）１０４と、アプリケーションからのＱｏＳ、リソース要求を保持するユーザ情報データベース１０５と、ネットワーク状態を保持するネットワーク（ＮＷ）状態データベース１０６とから構成されている。
【００３４】
次に、このネットワークシステムにおけるＱｏＳ制御の動作について、図１及び図２を用いて説明する。
【００３５】
まず、呼の到来に先立ち、リソース割当てが行われる（ステップ２４０）。このとき、ＱｏＳサーバ１００のネットワーク監視部１０３は、ネットワーク１１０から入力する信号１３１によって、ネットワーク１１０の初期設定時から常時ネットワーク１１０を監視しており（ステップ２３１）、ネットワークのトポロジー情報、リンクメトリック、帯域使用状態をネットワーク情報１３２としてネットワーク状態データベース１０６に蓄積している（ステップ２３２）。
【００３６】
ネットワーク１１０の初期設定時に、コールエージェント１２１内のリソース要求部１０７は、呼の到来に先立ち、前もってまとまった呼数分のトラヒックが使用するリソース、図３でいうところのＮ０呼分のリソース要求を行う（ステップ２３３）。リソース要求１３３には、トラヒックの要求遅延、使用帯域、パケットの識別情報（ヘッダ情報など）、ソース・宛先アドレスが示されている。
【００３７】
ＱｏＳサーバ１００内のリソース割当計算部１０１は、ネットワーク監視部１０３が収集してネットワーク状態データベース１０６に蓄積されたネットワーク、ユーザ監視情報１３４を元に、リソース要求１３３に対するリソース割当て計算する（ステップ２３４）。リソース割当て計算には、トラヒックのソース−宛先アドレス間の要求遅延を満足する経路、経路上のリンク帯域、ネットワークノード内のバッファ割当ての計算がある。
【００３８】
リソース割当計算部１０１は、計算したリソース割当てをリソース割当て情報１３５としてリソース割当データベース１０４に蓄積し（ステップ２３５）、リソース割当て要求１３６を出すことにより、ネットワーク設定部１０２に設定を行うように通知する（ステップ２３６）。
【００３９】
ネットワーク設定部１０２は、リソース割当データベース１０４に蓄積されたリソース割当て情報１３７を読出し（ステップ２３７）、ネットワーク１１０に対してリソース割当て設定１３８を送出することにより、ネットワークにおけるリソース割当ての設定を行う（ステップ２３８）。これにより、ネットワーク１１０の設定が終了する。
【００４０】
このネットワーク１１０の設定が完了すると、ネットワーク設定部１０２はリソース割当計算部１０１に設定完了を応答信号（ＡＣＫ）１３９として通知する（ステップ２３９）。
【００４１】
リソース割当計算部１０１は、受け付けたリソース要求をユーザ情報１４０としてユーザ情報データベース１０５に蓄積し（ステップ２４０）、リソース割当てが成功したことを応答信号（ＡＣＫ）１４１としてコールエージェント１２１に通知する（ステップ２４１）。
【００４２】
リソース割当て完了後、シグナリングゲートウェイ１２２ａ，１２２ｂを経由して呼設定信号が到来し、呼設定が行われる（ステップ２５０）。
【００４３】
呼設定２５０は、図８において示した従来のＭＧＣＰによる手順と同様である。すなわち、既存電話網１２４ａ側から発呼する場合を考えると、まず、シグナリングゲートウェイ１２２ａからコールエージェント１２１にＩＡＭ１５１が送られ（ステップ２５１）、コールエージェント１２１とトランクゲートウェイ１２３ａの間でＣＲＣＸ／ＡＣＫ１５２がやり取りされ（ステップ２５２）、その後、コールエージェント１２１とトランクゲートウェイ１２３ｂの間でＣＲＣＸ／ＡＣＫ７５３がやり取りされ（ステップ２５３）、コールエージェント１２１からシグナリングゲートウェイ１２２ｂに、ＩＡＭ１５４が送られる（ステップ２５４）。その後、シグナリングゲートウェイ１２２ｂからコールエージェント１２１にＡＣＭ１５５が送られ（ステップ２５５）、コールエージェント１２１からシグナリングゲートウェイ１２２ａにＡＣＭ１５６が送られる（ステップ２５６）。引き続き、シグナリングゲートウェイ１２２ｂからコールエージェント１２１にＡＮＭ１５７が送られ（ステップ２５７）、コールエージェント１２１とトランクゲートウェイ１３２ａの間でＭＤＣＸ／ＡＣＫ１５８がやり取りされ（ステップ２５８）、コールエージェント１２１からシグナリングゲートウェイ１２２ａにＡＮＭ１５９が送られる（ステップ２５９）。
【００４４】
ステップ２５０に示す呼設定の完了後、トランクゲートウェイ１２３ａからネットワーク１１０へのトラヒック１６１の転送が開始される（ステップ２６１）。転送されたトラヒックは、ネットワーク１１０において設定されたりソース割当て、すなわち経路、リンク帯域、バッファを使用して、トラヒック１６２として、トランクゲートウェイ１２３ｂに転送される（ステップ２６２）。
【００４５】
また上述の呼設定完了後、ＱｏＳサーバ１００は、ネットワーク１１０を監視し、障害回避を行う（ステップ２７０）。
【００４６】
この監視と障害回避のステップ２７０では、ＱｏＳサーバ１００内のネットワーク監視部１０３は、ユーザ情報データベース１０５に蓄積されているユーザ情報１７１から、リソース割当て計算部１０１がどのようなリソース要求を受け付けたかを知る（ステップ２７１）。また、ネットワーク監視部１０３は、ネットワーク１１０から入力する信号（監視したリソース情報）１７２により、トラヒックに割当てられたリソースを監視する（ステップ２７２）。さらにネットワーク監視部１０３は、受信側のトランクゲートウェイ１２３ｂに対しても、アプリケーショントラヒック情報１７３により、トラヒックが要求どおりの品質で受信されているかを問い合わせる（ステップ２７３）。その後、ネットワーク監視機能１０３は、監視したリソース情報１７２及びアプリケーショントラヒック情報１７３をユーザ監視情報１７４として、ネットワーク状態データベース１０６に蓄積する（ステップ２７４）。そしてネットワーク監視部１０３は、リソースの障害が発生したりトラヒックが要求品質どおりに転送されていないことを検知すると、リソース割当計算機能１０１に障害情報（障害通知１７５）を通知する（ステップ２７５）。
【００４７】
障害通知１７５を受け取ったリソース割当計算部１０１は、ユーザ情報データベース１０５に蓄積されているユーザ情報１７６から、アプリケーションの要求条件を引き出し（ステップ２７６）、ネットワーク状態データベース１０６に蓄積されているネットワーク状態、障害内容（ネットワーク、ユーザ監視情報１７７）を元に、障害を回避するようにリソース割当てを再計算する（ステップ２７７）。そしてリソース割当計算部１０１は、その計算結果をリソース割当て変更情報１７８としてリソース割当データベース１０４に蓄積し（ステップ２７８）、ネットワーク設定部１０２に、リソース割当て変更要求１７９として、再設定要求を通知する（ステップ２７９）。リソース割当ての再計算には、バックアップ経路の計算などがあるが、ステップ１３４のリソース割当計算時に障害を想定してあらかじめバックアップ経路も計算し、リソース割当データベース１０４に蓄積しておいてもよい。
【００４８】
次に、ネットワーク設定部１０２は、リソース割当データベース１０４に蓄積されたリソース割当て変更情報１８０を読出し（ステップ２８０）、読出しリソース割当て変更情報１８０に従ってリソース割当て再設定２８１をネットワーク１１０に送出することによってネットワークを再設定し（ステップ２８１）、再設定完了後、リソース割当計算部１０１に対し、応答信号１８２により、設定完了を通知する（ステップ２８２）。
【００４９】
一方、コールエージェント１２１内のリソース要求部１０７は、接続呼数を監視し、接続呼数に従い追加リソース割当あるいはリソース解放をＱｏＳサーバ１００に要求する。追加リソース割当、リソース解放の手順自体は、上述したステップ２４０（リソース割当て）の場合と同様である。以下、図３を用いて、追加リソース割当、リソース解放のタイミングを説明する。
【００５０】
ます、追加リソース割当てについて説明する。あらかじめＮ０呼分のリソース３０４ａが割当てられており、このリソースの範囲内で既にリソース追加要求しきい値３０２ａａが定められているものとする。ここで接続呼数３０１ａがリソース追加要求しきい値３０２ａａを越えると、使用リソース３０３ａ（図示斜線部）が割当てられたリソース３０４ａを越えないうちに、コールエージェント１２１は、Ｎ１呼分の追加リソース３０５を要求し、新たなリソース追加要求しきい値１３２ａｂを設定する。もちろん、新たなしきい値１３２ａｂは、Ｎ０＋Ｎ１呼の範囲内に設定される。
【００５１】
次に、リソース解放について説明する。既に、Ｎ０＋Ｎ１＋Ｎ２呼分のリソースが割当てられており、また、リソース解放要求しきい値３０２ｂａが設定されているものとする。接続呼数３０１ｂがリソース解放要求しきい値３０２ｂａを下回ると、コールエージェント１２１はＮ２呼分のリソース３０６の解放を要求し、新たなリソース解放要求しきい値１３２ｂｂを設定する。図において斜線部は使用リソース３０３ｂである。
【００５２】
以上のように構成することにより、この実施の形態のネットワークシステムでは、ＱｏＳサーバがアプリケーション側とのインタフェースを備えているので、ＱｏＳサーバは、アプリケーションの要求ＱｏＳ、要求リソースを取得することができ、アプリケーションの要求に応じたリソース割当てを行うことができる。またネットワークを監視してネットワーク状態、トラヒック状態をアプリケーションへのリソース割当てにフィードバックすることにより、ネットワーク状態に応じたリソース割当てを行うことができる。この際、リソースの障害やリソースを割当てたアプリケーショントラヒックの品質低下を検出し、リソース割当て変更を行うことにより、障害回避を行うことができる。
【００５３】
したがって、オペレータによる設定を介することなく、動的なリソース割当て、ネットワーク設計が可能となる。
【００５４】
さらに、リソース割当ては、アプリケーションの呼の到来前に、まとまった呼単位で行われるため、リソース割当て処理がアプリケーションの呼設定遅延の原因になることがない。呼設定のシグナリングとリソース割当てのシグナリングは分離しているので、ＱｏＳサーバの障害時でも、アプリケーションは呼設定を続けることができる。
【００５５】
次に本発明の第２の実施形態について説明する。本発明において、リソース要求部１０７の設けられる位置は、コールエージェント（呼設定サーバ）１２１内に限定されるものではない。例えば、実際に音声パケットを取扱うトランクゲートウェイの内部や、ＱｏＳサーバ自体の内部にリソース要求部１０７を設けることが可能である。
【００５６】
図４は、本発明の第２の実施の形態におけるＱｏＳサーバを備えたネットワークシステムの構成を示すブロック図である。図４は、リソース要求部１０７がトランクゲートウェイ１２３ａ内に存在する例を示している。ここでは、リソース要求部１０７は、トランクゲートウェイ１２３ａがコールエージェント１２１から受けた呼設定シグナリング１５８に従い設定した呼の数を監視し、設定した呼の数に従いリソース要求１３３を行う。その他の動作は、第１の実施の形態の場合と同様である。すなわちこの実施の形態でも、▲１▼呼の到着前に前もってトラヒックの要求品質、要求リソースを得て、経路、リソース割当てを計算し、経路、リソース割当てを行い、▲２▼複数呼のトラヒックの要求品質、要求リソースを得て、経路、リソース割当てを計算し、経路、リソース割当てを行い、▲３▼接続呼数があるしきい値を越えると追加の複数呼のトラヒックの要求品質、要求リソースを得て、リソース割当てを再計算してリソースの追加割当てを行うようにし、▲４▼接続呼数があるしきい値を下回ると削減された複数呼のトラヒックのリソース解放要求を得て、リソース割当てを解放し、▲５▼割当てたリソース上を流れるトラヒックを監視し、要求品質が満たされていないことを検出すると経路、リソース割当てを再計算し、経路、リソース割当てを修正するようにしている。
【００５７】
次に、本発明の第３の実施の形態について説明する。ここに示す例は、ＲＳＶＰなどのように、シグナリングを集中制御するコールエージェントや呼接続を行うトランクゲートウェイを持たないアプリケーションに、本発明を適用した場合の例である。コールエージェント（呼設定サーバ）及びトランクゲートウェイを設けない代わりに、呼受付決定を行うポリシーサーバが設けられている。
【００５８】
図５は、本発明の第３の実施の形態におけるＱｏＳサーバ及びポリシーサーバを備えたネットワークシステムの構成を示すブロック図である。
【００５９】
図５に示す構成では、ネットワーク１１０内には、それぞれ呼受付部５１２ａ〜５１２ｃを有するルータ５１１ａ〜５１１ｃが設けられている。ネットワーク１１０の一端側は、符号５２４ａで示す他のネットワークまたは端末が接続し、他端側は、符号５２４ｂで示す他のネットワークまたは端末が接続している。ここでは、他のネットワークまたは端末５２４ａ，５２４ｂは、外部網の範疇に属する。ルータ５１１ａ〜５１１ｃは、それぞれパケット５５１ａ〜５５１ｃを受け取ってルーティングを行い、パケット５１１ｂ〜５１１ｄとして出力する。呼受付部５１２ａ〜５１２ｃのそれそれは、隣接する他のルータの呼受付部あるいは他のネットワークまたは端末５２４ａ，５２４ｂの間で、シグナリング５１５ａ〜５１５ｄをやり取りする。
【００６０】
ＱｏＳサーバ１００は、リソース割当て計算部１０１、ネットワーク監視部１０３、ユーザ情報データベース１０５及びネットワーク情報データベース１０６を備えている。図１あるいは図４に示す例におけるＱｏＳサーバと比べ、図５に示すＱｏＳサーバには、ネットワーク設定部及びリソース割当てデータベースが設けられていないが、それらの機能は、後述するようにポリシーサーバ５１３によって実行される。
【００６１】
リソース要求部１０７は、呼受付決定を行うポリシーサーバ５１３内に設けられる。さらにポリシーサーバ５１３には、ポリシーを決定するポリシー決定部５１７と、ポリシーとリソース割当て情報１３５，１７８を蓄積するリソース割当て・ポリシーデータベース５１８とを備えている。ポリシー決定部５１７は、ネットワーク設定部としての機能も果たし、また、リソース割当て・ポリシーデータベース５１８は、リソース割当てデータベースとしての機能も果たす。
【００６２】
ポリシー決定部５１７は、ＲＳＶＰシグナリング５１５〜５１５ｃを受信した各ルータ５１１ａ〜５１１ｃ内の呼受付部５１２ａ〜５１２ｃからの呼受付決定要求５１６ａ〜５１６ｃに対して呼受付決定を行う。また、リソース要求部１０７は、リソース割当て・ポリシーデータベース５１８から得られる情報５９３を利用して、ポリシー決定部が管理している受け付けた呼の情報（ポリシー５１９）を監視し、受け付けた呼の数にしたがってリソース要求１３３を行う。これにより、受付呼数にしたがって事前に新たな呼のためのネットワークのリソース設定１３８が行われるので、ポリシーサーバ５１３が新たに呼受付決定要求５１６ａ〜５１６ｃを受けたときにはリソース割当て情報１３７を参照するだけで、呼受付決定ができる。したがって、この実施の形態によれば、リソース割当て計算が呼設定遅延の原因になることがない。
【００６３】
上述の他の動作については、第１の実施の形態と同様である。すなわちこの実施の形態でも、▲１▼呼の到着前に前もってトラヒックの要求品質、要求リソースを得て、経路、リソース割当てを計算し、経路、リソース割当てを行い、▲２▼複数呼のトラヒックの要求品質、要求リソースを得て、経路、リソース割当てを計算し、経路、リソース割当てを行い、▲３▼接続呼数があるしきい値を越えると追加の複数呼のトラヒックの要求品質、要求リソースを得て、リソース割当てを再計算してリソースの追加割当てを行うようにし、▲４▼接続呼数があるしきい値を下回ると削減された複数呼のトラヒックのリソース解放要求を得て、リソース割当てを解放し、▲５▼割当てたリソース上を流れるトラヒックを監視し、要求品質が満たされていないことを検出すると経路、リソース割当てを再計算し、経路、リソース割当てを修正するようにしている。
【００６４】
次に、本発明の第４の実施の形態について説明する。本発明はシグナリングを持たないアプリケーションに対しても有効である。図６は、シグナリングを持たないアプリケーションに対して適用した場合のネットワークシステムを示している。ここではネットワーク１１０は、符号６２４ａ，６２４ｂにより示される他のネットワークまたは端末と接続している。ここでは、他のネットワークまたは端末６２４ａ，６２４ｂは、外部網の範疇に属する。
【００６５】
シグナリングを持たないので、当然、シグナリングゲートウェイやコールエージェントは存在しないことになる。図示する例の場合、リソース要求部１０７はＱｏＳサーバ１００内に存在する。
【００６６】
オペレータ６９０は、ＱｏＳサーバ１００がサポートすべきアプリケーションのトラヒック識別情報、要求ＱｏＳ情報を、設定情報６９１として、ユーザ情報データベース１０５に設定する。リソース要求部１０７は、ユーザ情報データベース１０５に設定された設定情報から、サポートすべきアプリケーションの情報６９２を得て、ネットワークの初期設定時に、第１の実施の形態と同様に、リソース割当て計算部１０１に対してリソース要求１３３を行う。リソース割当ての完了後、リソース要求部１０７は、ネットワーク監視部１０３が信号１７２によってネットワーク１１０を監視することによってネットワーク状態データベース１０６に蓄積したアプリケーショントラヒック情報１７４から、アプリケーショントラヒックの呼の増減６９３を検知し、第１の実施の形態と同様に、リソース割当て計算部１０１に対して、リソースの追加要求、解放要求１４１を行う。
【００６７】
シグナリング関係の構成を有しないことを除けば、図６に示すように、このネットワークシステムにおける上述したもの以外の配置及び動作は、図１、図４に示したものにおける配置及び動作を同様である。すなわちこの実施の形態でも、▲１▼呼の到着前に前もってトラヒックの要求品質、要求リソースを得て、経路、リソース割当てを計算し、経路、リソース割当てを行い、▲２▼複数呼のトラヒックの要求品質、要求リソースを得て、経路、リソース割当てを計算し、経路、リソース割当てを行い、▲３▼接続呼数があるしきい値を越えると追加の複数呼のトラヒックの要求品質、要求リソースを得て、リソース割当てを再計算してリソースの追加割当てを行うようにし、▲４▼接続呼数があるしきい値を下回ると削減された複数呼のトラヒックのリソース解放要求を得て、リソース割当てを解放し、▲５▼割当てたリソース上を流れるトラヒックを監視し、要求品質が満たされていないことを検出すると経路、リソース割当てを再計算し、経路、リソース割当てを修正するようにしている。
【００６８】
【発明の効果】
以上説明したように本発明は、ＱｏＳサーバがアプリケーション側とのインタフェースを備えているので、ＱｏＳサーバは、アプリケーションの要求ＱｏＳ、要求リソースを取得することができ、アプリケーションの要求に応じたリソース割当てを行うことができるという効果がある。またネットワークを監視してネットワーク状態、トラヒック状態をアプリケーションへのリソース割当てにフィードバックすることにより、ネットワーク状態に応じたリソース割当てを行うことができるという効果がある。この際、リソースの障害やリソースを割当てたアプリケーショントラヒックの品質低下を検出し、リソース割当て変更を行うことにより、障害回避を行うことができる。したがって、本発明によれば、オペレータによる設定を介することなく、動的なリソース割当て、ネットワーク設計が可能となる。
【００６９】
さらに本発明においてリソース割当ては、アプリケーションの呼の到来前に、まとまった呼単位で行われるため、リソース割当て処理がアプリケーションの呼設定遅延の原因になることがない。呼設定のシグナリングとリソース割当てのシグナリングは分離しているので、ＱｏＳサーバの障害時でも、アプリケーションは呼設定を続けることができる。
【図面の簡単な説明】
【図１】本発明の実施の第１の形態におけるＱｏＳサーバを備えたネットワークシステムの構成を示すブロック図である。
【図２】図１に示すネットワークシステムにおけるＱｏＳ制御を説明するフロー図である。
【図３】追加リソース割当、リソース解放のタイミングを説明する図である。
【図４】本発明の第２の実施の形態におけるＱｏＳサーバを備えたネットワークシステムの構成を示すブロック図である。
【図５】本発明の第３の実施の形態におけるＱｏＳサーバとポリシーサーバを備えたネットワークシステムの構成を示すブロック図である。
【図６】本発明の第４の実施の形態におけるＱｏＳサーバを備えたネットワークシステムの構成を示すブロック図である。
【図７】ＭＧＣＰが適用される従来のネットワークシステムの構成を示すブロック図である。
【図８】ＭＧＣＰにおける呼設定処理の手順を示すフロー図である。
【図９】ＲＦＣ２７５３に示される呼受付制御のためのメカニズムを示すブロック図である。
【符号の説明】
１００    ＱｏＳサーバ
１０１    リソース割当て計算部
１０２    ネットワーク設定部
１０３    ネットワーク監視部
１０４    リソース割当てデータベース
１０５    ユーザ情報データベース
１０６    ネットワーク状態データベース
１０７    リソース要求部
１１０    ネットワーク
１２１    コールエージェント
１２２ａ，１２２ｂ    シグナリングゲートウェイ
１２３ａ，１２３ｂ    トランクゲートウェイ
１２４ａ，１２４ｂ    既存電話網
５１３    ポリシーサーバ
５１８    リソース割当て・ポリシーデータベース
５１９    ポリシー決定部
【図１】
0003578209.tif 000002
【図２】
0003578209.tif 000003
【図３】
0003578209.tif 000004
【図４】
0003578209.tif 000005
【図５】
0003578209.tif 000006
【図６】
0003578209.tif 000007
【図７】
0003578209.tif 000008
【図８】
0003578209.tif 000009
【図９】
0003578209.tif 000010