(57)【特許請求の範囲】
【請求項１】
複数の端末装置と、端末装置からのサービス要求に応じてアプリケーションの提供サービスを行うアプリケーションサーバと、ネットワークのリンク速度及びバッファ時間に関する情報を保有し、端末装置からのサービス要求を受け付けるか否かを判定する帯域管理サーバとを具えるネットワークにおいて、利用者がアプリケーションサーバから所望のアプリケーションの提供サービスを受ける際、パケットロス率が所定の基準値以下となるように制御するネットワークの品質制御方法であって、
利用者は、サービス要求を行う際、サービス要求内容と共に、長時間平均レート（Ｒ）、瞬間最大レート（Ｐ）及び一度に流れるバースト量（Ｂ）のパラメータを含むバーストパラメータとを帯域管理サーバに通知し、
通知を受けた帯域管理サーバは、
提供されるアプリケーションのストリームが経由するリンクを特定する工程と、
特定されたリンクについて、通知を受けたバーストパラメータとほぼ同一のバーストパラメータを有するストリームが流れているか否か判定し、ほぼ同一のバーストパラメータを有するストリームが流れていると判定した場合、通知されたサービス要求が収容上限帯域を満たすものとみなして当該サービス要求を許可する工程を実行することを特徴とするネットワークの品質制御方法。
【請求項２】
請求項１に記載のネットワークの品質制御方法において、前記判定工程において、前記通知されたバーストパラメータとほぼ同一のバーストパラメータを有するストリームが検出されなかった場合、前記帯域管理サーバは、さらに、前記利用者から通知されたバーストパラメータを用いて、特定されたリンクについてパケットロス率を算出する工程と、
算出されたパケットロス率と所定の基準値とを比較し、算出されたパケットロス率が基準値以下の場合に当該アプリケーションの提供を許可する工程とを実行することを特徴とするネットワークの品質制御方法。
【請求項３】
請求項１または２に記載のネットワークの品質制御方法において、前記アプリケーションサーバから提供されるアプリケーションが、周期的なバースト性を有するストリームトラヒックであること特徴とするネットワークの品質制御方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はＩＰ網の品質制御方法、特に品質制御対象がアプリケーションあるいはプラットホーム特性により周期的なバースト性をもつストリームトラヒックである場合にネットワークの品質低下を防止する品質制御方法に関するものである。
【０００２】
【従来の技術】
Bandwidth−Brokerモデルと呼ばれる帯域管理システムが提案されている（例えば、非特許文献１参照）。この帯域管理システムは、品質制御を目的としてサービス利用者の利用要求に対して受付制御という手法を用いるネットワークの実現形態である。Bandwidth−Brokerという名前が示すように、このモデルは主として帯域制御という考え方に基づくもので、基本的には必要帯域が確定しているサービスに対して制御するという前提であり、リアルタイム性やマルチキャストを利用するアプリケーションで扱われるなど再送制御による品質制御が困難でネットワーク側で品質制御を行う必要があるサービスへの適用性が見出されている。
【０００３】
ところが、現実のＩＰトラヒックを見ていると、厳密にはこの前提が成立しない場合が多い。図１は、ある映像ストリームをキャプチャした結果を示す。バーストが一定の周期で発生していることがわかる。このような短時間でのバーストに対しては、各ノードのバッファ時間がバースト間隔より長ければ考慮することが必要であるが、現実のトラヒックとノードにおいてはこのバースト性は無視できない場合が多く見られ、Bandwidth−Broker側にはトラヒックの振る舞いを考慮した対処が必要になる。
【０００４】
こうした場合にパケットロス率を基準値以下に抑える品質制御ないし受付制御技術に関しては、従来から様々な研究がなされており、その代表的なものとしてＡＴＭのトラヒック制御技術として既に標準的な手法が確立されており（例えば、非特許文献２参照）、以下のような共通の性質をもつ。
１．ＵＰＣ（Usage Parameter Controller）によりトラヒックを加工する。
２．各フロー毎にＶＣを割当ててＶＣ単位に制御する。
３．ＱｏＳパラメータにより統計多重効果を推定して、品質制御を行う。
【０００５】
また、ＩＰでの品質保証技術としては、ＲＳＶＰを利用したＲＳＶＰ−ＴＥなどがあるが（例えば、非特許文献３参照）、以下のような特徴をもっている。
１．ＵＰＣの存在は前提とはされていない。
２．経路制御は一般には各ノードの自律分散によって行われ、ＡＴＭに比べて経路計算処理負荷が小さい。各フローの状態管理はセッション制御によって行われる。
３．受付制御を行う品質制御の技術としてはＲＳＶＰ−ＴＥのようにリソースの排他的予約モデルに基づくものが多く、統計多重効果は利用されていない。
【０００６】
ＶＬＡＮ単位のレートシェーピングのような低位レイヤでの制御方法もあるが、これらは、ＩＰルーティングとは独立に動作する静的な制御である。
なお、こうした特性を持つトラヒックはそれほど特殊なものでなく、図２のように一定のクロックで動くサーバが定常的にトラヒックをイーサネット（登録商標）に送出する過程において頻繁に見られる特徴である。また、ＶＢＲ性は、図２のようにデータ量に時間依存性がある場合だけでなく、図３のように、割り込み処理等によりサーバが複数周期分のデータをまとめて送出する場合にも適用可能である。本発明は、このトラヒック特性があることを前提とする。
【０００７】
【非特許文献１】
B．Teitelbaum， et al．：”Qbone Bandwidth Broker Architecture”，work in progress，
http：//qbone．internet2．edu/bb/bboutline2．html
【非特許文献２】
Paul Ferguson；Geoff Huston，”インターネットQoＳ”オーム社，pp．123−154，2000
【非特許文献３】
D．Awduche；L．Berger；D．Gan；Ｔ．Li；Ｖ．Srinivasan；Ｇ．Swallow，”RSVP−TE：
Extensions to RSVP for LSP Tunnels”，IETF Networking Group RFC 3209，2001
【０００８】
【発明が解決しようとする課題】
ＡＴＭのトラヒック制御技術にはＩＰでのトラヒック制御技術に比べて次のような課題があった。
１．ＵＰＣの実装が必要であり、収容ノードに対する要求条件が厳しくなる。
２．ＶＣを各フローに割当てる為、フロー数が大きくなると経路計算負荷がＩＰのルーティング制御に比べて急速に増加する。
一方ＩＰによる既存トラヒック制御技術では次の課題があった。
３．各フローに対してリソースを排他的に予約するため、統計多重効果による効果を考慮してトラヒック制御が出来ない。
また両者に共通の課題があった。
４．ＶＢＲ的なトラヒックに対する対応が難しい。ＵＰＣによるトラヒック加工を利用する場合にはＵＰＣのコストが増大し、リソース予約に基づくモデルでは必要となるリソース量が増大する。ＡＴＭのＣＡＣアルゴリズムの中には参考文献〔４〕］のようにNon Parameteric ＣＡＣという手法も存在するが、図１のようにピーク速度がリンク速度に近い場合には適用範囲外である。
【０００９】
これらの課題は、トラヒック特性を任意のものとしているために発生したものである。ＡＴＭの場合には任意のトラヒックをＵＰＣにより加工し扱いやすくした上で統計多重効果を用いるという手法であったためＵＰＣやＶＣへの要求条件が厳しくなり、一方ＩＰ（ＲＳＶＰ−ＴＥ）はトラヒックをそのまま扱うため統計多重効果を用いられなくなった。
【００１０】
しかし前項で述べたように、実際のストリームの出力特性は図１に示すように、ストリームのバースト間隔、バーストサイズ及びピークレートが時間的に一定となる規則性をもっており、受付制御の際にBandwidth−Brokerの既存機能を利用してこの出力特性を利用者から申告させる方法は容易である。この特性を利用してＵＰＣを用いることなく、既存のＩＰの経路制御プロトコルを用いて、バースト特性と統計多重効果の影響を考慮した受付制御を可能とする事が本発明の目的であり、そのために、Bandwidth−Brokerの受付判定論理にバースト特性の統計多重効果を盛り込むことが本発明の解決しようとする課題である。
【００１１】
【課題を解決するための手段】
本章では、まず課題を解決する実現方式を述べた後、対象となるストリームの定義と後述する各実施例で述べられているユーザーが帯域管理サーバに通知ないし申告すべきパラメータを定義する。最後に本発明が利用する統計多重効果の性質について説明する。
Ｉ．課題を解決する実現方式
Bandwidth−Brokerに以下の（１）〜（４）の特性をもつ受付判定論理を具備することにより、ストリームのサービス利用者の利用要求に対して、ストリームがバースト性を持つという条件下でも受付制御という手法でパケットロス率を基準値以下に制御することが可能になる。
（１）極限ＯＮ−ＯＦＦモデルによりバースト特性を持つトラヒックを受付制御の対象とする場合に、利用者が利用要求時にバースト特性のパラメータを申告することで、事前に受付判定を可能とする方法及び受付判定アルゴリズム。
（２）（１）と同じ特性を持つトラヒックを対象とする際に、受付制御部（ネットワークに設けた帯域管理サーバ）において利用要求時に申告されたパラメータを現在ネットワークを流れているストリームのバーストパラメータと比較することにより、より簡易に事前判定を可能とする受付判定アルゴリズム
（３）（１）と同じ特性を持つトラヒックを対象とする際に、事前にサービス提供者（アプリケーションサーバ）より提供されるサービスのバースト特性のパラメータをサービス提供者が帯域管理サーバに申告することにより、簡易に事前判定を行う方法。
（４）バーストが時間周期性を持つもののその都度のバーストサイズが異なり、バーストサイズの最大値と長時間平均レートのみが保証される場合に、事前の受付判定を可能とする方法及び受付判定アルゴリズム。
なお、Bandwidth−Broker（帯域管理サーバ）そのものの仕組みとしては公知の事実であり、本発明ではその受付判定論理を発明の対象とするため、ストリームソースーユーザー間通信方法、ストリームソース−受付判定部間通信方法、並びにセッション管理方式は既存の方法を利用することとする。
【００１２】
II．対象となるストリームとユーザーが申告すべきパラメータ
極限ＯＮ−ＯＦＦモデルとは、図１に示されるようなバーストストリームを意味し、ストリームのバースト間隔、バーストサイズ及びピークレートが時間的に一定の性質を持つバーストを意味する。そして、例えば、映像ストリームや音楽配信ストリームのようなバースト性を有する各種のストリームは、バースト間隔、バーストサイズ及びピークレートが時間的にほぼ一定していることが確認された。このようなバースト性のトラヒックは３つのパラメータ（Ｒ，Ｐ，Ｂ）によって表現が可能である（Ｒ：長時間平均レート、Ｐ：瞬間最大レート、Ｂ：１度のバーストで流れるデータ量）。一方、後述する実施例４ではＢの大きさが一定ではなく最大値Bmaxのみが保証されているパターンである。申告すべきパラメータとしは、実施例１及び２では、ユーザーが（Ｒ，Ｐ，Ｂ）を、実施例３ではサーバが（Ｒ，Ｐ，Ｂ）およびユーザーがＲを、実施例４ではユーザーが（Ｒ，Ｂmax）を申告する必要がある。また、既知となっているノードのリンク速度とバッファ長をそれぞれＷ，Ｔとし、これらネットワークのリンク速度及びバッファ長に関するデータは、品質制御を行う帯域管理サーバが保有する。
【００１３】
III．  最後に本発明が利用する統計多重効果の性質
まず、上述したバースト特性を有する極限Ｏｎ−ＯＦＦモデルのトラヒックに関して考察する。全てのフローがバッファにより最大限待たされて出力された場合のサービス関数Ｓ(t)を考える。この場合はストリームが最も効率的に収容された場合である。
【数１】
0003949606.tif 000002
【００１４】
ここで、μはそのバーストのロスなし多重のための実効帯域と呼ばれるもので、ロスなしの条件（安全側近似）は各バーストのμの総和がリンク速度を超えないことである（例えば、参考文献、A．Elwalid et al，“A New Approach for Alloating Buffers and Bandwidth to eterogeneous，Regulated Traffic in an ATM Node，”IEEE IEEE Journal on Selected Areas in Communications，13：6，pp．1115−1127，August 1995、及び謝宇計，”情報流通プラットホームにおけるQoＳ保証のためのトラヒック制御，”NII Journal No．3，pp．23−33，2001）。すなわち、図4に示すように、パケットロス率の下限は各瞬間のμの総和がリンク速度を超える確率から求めることが出来る。バーストの種別をｉで表すとすると、各バーストパターン（Ri，Pi，Bi）の本数がNi本であるときにパケットロス率の下限Ｐlossは以下の式で表すことができる。
【数２】
0003949606.tif 000003
【００１５】
この式はBandwidth−Brokerのように呼毎に例えば利用者のサービス要求毎に判定する場合は計算可能である。ところで、ΣS(t)は以下のような性質を持つ。
【数３】
0003949606.tif 000004
【００１６】
これは、ΣS(t)がBi（Ｋ，T2／T）の重みつき平均値であることを示しており、（４）式がなりたつ範囲では、（５）式が成り立つ。
【数４】
Σri＝Σkiμi＝ｒ（一定）                            式（４）
Pr（ΣS(t)＞Ｗ≦max{Pr（μiBi（ｒ／Ri，T2／Ｔ）＞Ｗ   式（５）
【００１７】
これは、各単元ストリームの収容上限帯域をCiとするときに
【数５】
ΣRi≦min｛Ci｝                                      式（６）
Ｃi＝ｎiＲi(但し、ｎiはＰr(μiＢi(ｎi,Ｔ2／Ｔ)>＞Ｗ)＜ε(パラメータロス基準値)を満たす最大の数)
従って、収容上限帯域Ｃiを（２）式の安全側近似として用いることが出来るということである。この結果をバーストの間隔が一定の場合に適用すれば、収容率上限を決定するのは最大バーストサイズ（Ｂ＝Ｂmax）のストリームであり、「バースト周期T2でバーストサイズが常にＢmax」のフローの収容上限帯域をＣ0とすれば、実施例４の対象ストリームの受付判定条件は(7)式となる。
ΣRi≦C0                                              式(7)
なお、従来の排他的なリソース予約型の場合の帯域判定アルゴリズムにおいては
Σμ≦Ｗ（実施例１，２，３の場合）                    式(8)
Σμ≦C0（実施例４の場合但しμ≡Ｂmax／T2）           式(9)
が、理論的限界値となる。
【００１８】
【発明の実施の形態】
実施形態と具備機能を説明する。実施例２，３は実施例１の簡易実現方法であり、実施例４は実施例１の発展形であることから、実施例１を説明した後、他の方法について説明を行う。
図５は本発明によるネットワークの品質制御方法が適用されるネットワークの一例の構成を示す線図である。例えば、２つのドメイン１及び２が接続され、各ドメインには境界ルータ（ＢＲ）３及び４をそれぞれ設け、これら境界ルータによりドメインを相互接続する。各ドメインにはネットワークの品質管理ないし帯域管理を行う帯域管理サーバ（ＢＢ）５及び６をそれぞれ設け、ネットワーク上でも品質制御を実行する。この帯域管理サーバは、サービス利用者からの利用要求を受け付けるか否かを判定する受付制御機能も実行する。各ドメインにはサービスの提供を受ける利用者が操作する複数の端末装置７が接続される。尚、図面上１個の端末装置だけを示すが、勿論複数の端末装置が接続されているものとする。この端末装置は、例えばパーソナルコンピュータ（ＰＣ）や携帯電話等の各種端末装置とすることができる。また、当該ネットワークには、例えば映像配信サーバや音楽配信サーバのようなアプリケーションサーバ８を接続する。このアプリケーションサーバ８は、利用者の要求に応じて利用者の端末装置に各種アプリケーションを送信する。アプリケーションサーバ８から配信される映像ストリームがON-OFFモデルによるバースト特性を有する場合、本発明の品質制御方法を用いることによりネットワークの品質を良好な状態に維持することができる。
【００１９】
利用者がアプリケーションサーバ8からのサービスの提供を希望する場合、利用者は、自己の端末装置7を介して帯域管理サーバ５に対してサービス要求内容及び後述するバーストパラメータを通知する。通知を受けた帯域管理サーバ５は、リンクを特定すると共に受信したバーストパラメータを用いてパケットロス値を算出し、得られたパケットロス値が所定の基準以下の場合当該サービス要求を受け入れる。このサービス要求受付判定アルゴリズムを以下に説明する。
【００２０】
［実施例１］
１．帯域管理サーバはネットワーク内の各リンクのリンク速度（Ｗ）及びバッファ時間（Ｔ）を記憶する。
２．利用者は、各種アプリケーションの配信サービスを受ける際、帯域管理サーバに対してサービス要求内容及びバーストパラメータ（Ｒ，Ｐ，Ｂ）を通知する。
３．帯域管理サーバは、利用者からサービス要求があると、既存の機能に従い配信されるストリームの始点と終点を特定しストリームの経由するリンクを特定する。
４．帯域管理サーバは、特定された各リンクに対し、受信したバーストパラメータ（Ｒ，Ｐ，Ｂ）を用いて（２）式を適用し、パケットロス率が基準値（Ｗ）を満たすかどうかを判定する。
５．判定が全てのリンクに対して満足されれば、帯域管理サーバはサービス要求を許可する。そしてセッション情報としてバーストパラメータ（Ｒ，Ｐ，Ｂ）を保持する。
６．サービスの提供が終了すると、帯域管理サーバは、既存の機能によりサービス終了を検出し、保持したバーストパラメータをセッション情報から削除する。
帯域管理サーバがこのような受付処理を実行することにより、ネットワーク上においてパケットロス率を基準値以下に制御することができる。る。手順１，３，６はBandwidth −Brokerの既存機能をそのまま利用している。
【００２１】
［実施例２］
本例では、帯域管理サーバが受信したバーストパラメータに基づいてパケットロスを計算するのではなく、現在流れているストリームのバーストパラメータと通知されたバーストパラメータとを比較し、流れているものと判定した場合収容上限帯域Ｃiの条件を満たすものと判定し、当該サービス要求を許可する。
１．実施例１と同様に、帯域管理サーバは、ネットワーク内の各リンクのリンク速度（Ｗ）及びバッファ時間（Ｔ）を記憶する。
２．利用者は、ストリームを受ける際に帯域管理サーバに対して、サービス要求内容とバーストパラメータ（Ｒ，Ｐ，Ｂ）を通知する。
３．帯域管理サーバは、利用者からサービス要求があると、既存の機能に従い配信されるストリームの始点と終点を特定しストリームの経由するリンクを特定する。
４．帯域管理サーバは、特定された各リンクに対し、バーストパラメータ（Ｒ，Ｐ，Ｂ）とほぼ同一のパラメータのストリームが流れているかどうかを検索する。流れていれば、Ciが得られる。流れていなければCiを計算する。
５．得られたＣiについて（６）式を適用してパケットロス率が基準値を満たすかどうかを判定する。
６．判定が全てのリンクに対して満足されれば、帯域管理サーバはサービスを許可する。そしてセッション情報として（Ｒ，Ｐ，Ｂ）及びＣiを保持する。
７．サービスの提供が終了すると、帯域管理サーバは、既存の機能によりサービス終了を検出し、保持したバーストパラメータをセッション情報から削除する。
本例では、パケットロス率の計算が省略されるので、受付処理の負荷が軽減される。
【００２２】
［実施例３］
本例では、サービス提供者がバーストパラメータを帯域管理サーバに通知する例のアルゴリズムを説明する。
１．実施例１と同様に、帯域管理サーバは、ネットワーク内の各リンクのリンク速度（Ｗ）及びバッファ時間（Ｔ）を記憶する。
２．各サービス提供者は、サービスの提供を開始する前に、帯域管理サーバに対して、提供するアプリケーションのバーストパラメータ（Ｒ，Ｐ，Ｂ）を通知する。
３．帯域管理サーバは、サービス提供者からの通知を用いて各リンクに対して収容上限帯域Ciを計算する。そして各リンクに対するCiを記憶する。
４．利用者は、ストリームを受けるに当たり、帯域管理サーバに対して、サービス要求内容と長時間平均レート（Ｒ）を通知する。
５．帯域管理サーバは、利用者からサービス要求があると、既存の機能に従い配信されるストリームの始点と終点を特定しストリームの経由するリンクを特定する。
６．帯域管理サーバは、特定された各リンクに対し、（７）式を適用してパケットロス率が基準値を満たすかどうかを判定する。
７．判定が全てのリンクに対して満足されれば、帯域管理サーバは当該サービス要求を許可する。そしてセッション情報としてＲを保持する。
８．サービスの提供が終了すると、帯域管理サーバは、既存の機能によりサービス終了を検出し、保持したバーストパラメータをセッション情報から削除する。
【００２３】
［実施例４］
１．実施例１と同様に、帯域管理サーバは、ネットワーク内の各リンクのリンク速度（Ｗ）及びバッファ時間（Ｔ）を記憶する。
２．利用者は、ストリームを受ける際に帯域管理サーバに対して、サービス要求内容とバーストパラメータ（Ｒ，Ｂmax）を通知する。
３．帯域管理サーバは、利用者からサービス要求があると、既存の機能に従い配信されるストリームの始点と終点を特定しストリームの経由するリンクを特定する。
４．帯域管理サーバは、特定された各リンクに対し、Ｂmaxの値の最大値を求め、それに対応するC0がなければ、C0を計算する。存在すればその値を用いる。
５．（７）式を適用してパケットロス率が基準値を満たすかどうかを判定する。
６．判定が全てのリンクに対して満足されれば、帯域管理サーバはサービスを許可する。そしてセッション情報として（Ｒ，Ｂmax）とそのＢmaxに対応するC0を保持する。
７．サービスの提供が終了すると、帯域管理サーバは、既存の機能によりサービス終了を検出し、保持したバーストパラメータをセッション情報から削除する。
【００２４】
次に、利用者がバーストパラメータを帯域管理サーバに通知する方法について説明する。この通知方法として種々の方法を用いることができ、一例として図６に記載する方法を説明する。利用者は、Webブラウザを用いて、ポータルサイトのストリームの一覧(以下、「番組表」と称する)から提供を希望するストリームを選択する場合を想定する。利用者は、事業者の定めるHTTPプロキシサーバをWebに設定する。その後、番組表にWebブラウザでアクセスし、提供を希望するストリームを選択する。一方、事業者は一定のルールに基づいてURLを定める。例えば、図1のような映像ストリームに対してそのファイル名として、
Cinema1-6.72M-16800B.mpeg
のようにファイル名とバーストパラメータとを結び付けておく。この映像ストリームのURLは以下のように表現される。
HTPP://WWW.AAA.BBB.CCC/Cinema1-6.72M-720M-16800B.mpeg
利用者がストリームを選択すると、Webブラウザからは利用要求としてHTTP GETメッセージがHTTPプロキシに向けて送信されるが、当該メッセージ中に当該URLが記述されているので、このURLを文字列処理することにより、バーストパラメータを得ることができる。
【００２５】
【発明の効果】
本発明により、バースト性の強い映像ストリームに対しても多重効果を用いた受付制御を行うことが出来るようになった。
実施例４に関しては本方式により従来のリソース予約型方式に比べてμ／R倍の収容率が得られることとなる。
実施例１，２，３に関してはＷとＲの比によって改善度合いが異なるが、例えば表１のような状況での比較を行うと図６に示す最大収容率の結果が得られる。
【００２６】
【表１】
0003949606.tif 000005
【図面の簡単な説明】
【図１】  映像ストリームのストリーム特性を示す線図である。
【図２】  本発明が対象とするストリームの発生過程（バーストの発生過程）を示す線図である。
【図３】  本発明が対象とするストリームの発生過程（バーストサイズの揺らぎ）を示す線図である。
【図４】  パケットロス率の計算方法とΣS(t)の関係を示す線図である。
【図５】  本発明による品質制御方法が適用されるネットワークの一例を示す線図である。
【図６】  利用者がバーストパラメータを帯域管理サーバに通知する一例の方法を示す線図である。
【図７】  ストリームの平均レートと最大収容率との関係を本発明による品質制御方法と従来方法と対比して示すグラフである。
【符号の説明】
１，２    ドメイン
３，４    境界ルータ
５，６    帯域管理サーバ
７        帯域装置
８        アプリケーションサーバ
【図１】
0003949606.tif 000006
【図２】
0003949606.tif 000007
【図３】
0003949606.tif 000008
【図４】
0003949606.tif 000009
【図５】
0003949606.tif 000010
【図６】
0003949606.tif 000011
【図７】
0003949606.tif 000012