(57)【要約】【課題】受付判定として、従来の実効帯域ｅｋを用いて行う判定よりも安全側となり、論理的パケットロスをゼロのままとして、スケーラビリティを向上させ、収容効率を最大とした受付判定を可能とする。【解決手段】ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定を行い、ＵＮＩ間品質保証を提供するサービス提供網の受付判定方法であり、各転送ノードの接続情報、リンクリソースを把握する手順（２０１）、各セッションフローｋへ割り当てる実効帯域を経由するリンクｉｊに依存せず網内で共通した値ｅｋとする手順（Ｄｍｉｎを計算する手順からｅｋを計算）（２０４）、リンク帯域Ｃｉｊと全セッションフローの実効帯域合計値Σｅｋを比較して受付可否を判定する手順（２０６〜２０８）と、σｋ＝ｒｋＤｍｉｎの関係式を用いて上記受付可否を判定する手順を有する。【選択図】図８
2006229516.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ制御により、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定を行い、ＵＮＩ間品質保証を提供するサービス提供網の受付判定方法において、
帯域管理サーバが、該帯域管理サーバ内のリソースデータベースにアクセスして、前記サービス提供網内の各転送ノードの接続情報、リンクリソース情報（ノードｉからノードｊへのリンクｉｊにおけるリンク帯域Ｃｉｊ、バッファ網Ｂｉｊ）を読み取る手順と、
前記帯域管理サーバが、該帯域管理サーバ内の受付判定部の演算回路を動作して演算することで、各セッションフローｋへ割り当てる実効帯域ｅｋ，ｉｊを経路を構成するリンクｉｊに依存することなく、前記サービス提供網内で共通した値ｅｋとする手順と、
前記受付判定部の演算回路で、前記リンク帯域Ｃｉｊと全セッションフローの実効帯域Σｋｅｋを比較演算し、演算結果により前記ユーザ網内装置から要求されたセッションフローの受付可否を判定する手順と
を有することを特徴とするセッションフローごとの受付判定方法。
【請求項２】
コンピュータ制御により、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定を行い、ＵＮＩ間品質保証を提供するサービス提供網の受付判定方法において、
帯域管理サーバが、該帯域管理サーバ内のリソースデータベースにアクセスして、前記サービス提供網内の各転送ノードの接続情報、リンク帯域Ｃｉｊおよびバッファ量Ｂｉｊを含むリンクリソース情報を読み取る手順と、
該帯域管理サーバ内の受付判定部の演算回路を動作して演算することで、前記リンク帯域Ｃｉｊと前記ユーザ網内装置から要求されるセッションフローｋごとのトークンレートｒｋの積み上げ計算値Σｋｒｋを比較して、要求されたセッションフローの受付可否を判定する手順と、
前記演算回路での演算の結果、受付が可能と判定されたとき、セッションフローｋごとのバケットサイズを前記サービス提供網側で計算し、計算した結果のバケットサイズをＵＮＩトラヒック規定値と決定する手順と
を有することを特徴とするセッションフローごとの受付判定方法。
【請求項３】
請求項１に記載のセッションフローごとの受付判定方法において、
前記セッションフローｋへ割り当てる実効帯域ｅｋ，ｉｊを経由を構成するリンクｉｊに依存することなく、サービス提供網内で共通した値ｅｋとする手順は、
前記サービス提供網内の全てのリンクの集合をＡとし、該Ａの中からトラヒックの集線効果のあるリンクを抽出する手順と、
抽出したリンクの集合をＳとするとき、
【数１】
2006229516.tif 000026
を計算する手順と、
セッションフローｋの実効帯域を
【数２】
2006229516.tif 000027
と計算する手順と
を有することを特徴とするセッションフローごとの受付判定方法。
【請求項４】
請求項２に記載のセッションフローごとの受付判定方法において、
前記受付が可能なとき、セッションフローｋごとのバケットサイズをサービス提供網側で計算し、ＵＮＩトラヒック規定値とする手順は、
前記セッションフローｋのバケットサイズσｋを、全てのリンク集合Ａから、
【数３】
2006229516.tif 000028
としてサービス提供網側で計算する手順
であることを特徴とするセッションフローごとの受付判定方法。
【請求項５】
請求項４に記載のセッションフローごとの受付判定方法において、
前記セッションフローｋのバケットサイズσｋを、
【数４】
2006229516.tif 000029
としてサービス提供網側で計算する手順は、
全てのリンク集合Ａからトラヒックの集線効果のあるリンクを抽出したリンク集合Ｓから
【数５】
2006229516.tif 000030
として、セッションフローｋのバケットサイズσｋをサービス提供網側で計算する手順
であることを特徴とするセッションフローごとの受付判定方法。
【請求項６】
コンピュータ制御により、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定を行い、ＵＮＩ間品質保証を提供するサービス提供網のトラヒック制御方法において、
帯域管理サーバ内の監視制御部は、受付可の場合、申告されたトークンレートｒｋ，計算済みのバケットサイズσｋのパラメータを用いて、前記サービス提供網がセッションフローごとに（平均制限帯域）＝（トークンレート）、（平均バーストサイズ）＝（バケットサイズ）として転送トラヒック量を監視し、監視流量内のトラヒックのみを前記サービス提供網内に透過させることを特徴とするトラヒック制御方法。
【請求項７】
コンピュータ制御により、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定を行い、ＵＮＩ間品質保証を提供するサービス提供網のトラヒック制御システムにおいて、
帯域管理サーバは、
サービス提供網内の各転送ノードの接続情報、リンクリソース情報（ノードｉからノードｊへのリンクｉｊにおけるリンク帯域Ｃｉｊ、バッファ網Ｂｉｊ）を把握する手段を有するリソースＤＢと、
各セッションフローｋへ割り当てる実効帯域ｅｋを用いて受付判定を行う手段を備えた受付判定部と、
受付可の場合、セッションフローｋごとに（平均制限帯域）＝（トークンレート），（平均バーストサイズ）＝（バケットサイズ）として転送トラヒック量を監視し、監視流量内トラヒックのみを前記サービス提供網に透過させるようにトラヒック制御を行う手段を備えた監視制御部とを有することを特徴とするトラヒック制御システム。
【請求項８】
コンピュータ制御により、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデルによりＵＮＩトラヒック規定を行い、ＵＮＩ間品質保証を提供するサービス提供網の受付判定システムにおいて、
帯域管理サーバは、
サービス提供網内の各転送ノードの接続情報、リンクリソース情報（ノードｉからノードｊへのリンクｉｊにおけるリンク帯域Ｃｉｊ、バッファ量Ｂｉｊ）を把握する手段、および、各セッションフローｋへの割り当てる実効帯域ｅｋを経路を構成するリンクｉｊに依存せず網内で共通した値ｅｋとする手段を備えたリソースＤＢと、
リンク帯域Ｃｉｊと全セッションフローの実効帯域Σｋｅｋを比較して、要求されたセッションフローの受付判定を行う受付判定部とを有することを特徴とする受付判定システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＵＮＩ（Ｕｓｅｒ−Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ）間の品質保証サービスを提供するための品質保証サービスを実現する受付判定方法およびトラヒック制御方法、ならびにそのシステムに関する。
【背景技術】
【０００２】
ブロードバンド回線が低価格でユーザに提供されるようになり、インターネットは急激に普及してきている。それに伴って、様々なサービスがインターネットを介して提供されるようになり、その通信品質が重要視されるようになっている。特に、リアルタイムな映像、音声サービスに対してはネットワーク上におけるデータ転送品質が大きく影響するが、インターネットでは、そのデータ転送品質を保証する仕組みがないため、従来では、ＩＰ閉域網としてネットワークを構築し、データ転送品質を保証する技術と組み合わせて品質保証型のサービスを提供することが検討されている。
【０００３】
ＩＰ網においては、データ転送品質を保証するサービスモデルとして、主にＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋｆｏｒｃｅ）（標準化団体）で検討されたＩｎｔｓｅｒｖとＤｉｆｆｓｅｒｖに分けられる。
Ｉｎｔｓｅｒｖは、ネットワーク経路上の帯域を確保した上で、その確保した品質に応じたサービスを受けるモデルである。Ｉｎｔｓｅｒｖモデルでは、ｅｎｄ−ｔｏ−ｅｎｄでネットワーク経路上の帯域を予約するプロトコルであるＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を用いて、遅延、パケット損失率を厳密に保証するサービスクラス（Ｇｕａｒａｎｔｅｅｄ  Ｓｅｒｖｉｃｅ）か、優先サービスクラス（Ｃｏｎｔｒｏｌｌｅｄ−ｌｏａｄ  Ｓｅｒｖｉｃｅ）を提供する。
【０００４】
ＲＳＶＰリクエストはネットワーク内の各転送ノードによりフォワーディングされ、リクエストを受ける転送ノードは管理する帯域情報をもとにリクエストされるサービスが提供可能か否かを判断し、提供可能な場合にはｅｎｄ−ｔｏ−ｅｎｄで帯域を確保し、コネクションを確立させる。ＲＳＶＰリクエストはトークンバケットモデルに従ったトラヒック規定を含んでおり、トークンバケットパラメータに従った帯域確保を行なう。
しかしながら、品質保証型のサービスを提供するためには、ＲＳＶＰを用いたＩｎｔｓｅｒｖでは、ネットワーク転送ノードにおいて、ＲＳＶＰに関連する情報を全てリアルタイムに管理し、かつパケット転送を行う必要があるため、統一された受付判定を行わなければならないという課題と、サービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題がある（例えば、Ｓ．Ｓｈｅｎｋｅｒ，ａｎｄ  Ｊ．Ｗｒｏｃｌａｗｓｋｉ，“Ｇｅｎｅｒａｌ  Ｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ  Ｐａｒａｍｅｔｅｒｓ  ｆｏｒ  Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅ  Ｎｅｔｗｏｒｋ  Ｅｌｅｍｅｎｔｓ，”Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ  ＲＦＣ２２１５，Ｓｅｐ．１９９７（ｐｐ．７〜ｐｐ．１１）（非特許文献１参照）、Ｊ．Ｗｒｏｃｌａｗｓｋｉ，“Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｏｆ  ｔｈｅ  Ｃｏｎｔｒｏｌｌｅｄ−Ｌｏａｄ  Ｎｅｔｗｏｒｋ  Ｅｌｅｍｅｎｔ  Ｓｅｒｖｉｃｅ，”Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，ＲＦＣ２２１１，Ｓｅｐ．１９９７（ｐｐ．２〜ｐｐ．４）（非特許文献２参照）。および、Ｓ．Ｓｈｅｎｋｅｒ  Ｃ．Ｐａｒｔｒｉｄｇｅ，ａｎｄ  Ｒ．  Ｇｕｅｒｉｎ，“Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｏｆ  Ｇｕａｒａｎｔｅｅｄ  Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ，”Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，ＲＦＣ２２１２，Ｓｅｐ．１９９７（ｐｐ．３〜ｐｐ．４）（非特許文献３参照））。
【０００５】
一方、Ｄｉｆｆｓｅｒｖは、ネットワーク内において転送パケットにマーキングすることにより、クラス分けを行い、ネットワーク転送ノードにおけるパケットスケジューリングにより、クラスごとの転送品質の差異化を行なうモデルである。Ｄｉｆｆｓｅｒｖモデルでは、規定されたＰＨＢ（Ｐｅｒ−Ｈｏｐ  Ｂｅｈａｖｉｏｒ）により各ネットワーク転送ノードでの転送品質が確保される。サービスクラスに対応するＰＨＢは完全優先であるＥＦ（Ｅｘｐｅｄｉｔｅｄ  Ｆｏｒｗａｒｄｉｎｇ）、最低帯域保証であるＡＦ（Ａｓｓｕｒｅｄ  Ｆｏｒｗａｒｄｉｎｇ）が規定されており、市販のネットワーク転送ノードにも実装が進んでいる。
【０００６】
Ｄｉｆｆｓｅｒｖでは、ネットワーク転送ノードごとの転送品質を差異化し、各転送ノードでの制御のみを規定するだけであるため、Ｉｎｔｓｅｒｖにおけるスケールしないという課題を解決する。しかしながら、品質保証型のサービスを提供するためには、サービス提供網内で統一された利用帯域に関する受付判定を行わなければならないという課題と、サービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題は、依然として残っている（例えば、Ｓ．Ｂｌａｋｅ，Ｄ．Ｂｌａｃｋ，Ｍ．Ｃａｒｌｓｏｎ，  ａｎｄ  Ｅ．Ｄａｖｉｅｓ，  Ｚ．Ｗａｎｇ，Ｗ．Ｗｅｉｓｓ“Ａｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ｆｏｒ  Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅ，”Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，ＲＦＣ  ２４７５，Ｄｅｃ．１９９８（ｐｐ．８〜ｐｐ．１１）または（ｐｐ．２０〜ｐｐ．２４）（非特許文献４参照）。Ｂ．Ｄａｖｉｅ，Ａ．Ｃｈａｒｎｙ，  Ｊ．Ｃ．Ｒ．Ｂｅｎｎｅｔｔ，Ｋ．Ｂｅｎｓｏｎ，Ｊ．Ｙ．ＬｅＢｏｕｄｅｃ，Ｗ．Ｃｏｕｒｔｎｅｙ，Ｓ．Ｄａｖａｒｉ，Ｖ．Ｆｉｒｏｉｕ，ａｎｄ  Ｄ．Ｓｔｉｌｉａｄｉｓ，“Ａｎ  Ｅｘｐｅｄｉｔｅｄ  Ｆｏｒｗａｒｄｉｎｇ  ＰＨＢ（Ｐｅｒ−Ｈｏｐ  Ｂｅｈａｖｉｏｒ），”Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，ＲＦＣ３２４６，Ｍａｒ．２００２（ｐｐ．２−ｐｐ．８）（非特許文献５参照）。
Ｊ．Ｈｅｉｎａｎｅｎ，Ｆ．Ｂａｋｅｒ，Ｗ．Ｗｅｉｓｓ．ａｎｄ  Ｊ．Ｗｒｏｃｌａｗｓｋｉ，“Ａｓｓｕｒｅｄ  Ｆｏｒｗａｒｄｉｎｇ  ＰＨＢ  Ｇｒｏｕｐ，”ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，ＲＦＣ２５９７，Ｊｕｎ  １９９９（ｐｐ．２−ｐｐ．３）（非特許文献６参照）。）
【０００７】
サービス提供品質の規定に関してはＩＴＵ−Ｔ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｕｎｉｏｎ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  ｒｅｍｍｅｎｄａｔｉｏｎ）において、サービス品質を規定するためのパラメータ定義、転送品質クラス規定、サービスモデルが勧告化されている。しかしながら、ＩＴＵ−Ｔ勧告Ｙ．１５４１における規定された転送品質をＹ．１２２１におけるサービスモデルで実現する方法に関しては、検討されておらず、サービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題が依然として残る（例えば、ＩＴＵ−Ｔ勧告Ｙ．１５４１（ｐｐ．５−ｐｐ．６）（非特許文献７参照）。ＩＴＵ−Ｔ勧告Ｙ．１２２１（ｐｐ．６−ｐｐ．７）（非特許文献８参照）。）。
【０００８】
利用帯域に関する受付判定モデルとしては、トークンバケットパラメータに従ったネットワークへの入力トラヒックに対して受付判定を行う，仮想バッファ／トランクモデルがある。仮想バッファ／トランクモデルでは、トークンバケットモデルに従ったトラヒックの最悪条件をＯＮ／ＯＦＦトラヒックとしてモデル化し、申告帯域に対して、比例したバッファ量を仮想的に割り当てることによって、ネットワーク帯域を管理する帯域管理サーバによる各ネットワーク転送ノードのバッファ量を考慮した実効帯域（Ｅｆｆｅｃｔｉｖｅ  Ｂａｎｄｗｉｄｔｈ）の積み上げ管理を以下の考え方に基づいて行い、論理的パケット損失率ゼロの受付判定を行う。
【０００９】
（トークンバケットから送出されるトラヒックの最悪条件）
トークンバケットで規定されるトラヒックに関しては、図３に示す極値ＯＮ／ＯＦＦ過程（Ｔｏｎの期間はピークレートＰでパケットを送出し、Ｔｏｆｆの期間はパケットを送出しない）が最悪条件と考えられる。すなわち、極値ＯＮ／ＯＦＦ過程はトークンバケットから送出されるトラヒックパターンの中では、ネットワークに対して最も負荷が大きく、極値ＯＮ／ＯＦＦ過程でのトラヒックパターンの受付判定で、論理的パケットロス率がゼロである条件を満足すれば、そのほかのトラヒックパターンにおいても論理的パケットロス率がゼロである条件を十分満足する。時刻０からｔまでの間にトークンバケットから送出されるトラヒック量Ω（ｔ）とトークンバケットパラメータ（トークンレートｒ，バケットサイズσ，ピークレートＰ）、およびＴｏｎ，Ｔｏｆｆの関係は図４に示すように表わすことができ、図１、図２の関係から極値ＯＮ／ＯＦＦ過程におけるＴｏｎ，Ｔｏｆｆはトークンバケットパラメータで表わすことができ、次式（１）（２）で表わされる。
【００１０】
【数１】
2006229516.tif 000003
【００１１】
【数２】
2006229516.tif 000004
【００１２】
（極値ＯＮ／ＯＦＦ過程トラヒックが使用するリソース量（ｂ，ｃ）の特性）
図５に示すように、トークンバケットから送出された１本のセッションフローが確定的なキューイングシステムにおいてサービスされることを考える。
ｖ（ｔ）を時刻ｔにおけるバッファ量，ｂを使用するバッファ量の最大値，ｕ（ｔ）を時刻ｔにおける利用帯域，ｃを利用可能な最大帯域とする。図６に示す“キューイングシステムのバッファ量と滞留している時間”と“キューイングシステムにおいて利用している帯域とその時間”との関係に着目すると、このキューイングシステムサービス窓口でのｂｕｓｙ  ｐｅｒｉｏｄ  Ｄｏｎとｉｄｌｅ  ｐｅｒｉｏｄ  Ｄｏｆｆとの関係は、次式（３）（４）で表わされる。
【００１３】
【数３】
2006229516.tif 000005
【００１４】
【数４】
2006229516.tif 000006
【００１５】
以上の表現を用いてキューイングシステムにおけるｂｕｓｙ  ｐｅｒｉｏｄである時間の割合を（３），（４）式を用いて表わすと、次式（５）が成立する。
【００１６】
【数５】
2006229516.tif 000007
さらに、上式（５）を変形すると、
【００１７】
【数６】
2006229516.tif 000008
が成り立つ。
【００１８】
（仮想バッファ／トランクモデル）
今、トークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）を持つセッションフローｋ（ｋ＝１，２，・・，ｋ）がリソース（バッファ量Ｂｉｊ，リンク帯域Ｃｉｊ）を持つノードｉからノードｊへ至るリンクｉｊに多重されることを考える。このとき、図７に示すように各セッションフローｋに対してリンク帯域ｃｋ（ｒｋ≦ｃｋ≦Ｐｋ）を仮想的に割り当てることを考える。ただし、仮想リソースの総量はリンク帯域Ｃを上回らないようにする。すなわち、
【００１９】
【数７】
2006229516.tif 000009
このとき、セッションフローｋが使用する仮想的なバッファリソースの最大値ｂｋは、上式（６）の結果を用いて、
【００２０】
【数８】
2006229516.tif 000010
と表わすことができる。
【００２１】
実際のバッファ使用量の最大値ｂは、仮想バッファ使用量の和Σｂｋを上回ることはないので、次式（９）が成り立てば、論理的なパケットロスがゼロになる。
【００２２】
【数９】
2006229516.tif 000011
言い換えると、上式（８）を満たすＫ組の仮想リソース（ｂｋ，ｃｋ）に対して、上式（７）および上式（９）が成り立てば、当該リンクにおける論理的なパケットロスはゼロになる。
この方式では、一般的にバッファ量とリンク帯域という２種類のリソース使用量を管理しなければならないが、（ｂｋ，ｃｋ）が下式（１０）を満たせば、バッファ使用量＝リンク使用帯域となるため、どちらか一つのリソース管理を行うだけでよい。
【００２３】
【数１０】
2006229516.tif 000012
【００２４】
この場合、上式（８）および上式（１０）から仮想リンク帯域ｃｋは、下式（１１）となる。
【００２５】
【数１１】
2006229516.tif 000013
上式（１１）で与えられたｃｋを、セッションフローｋのリンクｉｊにおける実効帯域ｅｋ，ｉｊとすれば、この実効帯域ｅｋ，ｉｊはセッションフローｋを各ノードのＩＦにおいて論理的パケットロスがゼロの状態で多重し、積み上げ計算することができる帯域値である。
【００２６】
しかしながら、サービス提供網内のリソース（バッファ量Ｂｉｊ，リンク帯域Ｃｉｊ）をあらかじめ見積もる必要があるという課題と、実効帯域ｅｋ，ｉｊはトークンバケットパラメータに依存し、さらにサービス提供網において経由する全てのリンクにおけるリンク帯域とバッファ量に依存するため、実効帯域ｅｋ，ｉｊを積み上げ帯域として受付判定を行う仮想バッファ／トランクモデルは、論理的パケットロスをゼロにすることはできるが、各リンクごとに実効帯域ｅｋ，ｉｊを計算するためスケールしないという課題と、申告されるトークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）の組み合わせによっては、実効帯域ｅｋ，ｉｊが極端に大きくなり、サービス提供網における収容率が下がるという課題と、トークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）の全てを自由に指定することを許可するため、パラメータ数が多く、管理が煩雑になるという課題とがある（例えば、Ａ．Ｅｌｗａｌｉｄ，Ｄ．Ｍｉｔｒａ，ａｎｄ  Ｒ．Ｈ．Ｗｅｎｔｗｏｒｔｈ，“Ａ  Ｎｅｗ  Ａｐｐｒｏａｃｈ  ｆｏｒ  Ａｌｌｏｃａｔｉｎｇ  Ｂｕｆｆｅｒｓ  ａｎｄ  Ｂａｎｄｗｉｄｔｈ  ｔｏ  Ｈｅｔｒｏｇｅｎｅｏｕｓ，Ｒｅｇｕｌａｔｅｄ  Ｔｒａｆｆｉｃ  ｉｎ  ａｎ  ＡＴＭ  ｎｏｄｅ，”ＩＥＥＥ  Ｊｏｕｒｎａｌ  ｏｎ  Ｓｅｌｅｃｔｅｄ  Ａｒｅａｓ  ｉｎ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，１３（６）：１１１５−１１２７，Ａｕｇ．１９９５．（非特許文献９参照））。
【００２７】
ＩｎｔｓｅｒｖまたはＤｉｆｆｓｅｒｖまたはＩＴＵ−Ｔ勧告Ｙ．１２２１サービスモデルに仮想バッファ／トランクモデルを適用することにより、Ｉｎｔｓｅｒｖ，Ｄｉｆｆｓｅｒｖのサービス提供網内で統一された受付判定を行なわなければならないという課題は、解決可能である。
しかしながら、品質保証型のサービスを提供するためには、仮想バッファ／トランクモデルにおける課題が残っており、さらに、Ｉｎｔｓｅｒｖ，Ｄｉｆｆｓｅｒｖ，ＩＴＵ−Ｔ勧告Ｙ．１２２１における，サービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題が依然として残る。
【００２８】
【非特許文献１】Ｓ．Ｓｈｅｎｋｅｒ，ａｎｄ  Ｊ．Ｗｒｏｃｌａｗｓｋｉ，“Ｇｅｎｅｒａｌ  Ｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ  Ｐａｒａｍｅｔｅｒｓ  ｆｏｒ  Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅ  Ｎｅｔｗｏｒｋ  Ｅｌｅｍｅｎｔｓ，”Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ  ＲＦＣ２２１５，Ｓｅｐ．１９９７（ｐｐ．７〜ｐｐ．１１）
【非特許文献２】Ｊ．Ｗｒｏｃｌａｗｓｋｉ，“Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｏｆ  ｔｈｅ  Ｃｏｎｔｒｏｌｌｅｄ−Ｌｏａｄ  Ｎｅｔｗｏｒｋ  Ｅｌｅｍｅｎｔ  Ｓｅｒｖｉｃｅ，”Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，ＲＦＣ２２１１，Ｓｅｐ．１９９７（ｐｐ．２〜ｐｐ．４）
【非特許文献３】Ｓ．Ｓｈｅｎｋｅｒ  Ｃ．Ｐａｒｔｒｉｄｇｅ，ａｎｄ  Ｒ．  Ｇｕｅｒｉｎ，“Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｏｆ  Ｇｕａｒａｎｔｅｅｄ  Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ，”Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，ＲＦＣ２２１２，Ｓｅｐ．１９９７（ｐｐ．３〜ｐｐ．４）
【非特許文献４】Ｓ．Ｂｌａｋｅ，Ｄ．Ｂｌａｃｋ，Ｍ．Ｃａｒｌｓｏｎ，  ａｎｄ  Ｅ．Ｄａｖｉｅｓ，  Ｚ．Ｗａｎｇ，Ｗ．Ｗｅｉｓｓ“Ａｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ｆｏｒ  Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅ，”Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，ＲＦＣ  ２４７５，Ｄｅｃ．１９９８（ｐｐ．８〜ｐｐ．１１）または（ｐｐ．２０〜ｐｐ．２４）。
【非特許文献５】Ｂ．Ｄａｖｉｅ，Ａ．Ｃｈａｒｎｙ，  Ｊ．Ｃ．Ｒ．Ｂｅｎｎｅｔｔ，Ｋ．Ｂｅｎｓｏｎ，Ｊ．Ｙ．ＬｅＢｏｕｄｅｃ，Ｗ．Ｃｏｕｒｔｎｅｙ，Ｓ．Ｄａｖａｒｉ，Ｖ．Ｆｉｒｏｉｕ，ａｎｄ  Ｄ．Ｓｔｉｌｉａｄｉｓ，“Ａｎ  Ｅｘｐｅｄｉｔｅｄ  Ｆｏｒｗａｒｄｉｎｇ  ＰＨＢ（Ｐｅｒ−Ｈｏｐ  Ｂｅｈａｖｉｏｒ），”Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，ＲＦＣ３２４６，Ｍａｒ．２００２（ｐｐ．２−ｐｐ．８）。
【非特許文献６】Ｊ．Ｈｅｉｎａｎｅｎ，Ｆ．Ｂａｋｅｒ，Ｗ．Ｗｅｉｓｓ．ａｎｄ  Ｊ．Ｗｒｏｃｌａｗｓｋｉ，“Ａｓｓｕｒｅｄ  Ｆｏｒｗａｒｄｉｎｇ  ＰＨＢ  Ｇｒｏｕｐ，”ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，ＲＦＣ２５９７，Ｊｕｎ  １９９９（ｐｐ．２−ｐｐ．３）
【非特許文献７】ＩＴＵ−Ｔ勧告Ｙ．１５４１（ｐｐ．５−ｐｐ．６）
【非特許文献８】ＩＴＵ−Ｔ勧告Ｙ．１２２１（ｐｐ．６−ｐｐ．７）
【非特許文献９】Ａ．Ｅｌｗａｌｉｄ，Ｄ．Ｍｉｔｒａ，ａｎｄ  Ｒ．Ｈ．Ｗｅｎｔｗｏｒｔｈ，“Ａ  Ｎｅｗ  Ａｐｐｒｏａｃｈ  ｆｏｒ  Ａｌｌｏｃａｔｉｎｇ  Ｂｕｆｆｅｒｓ  ａｎｄ  Ｂａｎｄｗｉｄｔｈ  ｔｏ  Ｈｅｔｒｏｇｅｎｅｏｕｓ，Ｒｅｇｕｌａｔｅｄ  Ｔｒａｆｆｉｃ  ｉｎ  ａｎ  ＡＴＭ  ｎｏｄｅ，”ＩＥＥＥ  Ｊｏｕｒｎａｌ  ｏｎ  Ｓｅｌｅｃｔｅｄ  Ａｒｅａｓ  ｉｎ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，１３（６）：１１１５−１１２７，Ａｕｇ．１９９５．
【発明の開示】
【発明が解決しようとする課題】
【００２９】
前述のように、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデル（リーキーバケットモデル）によりＵＮＩトラヒック規定し、ＵＮＩ間品質保証を提供するサービス提供網において、１）仮想バッファ／トランクモデルの、あらかじめサービス提供網内の各ネットワーク転送ノードのリンクにおけるバッファ量を見積もる必要があるという課題があり、また、２）サービス提供網では、ネットワーク内の各リンクごとに実効帯域を計算する必要があるため、スケールしないという課題があり、また、３）ユーザが帯域要求時にトークンバケットパラメータである，トークンレート、バーストサイズ、ピークレートを全て自由に指定することを許可するため、サービス提供網における収容率が上がらないという課題があり、また、４）帯域要求時のサービス提供網側でのパラメータ管理が煩雑になるという課題があった。
【００３０】
（目的）
本発明の目的は、上記１）〜４）の課題を解決し、従来の品質保証型サービスモデルである，Ｉｎｔｓｅｒｖ，Ｄｉｆｆｓｅｒｖ，ＩＴＵ−Ｔ勧告Ｙ．１２２１におけるサービスプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定し、これを監視しなければならないという課題を解決することが可能な品質保証サービスを実現する受付判定方法およびトラヒック制御方法、ならびにそのシステムを提供することにある。
【課題を解決するための手段】
【００３１】
図１は、本発明による品質保証サービスを実現する受付判定システムの基本構成図であり、図２は本発明において、集線を行わないリンクを受付判定対象外とすることの説明図である。
本発明のサービス提供網の受付判定システムは、図１に示すユーザからの帯域要求に対して受付を行う帯域管理サーバＳと、帯域管理サーバＳに帯域要求やパラメータを送信する際の仲介をするサービス制御サーバＳＳと、ゲートウェイルータＧＷと、コアルータＲで構成されたサービス提供網Ｎに、ユーザ網Ｕ１，Ｕ２におけるターミナル装置（ただし、ターミナル装置は端末、ルータ、スイッチ、サーバ等を指す）ＴＥから流入するセッションフローのトラヒック特性をトークンバケットモデル（リーキーバケットモデル）によりＵＮＩトラヒック規定し、ＵＮＩ間品質保証を提供する。なお、図１において、Ｎはサービス提供網Ｎ、Ｕ１，Ｕ２はユーザ網である。ユーザ網Ｕ１，Ｕ２のターミナル装置ＴＥから帯域管理サーバＳに対して帯域要求が行われると、それに応じてサーバＳから回答がターミナル装置ＴＥに回答が送られる。
帯域管理サーバＳは、コンピュータ制御により該帯域管理サーバ内のリソースデータベースにおけるサービス提供網Ｎ内の各転送ノードの接続情報、リンクリソース情報（ノードｉからノードｊへのリンクｉｊにおけるリンク帯域Ｃｉｊ、バッファ網Ｂｉｊ）を管理し、また、帯域管理サーバＳは、該帯域管理サーバ内のリソースデータベースまたは受付判定部の演算回路を動作して種々の演算を実行する。
【００３２】
（請求項１，３について）
本発明のサービス提供網の帯域管理サーバでは、ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）、ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段により、サービス提供網内の各転送ノードにおけるＩＦの接続情報、リンク帯域、ＩＦにおけるバッファ量を取得、または設定を行う。さらに、取得、設定した（Ｃｉｊ，Ｂｉｊ）の値を用いて以下の各リンクｉｊでの許容遅延量Ｄｉｊを計算する。
【００３３】
【数１２】
2006229516.tif 000014
【００３４】
Ｄｉｊは、サービス提供網内の各ＩＦのリンク帯域、バッファ量に依存した値であるため、この値を含んでいる従来の式（１１）における実効帯域ｅｋ，ｉｊは各リンクごとに異なった値となり、受付判定を行うためには、各リンクごとに積み上げ帯域を計算しなくてはならない。
ここで、本発明では、論理的パケットロスをゼロとする条件を変えずに、実効帯域ｅｋ，ｉｊをリンクごとのリソース量により変化しない実効帯域を求める。そのためには、単純にＤｉｊを変化させたときの実効帯域ｅｋ，ｉｊの最大値を実効帯域とみなすことで安全側の判定となり、論理的パケットロスをゼロとする条件は変わらない。この場合、式（１１）からＤｉｊの最小値を用いることになる。ただし、サービス提供網のリンクの中には、ネットワークの構成上集線をしないために転送待ちが発生せず、受付判定を必要としないリンクも存在する。そのようなリンクでは、通常、Ｄｉｊの値は小さく、そのため単純にＤｉｊの最小値をとると、そのような受付判定の対象とならないリンクを選んでしまい、収容効率が必要以上に悪くなってしまう。そこで、Ｄｉｊの最小値を計算する際のリンクの集合を以下の方法で計算する。
【００３５】
サービス提供網内の全てのリンクの集合Ａの中で、転送ノードｎに直接接続されているリンクでノードｎより他ノードに至るリンクの集合をＳ（ｎ，Ｏ）、他ノードよりノードｎに至るリンクの集合をＳ（ｎ，Ｉ）とする。このとき、一回目の手順として、以下の条件を満たすリンクの集合を求める。
【００３６】
【数１３】
2006229516.tif 000015
Ｌ（１）に含まれるリンクｉｊは、例えば、図２に示されるリンク３４のように、集線を行っていないリンクであり、ノードｉにおける出力バッファでの待ち合わせによる遅延は発生しない。従って、リンクｉｊは受付判定の対象ではないので、Ｓ（ｉ，Ｏ）から除外する。すなわち、
【００３７】
【数１４】
2006229516.tif 000016
とする。
【００３８】
さらに、リンクｉｊによりノードｊへ至るトラヒックの最大帯域をＣｉｊとみなすのは過大であり、実際には、Σｈｉ∈Ｓ（ｉ，Ｉ）−｛ｊｉ｝Ｃｈｉで抑えられるため、ノードｊに至るリンクの集合からリンクｉｊを除外し、代わりにＳ（ｉ，Ｉ）−｛ｊｉ｝に含まれるリンクを加える。すなわち、下式（１５）とする。
【００３９】
【数１５】
2006229516.tif 000017
上式（１４），（１５）による変更を上式（１３）に含まれるリンク全てについて行い、集合Ｓ（ｎ，Ｏ），Ｓ（ｎ，Ｉ）の変更を行った後、新たに２回目の手順としてＬ（２）＝｛ｉｊ｜Ｃｉｊ≧Σ｛ｈｉ｝∈Ｓ（ｉ，Ｉ）−｛ｊｉ｝Ｃｈｉ｝を求める。以後、同様の処理を、除かれるリンクがなくなるまで、すなわちＮ回目の手順としてＬ（Ｎ）＝φとなるまで繰り返す。
【００４０】
ここでは、最終的に求められたサービス提供網内のリンクの集合を次式（１６）とし、
【００４１】
【数１６】
2006229516.tif 000018
次の最小値を計算する。
【００４２】
【数１７】
2006229516.tif 000019
【００４３】
以上に計算されたＤｍｉｎは、受付判定の対象となるリンクにおけるＤｉｊの中で最小となるため、サービス提供網内で統一的な値として用いる。この値を用いた次式（１８）の実効帯域を計算し、
【００４４】
【数１８】
2006229516.tif 000020
ｅｋをセッションフローｋ（トークンレートｒｋ，バケットサイズσｋ，ピークレートＰｋ）に対するサービス提供網における統一的な受付判定を行う際の実効帯域とする。ｅｋを用いて積み上げ計算を行い、以下の受付判定を行う。
セッションフローｋが経由するリンクｉｊにおける受付判定
【００４５】
【数１９】
2006229516.tif 000021
この受付判定は、従来の実効帯域ｅｋ，ｉｊを用いた受付判定よりも安全側の判定となるため、論理的パケットロスがゼロである条件は変わらない上に、スケーラビリティの阻害要因の一つであるリンクごとの実効帯域の再計算を回避することができる。
【００４６】
（請求項２，４，５について）
さらに、収容効率を考えると、上式（１９）で計算されるｅｋはトークンレートｒｋよりも大きく、ピークレートＰｋよりも小さい値であるため、ｅｋ＝ｒｋとなる場合が一番収容効率が良い。従って、次式（２０）となる。
【００４７】
【数２０】
2006229516.tif 000022
このときの式（２０）中のＤｍｉｎは、式（１３）〜式（１６）の手順を実施しなくてもよく、サービス提供網内の全てのリンク集合｛ｉｊ｝において以下の単純な最小値を用いてもよい。
【００４８】
【数２１】
2006229516.tif 000023
上式（２０）を計算すると、
【００４９】
【数２２】
2006229516.tif 000024
となる。
【００５０】
従って、セッションフローｋのパラメータσｋ，ｒｋおよびネットワークリソース量（Ｃｉｊ，Ｂｉｊ）から計算された固定値Ｄｍｉｎが式（２０）を満たすとき、セッションフローｋの実効帯域はトークンレートｒｋに等しくなる。
上式（２１）は、セッションフローのトークンパラメータが任意の値を取り得る場合には必ずしも成り立たないが、ＵＮＩでセッションフローｋのトークンバケットパラメータに関して規定できるのであれば、上式（２０）を満たすように（バーストサイズσを規定するように）することで収容効率を最大化することができる。具体的な手続きとしては、以下に述べる通りである。
【００５１】
サービス提供条件のＵＮＩトラヒック規定として、セッションフロー接続要求時にフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）に加え、トークンレートｒｋをユーザ網装置からサービス提供網側の帯域管理サーバへ申告し、バケットサイズσｋは式（２１）によりサービス提供網側の帯域管理サーバにおいて自動的に計算する。さらに、ピークレートはユーザ網に接続される物理回線帯域とし、帯域管理サーバでは、帯域要求時にはフロー識別情報からセッションフローが経由するリンクｉｊの集合を計算し、トークンレートｒｋの積み上げ計算により、以下の受付判定を行う。
【００５２】
セッションフローｋが経由するリンクｉｊにおける受付判定
【００５３】
【数２３】
2006229516.tif 000025
式（２３）による受付判定は式（２２）の条件付きであるため、受付可の場合には、ユーザ網装置に式（２２）によるバケットサイズσｋを通知する必要がある。
【００５４】
（請求項６，７について）
さらに、ＵＮＩトラヒック規定をサービス提供網側で監視する場合、帯域管理サーバは受け付けたセッションフローに対しては、申告されるセッションフロー識別情報と、トークンレートｒｋ，式（２１）で計算されるバケットサイズσｋを用いて、サービス提供網において（セッションフローｋの平均制限帯域）＝（トークンレートｒｋ），（平均バーストサイズ）＝（バケットサイズσｋ）として転送トラヒック流量を監視し、監視流量内のトラヒックのみをサービス提供網内に透過させるようにトラヒック制御を行う。
【００５５】
（請求項２，４，５について）
本発明によるサービス提供条件のＵＮＩトラヒック規定をまとめると、以下のようになる。
１）トークンレートｒ：ユーザ網から、サービス提供網へ申告
２）バケットサイズσ：式（２２）により、サービス提供網において計算
３）ピークレートＰ：物理回線帯域（リンク帯域）
【００５６】
ここで、図２の説明を行う。
図の１から６は図１に示したサービス提供網Ｎ内のゲートウェイルータ（ＧＷ）あるいはコアルータＲ）のいずれかに相当する。図１のネットワークではルータ３，４に着目したリンク集合として、Ｓ（３，Ｉ）はルータ３に入力する方向のリンク集合を示しており、この集合における各リンク帯域Ｃ１３，Ｃ２３，Ｃ４３とＣ３４を比較すると、式１３より１０Ｇｂｐｓ＞１Ｇｂｐｓ＋１Ｇｂｐｓであるので、Ｌ（１）＝｛３４｝となる。これは集線を行なっていないリンクであるため、全てのリンク集合の中から除外できる。従って、式（１４）より、Ｓ（３，Ｏ）：＝｛３１，３２｝であり、式（１５）よりＳ（４，Ｉ）：＝｛１３，２３，５４，６４｝である。
一方、ルータ４に着目して同様に考えると、各リンク帯域Ｃ５４，Ｃ６４，Ｃ３４とＣ４３を比較すると式（１３）より、１０Ｇｂｐｓ＜１０Ｇｂｐｓ＋１０Ｇｂｐｓであるので、Ｌ（１）＝Φとなり、従って、ルータ３，４に着目したときのＬ（１）は、Ｌ（１）＝｛３４｝となる。
同様に、２回目の手順を考えるとＬ（２）＝Φであり、手続きは終了する。
このとき、式（１６）からＳ（２）＝｛３１，３２，４３，４５，４６｝であるから、Ｄｍｉｎ〔Ｂ３１／Ｃ３１，Ｂ３２／Ｃ３２，Ｂ４３／Ｃ４３，Ｂ４５／Ｃ４５，Ｂ４６／Ｃ４６〕となる。
【発明の効果】
【００５７】
本発明によれば、ユーザ網内装置からサービス提供網に流入するセッションフローのトラヒック特性をトークンバケットモデル（リーキーバケットモデル）によりＵＮＩトラヒック規定し、ＵＮＩ間品質保証を提供するサービス提供網における受付判定方法とトラヒック制御方法およびシステムにおいて、以下の（課題１）〜（課題５）を解決することができる。
【００５８】
（課題１）帯域要求を受け付ける帯域管理サーバにおいて、セッションフローｋの実効帯域ｅｋを計算すると、このｅｋはリンクｉｊには依存しない値となり、実効帯域ｅｋを用いて、受付判定を行えば、同一セッションフローに対する実効帯域のリンクごとの計算を省略でき、ｅｋ≧ｅｋ，ｉｊとなり、受付判定としては従来のｅｋ，ｉｊを用いて行う判定よりも、安全側となるため、論理的パケットロスを依然としてゼロのままとしている。
従って、本発明における帯域管理サーバにおいて自動的にこのｅｋを計算し、積み上げ管理し、受付判定をすることにより、論理的ロスゼロという転送品質を確保しながら、従来のあらかじめサービス提供網内の各転送ノードのリンクにおけるバッファを見積もる必要があるという課題と、サービス提供網ではネットワーク内の各リンクごとに実効帯域を計算する必要があるためスケールしないという課題を、解決する。
【００５９】
（課題２）さらに、上記実効帯域ｅｋとトークンレートｒｋを等しくし、トークンバケットパラメータに関する関係式を見出すことにより、論理的ロスゼロという転送品質を確保しながら、トークンレートｒｋによる帯域積み上げ計算が可能になり、収容効率を最大とした受付判定が可能となる。これにより、サービス提供網における収容率が上がらないという課題を解決することができる。
【００６０】
（課題３）サービス提供条件としては、ＵＮＩトラヒック規定として、トークンレートｒｋはユーザ網装置からネットワーク側の帯域管理サーバへ申告することとし、バケットサイズσｋは申告されたｒｋをもとに式（２２）によりサービス提供網側で計算され、さらにピークレートＰｋはユーザ網に接続される物理回線帯域とすることにより、帯域要求ごとに申告するパラメータはトークンレートのみとなり、帯域要求時のパラメータ管理が煩雑になるという課題を解決できる。
【００６１】
（課題４）また、ＵＮＩトラヒック規定におけるＤｍｉｎはサービス提供網内のリソース量に応じて計算、規定する値であり、論理的ロスゼロという転送品質を確保しながら、１ｈｏｐでの許容遅延量をＤｍｉｎとする転送品質を規定しており、サービス提供網においてプロバイダはネットワーク内のリソースに応じて提供できる転送品質を規定しなければならないという課題を解決することができる。
【００６２】
（課題５）このとき、トークンレートｒｋとバケットサイズσｋを用いてセッションフローｋごとの転送トラヒック流量をサービス提供網側で監視し、監視流量内のトラヒックのみをサービス提供網内に透過させるようにトラヒック制御を行うことにより、転送品質を監視しなければならないという課題を解決することができる。
【発明を実施するための最良の形態】
【００６３】
以下、本発明の実施例を図面により詳細に説明する。
（実施例１）
図８は、本発明の実施例１に係る受付判定方法の動作フローチャートである。
実施例１においては、ユーザ網におけるＴＥ（ターミナル装置）からの帯域要求がサービス制御サーバを経由し、帯域管理サーバＳに送信され、アクセス網およびコア網により構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。
【００６４】
受付判定部、監視制御部、リソースＤＢにより構成される帯域管理サーバにおいて、リソースＤＢはサービス提供網Ｎ内のゲートウェイルータＧＷおよびコアルータＲの各リンクｉｊにおけるリンク帯域Ｃｉｊとバッファ量ＢｉｊをＳＮＭＰ，ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段を用いて、取得あるいは設定を行い、リンクが２重化等が行われている場合でも、論理的に１リンクとしてみなせる場合には、合計のリンク帯域をＣｉｊ、合計のバッファ網をＢｉｊとし、同様に取得、設定を行い、アクセス網においても、コア網と同様に取得、設定を行う（ステップ２０１）。
【００６５】
帯域管理サーバＳにおけるリソースＤＢは、取得、設定したリンク帯域Ｃｉｊとリンク集合Ｓ（ｎ，Ｉ），Ｓ（ｎ，Ｏ）の情報を元に、条件式（１３）〜（１５）の計算を繰り返し行い、この条件を適用しても、リンクの集合Ｌ（Ｎ）が全て空集合になるまで条件適用を行い、式（１６）によりＳ（Ｎ）を決定する（ステップ２０２，２０３）。
帯域管理サーバＳにおけるリソースＤＢは、式（１７）により許容遅延量Ｄｍｉｎの計算を行う（ステップ２０４）。
ユーザ網Ｕ１，Ｕ２におけるターミナル装置ＴＥは、帯域要求時にトークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）の申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う（ステップ２０５）。
【００６６】
帯域管理サーバＳにおける受付判定部は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）を用いて、実効帯域ｅｋを計算し、式（１９）による受付判定を行い（ステップ２０６）、受付許可の場合には、受付許可通知をサービス制御サーバを経由してターミナル装置ＴＥに対して行い（ステップ２０７）、受付不可の場合には、受付拒否通知をターミナル装置ＴＥに対して行う（ステップ２０８）。
【００６７】
（実施例２）
図９は、本発明の実施例２に係る品質保証サービスを実現する受付判定方法の動作フローチャートである。
本実施例２においては、図１に示すように、ユーザ網におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由し、帯域管理サーバＳに送られ、アクセス網およびコア網によって構成されるサービス提供網Ｎの受付判定を行うものである。ただし、ターミナル装置は端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。
【００６８】
受付判定部、監視制御部、リソースＤＢにより構成される帯域管理サーバＳにおいて、リソースＤＢはサービス提供網ＮのゲートウェイルータＧＷおよびコアルータＲの各リンクｉｊにおけるリンク帯域Ｃｉｊとバッファ量ＢｉｊをＳＮＭＰ，ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段を用いて、取得、あるいは設定を行い、リンクが２重化等が行われている場合でも、論理的に１リンクとしてみなせる場合には、合計のリンク帯域をＣｉｊ、合計のバッファ量をＢｉｊとし、同様に取得、設定を行い、アクセス網においても、コア網と同様に取得、設定を行う（ステップ３０１）。
帯域管理サーバＳにおけるリソースＤＢは、取得、設定したリンク帯域Ｃｉｊとバッファ量Ｂｉｊの値を元に、式（２１）のＤｍｉｎを計算する（ステップ３０２）。
【００６９】
ユーザ網Ｕ１，２におけるターミナル装置ＴＥは、帯域要求時にトークンレートｒｋの申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う（ステップ３０３）。
帯域管理サーバにおける受付判定部は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンレートｒｋを用いて、式（２３）による受付判定を行い（ステップ３０４）、受付不可の場合には、受付拒否通知をサービス制御サーバＳＳを経由してターミナル装置ＴＥに対して行う（ステップ３０５）。
帯域管理サーバＳにおける監視制御部は、受付可の場合には、申告されたトークンレートｒｋと、式（２２）でバケットサイズσｋを計算し、これをＵＮＩトラヒック規定値とし（ステップ３０６）、サービス制御サーバＳＳを経由して、ターミナル装置ＴＥに対してサービス受付許可通知を行い、バケットサイズσｋを通知する（ステップ３０７）。
【００７０】
（実施例３）
図１０は、本発明の実施例３に係る品質保証サービスを実現する受付判定方法およびトラヒック制御方法の動作フローチャートである。
本実施例３においては、図１に示すように、ユーザ網Ｕ１，Ｕ２におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由して帯域管理サーバＳに送られ、アクセス網およびコア網により構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは、端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。
【００７１】
受付判定部、監視制御部、リソースＤＢにより構成される帯域管理サーバＳにおいて、リソースＤＢはサービス提供網Ｎ内のゲートウェイルータＧＷおよびコアルータＲの各リンクｉｊにおけるリンク帯域Ｃｉｊとバッファ量ＢｉｊをＳＮＭＰ，ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段を用いて、取得、あるいは設定を行い、リンクが２重化等が行われている場合でも、論理的に１リンクとしてみなせる場合には、合計のリンク帯域をＣｉｊ、合計のバッファ量をＢｉｊとし、同様に取得、設定を行い、アクセス網においても、コア網と同様に取得、設定を行う（ステップ４０１）。
【００７２】
帯域管理サーバＳにおけるリソースＤＢは、取得、設定したリンク帯域Ｃｉｊとバッファ量Ｂｉｊの値を元に、式（２１）のＤｍｉｎを計算する（ステップ４０２）。
ユーザ網におけるターミナル装置ＴＥは、帯域要求時にトークンレートｒｋの申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う（ステップ４０３）。
帯域管理サーバＳにおける受付判定部は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンレートｒｋを用いて、式（２３）による受付判定を行い（ステップ４０４）、受付不可の場合には、受付拒否通知をサービス制御サーバＳＳを経由してターミナル装置ＴＥに対して行う（ステップ４０５）。
【００７３】
帯域管理サーバＳにおける監視制御部は、受付可の場合、申告されたトークンレートｒｋと、式（２２）でバケットサイズσｋを計算し、これをＵＮＩトラヒック規定値とし（ステップ４０６）、ゲートウェイルータＧＷに対して当該セッションフローの平均制限帯域＝トークンレートｒｋ，平均バーストサイズ＝バケットサイズσｋとして、転送トラヒック量を監視し、この監視流量内トラヒックのみをサービス提供網に透過させるようトラヒック制御を行い（ステップ４０７）、帯域管理サーバＳにおける受付判定部は、受付可の場合には、サービス制御サーバＳＳを経由してターミナル装置ＴＥに対してサービス受付許可通知を行う（ステップ４０８）。
【００７４】
（実施例４）
図１１は、本発明の実施例４に係る受付判定システムの構成図である。
本実施例においては、ユーザ網Ｕ１，Ｕ２におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由し、帯域管理サーバＳに送られ、アクセス網およびコア網によって構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは端末、ルータ、スイッチ、サーバ等を指し、トークンバケットモデルに従ったトラヒック転送を行うものとする。
【００７５】
受付判定部Ｓ１およびリソースＤＢ・Ｓ３により構成される帯域管理サーバＳにおいて、リソースＤＢ・Ｓ３は、サービス提供網内のゲートウェイルータＧＷおよびコアルータＲの各リンクｉｊにおけるリンク帯域Ｃｉｊとバッファ量ＢｉｊをＳＮＭＰ，ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段を用いて、取得あるいは設定を行い、リンクが２重化等が行われている場合でも、論理的に１リンクとしてみなせる場合には、合計のリンク帯域をＣｉｊ、合計のバッファ量をＢｉｊとし、同様に取得、設定を行い、アクセス網においても、コア網と同様に取得、設定を行う手段１（リソースＤＢ・Ｓ３から延長する矢印）を有する。
【００７６】
また、帯域管理サーバＳにおけるリソースＤＢ・Ｓ３は、取得、設定したリンク帯域Ｃｉｊとバッファ量Ｂｉｊの値を元に、条件（１３）〜（１５）の計算を繰り返し行い、この条件を適用しても、リンクの集合Ｌ（Ｎ）が全て空集合になるまで条件適用を行い、式（１６）によりＳ（Ｎ）を決定し、式（１７）により許容遅延量Ｄｍｉｎの計算を行う手段２（リソースＤＢ・Ｓ３の一部を構成する部分）を有する。
ユーザ網におけるターミナル装置ＴＥは、帯域要求時にトークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）の申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う手段３（ＴＥからサービス制御サーバＳＳに向かう矢印）を有する。
【００７７】
帯域管理サーバＳにおける受付判定部Ｓ１は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンバケットパラメータ（ｒｋ，σｋ，Ｐｋ）を用いて、実効帯域ｅｋを計算し、式（１９）による受付判定を行う手段４（受付判定部の一部を構成する部分）を有する。
受付許可の場合には、受付許可通知をサービス制御サーバＳＳを経由してターミナル装置ＴＥに対して行い、受付不可の場合には、受付拒否通知をターミナル装置ＴＥに対して行う手段５（帯域管理サーバＳからサービス制御サーバＳＳを介してＴＥに延長する矢印）を有する。
【００７８】
（実施例５）
図１２は、本発明の実施例５に係る受付判定システムおよびトラヒック制御システムの構成図である。
本実施例においては、ユーザ網におけるターミナル装置ＴＥからの帯域要求がサービス制御サーバＳＳを経由し、帯域管理サーバＳに送られ、アクセス網およびコア網によって構成されるサービス提供網Ｎの受付判定を行うものとする。ただし、ターミナル装置ＴＥは、端末、ルータ、スイッチ、サーバ等を指し、トークンパケットモデルに従ったトラヒック転送を行うものとする。
【００７９】
受付判定部Ｓ１、監視制御部Ｓ２、リソースＤＢ・Ｓ３によって構成される帯域管理サーバＳにおいて、リソースＤＢ・Ｓ３は、サービス提供網Ｎ内のゲートウェイルータＧＷおよびコアルータＲの各リンクｉｊにおけるリンク帯域Ｃｉｊとバッファ量ＢｉｊをＳＮＭＰ，ＣＯＰＳ等のネットワーク管理プロトコルまたはポリシー管理プロトコル等の手段を用いて、取得あるいは設定を行い、リンクが２重化等が行われている場合でも、論理的に１リンクとしてみなせる場合には、合計のリンク帯域をＣｉｊ、合計のバッファ量をＢｉｊとし、同様に取得、設定を行い、アクセス網においても、コア網と同様に取得、設定を行う手段１（リソースＤＢ・Ｓ３から延長する複数の矢印）を有する。
【００８０】
また、帯域管理サーバＳにおけるリソースＤＢ・Ｓ３は、取得，設定したリンク帯域Ｃｉｊとバッファ量Ｂｉｊの値に元に、式（２１）のＤｍｉｎを計算する手段２（リソースＤＢ・Ｓ３の一部を構成する部分）を有する。
また、ユーザ網におけるターミナル装置ＴＥは、帯域要求時にトークンレートｒｋの申告をサービス制御サーバＳＳを経由して帯域管理サーバＳに行う手段３（ＴＥからサーバス制御サーバＳＳを経由して帯域管理サーバＳに延長する矢印）を有する。
また、帯域管理サーバＳにおける受付判定部Ｓ１は、セッションフロー識別情報（送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号）によりセッションフローｋが経由するリンクｉｊの集合を計算し、申告されたトークンレートｒｋを用いて、式（２３）による受付判定を行う手段４（受付判定部Ｓ一の一部を構成する部分）を有する。
【００８１】
また、受付不可の場合には、受付拒否通知をサービス制御サーバＳＳを経由してターミナル装置ＴＥに対して行う手段５（帯域管理サーバＳからサービス制御サーバＳＳを経由してＴＥに延長する矢印）を有する。
また、帯域管理サーバＳにおける監視制御部Ｓ２は、受付可の場合、申告されたトークンレートｒｋと、式（２２）でバケットサイズσｋを計算し、ＵＮＩトラヒック規定値とする手段６（監視制御部Ｓ２からゲートウェイルータＧＷに向う矢印）を有する。
また、ゲートウェイルータＧＷに対して当該セッションフローの平均制限帯域＝トークンレートｒｋ，平均バーストサイズ＝バケットサイズσｋとして、転送トラヒック量を監視し、この監視流量内トラヒックのみをサービス提供網Ｎに透過させるようトラヒック制御を行う手段７（帯域管理サーバＳからサービス制御サーバＳＳを経由してＵＮＩに延長する矢印）を有する。
また、帯域管理サーバＳにおける受付判定部Ｓ１は、受付可の場合、サービス制御サーバＳＳを経由してターミナル装置ＴＥに対してサービス受付許可通知を行う手段８（受付判定部Ｓ１の一部を構成する部分）を有する。
【００８２】
なお、本発明における転送トラヒック量監視により違反したトラヒックの扱いについては、廃棄させるか、または、違反トラヒックへのリマーキングをして下位優先度のサービスクラスに送るか、廃棄優先度を高くして廃棄し易くさせる方式を考えることができるが、本発明では、このような転送トラヒック量監視により違反したトラヒックの扱いに関して限定されるものではない。
また、本発明では、ＩＰ電話サービス、映像コミュニケーションサービス、ストリーミング配信等、の要求品質が厳しいサービスをアプリケーションとして利用することができ、上記課題を解決する。従って、本発明はこれらアプリケーションに固有の技術、プロトコルによりその有効性が限定されるものではない。
さらに、本発明では、サービス制御を行うためのプロトコルとして、ＨＴＴＰ、ＳＩＰ、Ｈ．３２３等があるが、これらのシグナリングにより、その有効性が限定されるものではない。
【図面の簡単な説明】
【００８３】
【図１】本発明における実施例１〜３に係る受付判定方法の動作説明図である。
【図２】本発明における受付判定方法を説明するための図である。
【図３】トークンバケットから送出されるトラヒックの最悪パターンである極値ＯＮ／ＯＦＦ過程を説明する図である。
【図４】トークンバケットから送出されるトラヒック量とトークンバケットパラメータの関係を説明する図である。
【図５】バッファ量と帯域の関係を説明する図である。
【図６】キューイングシステムにおけるバッファ量と利用している帯域とそれぞれの時間の関係を説明する図である。
【図７】仮想バッファ／トランクモデルを説明する図である。
【図８】本発明の実施例１に係る受付判定方法の動作フローチャートである。
【図９】本発明の実施例２に係る受付判定方法の動作フローチャートである。
【図１０】本発明の実施例３に係る受付判定方法とトラヒック制御方法の動作フローチャートである。
【図１１】本発明の実施例４に係る受付判定システムの構成図である。
【図１２】本発明の実施例５に係る受付判定システムとトラヒック制御システムの構成図である。
【符号の説明】
【００８４】
ｒ：セッションフローのトークンレートを表すトークンバケットパラメータ
σ：セッションフローのバケットサイズを表すトークンバケットパラメータ
Ｐ：セッションフローのピークレートを表すトークンバケットパラメータ
Ｔ０Ｎ：セッションが極値ＯＮ／ＯＦＦ過程に従ってピークレートＰでパケットを送出する期間の長さ
Ｔｏｆｆ：セッションが極値ＯＮ／ＯＦＦ過程に従ってパケットを送出しない期間の長さ
ｂ：ネットワークノードが出力リンク用に割り当てているバッファ容量
ｃ：ネットワークノードからの出力リンクの帯域
Ｄｏｎ：仮想キューイングシステムにおけるｂｕｓｙ期間長
Ｄｏｆｆ：仮想キューイングシステムにおけるｉｄｌｅ期間長
ｒｋ，σｋ，Ｐｋ：特定のセッションフローｋのトークンバケットパラメータ
Ｃｉｊ：ノードｉからノードｊへ至るリンクｉｊのリンク帯域
Ｂｉｊ：ノードｉからノードｊへ至るリンクｉｊに対して、ノードｉの出力インターフェースに用意されるバッファ容量
Ｄｉｊ：ノードｉからノードｊに至るリンクｉｊに対して、ノードｉの出力インターフェースで発生する最大遅延時間
ｃｋ：セッションフローｋに割り当てられる仮想帯域
ｂｋ：セッションフローｋに割り当てられる仮想バッファ容量
ｅｋ，ｉｊ：リンクｉｊ上でセッションフローｋに割り当てられる実効帯域
Ｄｍｉｎ：ネットワーク上の全ノードで統一的に用いられる許容遅延時間
ｅｋ：セッションフローｋに割り当てられるネットワーク上で統一的な実効帯域
Ｓ（ｎ，Ｏ）：ノードｎから他ノードへ至るリンクの集合
Ｓ（ｎ，Ｉ）：他ノードからノードｎへ至るリンクの集合
Ｌ（Ｎ）：Ｎ回目の手順において、あるノードに着目したときの集線効果がなく、受付判定の必要のないリンクの集合
【図１】
2006229516.tif 000031
【図２】
2006229516.tif 000032
【図３】
2006229516.tif 000033
【図４】
2006229516.tif 000034
【図５】
2006229516.tif 000035
【図６】
2006229516.tif 000036
【図７】
2006229516.tif 000037
【図８】
2006229516.tif 000038
【図９】
2006229516.tif 000039
【図１０】
2006229516.tif 000040
【図１１】
2006229516.tif 000041
【図１２】
2006229516.tif 000042