(57)【要約】【課題】複数のコンテンツを同時に配信するデータ配信システムにおいて、上記データ配信システムが配信可能なクライアントユーザの数を増加させること。【解決手段】管理装置は、予め決められた配信ツリーのポリシを記憶し、コンテンツデータの配信ツリーを変更するか否かを判定し、判定の結果、変更できなかった場合、予め定められたポリシに基づいて他の配信サーバにおける他の配信ツリーにおける変更も判定し、判定の結果が変更の場合は、ポリシに基づいて他の配信ツリーを変更し、配信サーバと、他の配信サーバと、中継サーバとに、新たな配信ツリーと、新たな他の配信ツリーの接続情報を送信する。【選択図】図１
2013106283.tif 000002
【特許請求の範囲】
【請求項１】
配信要求を配信サーバに送信するクライアント装置と、クライアント装置に向けて１台以上の中継サーバを介してそれぞれのコンテンツデータを配信する複数の配信サーバと、前記配信サーバからデータを受信し、他の中継サーバ又はクライアント装置にデータを送信する中継サーバと、データの配信経路である配信ツリーを決定する管理装置を備えるデータ配信経路決定システムであって、
前記管理装置は、
前記クライアント装置が送信した前記コンテンツデータの配信要求を受信し、
予め決められた前記配信ツリーのポリシを記憶し、
前記コンテンツデータの前記配信ツリーのポリシに基づいて変更するか否かを判定し、
前記判定の結果が変更の場合は、予め定められた前記ポリシに基づいて前記配信ツリーを変更し、
更に、前記変更でなかった場合、予め定められた前記ポリシに基づいて他の配信サーバにおける他の配信サーバにおける他の配信ツリーの変更も判定し、
前記他の配信サーバの判定結果が変更の場合は、前記ポリシに基づいて前記配信ツリーと、前記他の配信ツリーとを変更し、
前記配信サーバと、前記他の配信サーバと、前記中継サーバとに、新たな前記配信ツリーと、新たな前記他の配信ツリーの接続情報を送信し、
前記配信サーバは、前記管理装置から受信した前記新たな配信ツリーの情報に基づいて前記コンテンツデータを送信し、
前記他の配信サーバは、前記管理装置から受信した前記新たな他の配信ツリーの情報に基づいて前記コンテンツデータを送信するデータ配信経路決定システム。
【請求項２】
請求項１に記載のデータ配信経路決定システムであって、
前記管理装置は、
複数の配信サーバに接続された前記クライアント装置の台数と、前記配信サーバが収容可能な台数を記憶し、
前記クラインアント装置の台数が当該配信サーバが収容可能な台数より多い場合、
前記配信ツリーを変更すると判定する配信経路決定システム。
【請求項３】
請求項２に記載のデータ配信経路決定システムであって、
前記管理装置は、
前記他の配信サーバの収容台数が、収容可能な台数より少ない場合、
前記他の配信サーバに接続された前記中継サーバの接続を切断するよう変更し、
当該中継サーバは、前記配信サーバ接続するよう変更するデータ配信経路決定システム。
【請求項４】
配信要求を配信サーバに送信するクライアント装置と、クライアント装置に向けて１台以上の中継サーバを介してそれぞれのコンテンツデータを配信する複数の配信サーバと、前記配信サーバからデータを受信し、他の中継サーバ又はクライアント装置にデータを送信する中継サーバと、データの配信経路である配信ツリーを決定する管理装置を備えるデータ配信経路決定システムにおけるデータ配信経路決定方法であって、
前記管理装置は、
前記クライアント装置が送信した前記コンテンツデータの配信要求を受信するステップと、
予め決められた前記配信ツリーのポリシを記憶するステップと、
前記コンテンツデータの前記配信ツリーのポリシに基づいて変更するか否かを判定するステップと、
前記判定の結果が変更の場合は、予め定められた前記ポリシに基づいて前記配信ツリーを変更するステップと、
更に、前記変更でなかった場合、予め定められた前記ポリシに基づいて他の配信サーバにおける他の配信サーバにおける他の配信ツリーの変更も判定するステップと、
前記他の配信サーバの判定結果が変更の場合は、前記ポリシに基づいて前記配信ツリーと、前記他の配信ツリーとを変更するステップと、
前記配信サーバと、前記他の配信サーバと、前記中継サーバとに、新たな前記配信ツリーと、新たな前記他の配信ツリーの接続情報を送信するステップとを備え、
前記配信サーバは、前記管理装置から受信した前記新たな配信ツリーの情報に基づいて前記コンテンツデータを送信するステップを備え、
前記他の配信サーバは、前記管理装置から受信した前記新たな他の配信ツリーの情報に基づいて前記コンテンツデータを送信するステップを備えるデータ配信経路決定方法。
【請求項５】
請求項４に記載のデータ配信経路決定方法であって、
前記管理装置は、
複数の配信サーバに接続された前記クライアント装置の台数と、前記配信サーバが収容可能な台数を記憶するステップとを更に備え、
前記クラインアント装置の台数が当該配信サーバが収容可能な台数より多い場合、
前記配信ツリーを変更すると判定するデータ配信経路決定方法。
【請求項６】
請求項５に記載のデータ配信経路決定方法であって、
前記管理装置は、
前記他の配信サーバの収容台数が、収容可能な台数より少ない場合、
前記他の配信サーバに接続された前記中継サーバの接続を切断するよう変更し、
当該中継サーバは、前記配信サーバ接続するよう変更するデータ配信経路決定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データのストリーミングデータを配信する経路を決定する技術に関する。
【背景技術】
【０００２】
ネットワークを介し、コンテンツ提供者が主に音声や動画などのマルチメディアデータをリアルタイムに生成しながらクライアントユーザに配信する、ストリーミング配信が普及してきている。
【０００３】
ストリーミング配信において、クライアント収容数を増加させる技術として、配信サーバとクライアントユーザの端末の通信経路の途中に、配信サーバからデータストリームを受信しながら、受信したデータストリームを複製して複数のクライアント装置に対して転送する「中継サーバ」を仲介させる方式が利用されている。
【０００４】
しかしながら配信ツリーは、手作業で作成するため、管理者に負担がかかる。
【０００５】
管理者の負担を軽減するために、特許文献１のような技術がある。特許文献１には、再配信サーバは、検出したホップ数と遅延の情報と、自ノードの負荷情報（ＣＰＵ（中央処理装置）負荷、メモリ使用量、配信ストリーム数）の情報をマスターサーバに通知し、マスターサーバは経路ツリーを自動構成することが開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００２−２３２４６６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１の技術では、配信サーバが複数ある場合が記載されていない。そのため、配信サーバが複数ある場合、配信を希望するクライアントユーザの数の少ない配信ツリーに対しても処理能力が高い中継サーバが割り当てられる場合が生じ、コンテンツ配信システム全体としてのクライアントユーザの収容可能数が低下してしまう課題が生じる。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、本発明の一態様は以下の構成を備える。即ち、管理装置は、
クライアント装置が送信した前記コンテンツデータの配信要求を受信し、予め決められた配信ツリーのポリシを記憶し、コンテンツデータの配信ツリーを変更するか否かを判定し、予め決められた配信ツリーのポリシを記憶し、判定の結果が変更の場合は、予め定められたポリシに基づいて配信ツリーを変更し、更に、変更ができなかった場合、予め定められたポリシに基づいて他の配信サーバにおける他の配信ツリーにおける変更も判定し、判定の結果が変更の場合は、ポリシに基づいて他の配信ツリーを変更し、配信サーバと、他の配信サーバと、中継サーバとに、新たな配信ツリーと、新たな他の配信ツリーの接続情報を送信し、配信サーバは、管理装置から受信した新たな配信ツリーの情報に基づいてコンテンツデータを送信し、他の配信サーバは、管理装置から受信した新たな他の配信ツリーの情報に基づいてコンテンツデータを送信する。
【発明の効果】
【０００９】
本発明に拠れば、ストリーミング配信おいて、配信ツリーごとに中継サーバの配信処理能力の確保量をクライアントユーザの数に応じて増減することができるようになり、コンテンツ配信システムが処理できる配信可能数と配信品質の向上が実現できる。
【図面の簡単な説明】
【００１０】
【図１】本発明を適用した配信システムの構成図の例である。
【図２】計算機の物理構成の例を示す図である。
【図３】管理部が保持するサーバ一覧テーブルの例である。
【図４】管理部が保持する配信状況テーブルの例である。
【図５】管理部が保持するリソース確保ポリシテーブルの例である。
【図６】管理部が保持するユーザ一覧テーブルの例である。
【図７】ポータル部が保持する配信データ一覧テーブルの例である。
【図８】中継サーバが保持するバインド情報テーブルの例である。
【図９】配信情報登録処理のフローチャートの例である。
【図１０】クライアント収容処理の例（クライアント収容）
【図１１】ポリシ判定処理のフローチャートの例である。
【図１２】配信ツリーが変更可能か判定する処理のフローチャートの例である。
【図１３】リソース解放に係る配信ツリー再計算処理のフローチャートの例である。
【図１４】リソース確保に係る配信ツリー再計算処理のフローチャートの例である。
【図１５】クライアント収容処理の例（クライアント到着）
【図１６】クライアント収容処理の例（余剰リソースの解放）
【発明を実施するための形態】
【００１１】
以下、実施例を図面を用いて説明する。
以下、ストリーミングデータを送受するために用いられるコンテンツ配信システムを構成する各機構間の論理的な通信路を「セッション」と記載する。
【００１２】
本実施例では、本発明の特徴である、ストリーミング配信の配信ツリーの制御を行う機構である管理部１００の例を説明する。
図１は、本実施例の管理部１００を適用した配信システムの構成図の例である。
管理部１００は、配信中のコンテンツごとに構成すべき配信ツリーを計算し、計算した配信ツリーを実現するためにセッション制御命令をセッション制御部１７０に送信する機構である。本実施例においては、管理部１００は、サーバ一覧１０１と、配信状況１０２と、リソース確保ポリシと、ユーザ一覧１０４と、配信状況管理部１０５と、ポリシ判定部１０６と、配信ツリー再計算部１０７と、セッション制御ＩＦ１０８と、配信サーバポータル部ＩＦ１０９と、クライアントポータル部ＩＦ１１０の機能を備える。
【００１３】
サーバ一覧１０１は、それぞれの配信サーバ１２０と中継サーバ１３０とＨＧＷ１４０についての、クライアント数の増減に関わらずに静的に定まる情報であって、少なくとも、それぞれのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）と、処理性能と、配信サーバ１２０については配信中のコンテンツの識別ＩＤと、を保持する。
サーバ一覧１０１としてＵＲＩを保持することで、管理部１００が、セッション制御部ＩＦ１０８を用いて、セッション制御部１７０へ、セッション制御命令を発行することができる。
【００１４】
サーバ一覧１０１として配信サーバ１２０と中継サーバ１３０の処理性能を保持することで、ポリシ判定部１０６が、後述の配信状況１０２と数値比較して後述のリソース確保ポリシ１０３の条件を参照する、リソース確保ポリシ判定処理を実施することができる。
サーバ一覧１０１で保持するデータの具体的な例については、後述の図３を用いて示す。リソース確保ポリシ判定処理の具体的な例については、後述の図１１を用いて示す。
【００１５】
配信状況１０２は、配信サーバ１２０と中継サーバ１３０とＨＧＷ１４０について、配信中のクライアント数に関わる情報であって、少なくとも、各配信ツリーを識別するためのコンテンツの識別ＩＤと、各配信ツリーのツリー構造を保持する。
配信ツリーとは、各コンテンツをクライアントに配信するためにコンテンツ配信システムが構成する、トップノードがそのコンテンツを配信する配信サーバ１２０、中間ノードが中継サーバ１３０、ボトムノードがＨＧＷ１４０、各枝がそれぞれのノード間に確立するセッション、である木構造のことである。
【００１６】
各配信ツリーのツリー構造とは、配信ツリーの様態を一意に把握するための情報である。
配信状況１０２を保持することで、ポリシ判定部１０６が、リソース確保ポリシ判定処理を実施することができる。配信状況１０２で保持するデータの具体的な例については、後述の図４を用いて示す。リソース確保ポリシ判定処理の具体的な例については、後述の図１１を用いて示す。
【００１７】
リソース確保ポリシ１０３は、配信ツリーが確保している中継サーバの処理リソース量が、その配信ツリーのクライアント数に対して、適切である／過剰である／不足している、のいずれであるかを、一意に判定するための判定条件であって、少なくとも、一つ以上の判定条件と、その判定条件を適用する配信ツリーを識別するための情報と、その判定処理を実施するタイミングを表す情報と、を保持する。
リソース確保ポリシ１０３として、判定条件と判定条件を適用する配信ツリーを識別するための情報を組にして保持することで、ポリシ判定部１０６が、配信ツリーごとにリソース確保ポリシ判定処理を実施することができる。
【００１８】
リソース確保ポリシ１０３として、判定処理を実施するタイミングを表す情報を保持することで、例えば、ある配信ツリーの判定イベントとして、「他の配信ツリーでリソース確保量が不足していると判定された」ことをそのツリーの判定処理開始条件に追加することができる。これにより、上述の他の配信ツリーがリソース不足である際に、上述の配信ツリーが過剰リソースを保持していればリソースを解放させる処理を行うことができるようになる。
【００１９】
リソース確保ポリシ１０３で保持するデータの具体的な例については、後述の図５を用いて示す。リソース確保ポリシ判定処理の具体的な例については、後述の図１１を用いて示す。ユーザ一覧１０４は、コンテンツ配信システムを利用するクライアントの情報の一覧である。ユーザ一覧１０４は、本発明の特徴である管理部１００が動作するために必ずしも必要な情報ではないが、ユーザ一覧１０４を保持し、後述する図１２と図１３で示す配信ツリー再計算処理に利用することで、本発明のクライアントユーザに対する実施効果として、さらに、同一クライアントユーザが短時間の間に繰り返し転送されることを防止する効果と、課金情報などのクライアントユーザの属性情報をもとにして優先的に転送処理を発生させるクライアントユーザを管理部１００が選択可能になる効果がある。
ユーザ一覧で保持するデータの具体的な例については、後述の図５を用いて示す。
上述したユーザ一覧１０４を保持することで現れるクライアントユーザに対する効果については、後述する図１２と図１３を用いて示す。
配信状況管理部１０５は、中継サーバ１３０からＨＧＷ１４０がコンテンツ配信システムから離脱した際に、ＨＧＷ１４０の離脱を知らせるシグナルを受信し、配信状況１０２の情報を更新する機能である。
【００２０】
ＨＧＷ１４０をコンテンツ配信システムに収容する場合においては、後述する図１０で示すようなクライアント収容処理によって常に管理部１００が介在するため、配信状況１０２を更新することができるが、ＨＧＷ１４０の離脱については、管理部１００を介することなくＨＧＷ１４０が自由に実施できるため、管理部１００が配信状況１０２を更新することができない。
ＨＧＷ１４０が離脱を自由に実施するとは、例えばコンテンツ配信システムに収容されているＨＧＷ１４０の電源が突然落ちる場合なども含む。
配信状況管理部１０５が、中継サーバ１３０やＨＧＷ１４０に対して、セッションの接続状況を能動的に問い合わせることで、ＨＧＷ１４０の離脱の発生を知ることができ、従って管理部１００が配信状況１０２を配信ツリーの実際の様態と一致するように更新することができる。
【００２１】
ポリシ判定部１０６は、リソース確保ポリシ１０３を参照し、サーバ一覧１０１と、配信状況１０２と、の情報を用いて、配信ツリーのクライアント数に対して中継サーバのリソース確保量が、適切である／過剰である／不足している、のいずれであるかを一意に判定し、過剰である、または、不足している、と判定した場合に配信ツリー再計算部１０７に対して、配信ツリーの再計算を指示する機能である。
リソース確保ポリシ判定処理の具体的な例については、後述の図１１を用いて示す。
【００２２】
配信ツリー再計算部１０７は、ポリシ判定部１０６が配信ツリーのクライアント数に対して中継サーバのリソース確保量が過剰である、または、不足している、と判定した場合にポリシ判定部１０６から通知を受け、該当配信ツリーがリソース確保ポリシを満たすために、配信ツリーをどのように再構築させるかを計算し、かつ、そのために必要なセッション制御命令のセットを計算してセッション制御部ＩＦ108へ通知する処理である。
配信ツリー再構築計算処理については、後述の図１２と図１３を用いて示す。
【００２３】
セッション制御部ＩＦ１０８は、管理部１００が、サーバ一覧１０１に格納されている各機構のＵＲＩを利用し、配信ツリー再計算部１０７の計算結果からに対応したセッション制御命令をセッション制御部１７０に対して送信するために用いるインタフェースである。ここで、管理部１００と、配信サーバポータル部１８０と、クライアントポータル部１９０は、管理サーバに備えられていても良いし、それぞれ別のサーバに備えられていても良いものとする。
【００２４】
配信サーバポータル部ＩＦ１０９は、管理部１００が、配信サーバポータル部１８０から、配信サーバポータル部１８０が配信サーバ１２０から受信した配信要求に含まれる配信情報を受信するために利用するインタフェースである。
クライアントポータル部ＩＦ１１０は、管理部１００が、クライアントポータル部１９０から、クライアントポータル部１９０がクライアント１５０から受信したストリームコンテンツの配信要求を受信するために利用するインタフェースである。
【００２５】
配信サーバ１２０は、コンテンツ提供者がストリームデータを配信するために利用する機構である。配信サーバ１２０は少なくとも、後述する配信情報登録部１２１と、制御信号受信部１２２と、配信データ生成部１２３と、データ配信部１２４の機能を備える。
【００２６】
配信情報登録部１２１は、コンテンツ提供者がコンテンツ配信システムを利用してストリーミングデータの配信を行う際に、配信サーバポータル部１８０へ、配信情報を登録するために利用する機能である。
配信サーバポータル部１８０へ登録する配信情報としては、少なくとも、コンテンツ提供者の識別ＩＤと、配信を開始する時刻と、配信を終了する時刻を含む。
配信情報登録部１２１は、配信サーバ１２０と別の計算機装置に実装されていてもよい。
【００２７】
制御信号受信部１２２は、管理部１００のセッション制御部ＩＦ１０８から、セッションの制御に関するシグナルを受信し、受信したシグナルに応じたセッションの確立・切断・転送を行う機能である。
配信データ生成部１２３は、コンテンツ提供者が配信するストリーミングデータを生成するための機能である。
【００２８】
配信データ生成部１２３は、配信サーバ１２０と別の計算機装置に実装され、配信サーバ１３０にネットワークや、その他の入出力機構を介して接続されていてもよい。
データ配信部１２４は、配信データ生成部１２３が生成するストリーミングデータを、制御信号受信部１２２が確立するセッションを介してコンテンツ配信システムへ送信するための機能である。
【００２９】
中継サーバ１３０は、セッションを確立している配信サーバ１２０もしくは別の中継サーバ１３０か、配信コンテンツのデータストリームを受信しながら、受信したデータストリームを複製して複数のさらに別の中継サーバ１３０もしくはＨＧＷ１４０へ転送する機構である。
中継サーバ１３０は、少なくとも、後述する、制御信号受信部１３１と、配信データ複製部１３２と、バインド情報１３４と、を備え、さらに本実施例においては、バッファリング部１３３、の機能を備える。
【００３０】
制御信号受信部１３１は、管理部１００のセッション制御部ＩＦ１０８から、セッションの制御に関するシグナルを受信し、受信したシグナルに応じたセッションの確立・切断・転送を行う機能である。
配信データ複製部１３２は、制御信号受信部１３１が確立する上流からのセッションを介して配信コンテンツのデータストリームを受信し、受信したデータストリームを複製して、制御信号受信部１３１が確立する下流へのセッションに送信する機能である。
【００３１】
バッファリング部１３３は、上流からのセッションを介して受信したデータストリームを数秒程度の分量だけ蓄えてから下流へのセッションに送信する機能である。
バッファリング部１３３を利用すると、バッファリング部が蓄える時間だけコンテンツの即時性が損なわれるが、その代わりに、ネットワーク１６０や、配信サーバ１２０、中継サーバ１３０、ＨＧＷ１４０の品質の揺らぎを吸収できるため、クライアント１５０が受信するコンテンツデータがコマ落ちしたり途切れたりするような品質の劣化を低減する効果を得ることができる。
【００３２】
また、バッファリング部１３３を利用することで、本発明の特徴的な動作である、配信ツリーの再構築時の処理においても、クライアント１５０が転送される場合に、そのクライアント１５０が受信するコンテンツデータがコマ落ちしたり途切れたりするような品質の劣化を低減する効果を得ることができる。
バインド情報１３４は、上流のセッションと下流のセッションとを紐付けるための情報であって、ひと組以上の、一つの上流のセッションを識別する情報と一つ以上の下流へのセッションを識別する情報と、を保持する。
【００３３】
ＨＧＷ（Ｈｏｍｅ  ＧａｔｅＷａｙ）１４０はクライアント１５０がネットワーク１６０に接続する際に経由するゲートウェイである。ＨＧＷ１４０は、少なくとも、制御命令受信部１４１と、配信データ複製部１４２を備え、さらに本実施例においては、バッファリング部１４３の機能を備える。
制御信号受信部１４１は、管理部１００のセッション制御部ＩＦ１０８から、セッションの制御に関するシグナルを受信し、受信したシグナルに応じたセッションの確立・切断・転送を行う機能である。
【００３４】
配信データ複製部１４２は、制御信号受信部１４１が確立する上流からのセッションを介して配信コンテンツのデータストリームを受信し、受信したデータストリームを複製して、クライアント１５０へ転送する機能である。
バッファリング部１４３は、上流からのセッションを介して受信したデータストリームを数秒程度の分量だけ蓄えてから下流へのセッションに送信する機能である。
バッファリング部１４３を利用すると、バッファリング部が蓄える時間だけコンテンツの即時性が損なわれるが、その代わりに、ネットワーク１６０や、配信サーバ１２０、中継サーバ１３０、ＨＧＷ１４０の品質の揺らぎを吸収できるため、クライアント１５０が受信するコンテンツデータがコマ落ちしたり途切れたりするような品質の劣化を低減する効果を得ることができる。
【００３５】
また、バッファリング部１４３を利用することで、本発明の特徴的な動作である、配信ツリーの再構築時の処理においても、クライアント１５０が転送される場合に、そのクライアント１５０が受信するコンテンツデータがコマ落ちしたり途切れたりするような品質の劣化を低減する効果を得ることができる。
バインド情報１４４は、上流のセッションと下流のセッションとを紐付けるための情報であって、一組以上の、一つの上流のセッションを識別する情報と一つ以上の下流へのセッションを識別する情報と、を保持する。
クライアント１５０は、クライアントユーザがストリーミングデータを受信するために利用する装置である。本実施例においては、配信されるストリームデータを受信して解釈する配信データ利用アプリケーション１５１の機能を備える。
【００３６】
ネットワーク１６０は、本発明のコンテンツ配信システムが接続されている通信ネットワークであって、例えばインターネットや閉域ネットワークである。
また、ネットワーク１６０として、ＮＧＮ（Ｎｅｘｔ  Ｇｅｎｅｒａｔｉｏｎ  Ｎｅｔｗｏｒｋ）を利用することは、本発明を適用したコンテンツ配信システムにとって最も好ましい態様である。
ネットワーク１６０としてＮＧＮを利用することにより、例えば、管理部１００のセッション制御部ＩＦに標準ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）である、Ｐａｒｌａｙ  Ｘを用いることができ、セッション制御部１７０に標準プロトコルであるＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）の第三者呼制御を利用することができ、配信サーバ１２０の制御信号受信部１２２および中継サーバ１３０の制御信号受信部１３１およびＨＧＷ１４０の制御信号受信部１４１にＳＩＰのインタフェースを利用できるようになる。
【００３７】
これにより、コンテンツ配信システムの開発者は、制御信号の送受に用いるプロトコルを独自に設計して実装する必要がなくなり、開発コストを低減することができる。
また、ＳＩＰを用いることでセッションの状態を通知するためのプレゼンス機能を利用することが可能になるため、管理部１００の配信状況管理部１０５についても、独自のプロトコルを使用せず、上述したＳＩＰのプレゼンス機能を利用することでクライアントの離脱の有無を取得することができる。
また、ＮＧＮでは、セッション毎のネットワーク帯域を指定して制御するためのＳＩＰインタフェースが公開されているため、ネットワーク１６０としてＮＧＮを利用する場合には、セッション制御部ＩＦ１０８を用いてセッション毎の帯域を制御することができる。
これにより、後述するようなリソース確保、解放処理において、セッションの接続数だけでなくネットワーク帯域についても制御可能になるという利点がある。
【００３８】
セッション制御部１７０は、管理部１００からセッション制御部IF108を介してセッション制御命令を受信し、受信したセッション制御命令を実行するためのセッション制御信号を、配信サーバ１２０、中継サーバ１３０、ＨＧＷ１４０のいずれか、もしくは複数の組合せに対して、ネットワーク１６０を介して送信する。
配信サーバポータル部１８０は、配信サーバ１２０から、ストリームコンテンツの配信要求を受信するための窓口となる機構である。本実施形態においては、配信サーバ１２０とのインタフェースである配信サーバＩＦ１８１と、配信サーバ１２０から受信した配信要求に含まれる配信情報を管理部１００に登録するためのインタフェースである管理部ＩＦ１８２の機能を備える。
ストリームコンテンツの配信要求処理の具体的な例については、後述する図９を用いて説明する。
【００３９】
クライアントポータル部１９０は、クライアント１５０から、ストリームコンテンツの配信要求を受信するための窓口となる機構である。本実施形態においては、コンテンツ配信システムが配信中と配信予定であるストリームコンテンツの一覧を保持する配信データ一覧テーブル１９１と、クライアント１５０からのコンテンツ配信要求を受信するクライアントＩＦ１９２と、クライアント１５０から受信したコンテンツ配信要求の内容を管理部１００へ送信するための管理部ＩＦ１９３と、の機能を備える。
クライアント１５０からのコンテンツ配信要求の受信処理の具体的な例については、後述する図１０を用いて説明する。
【００４０】
図１に示した構成は、本発明の機能構成を決定づけるものではなく、図１に記載の複数の機能が単一の計算機内部、あるいは仮想計算機内部に論理的に実装されていてもよい。
特に、ＨＧＷ１４０とクライアント１５０を、携帯電話やモバイルＰＣなどの可搬性を有する単一の計算機内に実装することは、クライアントユーザにとって好適な実施形態の一つである。
【００４１】
図２は、図１の各構成要素のハードウェア構成を例示した図である。これらの機器は、ＣＰＵ２０１と、メモリ２０２と、インターネットやＬＡＮを介して他の装置と通信を行うための通信装置２０４と、キーボードやマウス等の入力装置２０５と、モニタやプリンタ等の出力装置２０６と、読取装置２０７と、ハードディスク等の外部記憶装置２０３とが、インタフェース２０８を介して接続されている。また、読取装置２０７にはＩＣカードやＵＳＢメモリのような、可搬性を有する記憶媒体２０９を接続することができる。
【００４２】
本実施例における、管理部１００や、配信サーバ１２０、中継サーバ１３０、ＨＧＷ１４０、クライアント１５０、セッション制御部１７０、配信サーバポータル部１８０、クライアントポータル部１９０は、これらの機能を実現するプログラムがメモリ２０２上にロードされ、ＣＰＵ２０１により実行されることにより具現化される。これらのプログラムは、あらかじめ、上記情報処理装置の外部記憶装置２０３に格納されていても良いし、必要なときに、読取装置２０７や通信装置２０４と当該情報処理装置が利用可能な媒体を介して、他の装置から上記外部記憶装置に導入されてもよい。
上記当該情報処理装置が利用可能な媒体とは、たとえば、読取装置２０７に着脱可能な記憶媒体２０９、または通信装置２０４に接続可能なネットワークまたはネットワークを伝搬する搬送波やディジタル信号を指す。そして、プログラムは一旦外部記憶装置２０３に格納された後、そこからメモリ２０２上にロードされてＣＰＵ２０１に実行されてもよいし、あるいは外部記憶装置２０３に格納されることなく、直接メモリ２０２上にロードされて、ＣＰＵ２０１に実行されてもよい。
【００４３】
図３は、管理サーバ１００が保持するサーバ一覧１０１の例を示した図である。
本実施例において、サーバ一覧テーブル１０１は、ＵＲＩ３０１を保持し、この値を用いて、コンテンツ配信システムはセッションを制御する対象の機構のＵＲＩを取得する。
本実施例において、サーバ一覧テーブル１０１は、タイプ３０２を保持し、この値を用いて、各ＵＲＩ３０１に対応する機構のコンテンツ配信システム内での役割を識別する。
本実施例において、サーバ一覧テーブル１０１は、タイプ３０２の値が配信サーバであるデータに対して、配信するコンテンツの識別名をコンテンツ名３０３として保持し、この値を用いて、リソース確保ポリシ１０３に保持する判定条件をどの配信ツリーに対して適用するかのマッピング処理を行う。
【００４４】
本実施例において、サーバ一覧テーブル１０１は、各機構の処理性能を表す情報として、上位最大接続数３０４を保持する。この値は、一つの中継サーバ１３０、ＨＧＷ１４０が、同時に接続可能な上流セッションの最大数を表す。
本実施例において、サーバ一覧テーブル１０１は、各機構の処理性能を表す情報として、下位最大接続数３０４を保持する。この値は、一つの中継サーバ１３０、配信サーバ１２０が、同時に接続可能な下流セッションの最大数を表す。
【００４５】
図４は、管理サーバ１００が保持する配信状況１０２の例を示した図である。
本実施例において、配信状況１０２は、配信ツリーを一意に識別する情報としてコンテンツ名４０１を保持する。
本実施例において、配信状況１０２は、配信ツリーがすでに確保している中継サーバ１３０のリソース数として、リソース数４０２を保持する。
【００４６】
リソース数４０２は配信ツリーに最大で接続可能なＨＧＷ１４０の数であり、サーバ一覧１０１に保持する性能情報である下位最大接続数３０５と、後述するツリー情報４０６とを利用して一意に計算できる。
本実施例において、配信状況１０２は、配信ツリーが収容しているクライアントユーザの数として、収容数４０３を保持する。
収容数４０３は、後述するツリー情報４０６に含まれるＵＲＩ４１１の中で、サーバ一覧１０１のタイプ３０２がＨＧＷであるものの数である。
【００４７】
本実施例において、配信状況１０２は、配信ツリーが追加で収容できるクライアント数として、空き数４０４を保持する。
空き数４０４は、リソース数４０２と収容数４０３から一意に決定する。
本実施例において、配信状況１０２は、時間当たりの収容数の変化率として、増減率４０５を保持する。
【００４８】
増減率４０５は、例えば１分おきに収容数４０３の差分を計算することで取得する。
本実施例において、配信状況１０２は、配信ツリーの態様を一意に把握する情報として、ツリー情報４０６を保持する。
ツリー情報４０６は、配信ツリーに接続されている配信サーバ１２０、中継サーバ１３０、ＨＧＷ１４０のＵＲＩの一覧であるＵＲＩ４１１と、トップノードである配信サーバ１３０の値を０として接続されている枝の深さを表す深さ４１２と、各ノードに対して接続されている下流セッションの数である接続数４１３と、各ノードの上流に接続されているノードのＵＲＩである上位ノード４１４と、各ノードの下流に接続されているノードのＵＲＩの一覧である下位ノード４１５を保持する。
【００４９】
図５は、管理サーバ１００が保持するリソース確保ポリシ１０３の例を示した図である。
本実施例において、リソース確保ポリシ１０３は、配信ツリーを一意に識別するためのコンテンツ名５０１を保持する。
これにより、配信ツリーごとに後述する判定イベント発生条件５０２と、配信ツリー構築ポリシ５０４を保持することができ、コンテンツ提供者との契約に応じて、配信ツリーごとにリソース確保ポリシを設定することができる。
【００５０】
本実施例において、リソース確保ポリシ１０３は、コンテンツ名５０１ごとに、ポリシ判定処理を実行するトリガとなる判定イベント発生条件５０２を保持する。
これにより、例えば一定の時間間隔ごとに判定処理をするだけでなく、他の配信ツリーの判定結果をもとに、配信ツリーのリソース確保ポリシを判定できるようになる。
また、判定イベント発生条件を複数設定することで、配信ツリーの再構築が頻繁に実施され、クライアントが頻繁に転送されてしまい、当該クライアントが享受する配信品質が低下する問題については、後述するユーザ一覧１０４を利用することで解決できる。
【００５１】
本実施例において、リソース確保ポリシ１０３は、判定イベント発生条件５０２ごとに、該当の判定イベントが発生した場合に、実行するポリシ判定処理において満足されているかを判定する要求５１２のカテゴリである種別５１３の値を、判定種別５０３として保持する。
これにより、他の配信ツリーのリソース不足が起因となる判定イベントが発生した場合には、余剰リソース解放に係る種別の要求のみを判定することができ、ポリシ判定処理にかかる処理負荷を軽減できる。
【００５２】
また、後述する優先順序５１１の値が必須ではない、リソース確保に係る要求５１２によって、ポリシ判定中の配信ツリーにさらにリソースが確保されてしまうことを防止でき、設定した判定イベント発生条件５０２の設定意図に反しないようにポリシ判定を実行することができるようになる。
本実施例において、リソース確保ポリシ１０３は、配信ツリー構築ポリシとして、サーバ一覧１０１と配信状況１０２が保持する値を用いて一意に判定できる要求５１２と、その要求５１２が競合した場合に順守を優先する順位か、もしくは必ず順守する必要があることを示す優先順序５１１と、その要求がリソースの追加確保に係るものであるか余剰リソースの解放に係るものであるかを表す値である種別５１３と、を組みにして１つ以上保持する。
優先順序５１１を保持することにより、複数の要求５１２が競合した場合に後述する配信ツリー再計算処理がデッドロックすることを回避できる。
【００５３】
コンテンツ名５０１に対応する配信ツリーのポリシ判定処理を実施するきっかけとなる判定イベント発生条件５０２と、判定イベント発生条件５０２が発生した際に判定を実施する配信ツリー構築ポリシを構成する要求５１２の種別５１３を指定する判定種別５０３を保持する。
【００５４】
図６は、管理サーバ１００が保持するユーザ一覧１０４の例を示した図である。
本実施例において、ユーザ一覧１０４は、クライアントユーザを識別する情報としてユーザＩＤ６０１を保持する。
本実施例において、ユーザ一覧１０４は、クライアントユーザが利用しているＨＧＷ１４０のＵＲＩ６０２を保持する。
本実施例において、ユーザ一覧１０４は、ユーザの属性情報として、ユーザ属性６０３を保持する。
【００５５】
ユーザ属性とは、例えばコンテンツ配信システムに対する課金情報であり、本実施例では、課金しているユーザを“ｐｒｅｍｉｕｍ”、課金していないユーザを“ｇｕｅｓｔ”として表している。
本実施例において、ユーザ一覧１０４は、配信ツリー再構築のために、ユーザＩＤ６０１が使用する端末に対応するＵＲＩ６０２に対する転送制御を次回許可する時刻として、次回再配置可能時刻６０４を保持する。
【００５６】
転送を行ったユーザについては、次回再配置可能時刻６０４を設定し、その値が示す時刻になるまでは、そのユーザに対する転送制御を行わないようロックすることで、同一のユーザが短時間の間に連続して転送されて、そのユーザが受信するコンテンツデータの配信品質が劣化することを防止できる。
また、ユーザ属性６０３が“ｐｒｅｍｉｕｍ”のユーザについては、次回再配置可能時刻６０４の値を設定する際の時間間隔を“ｇｕｅｓｔ”ユーザより長く設定することで課金しているユーザの配信品質をさらに向上することができる。
【００５７】
図７は、クライアントポータル部１９０が保持する配信データ一覧１１１の例を示した図である。
配信データ一覧１１１の各値は、例えば、コンテンツ提供者が配信登録を行う際に入力させることで取得する。
本実施例において、配信データ一覧１１１は、クライアントポータル部１９０にアクセスしてきたクライアントユーザに対して、コンテンツ配信システムが配信中のコンテンツの一覧を提示するために用いる情報であり、例えば、コンテンツ提供者を識別する配信者ＩＤ７０１と、配信中のコンテンツを識別するためのコンテンツ名７０２と、コンテンツの概要を説明する文字列であるコンテンツ概要７０３と、配信開始時刻７０４と、配信終了時刻７０５を保持する。
【００５８】
図８は、バインド情報１３４、バインド情報１４０の例を示した図である。
バインド情報１３４とバインド情報１４０はいずれも、配信ツリーの中の、自らの装置が直接上流か下流のいずれかであるセッションの情報であり、例えば、コンテンツ名８０１と、上流セッションを指定する情報である上位ノードと、下流セッションを指定する下位ノードを保持する。
配信ツリーを構成するためには、受信したデータストリームをどのセッションに対して送信するかを識別する情報が必要であり、バインド情報１３４、バインド情報１４０はその情報を保持する。
【００５９】
図９は、コンテンツ提供者が、配信サーバ１２０を用いてはストリーミング配信を行うために、コンテンツ配信システムに配信情報を登録し、配信準備を行う処理の例を示した図である。
配信情報登録９０１はコンテンツ提供者がコンテンツ配信システムに対して自らが配信するコンテンツの情報を登録する処理であり、コンテンツ提供者が配信サーバ１２０の配信情報登録部１２１を用いて、ネットワーク１６０を介し、配信サーバポータル部１８０に対して、配信を予定するコンテンツの情報を送信する。
配信を予定するコンテンツの情報とは、コンテンツ配信システムが配信ツリーを構成するために必要である、配信サーバ１２０を識別してサーバ一覧１０１とリソース確保ポリシ１０３に格納する情報と、クライアントユーザに対して配信情報を掲示するために必要な配信データ一覧１９１に格納する情報を含む。
配信準備要求９０２は、配信サーバポータル部１８０が、管理部ＩＦ１８２を用いて、管理部に対して配信情報登録９０１において配信情報を送信した配信サーバ１２０のコンテンツ詩配信システムへの接続するための制御を管理サーバ１００へ要求する。
【００６０】
中継サーバ選択９０３は、配信ツリーのトップノードである配信サーバ１２０に対して、次数１となる中継サーバ１３０を選択する処理である。中継サーバの選択１３０においては、リソース確保ポリシの中１０３の、優先順序５１１の値が“必須”である要求５１２を満たすように選択する。
接続制御９０４は、管理部１００が、セッション制御ＩＦ１０８を用いて、中継型ミラーサーバ選択９０３において選択した中継サーバと、配信情報登録９０１において配信情報を送信した配信サーバ１２０との間にセッションを確立させる処理である。
配信準備応答９０５は、接続制御９０４の処理で管理サーバ１００が発行したセッション確立命令に応じて配信サーバ１２０と中継サーバ１３０の間にセッションが確立されたことを、配信サーバポータル部１８０に対し管理部１００が通知する処理である。
配信情報公開９０６は、配信サーバポータル部１８０が、配信準備応答９０５を受け、クライアントポータル部１９０に対して、配信データ一覧１９１に格納するための情報を通知する処理である。
【００６１】
クライアントポータル部１９０は、配信データ一覧１９１に受信した情報を格納し、クライアントＩＦ１９２を介して、配信データ一覧１９１の情報を、配信予定のコンテンツ情報としてクライアントユーザに対して提示する。
また、配信開始時刻を過ぎて、配信中のコンテンツデータについては、クライアントポータル部１９０が、クライアント１５０の配信データ利用アプリケーション１５１を起動してＨＧＷ１４０に接続させるためのストリーミングメディア・メタファイルを準備するなどの手段を用いることで、クライアントユーザによる配信データ利用アプリケーション１５１を起動してＨＧＷ１４０にアクセスする操作を省略させることができる。
【００６２】
図１１は、管理部１００のポリシ判定部１０６が行う、ポリシ判定処理の例を示した図である。
判定イベント発生１１０１は、リソース確保ポリシ１０３の判定イベント発生条件５０２のいずれかを満足したことを表す。
順守要求リスト生成１１０２は、現在の状況がポリシに違反していないかを判定する１１０３の処理、および、配信ツリーが変更可能かを判定する１１０４の処理の際に用いる、順守が必要な要求の一覧を生成する処理である。
種別５１３の値が、発生した判定イベント発生条件５０２の判定種別５０３の値と等しいか、もしくは、優先順序５１１の値が“必須”である、すべての要求を順守要求リストとする。
【００６３】
１１０３に示す分岐判定処理は、１１０２で生成したすべての順守要求リストについて、それぞれ満足しているかを、サーバ一覧１０１と配信状況１０２の値を用いて判定する処理である。
すべてを満足していれば何もせずに処理を終了し、いずれかが満たされていなければ、１１０４に進む。
１１０４に示す分岐判定処理は、現在の配信ツリーが、１１０２で生成した順守が必要な要求の一覧を満たすように変更可能か否かについて判定する処理である。また、本処理では、配信ツリーが変更可能であると判断した場合には、さらに、変更後の配信ツリーの形状についても計算する。本処理の詳細は後述の図１２である。
【００６４】
変更不可能であると判定した場合は１１０６に進み、そうでなければ１１０５に進む。つまり、管理装置は、クライアント装置が送信したコンテンツデータの配信要求を受信し、予め決められた配信ツリーのポリシを記憶し、コンテンツデータの配信ツリーのポリシに基づいて変更するか否かを判定し、判定の結果が変更の場合は、予め定められたポリシに基づいて配信ツリーを変更する。
配信ツリー変更制御１１０５は、１１０４の処理の結果として返された変更後の配信ツリーと、配信状況１０２が保持するツリーの状態の差分を取り、ツリーの状態が変更後の配信ツリーと同一になるように、セッションの制御と切断と転送を実施する処理である。
【００６５】
転送が発生したＨＧＷ１４０については、ユーザ一覧１０４の次回再配置可能時刻６０４を更新する。これにより、短時間に転送が頻繁に発生することを防止する。つまり、コンテンツデータの配信ツリーのポリシに基づいて変更するか否かを判定し、判定の結果が変更でなかった場合は、予め定められた前記ポリシに基づいて他の配信サーバにおける他の配信サーバにおける他の配信ツリーの変更も判定し、他の配信サーバの判定結果が変更の場合は、前記ポリシに基づいて配信ツリーと、他の配信ツリーとを変更する。
配信ツリー変更制御１１０５は、サーバ一覧１０１の値を用いて、セッション制御部ＩＦ１０８がセッション制御部１７０へセッション制御命令を送信することで実施する。つまり、配信サーバと、他の配信サーバと、中継サーバとに、新たな前記配信ツリーと、新たな前記他の配信ツリーの接続情報を送信し、配信サーバは、管理装置から受信した新たな配信ツリーの情報に基づいてコンテンツデータを送信し、他の配信サーバは、管理装置から受信した新たな他の配信ツリーの情報に基づいて前記コンテンツデータを送信する。
【００６６】
クライアント要求拒絶１１０６は、クライアントの要求を拒絶する処理であり、この判定イベントが発生した条件が「クライアント収容」であった場合に実施される。本処理では、クライアント１５０に対して、現在配信が不可能である旨のメッセージが返答される。
以上、図１１に示したように、本システムは、必須ではないが極力満たすべきポリシを保持し、そのポリシに適合するよう配信ツリーの再配置をイベントドリブンで実施する。
【００６７】
図１２は、管理部１００が現在の配信ツリーが渡された順守要求リストを満足する範囲で配信ツリーを変更可能か判定する処理である。
１２０１に示した分岐判定処理は、本処理が開始されてから１２０３から１２０７に示す処理を実施していない要求が順守要求リストに存在するかを判定する処理である。
存在すれば１２０２に、存在しなければ１２０８に進む。
１２０２は、順守要求リストの中から、１２０３から１２０７に示す処理を実施していない要求を一つ選択する処理である。
選択に当たっては、優先順序５１１の値が小さいものを優先的に選択する。
また、優先順序５１１の値が“必須”のものが一つ存在すれば、それを選択する。
また、優先順序５１１の値が“必須”のものが複数存在すれば、それを任意に一つ選択する。
【００６８】
１２０３は、１２０５、１２０６の処理で用いる判定要求リストを生成する処理である。
判定要求リストは、順守要求リストに含まれる要求の中で、優先順序５１１の値が“必須”の全ての要求、および、選択中の要求の優先順序５１１の値より小さい全ての要求とする。
１２０４に示す分岐判定処理は、選択中の要求の種別５１３の値によって処理の内容を振り分けるものである。種別５１３の値が“解放”であれば１２０５へ、種別５１３の値が“確保”であれば１２０６へ進む。
解放判定１２０５はリソース解放に係る配信ツリー再配置処理が可能か判定する処理であって、選択中の要求と、判定要求リストと、配信ツリーを引数とする。
【００６９】
引数の配信ツリーとしては、本処理が開始されてから既に１度以上１２０７の処理が実施されている場合は変更後配信ツリー、そうでなければ配信状況１０２が保持する配信ツリー状況を引数とする。
結果が、変更可能であれば１２０７へ、そうでなければ１２０８へ進む。
本処理の詳細は図１３に示す。
【００７０】
確保判定１２０６はリソース解放に係る配信ツリー再配置処理が可能か判定する処理であって、選択中の要求と、判定要求リストと、配信ツリーを引数とする。
引数の配信ツリーとしては、本処理が開始されてから既に１度以上１２０７の処理が実施されている場合は変更後配信ツリー、そうでなければ配信状況１０２が保持する配信ツリー状況を引数とする。
結果が、変更可能であれば１２０７へ、そうでなければ１２０８へ進む。
処理の詳細は図１４に示す。
【００７１】
変更後配信ツリーを上書き１２０７は、１２０５、及び１２０６の結果返された配信ツリーの情報を記憶して再度１２０１の処理に戻る処理である。
１２０８に示す分岐判定処理は、変更後配信ツリーが記憶されているかを判定する処理である。
変更後配信ツリーが記憶されていれば１２０９に、そうでなければ１２１０に進む。
変更可能１２０９は、配信ツリーが変更可能であるとして、結果として変更後配信ツリーを返す処理である。
変更不可能１２１０は、配信ツリーが変更不可能であるとして、結果を返す処理である。
【００７２】
図１３は、管理部１００の配信ツリー再計算部１０７が行う、リソース解放に係る要求について、他の制限となる要求に抵触せずに配信ツリーの変更が可能かを判定する処理である。
本処理は、対象とする要求と、制限とする判定要求リストと、配信ツリーと、を引数とし、変更が可能であるか否かと、変更が可能であれば、変更後の配信ツリーを返す処理である。
本処理は配信ツリーの態様について計算を行う処理であり、実際のセッションの確立・切断・転送制御は、図１０の配信ツリー変更制御１００７、もしくは、図１１の配信ツリー変更制御１１０５の中で行う。
【００７３】
１３０１に示す分岐判定処理は、１３０６によって記憶している変更後配信ツリーか、まだ１３０６を一度も実施していない場合は、引数として渡された配信ツリーが、引数として渡された対象とする要求を満足しているかを判定する処理である。
満足していれば１３０７へ、満足していなければ１３０２へ進む。
１３０２に示す分岐判定処理は、余剰リソース解放のために、配信ツリーから切断する候補となる中継サーバ１３０を選択する処理である。
候補としては、配信状況１０２の下位ノード４１５の全てが、サーバ一覧１０１のタイプ３０２の値が“ＨＧＷ”で、かつ、ユーザ一覧１０４の次回再配置可能時刻６０４の値が現在時刻より以前である、を満たしている中継サーバ１３０を選択する
これにより、配信ツリーの最も下位に接続されたノードを配信ツリーから切断する候補として選択できる。
【００７４】
また、これにより、同じクライアントユーザに対する転送が短時間に頻繁に発生することを防止できる。
候補が存在しなければ１３０９へ、存在すればもっとも接続されているＨＧＷの数が少ないものを一つ選択して１３０３へ進む。
１３０３に示す分岐処理は、１３０２で選択した中継サーバ１３０に接続されたＨＧＷ１４０全てを配信ツリーの他の中継サーバ１３０に転送すると判定する処理である。
【００７５】
選択中の中継サーバ１３０を除いた配信ツリーに全てを収容できるだけの空きがなければ１３０９へ、そうでなければ１３０４へ進む。
１３０４の処理は、１３０３で選択した中継サーバ１３０を切断すると判定する処理である。
１３０５に示す分岐処理は、１３０２、１３０３、１３０４の処理の結果となる配信ツリーが、引数として渡された判定要求リストに違反しないかを判定する処理である。
判定要求リストに含まれる全ての要求を満足していれば１３０６へ、そうでなければ１３０９へ進む。
【００７６】
１３０６は、１３０２、１３０３、１３０４の処理の結果となる配信ツリーの情報を記憶して再度１３０１の処理に戻る処理である。
１３０７に示す分岐処理は、変更後配信ツリーが記憶されているかを判定する処理である。
変更後配信ツリーが記憶されていれば１３０８に、そうでなければ１３０９に進む。
変更可能１３０８は、配信ツリーが変更可能であるとして、結果として変更後配信ツリーを返す処理である。
変更不可能１３０９は、配信ツリーが変更不可能であるとして、結果を返す処理である。
【００７７】
図１４は、管理部１００の配信ツリー再計算部１０７が行う、リソース確保に係る要求について、他の制限となる要求に抵触せずに配信ツリーの変更が可能かを判定する処理である。
本処理は、対象とする要求と、制限とする判定要求リストと、配信ツリーと、を引数とし、変更が可能であるか否かと、変更が可能であれば、変更後の配信ツリーを返す処理である。
本処理は配信ツリーの態様について計算を行う処理であり、実際のセッションの確立・切断・転送制御は、図１０の配信ツリー変更制御１００７、もしくは、図１１の配信ツリー変更制御１１０５の中で行う。
【００７８】
１４０１に示す分岐判定処理は、１４０９によって記憶している変更後配信ツリーか、まだ１４０９を一度も実施していない場合は、引数として渡された配信ツリーが、引数として渡された対象とする要求を満足しているかを判定する処理である。
満足していれば１４１０へ、満足していなければ１４０２へ進む。
【００７９】
１４０２に示す分岐判定処理は、リソース追加確保のために、配信ツリーへ新たに接続する候補となる中継サーバ１３０を選択する処理である。
候補としては、サーバ一覧１０１の中で下位最大接続数３０５空き数の最も多いものを選択する。
候補となる中継サーバ１３０が一つも存在しなければ１４１１へ、そうでなければ１４０３へ進む。
【００８０】
１４０３に示す分岐処理は、１４０２で選択した中継サーバ１３０と直接セッションを確立させるための、配信ツリー内の中継サーバ１３０を選択する処理である。
空きのある中継サーバが一つも存在しなければ１４０５へ、そうでなければ、配信ツリーの中で上位に接続されている中継サーバ１３０から優先して一つ選択して１４０７へ進む。
【００８１】
１４０５、１４０６に示す処理は、新たに中継サーバ１３０を配信ツリーに追加するために、すでに接続されているＨＧＷ１４０の一つを先に追加予定の中継サーバ１３０へ接続させることで、既存の配信ツリーに空きを一つ作り、できた空きに対して追加予定の中継サーバ１３０を接続させるための処理である。
１４０５に示す分岐処理は、配信ツリー内の中継サーバ１３０の中から、空きを作らせる中継サーバ１３０の候補を一つ選択する処理である。
候補としては、配信状況１０２の下位ノード４１５の中で、サーバ一覧１０１のタイプ３０２の値が“ＨＧＷ”で、かつ、ユーザ一覧１０４の次回再配置可能時刻６０４の値が現在時刻より以前である、を満たしているものが一つ以上存在する中継サーバ１３０を選択する。
複数の候補が存在する場合は、配信ツリーの最も上位のものを優先的に選択する。
【００８２】
これにより、中継ミラーが多段階に接続されることを軽減し、ストリーミング配信の遅延を軽減する効果が得られる。
候補が存在すれば１４０６へ、そんざいしなければ１４１２へ進む
１４０６に示す処理は、接続されているＨＧＷ１４０の一つを先に追加予定の中継サーバ１３０へ接続させることを判断する処理である。
１４０５で選択した中継サーバ１３０の下位ノードの中から、ユーザ一覧１０４の次回再配置可能時刻６０４の値が現在時刻より以前であるＨＧＷ１４０を一つ選択、選択したＨＧＷ１４０のセッションを、１４０２で選択した中継サーバ１３０へ転送すると判定する。
【００８３】
１４０７の処理は、１４０２で選択した中継サーバ１３０と、１４０３もしくは１４０５で選択した中継サーバ１３０の間にセッションを確立すると判定する処理である。
１４０８に示す分岐処理は、１４０２から１４０７の一連の処理の結果となる配信ツリーが、引数として渡された判定要求リストに違反しないかを判定する処理である。
判定要求リストに含まれる全ての要求を満足していれば１４０９へ、そうでなければ１４１２へ進む。
【００８４】
１４０９は、１４０２から１４０７の一連の処理の結果となる配信ツリーの情報を記憶して再度１４０１の処理に戻る処理である。
１４１０に示す分岐処理は、変更後配信ツリーが記憶されているかを判定する処理である。
変更後配信ツリーが記憶されていれば１４１１に、そうでなければ１４１２に進む。
【００８５】
変更可能１４１１は、配信ツリーが変更可能であるとして、結果として変更後配信ツリーを返す処理である。
変更不可能１４１２は、配信ツリーが変更不可能であるとして、結果を返す処理である。
【００８６】
図１５は、ある配信ツリーで配信リソースが不足した場合に、他の配信リソースに余剰のある配信ツリーからその配信リソースを取得する様子を例示した図である。
図１５は、配信サーバ「ｓｅｒｖｅｒＡ」と配信サーバ「ｓｅｒｖｅｒＢ」がそれぞれコンテンツ配信中である時の、それぞれの配信ツリー（「ツリーＡ」、「ツリーＢ」）を例示した図である。 
新規にｓｅｒｖｅｒＢが配信するコンテンツを要求するクライアントが到着した場合、そのままそのクライアントを収容すると、既に配信サーバと中継サーバは最大接続数に達しているため、配信ツリー構築ポリシに抵触する。 
利用可能な中継サーバがあれば、図１６をスキップして図１０に移る。利用可能な中継サーバがなければ図１６に示す処理を実施し、その結果解放された中継サーバを利用して図１０に移る。つまり、管理装置は、複数の配信サーバに接続されたクライアント装置の台数と、配信サーバが収容可能な台数を記憶し、クラインアント装置の台数が当該配信サーバが収容可能な台数より多い場合、配信ツリーを変更する。
図１６は、「ツリーＢで、配信ツリー構築ポリシ違反が発生した」ことをきっかけにして、ツリーＡが自らの解放ポリシに違反していないかを判定し、その結果として、余分に確保していた中継サーバ（「ｍｉｒｒｏｒ３」）を配信ツリーから解放した例を表している。 
本発明は、判定イベント発生条件（５０２）の2行目に示したような条件を保持することで、いずれかの配信ツリーでリソースが不足する状況になった際に、別のツリーが自らの配信ツリー構築ポリシを満足する範囲の中で、余分に確保している中継サーバを解放することを可能にしている。 
また、その際、中継サーバにクライントが接続されている場合、そのまま切断すると、その中継サーバに接続されているクライアントも配信ツリーから切断されてしまう。従って、接続されている全てのクライアントを別の中継サーバへ振り分ける必要がある。本発明では、図１３に示した処理フローの１３０２から１３０４の処理を実施することでこの問題を解決している。 
また、１３０２においては、ユーザ一覧１０４の中の次回再配置可能時刻６０４を満たすユーザのみを転送するように制御することで、同一のユーザが頻繁に転送されてそのユーザのサービス品質が劣化することも回避している。 
図１０は、図１６で新たに解放した中継サーバをツリーＢに接続することで新規に配信リソースを確保し、新規到着クライアントをツリー内に収容する例を表している。
本処理は、図１４に示した確保判定処理の処理フローに従う。すなわち、新規に接続する中継サーバの接続先として、配信ツリー内の中継サーバに空きがあればその中継サーバへ接続する。空きがなければ、ユーザ一覧１０４の中の次回再配置可能時刻６０４を満たすユーザを選択して、そのユーザが接続されている中継サーバへ接続する。つまり、管理装置は、他の配信サーバの収容台数が、収容可能な台数より少ない場合、他の配信サーバに接続された中継サーバの接続を切断するよう変更し、当該中継サーバは、配信サーバ接続するよう変更する。これにより、ユーザの転送を最小限に抑えることができ、サービス品質の劣化を抑えることができる。
以上本実施例に示した処理に従うことで、本発明のデータ配信システムは上述した効果を得ることができる。
【符号の説明】
【００８７】
１００  管理部
１０１  サーバ一覧テーブル
１０２  配信状況テーブル
１０３  リソース確保ポリシテーブル
１０４  ユーザ一覧テーブル
１０５  配信状況管理部
１０６  ポリシ判定部
１０７  配信ツリー再計算部
１２０  配信サーバ
１３０  中継サーバ
１４０  ＨＧＷ
１５０  クライアント
１６０  ネットワーク
１７０  セッション制御部
１８０  配信サーバポータル部
１９０  クライアントポータル部
２００  各構成要素のハードウェア構成要素
【図１】
2013106283.tif 000003
【図２】
2013106283.tif 000004
【図３】
2013106283.tif 000005
【図４】
2013106283.tif 000006
【図５】
2013106283.tif 000007
【図６】
2013106283.tif 000008
【図７】
2013106283.tif 000009
【図８】
2013106283.tif 000010
【図９】
2013106283.tif 000011
【図１０】
2013106283.tif 000012
【図１１】
2013106283.tif 000013
【図１２】
2013106283.tif 000014
【図１３】
2013106283.tif 000015
【図１４】
2013106283.tif 000016
【図１５】
2013106283.tif 000017
【図１６】
2013106283.tif 000018