JP3783947B2 - 映像ストリームの品質制御方法、そのプログラム及び記録媒体 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明はＩＰ網の品質制御技術に係わり、特に周期的なバーストを持つ映像ストリームトラフィックに対する品質制御として、統計多重効果をパラメータ化すること及びそのパラメータを利用してネットワークに品質制御機能を持たせる技術に関するものである。
【０００２】
【従来の技術】
映像ストリームは、一般に、バーストが一定周期で発生して、１度のバーストで流れるデータ量が一定である性質を持つ。図１７は、このような映像ストリームの一例を示したもので、ストリーム特性（トラフィック）は３つのパラメータＰ、ρ、σによって表現が可能である。ここで、ρは長時間平均レート、Ｐは瞬間最大レート、σは１度のバーストで流れるデータ量を表わしている。このようなストリームは、パケットロスが著しい品質劣化を起こす性質をもつが、リアルタイム性やマルチキャストを利用するアプリケーションで扱われるなど、再送制御による品質制御が困難で、ネットワーク側で品質制御を行う必要がある。
【０００３】
まず、バースト性のあるトラフィックに対して品質制御を行う為の従来技術としては、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ ｍｏｄｅ：非同期転送モード）のトラフィック制御技術として既に標準的な手法が確立されている（文献：Ｐａｕｌ Ｆｅｒｇｕｓｏｎ；Ｇｅｏｆｆ Ｈｕｓｔｏｎ，“インターネットＱｏＳ”，オーム社，ｐｐ，１２３−１５４，２０００）。それらに共通な性質は、以下のようなものである。
１．ＵＰＣ（Ｕｓａｇｅ Ｐａｒａｍｅｔｅｒ Ｃｏｎｔｒｏｌｌｅｒ）によりトラヒックをネットワークの都合に合わせて加工する。ＵＰＣは、一般にすべてのネットワーク資源が使われたとき、過剰にトラヒックネットワークに入ることを禁止することにより輻輳を防ぐものである。
２．各フロー毎にＶＣ（仮想チャネル）を割当ててＶＣ単位に制御する。
３．ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）パラメータにより統計多重効果を推定して、品質制御を行う。通信品質に影響を及ぼすパラメータは、遅延時間や遅延のバラッキ、データ損失率、ピーク速度などである。
【０００４】
また、ＩＰ網での品質保証技術としては、ルータ間で特定の通信チャネルの伝送帯域を管理するためのプロトコルであるＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｓｅｔｕｐ Ｐｒｏｔｏｃｏｌ）を利用したＲＳＶＰ−ＴＥなどがあるが（文献：Ｄ．Ａｗｄｕｃｈｅほか“ＲＳＶＰ−ＴＥ：Ｅｘｔｅｎｓｉｏｎ ｔｏ ＲＳＶＰ ｆｏｒ ＬＳＰ Ｔｕｎｎｅｌｓ”，ＩＥＴＦ Ｎｅｔｗｏｒｋｉｎｇ Ｇｒｏｕｐ ＲＦＣ ３２０９，２００１）、以下のような特徴をもっている。
１．ＵＰＣの存在は必須ではない。
２．経路制御プロトコルで行われる為、一般には各ノードの自律分散によって行われ、ＡＴＭに比べて経路計算処理負荷が小さい。
３．ＲＳＶＰ−ＴＥのようにリソース予約モデルに基づくものが多く、パラメータは単純なものが主である。
【０００５】
このように、ＡＴＭとＩＰの品質制御は異なる方向性をもっている。ほかには、ＶＬＡＮ単位のレートシェービングのような低位レイヤでの制御方法もあるが、これらはＩＰルーティングとは独立に動作した静的な制御である。
【０００６】
【発明が解決しようとする課題】
上記ＡＴＭのトラフィック制御技術には、ＵＰＣの実装が必要であり、収容ノードに対する要求条件が厳しくなること、また、ＶＣを各フローに割当てる為、フロー数が大きくなると経路計算負荷がＩＰのルーティング制御に比べて急速に増加するなどの課題があった。また、ＩＰによる既存トラフィック制御技術では、リンク帯域や必要帯域といった単純なパラメータしか使えないため、バースト性を考慮しておらず、バースト性を考慮する場合には必要帯域として最大ピークレートを用いる必要があり、統計多重効果による効果を考慮してトラフィック制御が出来ない課題があった。
【０００７】
これらの課題は、入力トラヒックとして一般のトラヒックを前提としているための問題である。先に述べたように映像ストリームの出力特性はある程度の規則性をもっており、かつ、そのパケットロス目標値は大変小さい。
【０００８】
本発明の目的は、映像ストリームのこのような特性を利用して、ＵＰＣを用いることなく、既存のＩＰの経路制御プロトコルを用いて、バースト特性と統計多重効果の影響を考慮したトラフィック制御を可能とすることにある。
【０００９】
【課題を解決するための手段】
本発明は、事前の統計解析によるパラメータ化とユーザーの視聴要求時にリアルタイムに判定処理を行う手続きの２つに大別される。リアルタイム手続きの際に必要となる受付判定部は、ネットワークにおける各ノード、あるいはネットワーク内に存在するＱｏＳサーバに置かれる。
１． 事前の統計解析によるパラメータ化
（１）映像ストリームのモデル化を行う為、事前にサーバストリームを測定しておき、ストリーム特性（Ｐ，ρ，σ）を確定させておく。また、そのストリームのコーデック種別がどのくらいのパケットロスを許容するかを調べ、許容するパケットロス率（ε）を設定しておく。
（２）ノードｊでの多重特性を見積もる為、ネットワーク内で品質制御対象となる全リンクＬｊに対してリンク速度（Ｃｊ）とバッファ時間（Ｔｊ）を調べておく。
（３）（１），（２）の結果を元に統計解析を行い、同一のリンクにＫ本の（Ｐ，ρ，σ）の等しいストリームを流す場合のパケットロス率（Ｐｌｏｓｓ（Ｋ））を求め、Ｐｌｏｓｓ（Ｋ）＜εとなるＫの最大値Ｋ０を求める。
（４）Ａ≡Ｃ／Ｋ０ρと定義することにより、ストリーム側条件Ｓｉ（Ｐｉ，ρｉ，σｉ，εｉ）とノード側条件Ｌｊ（Ｃｊ，Ｔｊ）が決定した場合の多重化パラメータＡｉｊを求める。
（５）ＡｉｊをＡｉｊ≒αｉ／βｊとなるα，βのパラメータに分解する。
【００１０】
モデル化で定義したＳ（Ｐ，ρ，σ）のストリーム多重特性については、既に定式化されている（文献：計 宇生，“情報流通プラットホームにおけるＱｏｓ保証のためのトラヒック制御”，ＮＩＩ ＪｏｕｒｎａｌＮｏ．３，ｐｐ．２３ −２００１）。同一のリンクにＫ本の（Ｐ，ρ，σ）の等しいストリームを流す場合のパケットロス率（Ｐｌｏｓｓ（Ｋ））は以下のように上限値を起こせることが可能である。
ｌｏｇ（Ｐｌｏｓｓ（Ｋ））＝−ｓｕｐ［ｓ（Ｋμ−Ｃ）−Ｋｌｏｇ（Ｋρ／Ｃ）］：ｓ≧０
但し、μは損失無し多重化のための実効帯域と呼ばれるもので、ノードで許される遅延の最大値がバッファ時間（Ｔ）であるとすると以下のようになる。
μ＝ｍａｘ［ρ，Ｐσ／｛（σ＋Ｔ（Ｐ−ρ）））
このときＰｌｏｓｓ（Ｋ）＜εであるための条件としては、（１）または（２）の式で表される。
Ｋ＜Ｃ／μ （１）
Ｋｌｏｇ（Ｋρ／Ｃ）＜ｌｏｇ（ε） （２）
ここで（２）式は、εが十分小さく、Ｃ／ρがあまり大きくない場合には自然数の解を持たない場合があり、解を持つ場合には（Ｋρ／Ｃ）が１に近い値をもつという傾向がある。
全てのリンクで（２）式が解を持つ場合には（２）式を用いてパラメータを決定し、そうでない場合は（１）を用いてパラメータを決定する。
（２）式を用いる場合にはリンク種別ごとの差が殆ど無いことになるので以下のように決定する。
Ａ≡Ｃ／Ｋ０ρ，α＝Ａ，β＝１ （３）
（１）式を用いる場合には、１度のバーストの時間Ｔｏｎを用いて以下のようにかける。
Ａρ＝μ＝Ｐσ／｛σ＋Ｔ（Ｐ−ρ）｝＝Ｐ／｛１＋Ｔ／Ｔｏｎ｝≒σ／Ｔ
但しＴ>>Ｔｏｎのとき
ここで、σはストリームの性質であり、Ｔはノードの性質であるから、以下のように決定できる。
α＝σ／ρ，β＝Ｔ （４）
【００１１】
２． ユーザーの視聴要求時にリアルタイムに判定処理を行う手続き
（１）ネットワーク内に受付判定部を置き、ネットワーク内の各リンクＬｊに対して、リンクＬｊに現在流れているストリームの使用帯域（ΣＡｉｊρｉあるいはΣαｉρｉ）を記録しておく。
（２）ユーザー端末がストリームソースに対して新規視聴要求を行うと、ストリームソースは受付け判定部に対して受付判定要求を行う。
（３）受付判定要求を受け取ると、受付判定部は品質制御の対象となるリンクを確定し、新規に視聴要求を受けたストリームの必要帯域ＡＩｊρＩ或いはαＩρＩを調べて各リンクＬｊに対し判定式
｛ΣＡｉｊρｉ＋ＡＩｊρＩ＜Ｃｊ｝あるいは｛Σαｉρｉ＋αＩρＩ＜βｊＣｊ｝
の値の真／偽をストリームソースに返す。
（４）真が返された場合、ストリームソースはストリームの配信を行い、配信が終了すると終了通知を受付判定部に行う。偽が返された場合はストリームソースはストリームの配信を拒否する。
（５）受付判定部では、終了通知を受け取るとストリームの使用帯域から、そのストリームの使用帯域の値を引いた値に修正する。
【００１２】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
〈事前統計解析によるパラメータ〉
図１に、事前の統計解析によるパラメータ化の処理フローチャートを示す。これは、後述する各実施例に共通である。
まず、事前に映像ストリームのトラヒックを測定し、映像ストリームの特性を（Ｐ、ρ、σ）でモデル化するとともに、許容するパケットロス率（ε）を決定する（Ｓ１）。図１７に示したように、Ｐはトラヒックの最大レート、ρは長時間平均レート、δは１度のバーストのデータ量を表わす。また、ノード特性（出力側）としてネットワーク（ＮＷ）の各ノードのリンク速度Ｃ、バッファ時間（Ｔ）を調査しておく（Ｓ２）。
【００１３】
次に、ステップＳ１、Ｓ２の結果を元に統計解析を行い、同一のリンクにＫ本のストリーム特性（Ｐ、ρ、σ）の等しいストリームを流す場合のパケットロス率（Ｐｌｏｓｓ（Ｋ））を求め、Ｐｌｏｓｓ（Ｋ）＜εとなるＫの最大値Ｋ０を決定する（Ｓ３）。そして、このＫ０により、多重化パラメータＡ＝Ｃ／Ｋ０を定義する（Ｓ４）。
【００１４】
Ａには入出両方の条件が関わっているため、条件を入力側、出力側に分割し、Ａ＝α／βのように、２つのパラメータα、βで表現する。ここで、αは入力側条件、βは出力側条件を表わす。
【００１５】
先に述べたように、パラメータのα、βの決定は、Ｋ＜Ｃ／μで、Ｋｌｏｇ（Ｋρ／Ｃ）＜（ε）が自然数の解をもつか判定し（Ｓ５）、次のように定める。すなわち、自然数の解をもつ場合には、先の（３）式から、α＝Ｃ／Ｋ０ρ、β＝１とする（Ｓ６）。また、自然数の解をもたない場合には、先の（４）式から、α＝σ／ρ、β＝Ｔとする（Ｓ７）。
【００１６】
以下、本発明を適用した各実施例を示す。
〈実施例１〉
これは、ストリームのソースのソースとデストネーションが判明すると経路が特定できる閉域ネットワークにおいて、視聴要求時にソースとデストネーションのＥｎｄ−ｔｏ−Ｅｎｄで通信品質が基準を満たせるかを判定可能とするものである。
【００１７】
図２に本実施例のネットワーク構成例を示す。図２において、１００はストリームソース、１１０はノード、１２０はユーザ端末、１３０はＱｏＳサーバであり、該ＱｏＳサーバ１３０内に受付判定部１３５が存在する。受付判定部１３５は、全ノードのインターフェース（ＩＦ）のリンク速度、使用帯域等を管理している。
ユーザ端末１２０は、ストリームソース１００に対してストリームの視聴要求を行う。ストリームソース１００は、ユーザ端末１２０の視聴要求に応じてＱ０Ｓサーバ１３０の受付判定部１３５に受付判定要求を行い、返答が真であれば、ストリームの配信を行う。各ノード１１０は、経路制御に基づいてパケットを転送する。なお、受付判定部１３５については後述する。
【００１８】
〈実施例２〉
これは、トラヒックの多重による品質劣化の起こるノードが予め定まっているネットワークにおいて、該当するノードのバッファ時間がストリームの１度のバースト時間より十分長い範囲の場合、バースト周期及び長時間平均レートが異なるストリームが混在しても、該当するノードでのパケット率の上限値を算出し、Ｅｎｄ−ｔｏ−Ｅｎｄで通信品質が基準を満たせるかを判定可能とするものである。
【００１９】
図３に本実施例のネットワーク構成例を示す。これは、アクセス区間のみがボトルネットとなる以外、図２と基本的に同じである。Ｑ０Ｓサーバ１３０内の受付判定部１３５は、対象ノードのＩＦのリンク速度、使用帯域等を管理する。
【００２０】
図４に、実施例１、２におけるストリームソース１００とＱ０Ｓサーバ１３０の一構成例の機能ブロック図を示す。ストリームソース１００はサーバ通信プロセス部１０１、ストリーム配信アプリケーション部１０２、トラヒック分類器１０３、パケットスケジューラ１０４などで構成される。サーバ通信プロセス部１０１は、ユーザ端末の視聴要求に応じてＱ０Ｓサーバ１３０に受付判定要求を行い、その返答を受け取り、返答が真であれば、ストリーム配信アプリケーション部１０２やパケットスケジュール１０４にストリームの配信を指示し、配信が終了すると、Ｑ０Ｓサーバ１３０に終了通知を行うものである。その他の機能は、基本的に従来と同様である。
【００２１】
Ｑ０Ｓサーバ１３０は通信プロセッサ１３１、経路計算部１３２、受付判定部１３５などで構成される。通信プロセッサ１３１はストリームソース１００や各ノード１１０の通信制御を司り、経路計算部１３２はパケットの経路選択を司るものである、これらは、本発明に直接関係しないので、詳細は省略する。本発明は受付判定部１３５にかかわる。
【００２２】
図５にＱ０Ｓサーバ１３０内の受付判定部１３５の構成例を示す。本受付判定部１３５はインターフェース機能部１３５１、帯域計算・判定部１３５２、ストリームデータ管理ＤＢ１３５３、ノードデータ管理ＤＢ１３５４、帯域使用量管理ＤＢ１３５５、記録媒体１３５６などで構成される。図６に各管理ＤＢ１３５３、１３５４、１３５５での管理内容の具体例を示す。
【００２３】
図７は本実施例１、２における判定処理フロー例を示したものである。以下、図７にもとづいて、実施例１、２の場合のユーザ視聴要求時のリアルタイム判定処理を説明する。
Ｑ０Ｓサーバ１３０の受付判定部１３５では、ネットワーク内の全ノードの現在流れているストリームの使用帯域ΣＡｉρｉを管理している（Ｓ１１）。ユーザ端末１３０がストリームソース１００に対して新規視聴要求を行うと、ストリームソース１００はＱ０Ｓサーバ１３０へ受付判定要求（帯域ρ）を行う（Ｓ１２）。Ｑ０Ｓサーバ１３０は、ストリームの経路を計算し（Ｓ１３）、該経路上の全ノードｉに対し、ΣＡｉρｉ＋ＡＩｊρＩを計算して、ΣＡｉρｉ＋ＡＩｊρＩ＜Ｃｊを判定する（Ｓ１４）。そして、判定が偽なら、ストリームソース１００にＮＧを返す（Ｓ１５）。一方、判定が真ならば、経路上のリンクに対し、使用帯域ΣＡｉρｉにＡＩｊρＩを加算し、ストリームソース１００にＯＫを返す（Ｓ１６）。ストリームソース１００は、Ｑ０Ｓサーバ１３０からＯＫが返されると、ストリーム配信を行い（Ｓ１７）、配信が終了すると、Ｑ０Ｓサーバ１３０へ終了報告を行う（Ｓ１８）。Ｑ０Ｓサーバ１３０は、ストリームソース１００から終了報告を受け取ると、該当経路上のリンクに対し、ＡＩｊρＩを使用帯域から減算する（Ｓ１９）。
【００２４】
〈実施例３〉
これは、各ノードが自らのもつインターフェースに関してそのリンク速度と現状の使用帯域を把握し、新規のセッションに対して必要リソースの確保が可能な場合にセッションを確立する機能をもつネットワークにおいて、ノードに見做しリンク速度（βＣ）を設定し、必要帯域として見做し長時間平均レート（αρ）を用いることによって、Ｅｎｄ−ｔｏ−Ｅｎｄで通信品質が基準を満たしたときのみにストリームの送信を可能とするものである。
【００２５】
図８に本実施例のネットワーク構成例を示す。図８において、１００はストリームソース、１１０はノード、１２０はユーザ端末であり、各ノード１１０内に受付判定部１１５が存在する。各受付判定部１１５は、自ノードのＩＦの使用帯域（Σαρ）、リンク速度（βＣ）を管理している。
【００２６】
ユーザ端末１２０はストリームソース１００に対してストリームの視聴要求を行う。ストリームソース１００は、該ストリームソース１００が収容されるノード１１０（以下、受付ノード）に受付判定要求を行う。受付ノード１１０は、ＲＳＶＰ−Ｐａｔｈメッセージで経路上の各ノードへ帯域のαＩρＩを要求し、各ノードの受付判定部１１５で判定を行い、判定が真ならＲＳＶＰ−Ｒｅｓｖメッセージを返し、受付ノード１１０が、ストリームソース１００に返答する。ストリームソース１００は、返答が真であれば、ストリームの配信を行う。
【００２７】
図９に、本実施例におけるストリームソース１００と各ノード１１０の構成例の機能ブロック図を示す。なお、ノード１１０の一つが受付ノードとなる。ストリームソース１００はサーバ通信プロセス部１０１がＲＳＶＰプロセス部１０５に置き替った以外、先の図４と同様である。受付ノード１１０はＲＳＶＰプロセッサ１１１、ルーティングプロセッサ１１２、トラフィック分類部１１３、受付制御部１１４、受付判定部１１５、パケットスケジューラ１１６などで構成される。ここで、受付判定部１１５が本発明にかかわる。
【００２８】
図１０に、各ノード内の受付判定部１１５の構成例を示す。本受付判定部１１５はインターフェース機能部１１５１、帯域計算・判定部１１５２、リンク情報管理ＤＢ１１５３、帯域使用量管理ＤＢ１１５４、記憶媒体１１５５などで構成される。図１１に各管理ＤＢ１１５３、１１５４での管理内容の具体例を示す。
【００２９】
図１２は本実施例３における判定処理フローチャート例を示したものである。以下、図１２にもとづいて、実施例３の場合のユーザ視聴要求時のリアルタイム判定処理を説明する。
各ノード１１０の受付判定部１１５では、自ノードの使用帯域（Σαρ）、リンク速度（βＣ）を管理している（Ｓ２１）。ユーザ端末１３０がストリーム１００に対して新規視聴要求を行うと、ストリームソース１００は、受付ノード１１０へＲＳＶＰ−Ｐａｔｈメッセージで帯域（αＩρＩ）を要求する（Ｓ２２）。メッセージを受け取った受付ノード１１０は、ルーティングプロトコルにより出力ＩＦを決定し（Ｓ２３）、出力ＩＦに対して、Σαρ＋αＩρＩを計算し、Σαρ＋αＩρＩ＜βｊＣｊを判定する（Ｓ２４）。ここで、判定が偽ならば、Ｐａｔｈメッセージ破棄をストリームソース１００に返す（Ｓ２５）。一方、判定が真ならば、ユーザ端末１３０が直下に収容されているか判定し（Ｓ２６）、収容されていない場合は、出力ＩＦから次のノードへＲＳＶＰ−Ｐａｔｈメッセージで帯域（αＩρＩ）要求を行う（Ｓ２７）。以下、判定が真の場合、各ノードで同様の処理を行う。ユーザ端末１３０が直下に収容されている場合、該当ノード１１０は、ＲＳＶＰ Ｒｅｓｖメッセージを一つ手前に返し、該当リンクに対し、使用帯域にαＩρＩを加算し、受付制御部に登録する（Ｓ２８）。こうして、経路上の各ノード１１０で判定が真だった場合、受付ノード１１０がＲＳＶＰ−Ｒｅｓｖメッセージをストリームソース１００に返答することになる。ストリームソース１００は、ＲＳＶＰ−Ｒｅｓｖメッセージを受け取ると、ストリームを配信し、配信中はＲＳＶＰ−Ｃｏｎｆメッセージを、受付ノードを介し、経路上の各ノード１１０へ送信する（Ｓ２９）。各ノード１１０では、ＲＳＶＰ−Ｃｏｎｆが来なくなったら、使用帯域からαＩρＩを減算し、受付制御部の登録から削除する（Ｓ３０）。
【００３０】
〈実施例４〉
これは、ネットワーク構成は先の実施例３と同様であるが、過去にストリームを流した事のあるストリームソースに対するストリームパラメータを記憶することにより、事前解析を自動化してオンデマンに行い、Ｅｎｄ−ｔｏ−Ｅｎｄで通信品質が基準を満たしたときのみにストリームの送信を可能とするものである。ネットワーク構成は図８と同様であり、各ノード１１０に受付判定部１１５が存
在する。
【００３１】
図１３に、本実施例におけるストリームソース１００と各ノード１１０の構成例の機能ブロック図を示す。ストリームソース１００の構成は先の図９と同様である。ノード１００の構成も、トラフィック測定部１１７が加付された以外、先の図９と同様である。ただし、受付判定部１１５の内部構成が若干相違する。
【００３２】
図１４に受付判定部１１５の構成例を示す。本受付判定部１１５はインタフェース機能部１１５、帯域計算・判定部１１５２、ストリームデータ管理ＤＢ１１５６、リンク情報管理ＤＢ１１５３、帯域使用量管理ＤＢ１１５４、記憶媒体１１５５などで構成される。これは、基本的には、先の図５に類似している。図１５に、各管理ＤＢ１１５６、１１５３、１１５４における管理内容の具体例を示す。ここで、ストリームデータ管理ＤＢ１１５６の内容は随時追加される。
【００３３】
図１６に本実施例４における判定処理フローチャート例を示す。先の図１２との相違は、ストリームソースのＩＰアドレスからパラメータ（Ｐ，ρ，Ｔｏｆｆ）を検索する処理（Ｓ３４）、ストリームを配信した際に、トラヒック測定部にて、そのストリーム（ソースとディストネーションの組）に対し、パラメータ（Ｐ，Ｔｏｆｆ，ρ）を測定する処理（Ｓ４１）が追加されたことである。
【００３４】
なお、各実施例で示した装置における各部の一部もしくは全部の処理機能をコンピュータのプログラムで構成し、そのプログラムをコンピュータを用いて実行して本発明を実現することができること、あるいは、図１、図７、図１２、図１６などで示した処理手順をコンピュータのプログラムで構成し、そのプログラムをコンピュータに実行させることができることは言うまでもない。また、コンピュータでその処理機能を実現するためのプログラム、あるいは、コンピュータにその処理手順を実行させるためのプログラムを、そのコンピュータが読み取り可能な記録媒体、例えば、ＦＤや、ＭＯ、ＲＯＭ、メモリカード、ＣＤ、ＤＶＤ、リムーバブルディスクなどに記録して、保存したり、提供したりすることができるとともに、インターネット等のネットワークを通してそのプログラムを配布したりすることが可能である。
【００３５】
【発明の効果】
本発明によれば、バースト性の強い映像ストリームに対してもリソース予約モデルを適用して品質制御を行うことが可能となる。またパラメータをα，βの２つに分離したことにより、ノード自律分散型の品質制御への適用も可能となる。
トラフィック多重効果を考慮したことによる収容率向上の例として、市販のストリームソースとレイヤ３スイッチのデータを基にＫ０及びＡを起算した結果を図１８に示す。また、その計算データを図１９に示す。先の条件式（１）で計算した場合に比べて条件式（２）で計算した結果の方が非常に収容率が高くなっていることがわかる。
【図面の簡単な説明】
【図１】 本発明による事前統計解析によるパラメータ決定の処理フロー例である。
【図２】 本発明の実施例１のネットワーク構成例である。
【図３】 本発明の実施例２のネットワーク構成例である。
【図４】 実施例１，２におけるストリームソースとＱ０Ｓサーバの一実施例の機能ブロ
ック図である。
【図５】 Ｑ０Ｓサーバ内の受付判定部の機能ブロック図である。
【図６】 受付判定部内の各管理ＤＢの管理内容である。
【図７】 実施例１、２における判定処理フローチャート例である。
【図８】 本発明の実施例３のネットワーク構成例である。
【図９】 実施例３におけるストリームソースと各ノードの一実施例の機能ブロック図である。
【図１０】 各ノード内の受付判定部の機能ブロック図である。
【図１１】 受付判定部内の各管理ＤＢの管理内容である。
【図１２】 実施例３における判定処理フローチャート例である。
【図１３】 本発明の実施例４におけるストリームソースと各ノードの一実施例の機能ブロック図である。
【図１４】 各ノード内の受付判定部の機能ブロック図である。
【図１５】 受付判定部内の各管理ＤＢの管理内容である。
【図１６】 実施例４における判定処理フローチャート例である。
【図１７】 本発明で対象とする映像ストリームのストリーム特性である。
【図１８】 本発明による統計多重効果例を示す。
【図１９】 図１８の計算データ例を示す。
【符号の説明】
１００ ストリームソース
１１０ ノード
１１５ 受付判定部
１２０ ユーザ端末
１３０ Ｑ０Ｓサーバ
１３５ 受付判定部

