(57)【要約】【課題】仮想バッファ／トランクモデル方式に基づく呼受付判定方法を、優先制御を行うネットワークノードに適用可能とし、複数クラスの品質を保証できる形に拡張できるようにする。【解決手段】新規受付呼の優先クラスのフローと当該優先クラスよりも優先度の高い優先クラスのフローとで集合を構成して仮想最大バッファ容量を求め（ステップ３，４）、当該優先クラスよりも優先度の低いクラスについても、同様にして自クラスのフローと自クラスよりも優先度の高い優先クラスのフローとで集合を構成して、順次、仮想最大バッファ容量を求めていき（ステップ６〜９）、新規受付呼の優先クラス、および当該優先クラスよりも優先度の低い各クラスの仮想最大バッファ容量が、各クラス毎に設けられたバッファ量を超えるか否かに基づいて（ステップ５，１０）、新規受付可否を判定する（ステップ１２，１３）。【選択図】図１２
2006246119.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰ網における複数クラスの品質保証を行うためのコンピュータ制御による呼受付判定方法であって、
サービス制御装置は、演算回路を起動して、新規受付呼の優先クラスのフローと当該優先クラスよりも優先度の高い優先クラスのフローとで集合を構成して、仮想最大バッファ容量を求め、
該演算回路を動作して、当該優先クラスより優先度の低いクラスについても、前記と同様に当該クラスのフローと当該クラスよりも優先度の高い優先クラスのフローとで集合を構成し、順次、仮想最大バッファ容量を求め、
該サービス制御装置は、該演算回路を動作して、新規受付呼の優先クラス、および当該優先クラスよりも優先度の低い各クラスの仮想最大バッファ容量と、各クラス毎に設けられたバッファ設備量とを比較し、該各クラスの仮想最大バッファ容量がバッファ設備量を超えるか否かに基づいて、新規受付可否を判定することを特徴とする呼受付判定方法。
【請求項２】
サービス制御装置が、演算回路の動作により、セッションフローの集合Ｓについて、セッションフローｉ∈Ｓのトラヒック特性がピークレートＰｉ，トークンレートρｉ，バーストサイズσｉのトークンパケットモデルで表されるとき、まず各セッションフローへトークンレート相当の帯域を仮想的に割り当て、ノードの処理能力と割り当て済みの仮想帯域の差分については、セッションフロー毎のバースト継続時間ｔｉ＝σｉ／（Ｐｉ−ρｉ）を計算し、計算されたバースト継続時間のより長いセッションへの仮想的な割り当て帯域がピークレートに相当するように配分し、セッションフローｉに割り当てられた仮想帯域ｃｉに対して、仮想バッファ最大値をｂｉ＝ｔｉ（Ｐｉ−ｃｉ）で計算し、セッションフロー全体による仮想最大バッファ量をｂ＝Σｉ∈Ｓｂｉで計算する呼受付判定方法であって、
該サービス制御装置は、セッションフローの優先度別に個別バッファを設けるとともに、優先度の高いバッファに収容されたデータは優先度の低いバッファに収容されたデータよりも必ず優先的に処理されるように構成し、
該演算回路を動作することで、優先度の高いクラスに対しては、当該クラスに対応するセッションフローのみで前記集合Ｓを構成して、当該クラスの仮想最大バッファ量を計算し、
優先度の低いクラスに対しては、当該クラスおよび優先度の高いクラスのセッションフローにより前記集合Ｓを構成して、当該クラスの仮想最大バッファ量を計算することを特徴とする呼受付判定方法。
【請求項３】
請求項２に記載の呼受付判定方法において、
前記サービス制御装置は、新規呼の受付要求時に、演算回路を起動して、新規呼を含めた場合の各クラスの仮想最大バッファ量を計算し、
計算された仮想最大バッファ量がノードに実装されているバッファ量以下であれば論理的パケットロスをゼロとみなして、新規呼の受付を許可し、
計算された仮想最大バッファ量がノードに実装されているバッファ量を超える場合は、論理的パケットロスをゼロにできないと判断して、新規呼の受付を拒否することを特徴とする呼受付判定方法。
【請求項４】
請求項２に記載の呼受付判定方法において、
前記サービス制御装置は、演算回路を動作して、ある優先クラスの仮想最大バッファ量を、まず当該クラスより高い優先度を有する全てのクラスの仮想バッファが空になるまでの時間を計算し、
上記空になった時点での当該クラスのデータフローレートと利用可能な帯域を比較し、
当該クラスのデータフローレートが利用可能な帯域を下回る場合には、該下回った時点までの当該クラスの到着データ量を計算して、計算結果を仮想最大バッファ量とし、
当該クラスのデータフローレートが利用可能な帯域を上回る場合には、請求項２に記載の方法により仮想最大バッファ量とすることを特徴とする呼受付判定方法。
【請求項５】
請求項４に記載の呼受付判定方法において、
前記サービス制御装置は、新規呼の受付要求時に、演算回路を起動して、新規呼を含めた場合の各クラスの仮想最大バッファ量を計算し、
計算された仮想最大バッファ量がノードに実装されているバッファ量以下であれば論理的パケットロスをゼロとみなして、新規呼の受付を許可し、
計算された仮想最大バッファ量がノードに実装されているバッファ量を超える場合は、論理的パケットロスをゼロにできないと判断して、新規呼の受付を拒否することを特徴とする呼受付判定方法。
【請求項６】
ユーザ網内装置からＩＰまたはＭＰＬＳによるサービス提供網に流入するセッションフローをＵＮＩで規定し、ＵＮＩ間品質保証を提供するネットワークシステムにおいて、
複数のネットワークノード、ユーザターミナル装置、ＵＮＩ装置と接続して送受信を行うサービス制御装置に、
優先クラス１〜Ｎに対応し、それぞれ異なる容量を持つ複数個の個別バッファ群と、
各セッションフローが優先クラスを有し、該セッションフローのトラヒック特性がピークレート、トークンレート、バーストサイズを用いたトークンバケットモデルで表されることにより、該サービス提供網内の転送ノードで各優先クラスのデータロスの有無を計算する品質演算装置と、
新規呼の当該ネットワークノードへの接続要求と当該呼の申告パラメータ、および接続済みの呼の終了通知を外部信号線より取得し、新規呼の接続可否判断の結果を外部信号線を通じて発信する信号制御装置と、
接続済みの各呼により申告されたトークンバケットパラメータおよび優先クラスについての情報を格納し、新規受付を要求する呼から申告されたパラメータを格納し、新規呼の接続が拒否された場合、および、接続済みの呼の終了通知が該信号制御装置に伝えられた場合には、該パラメータを消去する呼情報記憶装置とを設けることを特徴とするネットワークシステム。
【請求項７】
ＩＰ網における複数クラスの品質保証を行うための呼受付判定用プログラムであって、
サービス制御装置のコンピュータに、演算回路を起動して、新規受付呼の優先クラスのフローと当該優先クラスよりも優先度の高い優先クラスのフローとで集合を構成し、仮想最大バッファ容量を求める手順、該演算回路を動作して、当該優先クラスより優先度の低いクラスについても、前記と同様に当該クラスのフローと当該クラスよりも優先度の高い優先クラスのフローとで集合を構成し、順次、仮想最大バッファ容量を求める手順、該演算回路を動作して、新規受付呼の優先クラス、および当該優先クラスよりも優先度の低い各クラスの仮想最大バッファ容量と、各クラス毎に設けられたバッファ設備量とを比較する手順、該各クラスの仮想最大バッファ容量がバッファ設備量を超えるか否かに基づいて、新規受付可否を判定する手順を、実行させるための呼受付判定用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）網またはＭＰＬＳ（Ｍｕｌｔｉ  Ｐｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ）網において品質保証型のサービスを提供するための優先制御型ネットワークシステムおよびそのシステムにおける呼受付判定方法、ならびにそのプログラムに関する。
【背景技術】
【０００２】
ブロードバンド回線が低価格でユーザに提供されるようになり、インターネットは急激に普及している。様々なサービスがインターネットを介して提供されるようになるとともに、その通信品質が重要視されるようになった。特に、リアルタイムな映像、音声サービスに対してはネットワーク上におけるデータ転送品質が大きく影響するが、インターネットでは、そのデータ転送品質を保証する仕組みがないため、現在ではＩＰ閉域網としてネットワークを構築し、データ転送品質を保証する技術と組み合わせて品質保証型のサービスを提供することが検討されている。
ＩＰ網において、データ転送品質を保証するサービスモデルとして、主にＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）で検討されたＩｎｓｅｒｖとＤｉｆｆｓｅｒｖとに分けられる。
【０００３】
Ｉｎｓｅｒｖは、ネットワーク経路上の帯域を確保した上で、その確保した品質に応じたサービスを受けるモデルである。Ｉｎｓｅｒｖモデルでは、ｅｎｄ−ｔｏ−ｅｎｄでネットワーク経路上の帯域を予約するプロトコルであるＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を用いて、遅延、パケット損失率を厳密に保証するサービスクラス（Ｇｕａｒａｎｔｅｅｄ  Ｓｅｒｖｉｃｅ）か、優先サービスクラス（Ｃｏｎｔｒｏｌｌｅｄ−ｌｏａｄ  Ｓｅｒｖｉｃｅ）を提供する。ＲＳＶＰリクエストは、ネットワーク内の各転送ノードによりフォワーディングされ、リクエストを受ける転送ノードは、管理するする帯域情報をもとにリクエストされるサービスが提供可能か否かを判断し、提供可能な場合にはｅｎｄ−ｔｏ−ｅｎｄで帯域を確保し、コネクションを確立させる。
【０００４】
ＲＳＶＰリクエストは、トークンパケットモデルに従ったトラヒック規定を含んでおり、トークンパケットパラメータに従った帯域確保を行う。しかしながら、品質保証型のサービスを提供するためには、ＲＳＶＰを用いたＩｎｓｅｒｖでは、ネットワーク転送ノードにおいてＲＳＶＰに関連する情報を全てリアルタイムに管理、かつパケット転送を行う必要があるため、スケールしないという課題を持っている。
【０００５】
一方、Ｄｉｆｆｓｅｒｖは、ネットワーク内において転送パケットにマーキングすることによりクラス分けを行い、ネットワーク転送ノードにおけるパケットスケジューリングにより、クラスごとの転送品質の差異化を行うモデルである。Ｄｉｆｆｓｅｒｖモデルでは、規定されたＰＨＢ（Ｐｅｒ−Ｈｏｐ  Ｂｅｈａｖｉｏｒ）によって各ネットワーク転送ノードでの転送品質が確保される。サービスクラスに対応するＰＨＢは完全優先であるＥＦ（Ｅｘｐｅｄｉｔｅｄ  Ｆｏｒｗａｒｄｉｎｇ）、最低帯域保証であるＡＦ（Ａｓｓｕｒｅｄ  Ｆｏｒｗａｒｄｉｎｇ）が規定されており、市販のネットワーク転送ノードにも実装が進んでいる。
Ｄｉｆｆｓｅｒｖでは、ネットワーク転送ノードごとの転送品質を差異化し、各転送ノードでの制御のみを規定するだけであるため、Ｉｎｓｅｒｖにおけるスケールしないという課題を解決する。
【０００６】
しかしながら、品質保証型のサービスを提供するためには、サービス提供網内で統一された利用帯域に関する受付判定を行わなければならないという課題と、サービスプロバイダはネットワーク内のリソースに応じてサービス提供品質を規定しなければならないという課題は依然として残っている。
サービス提供品質の規定に関しては、ＩＴＵ−Ｔにおいて、サービス品質を規定するためのパラメータ定義、転送品質クラス規定、サービスモデルが勧告化されている。しかしながら、ＩＴＵ−Ｔ勧告Ｙ．１５４１における規定された転送品質をＹ．１２２１におけるサービスモデルで実現する手段に関しては検討されておらず、サービスプロバイダはネットワーク内のリソースに応じてサービス提供品質を規定しなければならない、という課題が依然として残っている。
【０００７】
利用帯域に関する受付判定モデルとしては、トークンバケットパラメータに従ったネットワークへの入力トラヒックに対して受付判定を行う、仮想バッファ／トランクモデルがある。仮想バッファ／トランクモデルでは、トークンバケットモデルに従ったトラヒックの最悪条件をＯＮ／ＯＦＦトラヒックとしてモデル化し、申告帯域に対して、比例したバッファ量を仮想的に割り当てることによって、ネットワーク帯域を管理する帯域管理サーバによる各ネットワーク転送ノードのバッファ量を考慮した実効帯域（ｅｆｆｅｃｔｉｖｅ  ｂａｎｄｗｉｄｔｈ）の積み上げ管理を以下の考え方に基づき行い、論理的パケット損失率ゼロの受付判定を行う。
【０００８】
（トークンバケットから送出されるトラヒックの最大量）
トークンバケットで規定されるトラヒックに関しては、時刻０からｔまでに発生するトラヒックの最大量Ａ（ｔ）は、次式（１）で規定される。
【０００９】
【数１】
2006246119.tif 000003
ただし、ｍｉｎ｛｝は｛｝内の最小値、σはバケットサイズ、ρは比例係数を表している。図１は、トークンバケットで規定されるセッションフローから転送されるデータの最大量の時間経過を示す図、つまりトラヒックの最大量Ａ（ｔ）の特性曲線図である。
【００１０】
このとき、ピークレートＰでトラヒック送出が可能な最大時間をＴとすると、式（１）からＰＴ＝σ＋ρＴとなり、次式（２）を得る。
【００１１】
【数２】
2006246119.tif 000004
【００１２】
（トークンバケットから送出されるトラヒックが使用するリソース量（ｂ，ｃ）の特性）
図２は、トークンバケットで規定されるセッションフローから転送されるデータが仮想バッファ／トランクシステムに加わる様子を模した図である。
図２において、ｃはリンク数、ｂはバッファ量である。図２に示すように、トークンバケットから送出された１本のセッションフローが確定的なキューイングシステムにおいてサービスされることを考える。ｖ（ｔ）を時刻ｔにおける使用バッファ量、ｂを使用バッファ量の最大値、ｕ（ｔ）を時刻ｔにおける利用帯域、ｃを利用可能な最大帯域、ただし、ρ≦ｃ≦Ｐとする。フローが最大値Ａ（ｔ）でデータ送出するとき、時刻０よりＴまでの間は、使用バッファ量はＰ−ｃ≧０のレートで増加し、それ以降はｃ−ρのレートで減少することになるため、次式（３）が得られる。
【００１３】
【数３】
2006246119.tif 000005
図３は、トークンバケットで規定されるセッションフローが仮想バッファ／トランクシステムに加わった時の仮想バッファ使用量の時間経過を示す図である。
【００１４】
（仮想バッファ／トランクモデル）
図４は、トークンバケットで規定される複数のセッションフローが仮想バッファ／トランクシステムに加わる様子を模した図である。
今、トークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）を持つセッションフローｋ（ｋ＝１，２，・・・，Ｋ）がバッファ量Ｂ、リンク帯域Ｃを持つノードに多重されることを考える。このとき、図４に示すように、各セッションフローｋに対してリンク帯域ｃｋ（ρｋ≦ｃｋ≦Ｐｋ）を仮想的に割り当てることを考える。ただし、仮想リソースの総量はリンク帯域Ｃを上回らないようにする。すなわち、次式（４）が成立する。
【００１５】
【数４】
2006246119.tif 000006
このとき、セッションフローｋが使用する仮想的なバッファリソースの最大値ｂｋは、前式（３）と同様に、次式（５）で表すことができる。
【００１６】
【数５】
2006246119.tif 000007
全フローによる実際のバッファ使用量の最大値ｂは、仮想バッファ使用量の和を上回ることはないので、次式（６）が成り立てば、論理的なパケットロスがゼロになる。
【００１７】
【数６】
2006246119.tif 000008
言い換えると、式（５）を満たすＫ組の仮想リソース（ｂｋ，ｃｋ）に対して、式（４）および式（６）が成り立てば、当該リンクにおける論理的なパケットロスはゼロになる。
各セッションフローに割り当てる仮想リソースを決定する第一の方法は、ｃｋを次式（７）で与える。なお、式（７）に関しては、Ａ．Ｅｌｗａｉｌｄ，Ｄ．Ｍｉｔｒａ  ａｎｄ  Ｒ．Ｈ．Ｗｅｎｔｗｏｒｔｈ，“Ａ  Ｎｅｗ  Ａｐｐｒｏａｃｈ  ｆｏｒ  Ａｌｌｏｃａｔｉｎｇ  Ｂｕｆｆｅｒｓ  ａｎｄ  Ｂａｎｄ−ｗｉｄｔｈ  ｔｏ  Ｈｅｔｅｒｏｇｅｎｅｏｕｓ，Ｒｅｇｕｌａｔｅｄ  Ｔｒａｆｆｉｃ  ｉｎ  ａｎ  ＡＴＭ  ｎｏｄｅ，”ＩＥＥＥ  Ｊｏｕｒｎａｌ  ｏｎ  Ｓｅｌｅｃｔｅｄ  Ａｒｅａｓ  ｉｎ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，ｖｏｌ．１３，ｎｏ．６，ｐｐ．１１１５−１１２７，１９９５．（非特許文献１参照）に記載されている。
【００１８】
【数７】
2006246119.tif 000009
この方法では、結果として得られるｂｋの値が、次式（８）の関係を満たす。
【００１９】
【数８】
2006246119.tif 000010
この関係が満たされると、仮想帯域と仮想バッファ量のそれぞれが本来のリソース量に占める割合が等しくなり、リソース管理が簡単になるという利点がある。
仮想リソース割り当ての第二の方法として、前式（６）で表される仮想バッファ量の総和を最小化するような割当方法が考えられている。この方式を定式化すると、次式（９）となる。
【００２０】
【数９】
2006246119.tif 000011
ただし、次式（１０）となる。
【００２１】
【数１０】
2006246119.tif 000012
式（９）の解となるような仮想帯域割り当ては、以下の手順で求められる。先ず全てのフローに対してρｋに等しい仮想帯域を割り当てる。その後、余った帯域Ｃ−Σρｋ（ｋ＝１からＫまでの積分）については、フローごとに以下の式（１１）を用いる。
【００２２】
【数１１】
2006246119.tif 000013
式（１１）で計算されたピークレート送出可能時間Ｔｋについて、Ｔｋの値の大きなフローから順番に、Ｐｋ−ρｋだけ新たに追加して割り当てていく。この方式で仮想帯域ｃｋを割り当てた場合、式（６）が最小化されることが知られている。これについては、Ｆ．Ｌ．Ｐｒｅｓｔｅ，Ｚ．−Ｌ．Ｚｈａｎｇ，Ｊ．Ｋｕｒｏｓｅ  ａｎｄ  Ｄ．Ｔｏｗｓｌｙ，“Ｓｏｕｒｃｅ  Ｔｉｍｅ  Ｓｃａｌｅ  ａｎｄ  Ｏｐｔｉｍａｌ  Ｂｕｆｆｅｒ／Ｂａｎｄｗｉｄｔｈ  Ｔｒａｄｅｏｆｆ  Ｈｅｔｅｒｏｇｅｎｏｕｓ  Ｒｅｇｕｌａｔｅｄ  Ｔｒａｆｆｉｃ  ｉｎ  ａ  Ｎｅｔｗｏｒｋ  Ｎｏｄｅ，”ＩＥＥＥ／ＡＣＭ  Ｔｒａｎｓａｃｔｉｏｎｓ  ｏｎ  Ｎｅｔｗｏｒｋｉｎｇ，ｖｏｌ．７，ｎｏ．４，ｐｐ．４９０−５０１，Ａｕｇ．１９９９．（非特許文献２参照）に記載されている。
【００２３】
式（６）が成り立つことを条件とする呼受付判定法は、論理的なパケットロスをゼロとし、かつノードでの最大遅延時間もＢ／Ｃで保証できるため、フローの品質を保証することが可能な方式である。第一の方法と第二の方法を比較すると、第一の方法は、リソース割り当ての計算が簡単であることが利点となる。第二の方法では、リソース割り当ての方法は複雑になるが、計算された最大バッファ使用量は第一の方法で計算される最大バッファ使用量以下となることが保証されているため、呼受付判定に用いた場合により多くの呼を受け付けられ、収容効率に優れるという利点がある。
【００２４】
【非特許文献１】Ａ．Ｅｌｗａｉｌｄ，Ｄ．Ｍｉｔｒａ  ａｎｄ  Ｒ．Ｈ．Ｗｅｎｔｗｏｒｔｈ，“Ａ  Ｎｅｗ  Ａｐｐｒｏａｃｈ  ｆｏｒ  Ａｌｌｏｃａｔｉｎｇ  Ｂｕｆｆｅｒｓ  ａｎｄ  Ｂａｎｄ−ｗｉｄｔｈ  ｔｏ  Ｈｅｔｅｒｏｇｅｎｅｏｕｓ，Ｒｅｇｕｌａｔｅｄ  Ｔｒａｆｆｉｃ  ｉｎ  ａｎ  ＡＴＭ  ｎｏｄｅ，”ＩＥＥＥ  Ｊｏｕｒｎａｌ  ｏｎ  Ｓｅｌｅｃｔｅｄ  Ａｒｅａｓ  ｉｎ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，ｖｏｌ．１３，ｎｏ．６，ｐｐ．１１１５−１１２７，１９９５．
【非特許文献２】Ｆ．Ｌ．Ｐｒｅｓｔｅ，Ｚ．−Ｌ．Ｚｈａｎｇ，Ｊ．Ｋｕｒｏｓｅ  ａｎｄ  Ｄ．Ｔｏｗｓｌｙ，“Ｓｏｕｒｃｅ  Ｔｉｍｅ  Ｓｃａｌｅ  ａｎｄ  Ｏｐｔｉｍａｌ  Ｂｕｆｆｅｒ／Ｂａｎｄｗｉｄｔｈ  Ｔｒａｄｅｏｆｆ  Ｈｅｔｅｒｏｇｅｎｏｕｓ  Ｒｅｇｕｌａｔｅｄ  Ｔｒａｆｆｉｃ  ｉｎ  ａ  Ｎｅｔｗｏｒｋ  Ｎｏｄｅ，”ＩＥＥＥ／ＡＣＭ  Ｔｒａｎｓａｃｔｉｏｎｓ  ｏｎ  Ｎｅｔｗｏｒｋｉｎｇ，ｖｏｌ．７，ｎｏ．４，ｐｐ．４９０−５０１，Ａｕｇ．１９９９．
【発明の開示】
【発明が解決しようとする課題】
【００２５】
以上述べたように、ＩｎｓｅｒｖまたはＤｉｆｆｓｅｒｖまたはＩＴＵ−Ｔ勧告Ｙ．１２２１サービスモデルに仮想バッファ／トランクモデルを適用することにより、品質を保証した呼受付判定が可能となる。しかしながら、既存方式においては、例えば複数の優先度に分類されたトラヒックフローが帯域リソースを共有するような場合の優先度別品質は考慮されていない。従って、別バッファを設けて優先制御を行うＤｉｆｆｓｅｒｖのようなシステムでは、最も優先度の高いクラス以外に既存方式を直接適用することは難かしい。
【００２６】
（目的）
本発明の目的は、上述した仮想バッファ／トランクモデル方式に基づく呼受付判定方法を、優先制御を行うネットワークノードに適用可能とし、複数クラスの品質を保証できる形に拡張することが可能な優先制御を用いて品質保証サービスを実現するネットワークシステムおよび呼受付判定方法、ならびにそのプログラムを提供することにある。
【課題を解決するための手段】
【００２７】
本発明は、ＩＰ網において、複数クラスの品質保証を行うための呼受付制御技術であって、新規受付呼の優先クラスのフローと当該優先クラスよりも優先度の高い優先クラスのフローとで集合を構成して、仮想最大バッファ容量を求め、当該優先クラスよりも優先度の低いクラスについても、同様にして自クラスのフローと自クラスよりも優先度の高い優先クラスのフローとで集合を構成して、順次、仮想最大バッファ容量を求めていき、新規受付呼の優先クラス、および当該優先クラスよりも優先度の低い各クラスの仮想最大バッファ容量が、各クラス毎に設けられたバッファ量（設備量）を超えるか否かに基づいて、新規受付可否を判定することを特徴としている。
【００２８】
本発明の手順を具体的に述べる。例えば、優先クラス１〜５が存在すると仮定すると、優先クラス３の新規呼を受け付けた場合には、以下のような手順で処理される。
ａ）クラス１，２については、新規呼より優先度が高いので、影響がないと考える。
ｂ）クラス１〜３をＳとして、この場合のバッファ最大使用量推定値ｂ（Ｓ１，Ｓ２，Ｓ３）を求める。
ｃ）上記ｂ）で求めた値がクラス３に割り当てられたバッファの最大使用量として適当であれば、これを採用し、そうでなければ、さらに小さい値である場合があるので、別の計算を用いて求める（式は後述）。
ｄ）クラス１〜４をＳとして、この場合のバッファ最大使用量推定値ｂ（Ｓ１，Ｓ２，Ｓ３，Ｓ４）を求める（この値はｂ）で求めた値より大きくなる）。
ｅ）上記ｄ）で求めた値がクラス４に割り当てられたバッファの最大使用量として適当であればこれを採用し、そうでなければ、さらに小さい値である場合があるので、別の計算を用いて求める（式は後述）。
ｆ）クラス１〜５をＳとして、この場合のバッファ最大使用量推定値ｂ（Ｓ１，Ｓ２，Ｓ３，Ｓ４，Ｓ５）を求める。
ｇ）上記ｄ）で求めた値がクラス５に割り当てられたバッファの最大使用量として適当であればこれを採用し、そうでなければ、さらに小さい値である場合があるので、別の計算を用いて求める（式は後述）。
ｈ）上記ｃ）ｅ）ｇ）で求めたクラス３〜５のバッファ最大使用量が、各クラスの設備量以下であれば新規呼を受け付ける。いずれかの値が設備量を超える場合には、新規呼の受付を拒否する。
【００２９】
以下、本発明の原理を説明する。
図５は、複数の優先クラスに対応して個別バッファを有するノードシステムに対し、トークンバケットで規定される多数のセッションフローが加わる様子を模した図である。
本発明においては、優先クラスに対応したＮ種類のバッファを有し、クラス１が優先度が最も高く、以下、クラスＮが最も低い優先度とみなし、優先度の高いクラスのバッファに収容されたデータは優先度の低いクラスのバッファに収容されたデータよりも必ず優先的に処理される機能を有する図５に示すノードシステムにおいて、クラスＮに対応したバ
ッファ長がＢＮ、最大処理速度（帯域）がＣであるとき、各トラヒックフローの優先クラスおよびトラヒックパラメータに基づいた品質判定を以下のような手段で行う。
当該ノードに収容されているフロー全体の集合をＳ＝｛１，・・，Ｋ｝とし、優先クラスｎのフローからなる集合をＳｎで表すことにする。このとき、∪  Ｓｎ＝Ｓ（ｎ＝１からＮまでの集合）が成り立ち、またｉ≠ｊならばＳｉ∩Ｓｊ＝φである。優先クラス１のフローについては、常に帯域を優先的に使用できるため、リソース（Ｂ１，Ｃ）を持つノードシステム上の仮想バッファ／トランクモデル方式を考えればよい。従って、
【００３０】
【数１２】
2006246119.tif 000014
ただし、
【００３１】
【数１３】
2006246119.tif 000015
で求められる最大バッファ使用量ｂＳ１が優先クラス１に割り当てられたバッファ量Ｂ１以下であれば、優先クラス１の論理的パケットロスはゼロと判断できる。
図６は、優先クラス１および２のセッションフローが単一の仮想バッファ／トランクシステムに加わる様子を模した図である。
次に、優先クラス２のフローについて考えると、優先クラス３以下のフローについては考慮する必要がないが、優先クラス１のフローは無視できない。ここで、優先クラス１のバッファ使用量ｖＳ１（ｔ），と優先クラス２のバッファ使用量ｖＳ２（ｔ）および２つのクラスを同一のバッファに収容した場合、すなわち図６に示すような仮想的なシステムでのバッファ使用量ｖＳ１，Ｓ２（ｔ）を比較すると、
【００３２】
【数１４】
2006246119.tif 000016
という関係が成り立つ。
従って、ｖＳ２（ｔ）≦ｖＳ１，Ｓ２（ｔ）より、優先クラス２の最大バッファ使用量は図６の仮想システムの最大バッファ使用量で抑えられる。この最大バッファ使用量をｂＳ１，Ｓ２とすると、
【００３３】
【数１５】
2006246119.tif 000017
ただし、
【００３４】
【数１６】
2006246119.tif 000018
である。ｂＳ１，Ｓ２は集合Ｓ１∪Ｓ２のフローが加わった場合の最大バッファ使用量であり、既存技術と同様の方法で求められる。このとき、
【００３５】
【数１７】
2006246119.tif 000019
を満たせば、優先クラス２の論理的パケットロスはゼロと判断できる（第一の判定方法）。
第一の判定方法は、既存の方法を直接適用することが可能であり、計算は比較的容易であるが、優先クラス１のバッファ使用量を無視しているため、その分だけ効率が上がらない。そこで、以下に述べる第二の判定方法が考えられる。
フローｋが最大速度でデータ転送を行う場合、時刻０からＴｋ＝σｋ／（Ｐｋ−ρｋ）まではピークレートＰｋ，それ以降ではトークンレートρｋでのデータ転送となる。従って、時刻ｔでの転送レートｒｋ（ｔ）は
【００３６】
【数１８】
2006246119.tif 000020
で表される。ただし、１ＸはＸが真ならば１、偽ならば０をとる関数である。
いま、ｉｋを、優先クラス１の中で式（１１）で得られたＴｋの値がｋ番目に大きいフローとする（ｉｋ∈Ｓ１）と、定義より、Ｔｉ１≧Ｔｉ２≧・・・・・が成り立つ。
【００３７】
【数１９】
2006246119.tif 000021
が非負ならば、時刻Ｔｉ１でのバッファ使用量も非負であるから、優先クラス１のフローが時刻０から最大速度でデータ転送を行い、優先クラス１のバッファにデータが溜まり始めてから当該バッファが空になるまでの時間をＴ（１）とすると、Ｔ（１）≧Ｔｉ１が成り立つ。
時刻Ｔ（１）までに到着する優先クラス１のデータ量とサーバ処理量は等しいから、この時
【００３８】
【数２０】
2006246119.tif 000022
が成り立つ。式（２０）を変形すると、
【００３９】
【数２１】
2006246119.tif 000023
が得られる。
式（１９）が負の時、時刻Ｔｉ１の時点でバッファ使用量は既に０、すなわちＴ（１）≦Ｔｉ１である。この時、
【００４０】
【数２２】
2006246119.tif 000024
が正ならば、Ｔｉ２≦Ｔ（１）≦Ｔｉ１が成り立ち、区間（Ｔｉ１Ｔｉ１）でのバッファ使用量のデータ転送レートは一定であるから、バッファ使用量の推移も一定となり、
【００４１】
【数２３】
2006246119.tif 000025
が成り立つ。これを一般化すると、
【００４２】
【数２４】
2006246119.tif 000026
があるｒについてＱｉｒ≦０かつＱｉｒ＞０ならば、
【００４３】
【数２５】
2006246119.tif 000027
が成り立つ。
今、優先クラス２のフローが時刻０から最大速度でデータ転送を行ったと仮定すると、時刻０から時刻Ｔ（１）までの間は全ての帯域が優先クラス１のデータを処理するために使用されているので、優先クラス２のバッファ使用量ｖＳ２（ｔ）は増加する。時刻Ｔ（１）における優先クラス２のフロー全体の転送レート
【００４４】
【数２６】
2006246119.tif 000028
が、この時点で優先クラス２が利用可能な帯域より小さい場合、すなわち
【００４５】
【数２７】
2006246119.tif 000029
であれば、時刻Ｔ（１）以降ｖＳ２（ｔ）は減少する。従って、優先クラス２のバッファ使用量はｔ＝Ｔ（１）の時点で最大となり、
【００４６】
【数２８】
2006246119.tif 000030
で与えられる。逆に、
【００４７】
【数２９】
2006246119.tif 000031
が成り立つ場合、時刻Ｔ（１）以降もｖＳ２（ｔ）は増加する。この場合、優先クラス１のバッファ使用量が常に０であるので、優先クラス２の最大バッファ使用量は前述のｂＳ１，Ｓ２に等しい。従って、第二の判定方法では、式（２７）が成り立つ場合には、式（２８）の値、それ以外ならば式（１５）の値を優先クラス２の最大バッファ使用量ｂＳ２とし、ｂＳ２≦Ｂ２が成り立てば、優先クラスより高い優先度のクラス全体を上位クラス、上位クラスと当該クラスを併せたものを全体クラスとみなすことで、優先クラス２についての判定方法と同様の処理が可能となる。すなわち、優先クラスｎについては、第一の判定方法では、
【００４８】
【数３０】
2006246119.tif 000032
ただし、
【００４９】
【数３１】
2006246119.tif 000033
とし、
【００５０】
【数３２】
2006246119.tif 000034
を満たせば論理的パケットロスはゼロと判定する。第二の判定方法では、優先クラス１〜ｎ−１を一つにまとめた仮のクラスを想定し、式（１９）−（２５）を用いた手順により、このＴ（ｎ−１）を求める。この時
【００５１】
【数３３】
2006246119.tif 000035
が成り立てば、
【００５２】
【数３４】
2006246119.tif 000036
を、式（３３）が成り立たなければ式（３０）を優先クラスｎの最大バッファ使用量ｖＳ１，Ｓ２（ｔ）とし、ｖＳ１，Ｓ２（ｔ）Ｂｎ以下であれば論理パケットロスはゼロと判定する。
【発明の効果】
【００５３】
本発明によれば、任意の優先クラスについて、当該クラスおよび上位クラスのパラメータに基づき、当該クラスのバッファ最大使用量を求める手法を提供することができる。これにより、実施例１〜３に示したように、全てのクラスに対してバッファあふれによるデータ損失の有無を判定することが可能となり、実施例４に示した手続きにより複数優先クラスの呼受付制御法を実現する。
本発明の構成により、新規受付呼の優先クラスのみならず、当該クラスよりも優先度の低い優先クラス、つまり全ての優先クラスの品質保証サービスを実現することができる。
【００５４】
従来、トラヒックフローの申告パラメータに基づきバッファ使用量の最大値を予め計算する手法は、バッファあふれによるデータ損失の有無を事前に知ることを可能とするため、呼受付判定に有効である。この技術に関して、既存の検討においては、単一バッファの場合にのみ適用可能であるという限界があった。しかしながら、今後のインターネットサービスはサービスの差異化を考慮しており、ＤｉｆｆＳｅｒｖ等の技術では、ネットワークシステム上での複数バッファによる制御を前提とした優先制御が必須となる。複数バッファを持つシステムに対しては、既存の技術では、優先度の最も高いクラスの品質のみ判定可能であるが、他の優先クラスについては判定方法がない。あるいは、精度の保証されない方法しかないという課題が存在していた。本発明では、実施例４の手続きによる複数優先クラスの呼受付制御法の実現によってこの課題を解決することができる。
【発明を実施するための最良の形態】
【００５５】
図７は、本発明の実施例で用いられるトラヒックフローのパラメータを示す図である。
以下に示すパラメータを持つ複数のトラヒックフローが、２つの優先クラスに分類されてネットワークノードに収容されるものとする。ネットワークノードでの読出し帯域は、Ｃ＝１５０（Ｍｂｐｓ）であるとする。
図７に示すように、トラヒックフローのパラメータＰ，ρ，σ，Ｔは、呼種１〜４ごとに帯域（Ｍｂｐｓ）および時刻（ｓｅｃ）が設定・登録されている。例えば、優先クラス１は呼種１，優先クラス２は呼種２などのように、優先クラスごとに呼種が割り当てられている。
【００５６】
（実施例１）
図８は、本発明の実施例１に係る優先クラス毎のバッファ使用量の時間経過を示す図である。
本実施例においては、３０本のトラヒックフローがネットワークノードに収容された場合を考える。ｋ＝１，・・・，１０は呼種１のトラヒックフローで優先クラス１，ｋ＝１１，・・・，２０は呼種２のトラヒックフローで優先クラス１，ｋ＝２１，・・・，３０は呼種３のトラヒックフローで優先クラス２に属する。
優先クラス１のバッファ最大使用量ｂＳ１は、式（１２）および（１３）より、
【００５７】
【数３５】
2006246119.tif 000037
ただし、ｃ（１），ｃ（２）は呼種１，２へ与える仮想帯域量で、２Ｍｂｐｓから１０Ｍｂｐｓの間の値である。式（３５）はｃ（１）＝５，ｃ（２）＝１０の時最小化され、ｂＳ１＝５０（Ｍｂｐｓ）となる。
次に、第一の判定方法による優先クラス２のバッファ最大使用量は、式（１５）および（１６）より、
【００５８】
【数３６】
2006246119.tif 000038
ただし、ｃ（１），ｃ（２），ｃ（３）は呼種１，２，３へ与える仮想帯域量で、２Ｍｂｐｓから１０Ｍｂｐｓの間の値である。式（３６）はｃ（１）＝２，ｃ（２）＝３，ｃ（３）＝１０の時最小化され、ｂＳ１，Ｓ２＝２２０（Ｍｂｉｔ）となる。
第二の判定方法による優先クラス２のバッファ最大使用量については、式（１９）の値は非負であるので、式（２１）を用いて、Ｔ（１）＝２４／１１を得る。時刻Ｔ（１）における優先クラス２のフロー全体の転送レートはｒ（２）（２４／１１）＝１００（Ｍｂｐｓ）であり、これはこの時点で優先クラス２が利用可能な帯域Ｃ−σｋ∈Ｓ１ｒｋ（２４／１１）＝１１０（Ｍｂｐｓ）より小さい。従って、優先クラス２のバッファ最大使用量は、式（２８）より、
【００５９】
【数３７】
2006246119.tif 000039
で得られる。この実施例では、第二の判定方法による優先クラス２の最大バッファ使用量は、第一の判定方法とほとんど変わらない。
【００６０】
（実施例２）
図９は、本発明の実施例２に係る優先クラス毎にバッファ使用量の時間経過を示す図である。
本実施例では、３０本のトラヒックフローがネットワークノードに収容された場合を考える。ｋ＝１，・・・，１０は呼種１のトラヒックフローで優先クラス２，ｋ＝１１，・・・，２０は呼種２のトラヒックフローで優先クラス１，ｋ＝２１，・・・，３０は呼種３のトラヒックフローで優先クラス１に属する。
優先クラス１のバッファ最大使用量ｂＳ１は、式（１２）および（１３）より、
【００６１】
【数３８】
2006246119.tif 000040
ただし、ｃ（２）ｃ（３）は呼種２，３へ与える仮想帯域量で、２Ｍｂｐｓから１０Ｍｂｐｓの間の値である。式（３８）はｃ（２）＝５，ｃ（３）＝１０の時に最小化され、ｂＳ１＝１００（Ｍｂｐｓ）となる。
次に、第一の判定方法による優先クラス２のバッファ最大使用量は、式（１５）および（１６）より、
【００６２】
【数３９】
2006246119.tif 000041
ただし、ｃ（１），ｃ（２），ｃ（３）は呼種１，２，３へ与える仮想帯域量で、２Ｍｂｐｓから１０Ｍｂｐｓの間の値である。式（３９）は、ｃ（１）＝２，ｃ（２）＝３，ｃ（３）＝１０の時に最小化され、ｂＳ１，Ｓ２＝２２０（Ｍｂｐｓ）となる。
第二の判定方法による優先クラス２のバッファ最大使用量については、式（１９）の値は非負であるので、式（２１）を用いて、Ｔ（１）＝４０／１１を得る。時刻Ｔ（１）における優先クラス２のフロー全体の転送レートはｒ（２）（４０／１１）＝２０（Ｍｂｐｓ）であり、これはこの時点で優先クラス２が利用可能な帯域Ｃ−σｋ∈Ｓ１，ｒｋ（４０／１１）＝１１０（Ｍｂｐｓ）より小さい。従って、優先クラス２のバッファ最大使用量は、式（２８）より、
【００６３】
【数４０】
2006246119.tif 000042
で得られる。この実施例では、第二の判定方法による優先クラス２の最大バッファ使用量は約１５３Ｍｂｐｓであり、第一の判定方法（２２０Ｍｂｐｓ）に比べておよそ３０％低い値を求めることが可能となる。
【００６４】
（実施例３）
図１０は、本発明の実施例３に係る優先クラス毎のバッファ使用量の時間経過を示す図である。
本実施例では、３０本のトラヒックフローがネットワークノードに収容された場合を考える。ｋ＝１，・・・，１０は呼種１のトラヒックフローで優先クラス２，ｋ＝１１，・・・，２５は呼種２のトラヒックフローで優先クラス１，ｋ＝２６，・・・，３０は呼種４のトラヒックフローで優先クラス１に属する。
優先クラス１のバッファ最大使用量ｂＳ１は、式（１２）および（１３）より、
【００６５】
【数４１】
2006246119.tif 000043
ただし、ｃ（２），ｃ（４）は呼種２，４へ与える仮想帯域量で、２Ｍｂｐｓから１０Ｍｂｐｓの間の値である。式（４１）はｃ（２）＝２０／３，ｃ（４）＝１０の時に最小化され、ｂＳ１＝１００（Ｍｂｐｓ）となる。
次に、第一の判定方法による優先クラス２のバッファ最大使用量は、式（１５）および（１６）より、
【００６６】
【数４２】
2006246119.tif 000044
ただし、ｃ（１），ｃ（２），ｃ（４）は呼種１，２，４へ与える仮想帯域量で、２Ｍｂｐｓから１０Ｍｂｐｓの間の値である。式（４２）はｃ（１）＝２，ｃ（２）＝１６／３，ｃ（４）＝１０の時に最小化され、ｂＳ１，Ｓ２＝２２０（Ｍｂｐｓ）となる。
第二の判定方法による優先クラス２のバッファ最大使用量については、式（１９）の値は負であるので、式（２２），（２３）により、Ｔ（１）＝２４／７を得る。時刻Ｔ（１）における優先クラス２のフロー全体の転送レートはｒ（２）（２４／７）＝２０（Ｍｂｐｓ）であり、これはこの時点で優先クラス２が利用可能な帯域Ｃ−σｋ∈Ｓ１，ｒｋ（２４／７）＝７０（Ｍｂｐｓ）より小さい。従って、優先クラス２のバッファ最大使用量は、式（２８）より、
【００６７】
【数４３】
2006246119.tif 000045
で得られる。
【００６８】
（実施例４）
図１１は、本発明の実施例４に係る優先クラス毎のバッファ使用量の時間経過を示す図である。
本実施例では、４０本のトラヒックフローがネットワークノードに収容された場合を考える。ｋ＝１，・・・，１０は呼種１のトラヒックフローで優先クラス１，ｋ＝１１，・・・，２０は呼種２のトラヒックフローで優先クラス１，ｋ＝２１，・・・，４０は呼種３のトラヒックフローで優先クラス２に属する。
優先クラス１のバッファ最大使用量ｂＳ１は、優先クラス１のトラヒックフローが実施例１の場合と同一であるので、ｂＳ１＝５０（Ｍｂｐｓ）となる。
次に第一の判定方法による優先クラス２のバッファ最大使用量は、式（１５）および（１６）より、
【００６９】
【数４４】
2006246119.tif 000046
ただし、ｃ（１），ｃ（２），ｃ（３）は呼種１，２，３へ与える仮想帯域量で、２Ｍｂｐｓから１０Ｍｂｐｓの間の値である。式（４４）はｃ（１）＝２，ｃ（２）＝２，ｃ（３）＝５．５の時に最小化され、ｂＳ１＝５１０（Ｍｂｐｓ）となる。
第二の判定方法による優先クラス２のバッファ最大使用量については、式（１９）の値は非負であるので、式（２１）を用いて、Ｔ（１）＝２４／１１を得る。時刻Ｔ（１）における優先クラス２のフロー全体の転送レートはｒ（２）（２４／１１）＝２００（Ｍｂｐｓ）であり、これはこの時点で優先クラス２が利用可能な帯域Ｃ−σｋ∈Ｓ１，ｒｋ（２４／１１）＝１１０（Ｍｂｐｓ）より大きい。従って、優先クラス２のバッファ最大使用量は、第一の判定方法と等しく、ｂＳ１＝５１０（Ｍｂｐｓ）となる。
【００７０】
以上、実施例１〜４を説明したが、図９〜図１１に係る優先クラス毎のバッファ使用量の時間経過図について、各実施例ごとの特徴を説明する。
まず、実施例１は、優先クラス１のバッファ使用量が０となる時点Ｔ（１）で、優先クラス２のバッファ使用量が最大となる例である。しかしながら、実施例１における条件では、図８にみられるように、優先クラス１と優先クラス２のバッファ使用量の和、すなわち全体のバッファ使用量が最大値ｂＳ１，Ｓ２となる時点とＴ（１）の間隔が短い。従って、第二の判定方法を用いることで推定される優先クラス２の最大バッファ使用量ｂＳ２は、第一の判定方法により求められる最大バッファ使用量ｂＳ１，Ｓ２に比べてわずかに小さくなるにとどまり、第二の判定方法を採用する効果の小さい例となっている。
【００７１】
次に、実施例２は、実施例１と同様に優先クラス１のバッファ使用量が０となる時点Ｔ（１）で、優先クラス２のバッファ使用量が最大となる。実施例２における条件では、図９にみられるように、優先クラス１と優先クラス２のバッファ使用量の和、すなわち全体のバッファ使用量が最大値ｂＳ１，Ｓ２となる時点とＴ（１）の間隔が実施例１の場合より大きい。
従って、第二の判定方法を用いることで推定される優先クラス２の最大バッファ使用量ｂＳ２と、第一の判定方法により求められる最大バッファ使用量ｂＳ１，Ｓ２との差が大きくなり、実施例１に比べて第二の判定方法を採用する効果の大きな例となっている。
【００７２】
次に、実施例３では、実施例１および２と同様に、優先クラス１のバッファ使用量が０となる時点Ｔ（１）で、優先クラス２のバッファ使用量が最大となる。実施例１および２では、式（１９）の値が非負であったため、Ｔ（１）は式（２１）により直接求められるが、実施例３の条件では、式（１９）の値が負となるため、Ｔ（１）は式（２２）が成立する時点Ｔｉ１およびＴｉ２を求め、さらに式（２３）を用いる必要があり、計算量が増加する例となっている点で前の２例とは異なっている。また、これにより求められたＴ（１）は、図１０にみられるように、全体のバッファ使用量が最大値ｂＳ１，Ｓ２となる時点からある程度の時間が経過している。したがって、第二の判定方法による推定値ｂＳ２とｂＳ１，Ｓ２との差は大きくなり、第二の判定方法を採用する効果の大きな例となっている。
【００７３】
次に、実施例４では、前の３つの例とは異なり、優先クラス１のバッファ使用量が０となる時点Ｔ（１）では、優先クラス２のバッファ使用量が最大となっていない例である。この場合には、図１１にみられるように、第二の判定方法により計算される優先クラス２のバッファ使用量の最大値ｂＳ２は、第一の判定方法により求められる最大バッファ使用量ｂＳ１，Ｓ２と同じ値となるため、第二の判定方法を採用する効果のない例となっている。
【００７４】
（実施例５）
図１２は、本発明の実施例５に係る呼受付判定方法の動作フローチャートである。
本実施例においては、ユーザからの呼受付要求が信号網を介してネットワークノードに送られ、優先制御を行うネットワークノード上において、新規呼の受付判定を行うものとする。
（ステップ１）新規受付を要求する呼（Ｋ）は、トークンバケットパラメータ（Ｐｋ，ρｋ，σｋ）および優先クラスｍを申告する。
（ステップ２）規新呼Ｋの経路上のノードシステムは申告パラメータを受け取り、新規呼を受け付けた場合に品質保証が行えるか否かを判断するための手続きを開始する。優先クラスｍの集合Ｓｍに新規呼Ｋを一時的に加え、また式（１１）を用いてＴＫの値を求める。
（ステップ３）全てのクラスの呼のピークレートの和Σｋ∈ＳＰｋがＣ以下であれば、各クラスに１パケットを越える待ちは発生しないので、新規呼Ｋの受付を許可する（ステップ１２へ）。また、そうでなければ、次のステップへ進む。
（ステップ４）新規呼Ｋの優先クラスが１であれば、ｂＳ１を式（１２）を用いて計算し、次のステップへ進む。そうでなければステップ６へ進み、優先クラスｍ以降の品質を推定する。
【００７５】
（ステップ５）ノードシステムが優先クラス１に用いるバッファ設備の量Ｂ１が、ステップ４で求めたｂＳ１以上であれば、優先クラス１の損失はないと判断し、優先クラス２以降の品質を推定する（ステップ６へ）。もし、ｂＳ１＞Ｂ１であれば、優先クラス１の品質は保証できないので、新規呼Ｋの受付を拒否する（ステップ１３へ）。
（ステップ６）優先クラスｎの品質判定を行うため、式（１８）、（２１）〜（２５）を用いてＴ（ｎ−１），ｒ（ｎ），Ｔ（ｎ−１），および、Σｋ∈Ｓ１∪Ｓｎ−１ｒｋ（Ｔ（ｎ−１））の計算を行う。
（ステップ７）優先クラスｎのバッファ最大使用量ｂＳｎの計算方法を、式（３３）を用いて判断する。式（３３）が成り立てばステップ９、そうでなければステップ８の計算方法を適用する。
（ステップ８）式（３３）が成り立たない場合、式（３０）による計算結果を求め、これをｂＳｎとして採用する（ステップ１０へ）。
【００７６】
（ステップ９）式（３３）が成り立つ場合、式（３４）による計算結果を求め、これをｂＳｎとして採用する（ステップ１０へ）。
（ステップ１０）ノードシステムが優先クラスｎに用いるバッファ設備の量Ｂｎが、計算により求められたｂＳｎ以上であれば、優先クラスｎの損失は無いと判断し、ステップ１１へ進む。もし、ｂＳｎ＞Ｂｎであれば、優先クラスｎの品質は保証できないので、新規呼Ｋの受付を拒否する（ステップ１３へ）。
（ステップ１１）全ての優先クラスについて、品質判定が終了している場合（ｎ＝Ｎ）には、ステップ１２へ進む。そうでなければ、次の優先クラスの品質判定を続ける（ステップ６へ）。
（ステップ１２）全ての優先クラスについて損失が無いと判定し、新規呼Ｋの受付を許可して受付判定を終了する。
（ステップ１３）いずれかの優先クラスについて、品質が保証できないと判断されるので、新規呼Ｋを優先クラスｍの集合Ｓｍから取り除き、新規呼Ｋの受付を拒否して受付判定を終了する。
【００７７】
図１３は、本発明の実施例５に係るネットワークノードの構成を示す図である。
ネットワークノードは、速度Ｃの出力インタフェース（１）と、優先クラス１からＮまでに対応して、容量Ｂｎ（ｎ＝１，・・・，Ｎ）を持つ個別バッファ群（２）を装備している。また、新規呼の情報および受付可否を外部装置と通信するための信号制御装置（５）、接続呼の優先クラスおよびトークンバケットパラメータを収容する呼情報記憶装置（３）、および受付可非のための計算を行うための品質演算装置（４）を有している。
【００７８】
信号制御装置（５）は、図１２における（ステップ１）の新規呼の当該ネットワークノードへの接続要求と当該呼の申告パラメータ、および接続済みの呼の終了通知を外部信号線より取得し、また（ステップ１２）あるいは（ステップ１３）でなされる新規呼の接続可否の結果を外部信号線を通じて発信する機能を有する。
呼情報記憶装置（３）は、接続済みの各呼により申告されたトークンバケットパラメータおよび優先クラスについての情報を格納する。また、図１２の（ステップ１）において新規受付を要求する呼から申告されたパラメータを一時的に格納し、新規呼の接続が（ステップ１２）において認められた場合には、そのパラメータを引き続き格納し、逆に（ステップ１３）において新規呼の接続が拒否された場合には、そのパラメータを消去する。
さらに、接続済みの呼の終了通知が信号制御装置（５）に伝えられた場合には、当該呼のパラメータを消去する機能を有する。
【００７９】
品質演算装置（４）は、当該ノードシステムの設備量Ｃ、Ｂｎ（ｎ＝１，・・・，Ｎ）および呼情報記憶装置（３）に格納された各呼のパラメータを用いて、（ステップ２）におけるＴｋ、（ステップ３）におけるΣｋ∈ＳＰｋ、（ステップ４）におけるｂＳ１、（ステップ６）におけるＴ（ｎ−１），ｒ（ｎ−１）（Ｔ（ｎ−１）），Σｋ∈Ｓ１∪Ｓｎ−１ｒｋ（Ｔ（ｎ−１））、（ステップ７）〜（ステップ９）におけるｂＳｎの計算を行い、最終的に（ステップ１２）あるいは（ステップ１３）による新規呼の受付可否を決定する機能を有する。
【００８０】
（実施例６）
図１４は、本発明の実施例６に係る呼受付判定方法を実現するネットワークの動作説明図である。
図１４において、Ｓはサービス制御装置、ＴＥはユーザのターミナル装置、ＵＮＩはユーザネットワーク・インタフェース装置、ＮＮはネットワークノードである。図中の丸内の数字は各動作ステップ番号を示している。
（ステップ１）ユーザのターミナル装置ＴＥからの新規呼の接続要求が、新規呼の優先クラスおよびトークンバケットパラメータ情報とともに、サービス制御装置Ｓに通知される。
（ステップ２）サービス制御装置は、新規呼の通信経路上のネットワークノードＮＮに、接続を要求する新規呼の優先クラスおよびトークンバケットパラメータを通知する。
【００８１】
（ステップ３）各ネットワークノードＮＮは、新規呼を受け付けることで、各優先クラスの品質を保証できるか否かを（例えば、実施例４の方法を用いて）判定し、受付可否をサービス制御装置Ｓに通知する。
（ステップ４）サービス制御装置Ｓは、全てのネットワークノードＮＮから新規呼の受付許可が得られた場合、新規呼の最終的な接続許可をユーザターミナル装置ＴＥおよび各ネットワークノードＮＮに通知する（新規呼の接続）。もし、いずれかのネットワークノードＮＮから接続拒否を通知された場合、新規呼は受け付けられないので、ユーザターミナル装置ＴＥに受付拒否通知を行い、各ネットワークノードＮＮに新規呼の通信終了を通知する（ステップ７へ）。
【００８２】
（ステップ５）通信中の呼を終了する場合、ユーザターミナル装置ＴＥからサービス制御装置Ｓに当該呼の終了が通知される。
（ステップ６）サービス制御装置Ｓは、当該呼の通信系路上のネットワークノードＮＮに、当該呼の通信終了を通知する。
（ステップ７）各ネットワークノードＮＮは、通信終了した呼に関する情報を削除する（通信の終了）。
【００８３】
図１２におけるフローの手順および図１４における動作手順を、それぞれプログラム化して、ＣＤ−ＲＯＭなどの記録媒体に格納しておけば、優先制御を用いて品質保証サービスを実現するネットワーク用プログラムとして、汎用化に役立てることができ、また、Ｗｅｂサーバを介してプログラムの販売や貸与に供することもできる。
【図面の簡単な説明】
【００８４】
【図１】トークンバケットで規定されるセッションフローから転送されるデータの最大量の時間経過を示す図である。
【図２】トークンバケットで規定されるセッションフローから転送されるデータが仮想バッファ／トランクシステムに加わる様子を模した図である。
【図３】トークンバケットで規定されるセッションフローが仮想バッファ／トランクシステムに加わった時の仮想バッファ使用量の時間経過を示す図である。
【図４】トークンバケットで規定される複数のセッションフローが仮想バッファ／トランクシステムに加わる様子を模した図である。
【図５】複数の優先クラスに対応して個別バッファを有するノードシステムに対し、トークンバケットで規定される多数のセッションフローが加わる様子を模した図である。
【図６】優先クラス１および２のセッションフローが単一の仮想バッファ／トランクシステムに加わる様子を模した図である。
【図７】本発明の実施例で用いるトラヒックフローのパラメータを示すテーブル図である。
【図８】本発明の実施例１に係る優先クラス毎のバッファ使用量の時間経過を示す図である。
【図９】本発明の実施例２に係る優先クラス毎のバッファ使用量の時間経過を示す図である。
【図１０】本発明の実施例３に係る優先クラス毎のバッファ使用量の時間経過を示す図である。
【図１１】本発明の実施例４に係る優先クラス毎のバッファ使用量の時間経過を示す図である。
【図１２】本発明の実施例５に係る呼受付判定方法の動作フローチャートである。
【図１３】本発明の実施例５に係る呼受付判定方法を実現するネットワークノードの構成図である。
【図１４】本発明の実施例６に係る呼受付判定方法を実現するネットワークの動作説明図である。
【符号の説明】
【００８５】
１：出力インタフェース
２：個別バッファ
３：呼情報記憶装置
４：品質演算装置
５：信号制御装置
Ｓ：サービス制御装置
ＴＥ：ユーザターミナル装置
ＮＮ：ネットワークノード
ＵＮＩ：ユーザネットワーク・インタフェース装置
Ａ（ｔ）：トラヒックの最大量
Ｐ：ピークレート
Ｔ：トラヒック送出可能な最大時間長
ｒ：転送レート
σ：バケットサイズ
ｖ（ｔ）：時刻ｔの使用バッファ量
ｂ：使用バッファ量の最大値
ｕ（ｔ）：時刻ｔの利用帯域
ｃ：利用可能な最大帯域
Ｂ：バッファ量
Ｃ：リンク帯域
ｃ：セッションフローに対するリンク帯域
ρ：トークンレート
Ｓ：集合
Ｔ（１）：バッファにデータが溜まり始めてから空になるまでの時間
ｂＳ１，Ｓ２：優先クラス１，２の最大バッファ使用量
【図１】
2006246119.tif 000047
【図２】
2006246119.tif 000048
【図３】
2006246119.tif 000049
【図４】
2006246119.tif 000050
【図５】
2006246119.tif 000051
【図６】
2006246119.tif 000052
【図７】
2006246119.tif 000053
【図８】
2006246119.tif 000054
【図９】
2006246119.tif 000055
【図１０】
2006246119.tif 000056
【図１１】
2006246119.tif 000057
【図１２】
2006246119.tif 000058
【図１３】
2006246119.tif 000059
【図１４】
2006246119.tif 000060