(57)【特許請求の範囲】
【請求項１】
トラフィック処理システムが処理するトラフィック量の推移を収集する通信状況収集部と、
前記通信状況収集部が収集したトラフィック量が増設閾値を超過したときに前記トラフィック処理システムの処理能力を増設すると判定し、その増設を開始する時点から増設を終了する時点までの増設期間を求める増設処理部と、
前記増設処理部が前記増設期間におけるトラフィック量の推移を予測し、その予測結果において増設を終了する時点までに増設前の処理能力を超過するトラフィック量を求め、その超過するトラフィック量に相当する抑制するトラフィック量の分を、増設を終了する時点までに前記トラフィック処理システムが処理するトラフィック量から抑制するように制御する抑制処理部と、を有することを特徴とする
品質制御装置。
【請求項２】
前記抑制処理部は、前記通信状況収集部が収集した現在のトラフィック量が前記増設前の処理能力に基づく抑制閾値を超過したときに、前記抑制するトラフィック量とは別に、所定量のトラフィック量を抑制することを特徴とする
請求項１に記載の品質制御装置。
【請求項３】
前記抑制処理部は、前記抑制するトラフィック量の分について、既に送信したトラフィック量のバッファ量が所定範囲に収まるように、抑制する期間と、抑制しない期間とを決定することを特徴とする
請求項１に記載の品質制御装置。
【請求項４】
前記トラフィック処理システムは、複数のユーザのトラフィック量を処理しており、
前記抑制処理部は、前記抑制するトラフィック量の分を複数のユーザに等分して、抑制する各ユーザのトラフィック量を求めることを特徴とする
請求項１ないし請求項３のいずれか１項に記載の品質制御装置。
【請求項５】
前記トラフィック処理システムは、複数のユーザのトラフィック量を処理しており、
前記抑制処理部は、前記抑制するトラフィック量の分を複数のユーザに割り当てるときに、各ユーザのトラフィック量に比例して、抑制する各ユーザのトラフィック量を求めることを特徴とする
請求項１ないし請求項３のいずれか１項に記載の品質制御装置。
【請求項６】
品質制御装置は、通信状況収集部と、増設処理部と、抑制処理部と、を有しており、
前記通信状況収集部は、トラフィック処理システムが処理するトラフィック量の推移を収集し、
前記増設処理部は、前記通信状況収集部が収集したトラフィック量が増設閾値を超過したときに前記トラフィック処理システムの処理能力を増設すると判定し、その増設を開始する時点から増設を終了する時点までの増設期間を求め、
前記抑制処理部は、前記増設処理部が前記増設期間におけるトラフィック量の推移を予測し、その予測結果において増設を終了する時点までに増設前の処理能力を超過するトラフィック量を求め、その超過するトラフィック量に相当する抑制するトラフィック量の分を、増設を終了する時点までに前記トラフィック処理システムが処理するトラフィック量から抑制するように制御することを特徴とする
品質制御方法。
【請求項７】
前記抑制処理部は、前記通信状況収集部が収集した現在のトラフィック量が前記増設前の処理能力に基づく抑制閾値を超過したときに、前記抑制するトラフィック量とは別に、所定量のトラフィック量を抑制することを特徴とする
請求項６に記載の品質制御方法。
【請求項８】
前記抑制処理部は、前記抑制するトラフィック量の分について、既に送信したトラフィック量のバッファ量が所定範囲に収まるように、抑制する期間と、抑制しない期間とを決定することを特徴とする
請求項６に記載の品質制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、品質制御装置、および、品質制御方法の技術に関する。
【背景技術】
【０００２】
災害時やイベント時などに、通信のトラフィック量が、システムの処理能力を超過するくらいに急激に増加してしまうこともある。システムの処理能力を超過した場合、システム全体が不安定になってしまい、既存の接続が強制切断されたり、新規の接続要求が却下されたりしてしまう。
【０００３】
そこで、システムの処理能力を保護するために、超過分からは新規の接続要求を受け付けないように規制する通信制御が行われる。例えば、非特許文献１には、「災害時優先通信」として、優先されない一般電話機からの発呼の一部が規制される旨が記載されている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】総務省、"災害時優先通信"、［online］、2009年、［平成27年8月4日検索］、インターネット〈URL：http://www.soumu.go.jp/menu_seisaku/ictseisaku/net_anzen/hijyo/yusen.html〉
【発明の概要】
【発明が解決しようとする課題】
【０００５】
新規の接続要求を却下する通信規制だけでは、その場しのぎとしてシステムを保護するだけにとどまり、接続要求を行うユーザにサービスを提供できず、長期的なユーザの満足度が低下してしまう。そこで、サーバを増設するなどのシステムの処理能力を増強することにより、長期的なトラフィック量の増加に対応する場合を検討する。
【０００６】
サーバの増設には、増設開始から増設完了までの増設期間が発生する。まず、増設期間を遅らせてしまうと、システムの処理能力が増強される前に、急激に増加したトラフィック量が処理されない事態が発生する。一方、増設期間を早めに設定してしまうと、過剰な増設により遊休したサーバが増えてしまった結果、サーバのリソース利用率が悪くなり、余分なコスト増を招いてしまう。
【０００７】
そこで、本発明は、トラフィック量に見合うサーバの増設処理を円滑に実現することを、主な課題とする。
【課題を解決するための手段】
【０００８】
前記課題を解決するために、本発明の品質制御装置は、
トラフィック処理システムが処理するトラフィック量の推移を収集する通信状況収集部と、
前記通信状況収集部が収集したトラフィック量が増設閾値を超過したときに前記トラフィック処理システムの処理能力を増設すると判定し、その増設を開始する時点から増設を終了する時点までの増設期間を求める増設処理部と、
前記増設処理部が前記増設期間におけるトラフィック量の推移を予測し、その予測結果において増設を終了する時点までに増設前の処理能力を超過するトラフィック量を求め、その超過するトラフィック量に相当する抑制するトラフィック量の分を、増設を終了する時点までに前記トラフィック処理システムが処理するトラフィック量から抑制するように制御する抑制処理部と、を有することを特徴とする。
【０００９】
これにより、増設期間中に超過するであろうトラフィック量を事前に見積もり、そのトラフィック量の分だけ抑制することで、トラフィック量に見合うサーバの増設処理を円滑に実現することができる。
【００１０】
本発明は、前記抑制処理部が、前記通信状況収集部が収集した現在のトラフィック量が前記増設前の処理能力に基づく抑制閾値を超過したときに、前記抑制するトラフィック量とは別に、所定量のトラフィック量を抑制することを特徴とする。
【００１１】
これにより、事前に見積もったトラフィック量の範囲外となる突発的なトラフィック量の増加に対しても、トラフィック処理システムを保護することができる。
【００１２】
本発明は、前記抑制処理部が、前記抑制するトラフィック量の分について、既に送信したトラフィック量のバッファ量が所定範囲に収まるように、抑制する期間と、抑制しない期間とを決定することを特徴とする。
【００１３】
これにより、トラフィック量の抑制中であってもバッファ量を消化するので、ユーザ体験の低下を感じさせずに済む。
【００１４】
本発明は、前記トラフィック処理システムが、複数のユーザのトラフィック量を処理しており、
前記抑制処理部が、前記抑制するトラフィック量の分を複数のユーザに等分して、抑制する各ユーザのトラフィック量を求めることを特徴とする。
【００１５】
これにより、複数のユーザに対して平等にトラフィック量を抑制することで、特定のユーザに不満が集中することを予防できる。
【００１６】
本発明は、前記トラフィック処理システムが、複数のユーザのトラフィック量を処理しており、
前記抑制処理部が、前記抑制するトラフィック量の分を複数のユーザに割り当てるときに、各ユーザのトラフィック量に比例して、抑制する各ユーザのトラフィック量を求めることを特徴とする。
【００１７】
これにより、現在利用しているサービスのトラフィック量に応じて、各ユーザのトラフィック量を抑制することで、どのユーザであっても抑制後に最低限のサービスを受けることができる。
【発明の効果】
【００１８】
本発明によれば、トラフィック量に見合うサーバの増設処理を円滑に実現することができる。
【図面の簡単な説明】
【００１９】
【図１】本実施形態に係わる品質制御システムの構成図である。
【図２】本実施形態に係わる管理サーバの構成図である。
【図３】本実施形態に係わる品質制御処理のフローチャートである。
【図４】図４（ａ）は、増設中のユーザ数超過状況を示すグラフである。図４（ｂ）は、増設開始時刻でのユーザ数予測結果を示すグラフである。
【図５】図５（ａ）は、従来の技術における、超過ユーザの規制処理を示すグラフである。図５（ｂ）は、従来の技術における、増設期間の前倒し処理を示すグラフである。
【図６】図６（ａ）は、予測ベースの品質制御処理を示すグラフである。図６（ｂ）は、実測ベースの品質制御処理を示すグラフである。
【図７】本実施形態に係わる視聴端末のバッファ量に着目した品質制御処理を示すグラフである。
【発明を実施するための形態】
【００２０】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【００２１】
図１は、品質制御システムの構成図である。品質制御システムは、配信サーバ１と、視聴端末２と、管理サーバ３とがネットワークで接続されて構成される。
なお、品質制御システムの各装置は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、後記する各処理部により構成される制御部（制御手段）を動作させる。
以下では、品質制御システムの一例として、コンテンツを配信するコンテンツ配信システムを例示するが、銀行のトランザクション処理システムなど、トラフィック量が時間とともに変動するような任意のトラフィック処理システムに適用可能である。
【００２２】
各配信サーバ１は、各視聴端末２に対して視聴データのトラフィックを配信する。例えば、ライブストリーミング配信は、配信番組の時間帯のうちの特定の時間帯にだけ、各視聴端末２からの視聴要求とその要求に伴うトラフィックが増大する。特定の時間帯とは、例えば、番組開始時点や、目玉となるアーティストの登場シーン時点などである。なお、ライブストリーミング配信は、“今見ること”に価値があるため、録画配信のように、互いのユーザの配信時間を大きくずらして負荷分散することは難しい。
【００２３】
そこで、管理サーバ（品質制御装置）３は、トラフィック増加に伴うシステムの性能不足に対して、システムサイズの柔軟な拡張（配信サーバ１の増設）ができるように、各配信サーバ１を管理する。配信サーバ１の増設とは、作業員が筐体を新たに設置して接続する物理的増設でもよいし、クラウドや仮想化技術を用いて、仮想化した計算機資源を新たに利用可能にする論理的増設でもよい。
【００２４】
しかし、物理的増設であっても、論理的増設であっても、配信サーバ１の増設期間が最短でも分単位の時間を要するため、配信サーバ１のトラフィック量が増大したことを観測してから増設開始を指示しても、その増設期間が完了するまでの間に、システム性能が不足してしまうこともある。
そこで、管理サーバ３は、増大するトラフィック量に対するシステム性能不足を解消する手段として、配信サーバ１の増設という長期的な手段と、増設期間におけるトラフィック量の抑制制御という短期的な手段とを併用する。
【００２５】
管理サーバ３は、トラフィック量の抑制制御において、配信サーバ１に対して既に提供されているトラフィック量を抑制するようにサービスの品質を低下させる。ここで、システム性能が不足する増設期間だけしのげればよいので、管理サーバ３は、増設期間におけるシステム性能不足によるトラフィック量の超過量分を求め、その超過量分だけ（必要な量だけ）の品質低下に留めることで、配信サーバ１のシステム動作を保護しつつ、視聴端末２のユーザに対してあまりサービス品質の低下を感じさせずに済む。
【００２６】
図２は、管理サーバ３の構成図である。
管理サーバ３は、通信状況収集部３１と、抑制判定部３２と、抑制指示部３３と、増設判定部３４と、増設指示部３５とを含めて構成される。
抑制処理部は、抑制判定部３２と抑制指示部３３とで構成される。
増設処理部は、増設判定部３４と増設指示部３５とで構成される。
【００２７】
通信状況収集部３１は、配信サーバ１が視聴端末２に配信しているトラフィックの情報を収集する（Ｓ１１）。収集されるトラフィック情報は、例えば、視聴端末２に流すトラフィック量の推移の他に、そのトラフィックを受信する視聴端末２のユーザ数や、ＣＰＵ利用率、メモリ利用率、ネットワークインタフェース利用率などのトラフィックの伝送に使用されるリソース利用率である。
【００２８】
抑制判定部３２は、通信状況収集部３１が収集したトラフィック情報の各パラメータ値が、トラフィックの処理落ちが発生する可能性が高い水準を示す所定閾値（抑制閾値）を超過したときには、抑制指示部３３に対してトラフィック量の抑制制御を指示する旨の抑制モードをオンにする（Ｓ１２）。その後、収集されたトラフィック情報の各パラメータ値が所定閾値（抑制閾値）を下回ったときには、抑制指示部３３に対して抑制モードをオフに戻す。
【００２９】
抑制指示部３３は、抑制判定部３２が抑制モードをオンにしたことなどを契機として、配信サーバ１に対してトラフィック量の抑制を指示する（Ｓ１３）。なお、Ｓ１３の指示をする契機は、「抑制モードをオンであり、かつ、増設期間中であるとき」としてもよいし、「増設期間中であるとき」としてもよい。
そのため、抑制指示部３３は、どのユーザに対して、いつ、どの程度のトラフィック量を抑制するかというＳ１３の具体的な指示内容を計算する。
【００３０】
増設判定部３４は、通信状況収集部３１が収集したトラフィック情報の各パラメータ値が、今後のトラフィック量増加に伴いシステム性能不足が発生する可能性が高い水準を示す所定閾値（増設閾値）を超過したときには、増設指示部３５に対して配信サーバ１の増設を指示する（Ｓ１４）。
増設指示部３５は、Ｓ１４の指示に従い、新たに配信サーバ１を増設する（Ｓ１５）。ここで、増設指示部３５は、増設開始時点や増設終了時点などの増設期間を特定する情報を抑制指示部３３に通知する（Ｓ１６）ことで、抑制指示部３３がＳ１３の指示を行う支援をする。
【００３１】
図３は、品質制御処理のフローチャートである。適宜図２のＳ１１〜Ｓ１６を参照しつつ、図３を説明する。
Ｓ１０１として、抑制判定部３２は、Ｓ１２で抑制モードをオンにする。
Ｓ１０２として、抑制指示部３３は、Ｓ１３で指示する抑制内容（抑制方法）を事前準備する。この事前準備の詳細は、図４以降の説明で明らかにする。
Ｓ１１１として、増設指示部３５がＳ１６の指示により、現在が増設期間中か否かを判定する。Ｓ１１１でＹｅｓならＳ１２１に進み、ＮｏならＳ１１２に進む。
【００３２】
Ｓ１１２として、抑制判定部３２は、Ｓ１１４の増設開始前に通信状況収集部３１が収集した現在のトラフィック量により、通信状況が改善しているか否かを判定する。トラフィック量がＳ１２の抑制閾値を下回るときには（Ｓ１１２，Ｙｅｓ）、抑制モードをオフに戻す。一方、Ｓ１１２でＮｏなら、Ｓ１１３に進む。
Ｓ１１３として、増設判定部３４は、Ｓ１４の増設指示が必要か否かを判定する。Ｓ１１３でＹｅｓならＳ１１４に進み、ＮｏならＳ１２１に進む。
Ｓ１１４として、増設指示部３５は、配信サーバ１の増設を指示する（Ｓ１５）ことで、増設を開始する。併せて、増設指示部３５は、増設期間を特定する情報を抑制指示部３３に通知する（Ｓ１６）。
【００３３】
Ｓ１２１として、抑制指示部３３は、図１で説明したように、システム性能不足によるトラフィック量の超過量分（抑制分トラフィック量）を、抑制対象ユーザで分配することで、抑制を開始する。
抑制対象ユーザは、例えば配信サーバ１に接続が済んでいる既存ユーザ、これから配信サーバ１に接続しようとする新規ユーザ、または、配信サーバ１が収容する既存ユーザと新規ユーザとの両方（全ユーザ）、所定の地域（ロケーション）を担当する配信サーバ１が収容するユーザ、有料会員のユーザ、無料会員のユーザなど、サービスによって様々である。
なお、抑制対象ユーザのトラフィックとは、例えば、ユーザが接続する呼でもよいし、ユーザのトランザクションでもよい。
【００３４】
なお、一人の抑制対象ユーザあたりの抑制分のトラフィック量は、例えば、以下に例示する計算式のいずれかにより求めることができる。
・（１ユーザあたりの抑制分）＝（抑制分トラフィック量に依存しない固定値）
・（１ユーザあたりの抑制分）＝（抑制分トラフィック量）÷（抑制対象ユーザ数）
・（１ユーザあたりの抑制分）＝（抑制分トラフィック量）÷（抑制対象ユーザ数）×（１ユーザあたりの配信レートの比率に基づく乗数）。この乗数は、例えば、抑制対象ユーザごとの配信レートに比例する。つまり、トラフィック量が多いユーザほど、多くのトラフィック量を抑制する。
【００３５】
また、抑制分トラフィック量を元にした配信サーバ１から視聴端末２へのトラフィック量の抑制制御は、例えば、映像データのトラフィック量を抑制する場合は、配信サーバ１が低下させた配信レートに見合った圧縮率で映像をエンコードしてから、そのエンコード映像を視聴端末２に配信する処理である。
【００３６】
Ｓ１２２として、通信状況収集部３１は、Ｓ１１２と同様にして、現在の通信状況改善が改善したか否かを判定する。Ｓ１２２でＹｅｓなら、Ｓ１２２の抑制を終了し（Ｓ１２３）、抑制モードをオフに戻す。一方、Ｓ１２２でＮｏならＳ１３１に進む。
Ｓ１３１として、増設指示部３５は、Ｓ１１４で開始した増設の完了を確認する。Ｓ１３２として、抑制指示部３３は、Ｓ１２１で開始した抑制の終了を確認し、処理をＳ１１１に戻す。
【００３７】
以下、図４〜図７を参照して、どのユーザに対して、いつ、どの程度のトラフィック量を抑制するかというＳ１３の具体的な抑制指示部３３の指示内容を説明する。
【００３８】
図４（ａ）は、増設中のユーザ数超過状況を示すグラフである。
通信状況収集部３１は、実ユーザ数推移Ｎ［ｔ］を収集する。抑制判定部３２は、Ｎ［ｔ］をもとに予想ユーザ数推移Ｎｚ［ｔ］を予測する。Ｎｚ［ｔ］もＮ［ｔ］も、ｔ１１においてユーザ数増設閾値Ｎｔｈを超過する。よって、増設判定部３４は、増設開始時刻ｔ１１を決定し、そのｔ１１から増設終了時刻ｔ１２までの期間を増設期間とする。
【００３９】
ここで、全配信サーバ１のシステム処理能力は、ｔ１２までは増設前処理可能ユーザ数Ｎｃａであり、ｔ１２からは増設後処理可能ユーザ数Ｎｃｂに増加する。Ｎｚ［ｔ］に示すように、システム処理能力を超えないようにユーザ数が推移するときには、増設だけ行えば問題ない。
しかし、Ｎ［ｔ］に示すように、増設期間中（時刻ｔ２〜ｔ１２）にシステム処理能力を超えるユーザ数が発生した場合、Ｎｃａからの超過分のユーザ数分のトラフィックが処理されない恐れがある（図では、処理されないユーザ数を領域Ｎｅで示す）。
【００４０】
図４（ｂ）は、増設開始時刻でのユーザ数予測結果を示すグラフである。
抑制判定部３２は、ｔ１１の時点で増設期間のユーザ数推移を予測する。この予測結果は、例えば、グラフ点Ｐ１（ｔ１１，Ｎｔｈ）を起点とした半直線であり、その傾きが大きい順に、Ｎ１［ｔ］、Ｎ２［ｔ］、Ｎ３［ｔ］となる。このユーザの増加率を示すグラフの傾きは、予測時点ｔ１１以前のＮ［ｔ］の推移（時系列での差分）から求めることができる。
【００４１】
ここで、抑制判定部３２は、以下に示すように、抑制期間前後のトラフィック量の処理能力と、抑制期間におけるトラフィック量推移とをもとに、処理能力からの超過分を予測する。Ｎ２［ｔ］が通過する点Ｐ２（ｔ１２，Ｎｃａ）は、増設期間中にユーザ数が処理能力を超過するか否かを判断するための境界となる点である。つまり、Ｎ２［ｔ］よりも傾きが大きい（ユーザ数の増分が大きい）Ｎ１［ｔ］は、処理能力を超過すると判定される。一方、Ｎ２［ｔ］よりも傾きが小さいＮ３［ｔ］は、処理能力を超過しないと判定される。
処理能力を超過すると判定されたＮ１［ｔ］について、その超過ユーザ数を示す領域Ｎｅは、３つの頂点（Ｐ２，Ｐ３，Ｐ４）が形成する三角形の面積として近似される。なお、点Ｐ３（ｔ２，Ｎｃａ）であり、点Ｐ４（ｔ１２，Ｎ１［ｔ１２］）である。点Ｐ５（ｔ１２，Ｎｔｈ）は、図６の説明で用いる。
【００４２】
図５（ａ）は、従来の技術における、超過ユーザの規制処理を示すグラフである。規制前のユーザ数推移をＮａ［ｔ］とし、規制後のユーザ数推移をＮｂ［ｔ］とする。超過期間中（ｔ２〜ｔ１２）には、ユーザ数が処理能力を超過してしまう（Ｎａ［ｔ２］〜Ｎａ［ｔ１２］＞Ｎｃａ）。そこで、配信サーバ１は、超過期間中（ｔ２〜ｔ１２）の新規接続を受け付けないように規制をかけることで（Ｎｂ［ｔ２］〜Ｎｂ［ｔ１２］＝Ｎｃａ）、増設後の処理能力の補充が現時点で間に合わないことによる処理落ちを避ける。しかし、新規接続を受け付けないという強制的な規制では、新規のユーザの獲得機会を失ってしまう。
【００４３】
図５（ｂ）は、従来の技術における、増設期間の前倒し処理を示すグラフである。以下、図４（ａ）と図５（ｂ）とを比較しつつ、説明する。図５（ｂ）では、ユーザ数増設閾値Ｎｔｈを図４（ａ）よりも低く設定することで、増設判定部３４がトラフィック量の増加初期を検知し、増設期間を前倒しできる（ｔ１１より前のｔ３１，ｔ１２より前のｔ３２）。
これにより、Ｎ［ｔ］が処理能力を超過するレベルにまで増加する前に、増設終了時刻ｔ３２をむかえることができる。しかし、増設期間を前倒しする副作用として、Ｎｚ［ｔ］のように推移してしまうと、システム処理能力の過剰な余裕ができてしまい、リソースの利用効率が低下してしまう。
【００４４】
図６（ａ）は、予測ベースの品質制御処理を示すグラフである。図４、図５との違いとして、Ｙ軸をユーザ数からトラフィック量へと変更している。ユーザ数からトラフィック量への変換は、例えば、計算式「（トラフィック量）＝（ユーザ数）×（１ユーザあたりの平均配信レート）」により求めることができる。
管理サーバ３の処理能力は、増設終了時刻ｔ１２までは増設前処理可能トラフィック量Ｔｃａであり、増設終了時刻ｔ１２からは増設後処理可能トラフィック量Ｔｃｂに増加する。例えば、Ｔｃａ＝Ｎｃａ×（１ユーザあたりの平均配信レート）である。
抑制前トラフィック量推移Ｔａ［ｔ］では、増設前処理可能トラフィック量Ｔｃａを超過する期間（ｔ２〜ｔ１２）において、超過分（頂点P2,P3,P4に囲まれた三角形Ｔｅの面積）が発生してしまう。
【００４５】
抑制後トラフィック量推移Ｔｂ［ｔ］は、超過期間（ｔ２〜ｔ１２）において、Ｔａ［ｔ］よりも低いトラフィック量を流すように、品質制御処理を実行する。ここで、Ｔｂ［ｔ］の抑制量（頂点P1,P2,P3に囲まれた三角形Ｔｆの面積）を、三角形Ｔｅの面積以上にする必要があるが、抑制量をなるべく小さくしてユーザの視聴体験の低下を最小限に抑えるために、三角形Ｔｆの面積＝三角形Ｔｅの面積となるようにＴｂ［ｔ］を設定することが望ましい。
このように、増設期間中の超過量Ｔｅを事前に見積もり、その超過量Ｔｅと同量だけの抑制量Ｔｆを設けることにより、増設完了予想時刻から逆算して、低下させる質を最低限に抑えられる。
【００４６】
図６（ｂ）は、実測ベースの品質制御処理を示すグラフである。図６（ａ）の予測ベースで超過分を予め抑制したとしても、予測外の突発的なトラフィック量の増加が発生することもある。
そこで、突発的なトラフィック量の増加から配信サーバ１のシステムを保護するために、Ｔｔｈ〜Ｔｃａの間に、トラフィック量抑制閾値Ｔｔｂを設けることで、Ｔｔｂ〜Ｔｃａの範囲をトラフィックを緊急に抑制する必要がある「抑制ゾーン」とし、その抑制ゾーン外の「通常ゾーン」と区別する。
そして、抑制指示部３３は、Ｔａ［ｔ］が「抑制ゾーン」内に推移したときには、Ｔｃａを超過しないために、Ｔｂ［ｔ］へと所定量のトラフィック量を下げるように、図６（ａ）で求めた抑制量Ｔｆとは別に、品質制御処理を強制的に実行する。つまり、抑制ゾーンとは、強制的にトラフィック量を下げる必要のある緊急領域である。
【００４７】
図７は、視聴端末２のバッファ量に着目した品質制御処理を示すグラフである。
抑制指示部３３は、Ｓ１２１で説明した（１ユーザあたりの抑制分）を、１ユーザのバッファ量に応じて、動的に変化させてもよい。
バッファ量推移Ｂ［ｔ］は、視聴端末２のうちの所定の１端末に着目したときのその端末に貯蓄されているデータ量（バッファ量）である。なお、視聴端末２のメモリの大きさなどにより、Ｂ［ｔ］の最大値となるバッファ最大容量Ｂｃはあらかじめ決まっている。
視聴端末２は、時間経過にしたがって、バッファ量を消化して（読み込んで）受信したトラフィックをデコードし、その結果を視聴画面で再生する。つまり、Ｂ［ｔ］は再生用に読み込む度に減少しつつ、配信サーバ１から受信する度に増加する。
【００４８】
抑制指示部３３は、以下のルールに従って、バッファ量を参照しつつ現時点でのトラフィック量を決定する。
・バッファ量が多いときには（Ｂ［ｔ］＞バッファ量上限閾値Ｂｔｂ）、トラフィック量を下げる（時刻ｔ４１で抑制処理を開始するなど）。
・バッファ量が少ないときには（Ｂ［ｔ］＜バッファ量下限閾値Ｂｔａ）、トラフィック量を上げる（時刻ｔ４２で抑制処理を中断するなど）。
・トラフィック量を下げる分（抑制量）の全ユーザの総和が、図６の超過量Ｔｅ以上となるように、トラフィック量を下げる。
つまり、抑制指示部３３は、バッファ量Ｂ［ｔ］が所定範囲（バッファ量上限閾値Ｂｔｂ〜バッファ量下限閾値Ｂｔａ）に収まるように、トラフィック量を抑制する期間と、抑制しない期間とを決定する。
【００４９】
これにより、トラフィック量の抑制中であってもバッファ量を消化して再生するので、ユーザの視聴体験の低下を感じさせずに済む。さらに、ｔ４１〜ｔ４２で例示した品質抑制期間は、複数のユーザで互いに重複するように設けてもよいし（並列処理）、重複しないように（ユーザ順繰りに規制するように）設けてもよいし（直列処理）。
【００５０】
以上説明した本実施形態では、視聴端末２が急激に増加したとしても、配信サーバ１を増設するまでの期間で、抑制指示部３３が配信サーバ１を保護しつつ、かつ、視聴端末２のサービス品質の低下がなるべく小さくて済むように、適切な抑制量Ｔｆを計算する（図６（ａ）参照）。
これにより、ストリーミング配信システムにおいて、システム全体の配信レートを多少は低下させるものの、配信レートの低下に伴う影響を抑えつつ、増設期間が完了するまでの不安定な期間を乗り越えることができる。
【符号の説明】
【００５１】
１      配信サーバ
２      視聴端末
３      管理サーバ（品質制御装置）
３１    通信状況収集部
３２    抑制判定部
３３    抑制指示部
３４    増設判定部
３５    増設指示部
【図１】
0006353417.tif 000002
【図２】
0006353417.tif 000003
【図３】
0006353417.tif 000004
【図４】
0006353417.tif 000005
【図５】
0006353417.tif 000006
【図６】
0006353417.tif 000007
【図７】
0006353417.tif 000008