Claims (7)

1. バーストの周期が一定でかつ１度のバーストのデータ量が一定している映像ストリームを出力するストリームソースをもつネットワークにおいて、１つのノードに複数のストリームを入力させ一つのリンクからトラフィックを多重して出力させる際に、ノードバッファにより吸収できずに発生するパケットロス率の上限値を算出し、通信品質が基準を満たしているかを判定して、映像ストリームの品質を制御する方法であって、
   ストリームソースが複数の長時間平均レートを選択することが可能でかつ長時間レートが変化してもバーストの周期が一定で１度のバーストのデータ量が変化する性質をもち、各ノードのバッファ時間がストリームの１度のバースト時間より十分長い範囲において、長時間平均レートの違うストリームが混在しても、通信品質が基準を満たしているかを判定することを特徴とする映像ストリームの品質制御方法。
2. 請求項１記載の映像ストリームの品質制御方法において、ストリームのソースとデストネーションが判明すると経路が特定できる閉域ネットワークにおいて、視聴要求時にソースとデストネーションのＥｎｄ−ｔｏ−Ｅｎｄで通信品質が基準を満たせるかを判定することを特徴とする映像ストリームの品質制御方法。
3. 請求項１記載の映像ストリームの品質制御方法において、各ノードが自らのもつインターフェイスに関してそのリンク速度と現状の使用帯域を把握し新規のセッションに対して必要リソースの確保が可能な場合にセッションを確立する機能をもつネットワークにおいて、ノードに見倣しリンク速度を設定し、必要帯域として見倣し長時間平均レートを用いることによって、Ｅｎｄ−ｔｏ−Ｅｎｄで通信品質が基準を満たしたときのみにストリームの送信を可能とすることを特徴とする映像ストリームの品質制御方法。
4. 請求項１記載の映像ストリームの品質制御方法において、トラフィックの多重による品質劣化の起こるノードが予め定まっているネットワークにおいて、該当するノードのバッファ時間がストリームの１度のバースト時間より十分長い範囲の場合、バースト周期及び長時間平均レートが異なるストリームが混在しても、該当するノードでのパケットロス率の上限値を算出し、Ｅｎｄ−ｔｏ−Ｅｎｄで通信品質が基準を満たせるかを判定可能とすることを特徴とする映像ストリームの品質制御方法。
5. 請求項３記載の映像ストリームの品質制御方法において、過去にストリームを流した事のあるストリームソースに対するストリームパラメータを記憶することにより、事前解析を自動化してオンデマンドに行い、Ｅｎｄ−ｔｏ−Ｅｎｄで通信品質が基準を満たしたときのみにストリームの送信を可能とすることを特徴とする映像ストリームの品質制御方法。
6. 請求項１乃至５記載の映像ストリームの品質制御方法をコンピュータで実行するためのプログラム。
7. 請求項１乃至５記載の映像ストリームの品質制御方法をコンピュータで実行するためのプログラムを記録した記録媒体。

Images