(57)【要約】【課題】配信するコンテンツがユニキャスト配信とマルチキャスト配信との両方の配信方式でそれぞれ配信可能なときに、適切な配信方式を選択すること。【解決手段】コンテンツ配信システムの接続制御サーバ１が、配信サーバ３からユーザ端末６へコンテンツデータの配信数データ、配信サーバ３内の負荷データ、および、前記新規の配信要求数データのうちの少なくとも１つのデータを、負荷情報として時系列で取得し、その取得した時系列の負荷情報の単位時間あたりの変化量を示す負荷微分値が、所定しきい値より大きいときには配信方式をマルチキャスト配信とし、所定しきい値より大きくないときには配信方式をユニキャスト配信として選択し、その選択したコンテンツＩＤごとの配信方式を接続制御サーバ１内の配信方式記憶部１４へと記憶する。【選択図】図１
2012165236.tif 000002
【特許請求の範囲】
【請求項１】
配信サーバからユーザ端末へコンテンツデータを配信するときに、その配信方式としてユニキャスト配信およびマルチキャスト配信のうちのいずれかの前記配信方式を選択可能なコンテンツ配信システムであって、
前記コンテンツ配信システムの接続制御サーバは、
前記配信サーバから前記ユーザ端末へ前記コンテンツデータの配信数データ、前記配信サーバ内の負荷データ、および、新規の配信要求数データのうちの少なくとも１つのデータを、負荷情報として時系列で取得し、
その取得した時系列の負荷情報の単位時間あたりの変化量を示す負荷微分値が、所定しきい値より大きいときには前記配信方式をマルチキャスト配信とし、所定しきい値より大きくないときには前記配信方式をユニキャスト配信として選択し、その選択したコンテンツＩＤごとの前記配信方式を前記接続制御サーバ内の配信方式記憶部へと記憶し、
前記ユーザ端末から前記コンテンツＩＤを指定した新規の配信要求を受けつけると、前記配信方式記憶部内に記憶されている前記コンテンツＩＤごとの前記配信方式を読み取って、その読み取った前記配信方式に従って、前記新規の配信要求に対応する前記コンテンツデータの配信を開始することを特徴とする
コンテンツ配信システム。
【請求項２】
前記接続制御サーバは、
前記接続制御サーバ内の前記配信方式記憶部へと記憶する前記配信方式を決定する処理において、前記負荷微分値が所定しきい値より大きいか否かを判定する負荷判定式に加えて、取得した前記時系列の負荷情報のうちの負荷現在値が所定しきい値より大きいか否かを判定する前記負荷判定式、および、取得した前記時系列の負荷情報の所定期間における負荷の積分値が所定しきい値より大きいか否かを判定する前記負荷判定式をそれぞれ用いて負荷判定し、
複数の前記負荷判定式それぞれの負荷判定結果をもとに、前記コンテンツＩＤごとの前記配信方式を決定することを特徴とする
請求項１に記載のコンテンツ配信システム。
【請求項３】
前記接続制御サーバは、
複数の前記負荷判定式それぞれの負荷判定結果をもとに、前記コンテンツＩＤごとの前記配信方式を決定する処理において、
複数の前記負荷判定式で全て高負荷と判定したときに、前記コンテンツＩＤごとの前記配信方式をマルチキャスト配信とする第１判定処理、
複数の前記負荷判定式のうちの少なくとも１つで高負荷と判定したときに、前記コンテンツＩＤごとの前記配信方式をマルチキャスト配信とする第２判定処理、
前記第１判定処理および前記第２判定処理のうちの少なくとも１つで高負荷と判定したときに、前記コンテンツＩＤごとの前記配信方式をマルチキャスト配信とする第３判定処理のうちのいずれかの処理により実現されることを特徴とする
請求項２に記載のコンテンツ配信システム。
【請求項４】
前記接続制御サーバは、
複数の前記負荷判定式それぞれの負荷判定結果をもとに、前記コンテンツＩＤごとの前記配信方式を決定する処理において、前記第１判定処理、前記第２判定処理、および、前記第３判定処理のうちのいずれの判定処理を採用するかを、前記新規の配信要求ごとに順番に選択するラウンドロビンのアルゴリズムにより決定されることを特徴とする
請求項３に記載のコンテンツ配信システム。
【請求項５】
前記接続制御サーバは、
前記決定したコンテンツＩＤごとの前記配信方式を前記接続制御サーバ内の前記配信方式記憶部へと記憶する処理において、前記コンテンツＩＤごとに、その配信方式を採用するために用いられた前記第１判定処理、前記第２判定処理、および、前記第３判定処理のうちのいずれの判定処理を行ったかを示す情報を対応づけて記憶し、
前記配信方式記憶部を参照して、マルチキャスト配信を採用した配信数と、ユニキャスト配信を採用した配信数との配信比率を前記判定処理ごとに計算し、その配信比率が所定しきい値以上であるときには、その所定しきい値以上である配信比率に対応する判定処理を採用することを特徴とする
請求項３に記載のコンテンツ配信システム。
【請求項６】
配信サーバからユーザ端末へコンテンツデータを配信するときに、その配信方式としてユニキャスト配信およびマルチキャスト配信のうちのいずれかの前記配信方式を選択可能なコンテンツ配信システムによるコンテンツ配信方法であって、
前記コンテンツ配信システムの接続制御サーバは、
前記配信サーバから前記ユーザ端末へ前記コンテンツデータの配信数データ、前記配信サーバ内の負荷データ、および、前記新規の配信要求数データのうちの少なくとも１つのデータを、負荷情報として時系列で取得し、
その取得した時系列の負荷情報の単位時間あたりの変化量を示す負荷微分値が、所定しきい値より大きいときには前記配信方式をマルチキャスト配信とし、所定しきい値より大きくないときには前記配信方式をユニキャスト配信として選択し、その選択したコンテンツＩＤごとの前記配信方式を前記接続制御サーバ内の配信方式記憶部へと記憶し、
前記ユーザ端末から前記コンテンツＩＤを指定した前記新規の配信要求を受けつけると、前記配信方式記憶部内に記憶されている前記コンテンツＩＤごとの前記配信方式を読み取って、その読み取った前記配信方式に従って、前記新規の配信要求に対応する前記コンテンツデータの配信を開始することを特徴とする
コンテンツ配信方法。
【請求項７】
前記接続制御サーバは、
前記接続制御サーバ内の前記配信方式記憶部へと記憶する前記配信方式を決定する処理において、前記負荷微分値が所定しきい値より大きいか否かを判定する負荷判定式に加えて、取得した前記時系列の負荷情報のうちの負荷現在値が所定しきい値より大きいか否かを判定する前記負荷判定式、および、取得した前記時系列の負荷情報の所定期間における負荷の積分値が所定しきい値より大きいか否かを判定する前記負荷判定式をそれぞれ用いて負荷判定し、
複数の前記負荷判定式それぞれの負荷判定結果をもとに、前記コンテンツＩＤごとの前記配信方式を決定することを特徴とする
請求項６に記載のコンテンツ配信方法。
【請求項８】
前記接続制御サーバは、
複数の前記負荷判定式それぞれの負荷判定結果をもとに、前記コンテンツＩＤごとの前記配信方式を決定する処理において、
複数の前記負荷判定式で全て高負荷と判定したときに、前記コンテンツＩＤごとの前記配信方式をマルチキャスト配信とする第１判定処理、
複数の前記負荷判定式のうちの少なくとも１つで高負荷と判定したときに、前記コンテンツＩＤごとの前記配信方式をマルチキャスト配信とする第２判定処理、
前記第１判定処理および前記第２判定処理のうちの少なくとも１つで高負荷と判定したときに、前記コンテンツＩＤごとの前記配信方式をマルチキャスト配信とする第３判定処理のうちのいずれかの処理により実現されることを特徴とする
請求項７に記載のコンテンツ配信方法。
【請求項９】
前記接続制御サーバは、
複数の前記負荷判定式それぞれの負荷判定結果をもとに、前記コンテンツＩＤごとの前記配信方式を決定する処理において、前記第１判定処理、前記第２判定処理、および、前記第３判定処理のうちのいずれの判定処理を採用するかを、前記新規の配信要求ごとに順番に選択するラウンドロビンのアルゴリズムにより決定されることを特徴とする
請求項８に記載のコンテンツ配信方法。
【請求項１０】
前記接続制御サーバは、
前記決定したコンテンツＩＤごとの前記配信方式を前記接続制御サーバ内の前記配信方式記憶部へと記憶する処理において、前記コンテンツＩＤごとに、その配信方式を採用するために用いられた前記第１判定処理、前記第２判定処理、および、前記第３判定処理のうちのいずれの判定処理を行ったかを示す情報を対応づけて記憶し、
前記配信方式記憶部を参照して、マルチキャスト配信を採用した配信数と、ユニキャスト配信を採用した配信数との配信比率を前記判定処理ごとに計算し、その配信比率が所定しきい値以上であるときには、その所定しきい値以上である配信比率に対応する判定処理を採用することを特徴とする
請求項８に記載のコンテンツ配信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ配信システム、および、コンテンツ配信方法の技術に関する。
【背景技術】
【０００２】
コンテンツ配信システムは、配信するコンテンツを管理する配信サーバから、コンテンツを希望するユーザ端末へと、ネットワークを介してコンテンツを配信する。コンテンツの配信方式には、１台のユーザ端末ごとに配信するユニキャスト配信と、複数台のユーザ端末にまとめて配信するマルチキャスト配信とがそれぞれ運用されている。
マルチキャスト配信は、複数台のユーザ端末に対して１回の配信処理を行うだけで済むので、ネットワークの資源を効率よく使用でき、通信効率がよい。
【０００３】
そこで、特許文献１には、既に配信を開始している複数のユニキャスト配信について、それらを１つに束ねてマルチキャスト配信へと切り替える手法が、提案されている。そのとき、ユニキャスト配信からマルチキャスト配信への切替の前後でコンテンツ配信（再生）が途切れないように、複数台のユーザ端末それぞれに対して、既に配信されたコンテンツデータと、未配信のコンテンツデータとの配信状況を調査し、マルチキャスト配信への切替時に未配信のコンテンツデータが無い（再生が途切れない）ように、切替時刻を決定している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−８０５６６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、コンテンツ配信システムにおいて、配信するコンテンツがユニキャスト配信とマルチキャスト配信との両方の配信方式でそれぞれ配信可能なときに、いずれの配信方式を選択するべきかを決定する手法は、提案されていない。
【０００６】
前記したように、マルチキャスト配信を選択すると、通信効率がよい反面、マルチキャスト配信が可能なユーザ端末の数に制限がある。例えば、マルチキャストの配信ルータでは、配信先のユーザ端末へ配信するコンテンツデータのコピー処理が発生するが、そのコピー処理の負荷は、配信先のユーザ端末の数に応じて増加する。さらに、マルチキャストの配信ルータでは、マルチキャスト配信ツリーの状態管理用の制御処理を行うが、その制御処理の負荷も、配信先のユーザ端末の数に応じて増加する。
【０００７】
よって、マルチキャスト配信を選択する必要がない（または、効果が薄い）状況では、ユニキャスト配信を選択することで、マルチキャストの配信ルータの負荷を軽減することが有効である。例えば、マルチキャスト配信を選択する動機は、コンテンツ配信にかかる通信負荷や装置負荷の軽減であるので、現時点でそれらの負荷があまり発生していないときには、ユニキャスト配信を選択するほうがよい。
【０００８】
つまり、時々刻々と変化するコンテンツ配信システムの負荷状況に応じて、それに適した配信方式を自動的に選択するシステムが求められる。さらに、現在の負荷状況が高負荷になってしまってから配信方式を決定すると、マルチキャスト配信を選択したとしても事後処理になってしまうので、配信方式の選択は、将来の負荷状況を高精度で予測してから、その予測を元に決定することが、望ましい。
【０００９】
そこで、本発明は、配信するコンテンツがユニキャスト配信とマルチキャスト配信との両方の配信方式でそれぞれ配信可能なときに、適切な配信方式を選択することを、主な目的とする。
【課題を解決するための手段】
【００１０】
前記課題を解決するために、本発明は、配信サーバからユーザ端末へコンテンツデータを配信するときに、その配信方式としてユニキャスト配信およびマルチキャスト配信のうちのいずれかの前記配信方式を選択可能なコンテンツ配信システムであって、前記コンテンツ配信システムの接続制御サーバが、前記配信サーバから前記ユーザ端末へ前記コンテンツデータの配信数データ、前記配信サーバ内の負荷データ、および、前記新規の配信要求数データのうちの少なくとも１つのデータを、負荷情報として時系列で取得し、その取得した時系列の負荷情報の単位時間あたりの変化量を示す負荷微分値が、所定しきい値より大きいときには前記配信方式をマルチキャスト配信とし、所定しきい値より大きくないときには前記配信方式をユニキャスト配信として選択し、その選択したコンテンツＩＤごとの前記配信方式を前記接続制御サーバ内の配信方式記憶部へと記憶し、前記ユーザ端末から前記コンテンツＩＤを指定した前記新規の配信要求を受けつけると、前記配信方式記憶部内に記憶されている前記コンテンツＩＤごとの前記配信方式を読み取って、その読み取った前記配信方式に従って、前記新規の配信要求に対応する前記コンテンツデータの配信を開始することを特徴とする。
【００１１】
これにより、配信するコンテンツがユニキャスト配信とマルチキャスト配信との両方の配信方式でそれぞれ配信可能なときに、将来の負荷の変化を先取りして、ネットワークリソースを有効活用できるように、適切な配信方式を選択することができる。
【００１２】
本発明は、前記接続制御サーバが、前記接続制御サーバ内の前記配信方式記憶部へと記憶する前記配信方式を決定する処理において、前記負荷微分値が所定しきい値より大きいか否かを判定する負荷判定式に加えて、取得した前記時系列の負荷情報のうちの負荷現在値が所定しきい値より大きいか否かを判定する前記負荷判定式、および、取得した前記時系列の負荷情報の所定期間における負荷の積分値が所定しきい値より大きいか否かを判定する前記負荷判定式をそれぞれ用いて負荷判定し、複数の前記負荷判定式それぞれの負荷判定結果をもとに、前記コンテンツＩＤごとの前記配信方式を決定することを特徴とする。
【００１３】
これにより、変化が急激な時系列の負荷情報を扱うときでも、適切な配信方式を選択することができる。
【００１４】
本発明は、前記接続制御サーバが、複数の前記負荷判定式それぞれの負荷判定結果をもとに、前記コンテンツＩＤごとの前記配信方式を決定する処理において、複数の前記負荷判定式で全て高負荷と判定したときに、前記コンテンツＩＤごとの前記配信方式をマルチキャスト配信とする第１判定処理、複数の前記負荷判定式のうちの少なくとも１つで高負荷と判定したときに、前記コンテンツＩＤごとの前記配信方式をマルチキャスト配信とする第２判定処理、前記第１判定処理および前記第２判定処理のうちの少なくとも１つで高負荷と判定したときに、前記コンテンツＩＤごとの前記配信方式をマルチキャスト配信とする第３判定処理のうちのいずれかの処理により実現されることを特徴とする。
【００１５】
これにより、複数の負荷判定式をもとに、配信方式を決定するので、負荷判定の精度が向上する。
【００１６】
本発明は、前記接続制御サーバが、複数の前記負荷判定式それぞれの負荷判定結果をもとに、前記コンテンツＩＤごとの前記配信方式を決定する処理において、前記第１判定処理、前記第２判定処理、および、前記第３判定処理のうちのいずれの判定処理を採用するかを、前記新規の配信要求ごとに順番に選択するラウンドロビンのアルゴリズムにより決定されることを特徴とする。
【００１７】
これにより、特定の判定処理に偏らないので、ユニキャスト配信とマルチキャスト配信とをバランスよく選択させることができる。
【００１８】
本発明は、前記接続制御サーバが、前記決定したコンテンツＩＤごとの前記配信方式を前記接続制御サーバ内の前記配信方式記憶部へと記憶する処理において、前記コンテンツＩＤごとに、その配信方式を採用するために用いられた前記第１判定処理、前記第２判定処理、および、前記第３判定処理のうちのいずれの判定処理を行ったかを示す情報を対応づけて記憶し、前記配信方式記憶部を参照して、マルチキャスト配信を採用した配信数と、ユニキャスト配信を採用した配信数との配信比率を前記判定処理ごとに計算し、その配信比率が所定しきい値以上であるときには、その所定しきい値以上である配信比率に対応する判定処理を採用することを特徴とする。
【００１９】
これにより、マルチキャスト配信を優先的に選択させることで、コンテンツ配信の通信料を効率的に削減できる。
【発明の効果】
【００２０】
本発明によれば、配信するコンテンツがユニキャスト配信とマルチキャスト配信との両方の配信方式でそれぞれ配信可能なときに、適切な配信方式を選択することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の一実施形態に関するコンテンツ配信システムを示す構成図である。
【図２】本発明の一実施形態に関する接続制御サーバおよび配信サーバを示す構成図である。
【図３】本発明の一実施形態に関するユニキャストでの配信処理を示すフローチャートである。
【図４】本発明の一実施形態に関するマルチキャストでの配信処理を示すフローチャートである。
【図５】本発明の一実施形態に関する配信方式の決定処理を示すフローチャートである。
【図６】本発明の一実施形態に関する全一致条件により、配信方式を決定する処理を示すフローチャートである。
【図７】本発明の一実施形態に関する３種類の負荷判定を示す説明図である。
【図８】本発明の一実施形態に関する部分一致条件および複合一致条件により、それぞれ配信方式を決定する処理を示すフローチャートである。
【発明を実施するための形態】
【００２２】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【００２３】
図１は、コンテンツ配信システムを示す構成図である。
コンテンツ配信システムは、接続制御サーバ１と、セッションサーバ２と、配信サーバ３と、ルータ４と、宅内装置５と、ユーザ端末６とがそれぞれネットワークで接続されて構成される。
なお、図１のコンテンツ配信システムを構成する各装置は、ＣＰＵ（Central Processing Unit）とメモリとハードディスク（記憶手段）とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。
【００２４】
図１の装置間の矢印のうちの破線で示す矢印は、コンテンツ配信用の制御データ（ＳＩＰ（Session Initiation Protocol）の信号や、ＲＴＳＰ（Real Time Streaming Protocol）の信号など）の流れを示す。
ユーザ端末６は、ユーザがコンテンツの配信を受ける端末であり、セッションサーバ２を介して、接続制御サーバ１にコンテンツ配信を要求する。この要求メッセージには、少なくともコンテンツＩＤが含まれている。
接続制御サーバ１は、コンテンツ配信の要求を受け、そのコンテンツの配信方式（ユニキャスト配信かマルチキャスト配信か）、および、そのコンテンツの配信元である配信サーバ３を決定する。
そして、接続制御サーバ１は、コンテンツ配信を受けるための接続先の装置（ユニキャスト配信なら配信サーバ３、マルチキャスト配信ならルータ４）を決定し、宅内装置５またはユーザ端末６に返信する（図１では、宅内装置５への返信を示す破線矢印を記載）。
さらに、接続制御サーバ１は、セッションサーバ２を介して、宅内装置５またはユーザ端末６に返信した接続先に対して、新規のコンテンツ配信を指示する。これにより、ユーザ端末６は、新規のコンテンツ配信用の前準備（ユニキャスト配信なら１：１接続、マルチキャスト配信ならグループ参加）を実行することができる。
【００２５】
図１の装置間の矢印のうちの実線太字で示す矢印は、コンテンツデータの流れを示す。
配信サーバ３は、接続制御サーバ１から決定されたコンテンツの配信方式に従い、自身の装置内に格納されているコンテンツデータを、ルータ４から宅内装置５を経由して、ユーザ端末６に配信する。
ユーザ端末６は、配信されたコンテンツを受信すると、そのコンテンツを再生してユーザに鑑賞させる。
【００２６】
図２は、接続制御サーバ１および配信サーバ３を示す構成図である。
【００２７】
配信サーバ３は、負荷測定部３１と、負荷通知部３２と、配信制御部３３と、コンテンツ記憶部３４とを有する。
負荷測定部３１は、自装置の使用率情報（ＣＰＵ使用率、メモリ使用率）を所定の計測契機（例えば、１０秒ごと）に計測し、負荷通知部３２へと通知する。
負荷通知部３２は、負荷測定部３１から通知された自装置の使用率情報、および、配信制御部３３から通知された自装置の配信数を、自装置の負荷情報として、接続制御サーバ１の負荷取得部１１へと所定の通知契機（例えば、６０秒ごと）に通知する。なお、通知契機は、計測契機より長間隔であることが、望ましい。
配信制御部３３は、配信方式決定部１３で決定されて通知された配信方式（ユニキャスト配信またはマルチキャスト配信）に従って、自装置のコンテンツ記憶部３４内に記憶されるコンテンツデータを、ユーザ端末６に向けて配信する。ここで、配信先のアドレスは、ユニキャスト配信のときには配信先のユーザ端末６のアドレスであり、ＩＰｖ４マルチキャスト配信のときにはクラスＤのマルチキャストアドレス（224.0.0.0〜239.255.255.255）であり、ＩＰｖ６マルチキャスト配信のときには、先頭から順に、「マルチキャストプレフィックス（８ビット）＋フラグ（４ビット）＋範囲（４ビット）＋グループＩＤ（１１２ビット）」である。
コンテンツ記憶部３４は、ユーザ端末６に向けて配信されるコンテンツデータを、コンテンツＩＤごとに記憶する格納先である。コンテンツデータは、あらかじめコンテンツサーバ（図示省略）などからダウンロードされている。
【００２８】
接続制御サーバ１は、負荷取得部１１と、負荷判定部１２と、配信方式決定部１３と、配信方式記憶部１４と、接続要求処理部１５と、配信要求数取得部１６とを有する。
【００２９】
【表１】
2012165236.tif 000003
【００３０】
表１は、接続制御サーバ１内の負荷判定に用いられる情報についての一例を示す表である。
負荷取得部１１は、各配信サーバ３（ルータ４でもよい）からの負荷情報の通知に従い、配信サーバ３ごとに、その配信サーバ３から配信されるコンテンツと、そのコンテンツごとの同時接続数などのサーバの負荷情報を時系列で取得する。表１では、配信サーバ３からの負荷情報の一例として、配信サーバ３ごとのＣＰＵ使用率と、メモリ使用率とを示している。
配信要求数取得部１６は、接続要求処理部１５が受けた配信要求数を、接続要求処理部１５から取得して、負荷判定部１２に通知する。表１では、通知する配信要求数の一例として、コンテンツごとの配信要求数の時系列データ（時刻＝ｔ１〜ｔ５）を示している。
【００３１】
負荷判定部１２は、負荷取得部１１が取得した配信サーバ３の負荷情報と、配信要求数取得部１６が取得した配信要求数とを参照して、コンテンツ配信システム内のネットワークが高負荷か低負荷かを判定する。表１では、負荷判定用のパラメータの一例として、配信サーバ３ごとのＣＰＵ使用率と、配信サーバ３ごとの配信数と、通知された配信要求数という３つのパラメータについて、３種類の値（現在値、微分値、積分値）を示している（詳細は、図７）。なお、負荷判定用のパラメータは、説明した３つのパラメータに限定される、コンテンツ配信に関する任意のパラメータ（コンテンツごとの使用帯域など）を用いてもよい。
配信方式決定部１３は、負荷判定部１２の判定結果の通知を受け、配信方式を適用すべきコンテンツを抽出し、高負荷ならマルチキャスト配信を、低負荷ならユニキャスト配信を、それぞれコンテンツの配信方式として決定する。
【００３２】
【表２】
2012165236.tif 000004
【００３３】
表２は、配信方式記憶部１４内に記憶される統計値を示す表である。例えば、コンテンツＡは、ユニキャスト配信されているフロー数（ユーザ端末６の数）が７０（１０＋４０＋２０）であり、マルチキャスト配信されているフロー数が９０（３０＋２０＋４０）である。そして、マルチキャスト配信されているフロー数「９０」のうち、負荷判定条件（詳細は、図５）が「全一致条件」によってマルチキャスト配信と決定されたフロー数は「３０」である。
この統計値を参照することで、今後、高負荷になりそうなコンテンツ（マルチキャスト配信をした数が多いコンテンツ）を特定できる。
【００３４】
配信方式記憶部１４は、コンテンツごとの配信装置、および、その装置における配信方式決定部１３で決定された配信方式を記憶する格納先である。さらに、配信方式記憶部１４には、コンテンツごとに採用した配信方式（ユニキャスト配信か、マルチキャスト配信か）の履歴を示す統計値（配信方式を採用したフロー数のカウント値）を併せて記憶しており、その統計値が負荷判定部１２から読み出される。表２では、コンテンツごとの配信数の統計値として、負荷判定条件ごとの配信数を格納する。
接続要求処理部１５は、配信方式記憶部１４に記憶されているコンテンツごとの配信装置、および、その配信方式をユーザに通知する。
【００３５】
図３は、ユニキャスト配信での配信処理を示すフローチャートである。この図３の配信処理の前準備として、接続制御サーバ１内の配信方式記憶部１４には、他装置（図示しない企画データ配信サーバなど）からコンテンツごとの配信装置を企画データとして受信して格納しておくとともに、配信サーバ３内のコンテンツ記憶部３４には、企画データで示されるコンテンツデータを企画データ配信サーバなどから受信して格納しておくものとする。
【００３６】
まず、ユーザ端末６から接続制御サーバ１に対して、新規の配信要求が送信される。具体的には、ユーザ端末６から宅内装置５へのダイヤル（Ｓ１０１）が宅内装置５からセッションサーバ２へのＳＩＰ  ＩＮＶＩＴＥ（Ｓ１０２）へと変換され、接続制御サーバ１の接続要求処理部１５へと通知される（Ｓ１０３）。
【００３７】
接続制御サーバ１の接続要求処理部１５は、ＳＩＰ  ＩＮＶＩＴＥで指定されるコンテンツＩＤに対応する配信方式を配信方式記憶部１４から参照し、その配信方式に従って、以降の配信処理を行う。以下、図３では、配信方式がユニキャスト配信である場合を説明する。
【００３８】
接続制御サーバ１は、ユーザ端末６に向けてユニキャスト配信を開始する旨を、ＳＩＰ  ＩＮＶＩＴＥで宅内装置５を介して配信サーバ３へと通知し（Ｓ１１１，Ｓ１１２，Ｓ１１３）、その応答を「２００  ＯＫ」で受け（Ｓ１１４，Ｓ１１５，Ｓ１１６）、ＳＩＰ  ＩＮＶＩＴＥ（Ｓ１０２，Ｓ１０３）への応答を「２００  ＯＫ」で送信する（Ｓ１２１，Ｓ１２２）。
配信サーバ３は、Ｓ１１２の通知を受け、ユーザ端末６に向けてユニキャスト配信でのコンテンツ配信を行う（Ｓ１３０）。
【００３９】
ユーザ端末６は、コンテンツ配信の停止がユーザから入力されると、その旨を接続制御サーバ１に通知する。具体的には、ユーザ端末６から宅内装置５への切断信号（Ｓ１４１）が宅内装置５からセッションサーバ２へのＳＩＰ  ＢＹＥ（Ｓ１４２）へと変換され、接続制御サーバ１へと通知される（Ｓ１４３）。
接続制御サーバ１は、ＳＩＰ  ＢＹＥへの応答を「２００  ＯＫ」で送信する（Ｓ１４４，Ｓ１４５）。
【００４０】
図４は、マルチキャスト配信での配信処理を示すフローチャートである。図３の処理と同じ処理については、同じ符号を付し、前準備（企画データとコンテンツデータの格納処理など）も含めて、説明を省略する。以下、Ｓ１０３の配信要求を受け、図４では、配信方式がユニキャスト配信である場合を説明する。
【００４１】
接続制御サーバ１は、ＳＩＰ  ＩＮＶＩＴＥ（Ｓ１０２，Ｓ１０３）への応答を「２００  ＯＫ」で宅内装置５に送信する（Ｓ２０１，Ｓ２０２）ことで、ユーザ端末６に向けてマルチキャスト配信を開始する旨を宅内装置５に通知する。
宅内装置５は、マルチキャスト配信のグループ参加を示す「ＭＬＤ（Multicast Listener Discovery）  Ａｌｌｏｗ」をルータ４に通知することで、配信サーバ３からのマルチキャスト配信（Ｓ２１０）を、ユーザ端末６にも転送させる（Ｓ２１１）。
そして、図３で示したコンテンツ配信の停止処理（Ｓ１４１〜Ｓ１４５）に対して、宅内装置５からルータ４へのマルチキャスト配信のグループ離脱を示す「ＭＬＤ  Ｂｌｏｃｋ」通知処理（Ｓ２２０）が追加される。
【００４２】
以上、図３および図４でそれぞれ説明したコンテンツ配信処理では、配信方式の決定をユーザ端末６ではなく、接続制御サーバ１で行うため、ユーザ端末６からの配信要求（Ｓ１０１）では、ユニキャスト配信かマルチキャスト配信かを区別する必要がなくなり、ユーザへの負担が軽減される。
【００４３】
図５は、接続制御サーバ１の配信方式決定部１３が実行する配信方式の決定処理を示すフローチャートである。この図５の処理は、所定契機（例えば、５分ごと）ごとに繰り返し実行される。以下、配信方式の決定対象のコンテンツとして、コンテンツＡが選択された一例を説明する。
【００４４】
Ｓ１１として、配信方式決定部１３は、配信方式記憶部１４（表２）内の配信履歴を参照して、マルチキャスト配信実績が多いか否かを判定する。Ｓ１１でＹｅｓならＳ１３へ進み、ＮｏならＳ１２へ進む。例えば、コンテンツＡの全一致条件の配信履歴は、マルチキャスト配信（３０）／ユニキャスト配信（１０）＝配信数比＝３であり、所定しきい値「２」よりも大きいので、Ｓ１３へ進む。
【００４５】
Ｓ１２として、配信方式決定部１３は、ラウンドロビンで負荷判定条件を選択する。ここで、負荷判定条件を定義するための各要素（負荷判定式、負荷パラメータ、および、パラメータ参照方法）について、説明する。
負荷判定条件とは、複数の負荷判定式それぞれの判定結果を論理演算（ＡＮＤ演算、ＯＲ演算）して、１つの負荷判定結果へと集約する旨を規定する条件である。本実施形態では、負荷判定条件を、以下の３種類に分類している。
（１）全一致条件とは、複数の負荷判定式それぞれの判定結果のＡＮＤ演算により、１つの負荷判定結果を求める旨を示す。つまり、複数の負荷判定式を全て満たしたときに（全て高負荷と判定したときに）、負荷判定結果を高負荷とする。これにより、高負荷とする判定を高精度で行うことができる。
（２）部分一致条件とは、複数の負荷判定式それぞれの判定結果のＯＲ演算により、１つの負荷判定結果を求める旨を示す。つまり、複数の負荷判定式のうちの少なくとも１つを満たしたときに（１つの負荷判定式でも高負荷と判定したときに）、負荷判定結果を高負荷とする。これにより、高負荷とする判定を早期に行うことができる。
（３）複合一致条件とは、（１）全一致条件の負荷判定結果と、（２）部分一致条件の負荷判定結果とのうちの少なくとも１つの負荷判定結果が高負荷なら、最終的な負荷判定結果を高負荷とする旨を示す。これにより、（１）全一致条件の高精度と、（２）部分一致条件の早期決定とをバランスよく実施できる。
【００４６】
負荷判定条件を構成する複数の負荷判定式は、負荷パラメータ、および、パラメータ参照方法を用いて記述される。なお、負荷パラメータは、負荷判定部１２が負荷取得部１１や配信要求数取得部１６から通知されたパラメータであり（表１参照）、パラメータ参照方法は、時系列の負荷パラメータから取得できる、「負荷現在値」、「負荷微分値」、および、「負荷積分値」のうちの１つの方法である（詳細は、図７）。
例えば、負荷パラメータが「配信サーバ３ＡのＣＰＵ」であり、そのパラメータ参照方法が「負荷現在値」であるときには、
「配信サーバ３ＡのＣＰＵの負荷現在値が、所定しきい値よりも大きいときには高負荷とし、所定しきい値よりも大きくないときには低負荷とする」という１つの負荷判定式が定義される。
同様に、負荷パラメータが「制御サーバの配信要求数」であり、そのパラメータ参照方法が「負荷積分値」であるときには、
「制御サーバの配信要求数の負荷積分値が、所定しきい値よりも大きいときには高負荷とし、所定しきい値よりも大きくないには低負荷とする」という別の負荷判定式が定義される。
【００４７】
Ｓ１２の説明に戻り、ラウンドロビンとは、例えば、以下のように、新規の配信要求ごとに負荷判定条件を１つずつ順番に選択するアルゴリズムである。
（１つめのコンテンツＡを指定した新規の配信要求）→全一致条件を選択する。
（２つめのコンテンツＢを指定した新規の配信要求）→部分一致条件を選択する。
（３つめのコンテンツＣを指定した新規の配信要求）→複合判定条件を選択する。
（４つめのコンテンツＤを指定した新規の配信要求）→全一致条件を選択する。
【００４８】
Ｓ１３として、配信方式決定部１３は、マルチキャスト配信実績が多い負荷判定条件（Ｓ１１で配信数比が大きいと判定したときの負荷判定条件）を選択する。例えば、Ｓ１１で、コンテンツＡの全一致条件の配信数比「３」＞所定しきい値「２」よりも大きいと判定したので、Ｓ１３では「全一致条件」を負荷判定条件として選択する。
これにより、マルチキャスト配信が選ばれやすい負荷判定条件が優先的に選択されるので、マルチキャスト配信をユニキャスト配信よりも多く採用できる。
【００４９】
Ｓ２０として、配信方式決定部１３は、Ｓ１２またはＳ１３で選択された負荷判定条件に応じて負荷判定条件ごとの負荷判定部１２による負荷判定処理（Ｓ２１〜Ｓ２３）を呼び出す。これらの各負荷判定処理の詳細は、図６〜図８で後記する。以上により、コンテンツＡの配信方式が決定される。
Ｓ３１として、接続要求処理部１５は、コンテンツＡの配信を所望する旨の、新規の配信要求を受信する。この配信要求の受信処理は、図３，図４におけるＳＩＰ  ＩＮＶＩＴＥの受信処理（Ｓ１０３）に対応する。
Ｓ３２として、接続要求処理部１５は、Ｓ２１〜Ｓ２３で決定した配信方式で、コンテンツＡの配信を開始するとともに、配信方式記憶部１４にその配信した旨を履歴記録として記憶（配信数の加算）する。
【００５０】
図６は、全一致条件により、配信方式を決定する処理（Ｓ２１）の詳細を示すフローチャートである。なお、この図６では、全一致条件を構成する負荷判定式が、以下に列挙する４つである例を説明するが、負荷判定条件（全一致条件だけでなく、他の条件も）を構成する負荷判定式の数や、各負荷判定式の内容は、図６に限定せずに、任意に設定できる。
・配信サーバ３（Ａ）のＣＰＵ使用率の負荷現在値が所定しきい値より大きいか否かを示す負荷判定式（Ｓ３０１）
・配信サーバ３（Ａ）のＣＰＵ使用率の負荷微分値が所定しきい値より大きいか否かを示す負荷判定式（Ｓ３０２）
・配信サーバ３（Ｂ）のＣＰＵ使用率の負荷微分値が所定しきい値より大きいか否かを示す負荷判定式（Ｓ３０３）
・接続制御サーバ１の配信要求数の負荷積分値が所定しきい値より大きいか否かを示す負荷判定式（Ｓ３０４）
Ｓ３０１〜Ｓ３０４のうちの１つでも「低負荷」ならＳ３０６へ進み、Ｓ３０１〜Ｓ３０４のうちの全て「高負荷」ならＳ３０５へ進む。
Ｓ３０５では、高負荷なので、配信方式をマルチキャスト配信と決定する。
Ｓ３０６では、低負荷なので、配信方式をユニキャスト配信と決定する。
なお、負荷判定式を構成する負荷パラメータは、適宜変更してもよい。例えば、Ｓ３０１では、負荷パラメータとして「配信サーバ３（Ａ）のＣＰＵ使用率」を参照しているが、別の配信サーバ３（Ｃ）のＣＰＵ使用率が先に高負荷になったときには、Ｓ３０１の負荷パラメータとして、「配信サーバ３（Ｃ）のＣＰＵ使用率」に変更してもよい。
【００５１】
図７は、３種類の負荷判定時に参照されるパラメータ参照方法を示す説明図である。
【００５２】
図７（ａ）に示す負荷現在値での判定では、今まで低負荷と判定されていて、かつ、負荷現在値が第１しきい値より大きいときに、高負荷と判定する。同様に、今まで高負荷と判定されていて、かつ、負荷現在値が第２しきい値より小さいときに、低負荷と判定する。
これにより、負荷の過去値を参照しなくて済むため、計算量が少なく、早期の判定が可能である。
【００５３】
図７（ｂ）に示す負荷微分値での判定では、負荷過去値から負荷現在値への所定期間（微小期間）の負荷値の変化量（負荷微分値、グラフの傾き）が所定しきい値より大きいときに、高負荷と判定する。
これにより、瞬間的に負荷が変化（増加、減少）した際に、将来の負荷値を予測することができるので、早期の負荷判定が可能になる。
【００５４】
図７（ｃ）に示す負荷積分値での判定では、負荷過去値から負荷現在値への所定期間（積分期間）の負荷値の総和（負荷積分値、グラフの斜線部分の面積）が所定しきい値より大きいときに、高負荷と判定する。
これにより、負荷の増減が一時的に激しい場合でも、負荷判定を高精度に行うことができる。
【００５５】
図８（ａ）は、部分一致条件により、それぞれ配信方式を決定する処理（Ｓ２２）の詳細を示すフローチャートである。この図８（ａ）では、部分一致条件を構成する負荷判定式が、以下に列挙する２つである例を説明する。
・配信サーバ３（Ａ）のＣＰＵ使用率の負荷現在値が所定しきい値より大きいか否かを示す負荷判定式（Ｓ３１１）
・配信サーバ３（Ａ）のＣＰＵ使用率の負荷微分値が所定しきい値より大きいか否かを示す負荷判定式（Ｓ３１２）
Ｓ３１１〜Ｓ３１２のうちの１つでも「高負荷」ならＳ３１４へ進み、Ｓ３１１〜Ｓ３１２のうちの全て「低負荷」ならＳ３１３へ進む。
Ｓ３１３では、低負荷なので、配信方式をユニキャスト配信と決定する。
Ｓ３１４では、高負荷なので、配信方式をマルチキャスト配信と決定する。
【００５６】
図８（ｂ）は、複合一致条件により、それぞれ配信方式を決定する処理（Ｓ２３）の詳細を示すフローチャートである。
まず、部分一致条件による配信方式の決定処理（Ｓ２２，詳細は図８（ａ））を呼び出し、その結果が高負荷か否かを判定する（Ｓ３２１）。
次に、全一致条件による配信方式の決定処理（Ｓ２１，詳細は図６）を呼び出し、その結果が高負荷か否かを判定する（Ｓ３２２）。
Ｓ３２１，Ｓ３２２のうちの１つでも「高負荷」ならＳ３２４へ進み、Ｓ３２１，Ｓ３２２のうちの全て「低負荷」ならＳ３２３へ進む。
Ｓ３２３では、低負荷なので、配信方式をユニキャスト配信と決定する。
Ｓ３２４では、高負荷なので、配信方式をマルチキャスト配信と決定する。
【００５７】
以上説明した本実施形態では、コンテンツ配信システムで計測された負荷情報に応じて、高負荷ならマルチキャスト配信を選択し、低負荷ならユニキャスト配信を選択することを特徴とする。ここで、負荷判定用の負荷情報として、負荷パラメータの微分値（図７（ｂ）参照）を用いることにより、将来予想される負荷の変化分を先取りして、配信方式を選択することができるので、適切な配信方式を採用できる。
【００５８】
なお、コンテンツの特徴（コンテンツ長、ファイルサイズ、頭出しの有無など）によっては、配信方式を選択せずに、固定の配信方式を選択する場合もある。例えば、コンテンツが生中継のビデオ配信であるときには、頭出しができないので、配信方式はマルチキャスト配信の固定となる。よって、あらかじめ配信方式記憶部１４内に、配信方式が固定のコンテンツである旨を事前登録し、配信方式決定部１３にその登録内容を参照させることで、配信方式決定部１３による配信方式の決定処理を省略することができる。
【００５９】
また、配信方式の決定に参照される負荷判定式（および、その構成要素としての負荷パラメータ）については、前記した一例に限定されず、従来の負荷測定により計測される負荷判定手法を採用してもよい。例えば、特開２０００−４９９４０号公報では、測定情報のトラヒック量などの負荷情報を測定する際、同報宛先数が所定のしきい値以上と判定すると、発信が生じた時点で負荷判定し、負荷が高いと測定間隔を短くし測定制度を向上させる旨が開示されており、この測定手法を接続制御サーバ１に採用してもよい。
【符号の説明】
【００６０】
１      接続制御サーバ
２      セッションサーバ
３      配信サーバ
４      ルータ
５      宅内装置
６      ユーザ端末
１１    負荷取得部
１２    負荷判定部
１３    配信方式決定部
１４    配信方式記憶部
１５    接続要求処理部
１６    配信要求数取得部
３１    負荷測定部
３２    負荷通知部
３３    配信制御部
３４    コンテンツ記憶部
【図１】
2012165236.tif 000005
【図２】
2012165236.tif 000006
【図３】
2012165236.tif 000007
【図４】
2012165236.tif 000008
【図５】
2012165236.tif 000009
【図６】
2012165236.tif 000010
【図７】
2012165236.tif 000011
【図８】
2012165236.tif 000012