(57)【要約】【課題】サーバやネットワークの負荷を抑制してコンテンツ配信システムを実現する。【解決手段】コンテンツ取得要求受信部３１０はユーザからコンテンツ取得要求を受信する。分類制御部３２４は、このコンテンツ取得要求を割り当てるべきキャッシュサーバに関する情報などに基づき分類する。また、バッチング時間演算部３２６はこの分類に応じて、バッチング時間を設定する。コンテンツ取得要求をコンテンツごとに、バッチング時間を周期としてマルチキャストストリームを生成することにより、ユーザは所望のコンテンツを受信する。【選択図】  図８
2005018293.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続されるクライアント端末から、画像または音声データを含むことにより構成される所望のデジタルコンテンツについての取得要求であるコンテンツ取得要求を受信する取得要求受信部と、
前記受信したコンテンツ取得要求ごとに、その要求するデジタルコンテンツを送信すべきキャッシュサーバを割り当てるキャッシュサーバ選択部と、
前記割り当てたキャッシュサーバが送信すべきデジタルコンテンツごとに所定の待機時間であるバッチング時間を設定するバッチング時間設定部と、
前記設定したバッチング時間が経過したことを契機として、前記割り当てたキャッシュサーバから前記クライアント端末への前記デジタルコンテンツの送信を行わしめるキャッシュサーバ制御部と、を含むことを特徴とするコンテンツ配信制御装置。
【請求項２】
前記キャッシュサーバ選択部は、前記受信したコンテンツ取得要求において要求されるデジタルコンテンツに基づいて、前記キャッシュサーバを割り当てることを特徴とする請求項１に記載のコンテンツ配信制御装置。
【請求項３】
前記キャッシュサーバ選択部は、前記受信したコンテンツ取得要求を行ったクライアント端末に関する情報に基づいて、前記キャッシュサーバを割り当てることを特徴とする請求項１または２に記載のコンテンツ配信制御装置。
【請求項４】
前記受信したコンテンツ取得要求において要求されるデジタルコンテンツにつき、既にコンテンツ取得要求が行われている場合において、前記受信したコンテンツ取得要求を行ったクライアント端末と、前記既に行われているコンテンツ取得要求について割り当てられているキャッシュサーバとのネットワーク距離が所定の値以上であれば、前記キャッシュサーバ選択部は、前記受信したコンテンツ取得要求に対しては、前記割り当てられているキャッシュサーバとは別のキャッシュサーバを割り当てることを特徴とする請求項１から３のいずれかに記載のコンテンツ配信制御装置。
【請求項５】
前記受信したコンテンツ取得要求を行ったクライアント端末が、マルチキャストに対応するネットワークに所属しているか否かを検出する所属ネットワーク判断部、を更に含み、
前記所属ネットワーク判断部が、前記クライアント端末はマルチキャストネットワークに所属していないことを検出した場合には、前記キャッシュサーバ制御部は、前記バッチング時間が経過していなくとも、前記キャッシュサーバから前記クライアント端末への前記デジタルコンテンツの送信を行わしめることを特徴とする請求項１から４のいずれかに記載のコンテンツ配信制御装置。
【請求項６】
前記キャッシュサーバにかかる処理負荷に関する情報であるサーバ負荷情報を検出するサーバ負荷検出部、を更に含み、
前記キャッシュサーバ選択部は、前記検出したサーバ負荷情報に基づいて、前記受信したコンテンツ取得要求において要求されるデジタルコンテンツを送信すべきキャッシュサーバを割り当てることを特徴とする請求項１から５のいずれかに記載のコンテンツ配信制御装置。
【請求項７】
前記バッチング時間設定部は、前記割り当てたキャッシュサーバについて検出したサーバ負荷情報に基づいて、前記バッチング時間の長さを変化させることを特徴とする請求項６に記載のコンテンツ配信制御装置。
【請求項８】
前記バッチング時間設定部は、前記割り当てたキャッシュサーバが送信すべきデジタルコンテンツに対する前記コンテンツ取得要求の数に基づいて、前記バッチング時間を設定することを特徴とする請求項１から７のいずれかに記載のコンテンツ配信制御装置。
【請求項９】
前記キャッシュサーバ選択部による前記キャッシュサーバの割り当て方についての規則である第１のポリシの入力を検出する第１ポリシ設定部、を更に含み、
前記入力を検出した第１のポリシに基づいて、前記キャッシュサーバ選択部は前記キャッシュサーバの割り当てを行うことを特徴とする請求項１から８に記載のコンテンツ配信制御装置。
【請求項１０】
前記バッチング時間設定部による前記バッチング時間を設定するための規則である第２のポリシの入力を検出する第２ポリシ設定部、を更に含み、
前記入力を検出した第２のポリシに基づいて、前記バッチング時間設定部は前記バッチング時間の設定を行うことを特徴とする請求項１から９のいずれかに記載のコンテンツ配信制御装置。
【請求項１１】
ネットワークを介して接続されるクライアント端末から、画像または音声データを含むことにより構成される所望のデジタルコンテンツについての取得要求であるコンテンツ取得要求を受信する取得要求受信部と、
前記受信したコンテンツ取得要求において要求されるデジタルコンテンツを検出するコンテンツ検出部と、
前記検出したデジタルコンテンツごとに、前記受信したコンテンツ取得要求を分類する取得要求分類部と、
前記分類したコンテンツ取得要求を一時的に保持するためのメモリ領域である取得要求保持領域を、前記分類ごとに記録媒体において確保する取得要求保持領域管理部と、
前記確保した取得要求保持領域のそれぞれにおいて保持するコンテンツ取得要求群ごとに、それらのコンテンツ取得要求が要求するデジタルコンテンツを送信すべきキャッシュサーバを割り当てるキャッシュサーバ設定部と、
前記確保した取得要求保持領域のそれぞれにおいて保持するコンテンツ取得要求群ごとに、それらのコンテンツ取得要求を一時的に保持すべき時間であるバッチング時間を設定するバッチング時間設定部と、
前記設定したバッチング時間の経過状況を監視するバッチング時間管理部と、前記設定したバッチング時間の経過を検出した場合には、そのバッチング時間に対応する前記取得要求保持領域に保持されているコンテンツ取得要求を読み出し、前記取得要求保持領域に対応して割り当てたキャッシュサーバから前記読み出したコンテンツ取得要求を行ったクライアント端末への前記デジタルコンテンツの配信を行わしめるキャッシュサーバ制御部と、を含むことを特徴とするコンテンツ配信制御装置。
【請求項１２】
ネットワークを介して接続されるクライアント端末から、画像または音声データを含むことにより構成される所望のデジタルコンテンツについての取得要求であるコンテンツ取得要求を受信するステップと、
前記受信したコンテンツ取得要求ごとに、その要求するデジタルコンテンツを送信すべきキャッシュサーバを割り当てるステップと、
前記割り当てたキャッシュサーバが送信すべきデジタルコンテンツごとに所定の待機時間であるバッチング時間を設定するステップと、
前記設定したバッチング時間が経過したことを契機として、前記キャッシュサーバから前記クライアント端末への前記デジタルコンテンツの送信を行わしめるステップと、を含むことを特徴とするコンテンツ配信制御方法。
【請求項１３】
ネットワークを介して接続されるクライアント端末から、画像または音声データを含むことにより構成される所望のデジタルコンテンツについての取得要求であるコンテンツ取得要求を受信する機能と、
前記受信したコンテンツ取得要求ごとに、その要求するデジタルコンテンツを送信すべきキャッシュサーバを割り当てる機能と、
前記割り当てたキャッシュサーバが送信すべきデジタルコンテンツごとに所定の待機時間であるバッチング時間を設定する機能と、
前記設定したバッチング時間が経過したことを契機として、前記キャッシュサーバから前記クライアント端末への前記デジタルコンテンツの送信を行わしめる機能と、をコンピュータに発揮させることを特徴とするコンテンツ配信制御プログラム。
【請求項１４】
ネットワークを介して接続されるクライアント端末から、画像または音声データを含むことにより構成される所望のデジタルコンテンツについての取得要求であるコンテンツ取得要求を受信する取得要求受信機能と、
前記受信したコンテンツ取得要求において要求されるデジタルコンテンツを検出するコンテンツ検出機能と、
前記検出したデジタルコンテンツごとに、前記受信したコンテンツ取得要求を分類する取得要求分類機能と、
前記分類したコンテンツ取得要求を一時的に保持するためのメモリ領域である取得要求保持領域を、前記分類ごとに記録媒体において確保する取得要求保持領域管理機能と、
前記確保した取得要求保持領域のそれぞれにおいて保持するコンテンツ取得要求群ごとに、それらのコンテンツ取得要求が要求するデジタルコンテンツを送信すべきキャッシュサーバを割り当てるキャッシュサーバ設定機能と、
前記確保した取得要求保持領域のそれぞれにおいて保持するコンテンツ取得要求群ごとに、それらのコンテンツ取得要求を一時的に保持すべき時間であるバッチング時間を設定するバッチング時間設定機能と、
前記設定したバッチング時間の経過状況を監視するバッチング時間管理機能と、
前記設定したバッチング時間の経過を検出した場合には、そのバッチング時間に対応する前記取得要求保持領域に保持されているコンテンツ取得要求を読み出し、前記取得要求保持領域に対応して割り当てたキャッシュサーバから前記読み出したコンテンツ取得要求を行ったクライアント端末への前記デジタルコンテンツの配信を行わしめるキャッシュサーバ制御機能と、
をコンピュータに発揮させることを特徴とするコンテンツ配信制御プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、ネットワーク上におけるコンテンツ配信技術に関する。
【０００２】
【従来の技術】
近年、インターネットのブロードバンド化に伴いＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）や電子メールなどのテキストデータだけではなく、音声や動画像といったマルチメディアデータを用いたコンテンツ配信サービスが行われるようになった。その中でもビデオオンデマンド（Ｖｉｄｅｏ−ｏｎ−Ｄｅｍａｎｄ：以下、「ＶＯＤ」と表記する）は、ホームエンターテイメント、デジタルビデオ・ライブラリ、ムービー・オンデマンド、遠隔授業、遠隔会議、インターネットショッピング、ニュース・オンデマンド、医療情報サービスなど、様々な分野での活用が期待されている。
【０００３】
【非特許文献１】
池田康  外４名、「ポリシ選択型ＣＤＮプラットフォームの構成と検証」、電子情報通信学会論文誌  通信ソサエティ、社団法人  電気通信情報学会、２００３年３月、ＶＯＬ．Ｊ８６−ＢＮｏ．３、ｐ．４００−４０９
【非特許文献２】
Ｈｕａｄｏｎｇ  Ｍａ、Ｋａｎｇ  Ｇ．Ｓｈｉｎ、”Ｍｕｌｔｉｃａｓｔ  Ｖｉｄｅｏ−ｏｎ−Ｄｅｍａｎｄ  Ｓｅｒｖｉｃｅｓ”、ＡＣＭ  ＳＩＧＣＯＭＭ  Ｃｏｍｐｕｔｅｒ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｒｅｖｉｅｗ  Ｖｏｌｕｍｅ  ３２、Ｉｓｓｕｅ  １、ｐｐ．３１−４３、Ｊａｎｕａｒｙ  ２００２
【０００４】
【発明が解決しようとする課題】
画像等を含むマルチメディアデータは、テキストデータに比べデータ量が大きいだけでなく、連続的に安定したネットワーク帯域を確保する必要があるため伝送コストが高い。したがって、ユーザからの配信要求が多くなり、ネットワークおよびサーバ処理能力を越えるとサービスの遅延・停止が発生する。
【０００５】
このような問題に対処すべく提案されている技術として、ＣＤＮ（Ｃｏｎｔｅｎｔ  Ｄｅｌｉｖｅｒｙ／Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｎｅｔｗｏｒｋ）がある。ＣＤＮは、コンテンツ配信のために複数のキャッシュサーバをネットワーク上に配置する。これらのキャッシュサーバはコンテンツのコピーを保持する。ＣＤＮはユーザがアクセスするクライアント端末のＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を調べて、最寄りのキャッシュサーバにつなぐ構成となっている。ユーザへのコンテンツ配信を複数のキャッシュサーバが行うため、ネットワークやキャッシュサーバの負荷が分散される効果がある。
【０００６】
しかし、ＣＤＮを用いたとしても、ユーザ数やコンテンツの数、コンテンツ自体のデータ量が増加すれば、そのたびにキャッシュサーバの増強を余儀なくされる。ＣＤＮはコンテンツ配信システムが高コスト構造からの脱却するための決定打ではないのである。また、ＣＤＮはユニキャスト通信に基づくコンテンツ配信であるゆえに、ユーザ数の増加はそのまま通信コネクション数の増加につながる。ネットワークへの負荷が大きくなるため、キャッシュサーバへのアクセス数が増えるとネットワークの許容範囲を超えることも多い。
【０００７】
本発明は上記背景に鑑みてなされたものであり、その目的は、ネットワークまたはキャッシュサーバの負荷を抑制してコンテンツの配信を行うための技術を提供すること、にある。
【０００８】
【課題を解決するための手段】
本発明のある態様は、コンテンツ配信制御装置に関する。この装置は、ネットワークを介して接続されるクライアント端末から、画像または音声データを含むことにより構成される所望のデジタルコンテンツについての取得要求であるコンテンツ取得要求を受信する取得要求受信部と、受信したコンテンツ取得要求ごとに、その要求するデジタルコンテンツを送信すべきキャッシュサーバを割り当てるキャッシュサーバ選択部と、その割り当てたキャッシュサーバが送信すべきデジタルコンテンツごとに所定の待機時間であるバッチング時間を設定するバッチング時間設定部と、設定したバッチング時間が経過したことを契機として、その割り当てたキャッシュサーバからクライアント端末へのデジタルコンテンツの送信を行わしめるキャッシュサーバ制御部を含む。
【０００９】
「キャッシュサーバ」とは、デジタルコンテンツをクライアント端末に送信する機能を有するサーバ装置をいう。同一のデジタルコンテンツを複数のキャッシュサーバが配信する能力を有してもよい。また、キャッシュサーバは、一台で複数のデジタルコンテンツを配信する能力を有してもよい。
コンテンツ配信制御装置は、クライアント端末と、キャッシュサーバを結びつけ、コンテンツ配信システム全体の制御を行うための装置である。
【００１０】
この装置のキャッシュサーバ選択部は、受信したコンテンツ取得要求において要求されるデジタルコンテンツに基づいて、キャッシュサーバを割り当ててもよい。
【００１１】
たとえば、多数のユーザからの需要が見込まれるデジタルコンテンツの場合には、一台のキャッシュサーバだけではすべてのユーザの要求に応えられない可能性がある。このような場合には、同一のデジタルコンテンツに対するコンテンツ取得要求を、複数のキャッシュサーバに振り分けることでキャッシュサーバやネットワークの負荷を分散できる。
【００１２】
この装置のキャッシュサーバ選択部は、受信したコンテンツ取得要求を行ったクライアント端末に関する情報に基づいて、キャッシュサーバを割り当ててもよい。
【００１３】
「クライアント端末に関する情報」とはクライアント端末のＩＰアドレス、所属するドメイン名、クライアント端末の性能などに関する機器情報、コンテンツ配信サービスに対する契約の内容、クライアント端末の所属するネットワークに関する情報などをいう。以下、このクライアント端末に関する情報のことを、単に「クライアント情報」とよぶ。
【００１４】
受信したコンテンツ取得要求において要求されるデジタルコンテンツにつき、既にコンテンツ取得要求が行われている場合において、受信したコンテンツ取得要求を行ったクライアント端末と、既に行われているコンテンツ取得要求について割り当てられているキャッシュサーバとのネットワーク距離が所定の値以上であれば、キャッシュサーバ選択部は、受信したコンテンツ取得要求に対しては、割り当てられているキャッシュサーバとは別のキャッシュサーバを割り当ててもよい。
【００１５】
「ネットワーク距離」とは、２つの通信ノード間における通信上の距離をいう。ネットワーク距離は、経由するルータやネットワークの数により定義されてもよい。あるいは、キャッシュサーバとクライアント端末の間の物理的な距離で定義してもよいし、通信スループットまで考慮して定義してもよい。
【００１６】
受信したコンテンツ取得要求を行ったクライアント端末が、マルチキャストに対応するネットワークに所属しているか否かを検出する所属ネットワーク判断部を更に含み、その所属ネットワーク判断部が、クライアント端末はマルチキャストネットワークに所属していないことを検出した場合には、キャッシュサーバ制御部は、バッチング時間が経過していなくとも、キャッシュサーバからクライアント端末へのデジタルコンテンツの送信を行わしめてもよい。
【００１７】
キャッシュサーバにかかる処理負荷に関する情報であるサーバ負荷情報を検出するサーバ負荷検出部を更に含み、キャッシュサーバ選択部は、検出したサーバ負荷情報に基づいて、受信したコンテンツ取得要求において要求されるデジタルコンテンツを送信すべきキャッシュサーバを割り当ててもよい。
【００１８】
「サーバ負荷情報」とは、キャッシュサーバのＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）の使用率、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）などの記録媒体のメモリ使用量やメモリ占有率、キャッシュサーバが処理しているネットワークコネクション数などであってもよい。また、キャッシュサーバの処理能力を考慮して処理負荷を判定してもよい。以下、このサーバ負荷情報の外にも、サーバのＩＰアドレス、所属するドメイン名、キャッシュサーバの性能などに関する機器情報、配信能力を有するコンテンツの内容などの情報も含め、キャッシュサーバに関する情報を、まとめて「サーバ情報」とよぶ。
特定のキャッシュサーバに負荷が集中している場合には、別のキャッシュサーバにも処理を分担させることにより、全体としてキャッシュサーバの負荷を分散できる。
【００１９】
この装置のバッチング時間設定部は、割り当てたキャッシュサーバについて検出したサーバ負荷情報に基づいて、バッチング時間の長さを変化させてもよい。
【００２０】
この装置のバッチング時間設定部は、割り当てたキャッシュサーバが送信すべきデジタルコンテンツに対するコンテンツ取得要求の数に基づいて、バッチング時間を設定してもよい。
【００２１】
キャッシュサーバ選択部によるキャッシュサーバの割り当て方についての規則である第１のポリシの入力を検出する第１ポリシ設定部を更に含み、入力を検出した第１のポリシに基づいて、キャッシュサーバ選択部はキャッシュサーバの割り当てを行ってもよい。
【００２２】
バッチング時間設定部によるバッチング時間を設定するための規則である第２のポリシの入力を検出する第２ポリシ設定部を更に含み、入力を検出した第２のポリシに基づいて、バッチング時間設定部はバッチング時間の設定を行ってもよい。
【００２３】
本発明の別の態様も、コンテンツ配信制御装置である。この装置は、ネットワークを介して接続されるクライアント端末から、画像または音声データを含むことにより構成される所望のデジタルコンテンツについての取得要求であるコンテンツ取得要求を受信する取得要求受信部と、受信したコンテンツ取得要求において要求されるデジタルコンテンツを検出するコンテンツ検出部と、検出したデジタルコンテンツごとに、受信したコンテンツ取得要求を分類する取得要求分類部と、分類したコンテンツ取得要求を一時的に保持するためのメモリ領域である取得要求保持領域を、その分類ごとに記録媒体において確保する取得要求保持領域管理部と、確保した取得要求保持領域のそれぞれにおいて保持するコンテンツ取得要求群ごとに、それらのコンテンツ取得要求が要求するデジタルコンテンツを送信すべきキャッシュサーバを割り当てるキャッシュサーバ設定部と、確保した取得要求保持領域のそれぞれにおいて保持するコンテンツ取得要求群ごとに、それらのコンテンツ取得要求を一時的に保持すべき時間であるバッチング時間を設定するバッチング時間設定部と、設定したバッチング時間の経過状況を監視するバッチング時間管理部と、設定したバッチング時間の経過を検出した場合には、そのバッチング時間に対応する取得要求保持領域に保持されているコンテンツ取得要求を読み出し、取得要求保持領域に対応して割り当てたキャッシュサーバから読み出したコンテンツ取得要求を行ったクライアント端末へのデジタルコンテンツの配信を行わしめるキャッシュサーバ制御部を含む。
【００２４】
本発明の更に別の態様は、コンテンツ配信制御方法である。この方法は、ネットワークを介して接続されるクライアント端末から、画像または音声データを含むことにより構成される所望のデジタルコンテンツについての取得要求であるコンテンツ取得要求を受信するステップと、受信したコンテンツ取得要求ごとに、その要求するデジタルコンテンツを送信すべきキャッシュサーバを割り当てるステップと、割り当てたキャッシュサーバが送信すべきデジタルコンテンツごとに所定の待機時間であるバッチング時間を設定するステップと、設定したバッチング時間が経過したことを契機として、キャッシュサーバからクライアント端末へのデジタルコンテンツの送信を行わしめるステップを含むことを特徴とする。
【００２５】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、サーバ、システム、コンピュータプログラム、記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【００２６】
【発明の実施の形態】
インターネット上においては、特定のサーバにユーザのアクセスが殺到することはよくある。特に、人気のあるデジタルコンテンツ（以下、単に「コンテンツ」とよぶ）を有するサーバに対しては、一時的に大量のアクセスが集中しやすい。特定のサーバにユーザからのアクセスが集中すればサーバの負荷は増加し応答性は悪くなる。また、通信トラフィックの急増はネットワークに局所的な輻輳を発生させやすい。近年のブロードバンド化は、音声や動画像などデータ量の大きなコンテンツを受信しながら同時に再生を行ういわゆるストリーミングを可能としつつある。ネットワークがブロードバンド化しても、サーバやネットワークの負荷は付随的に増えるのである。
【００２７】
ＩＰネットワーク上で伝送コストを減らす手法としてＩＰマルチキャスト（以下、単に「マルチキャスト」とよぶ）がある。マルチキャストとは、一度のデータ送信で複数のクライアントが同一データを受信できるデータ配信技術である。マルチキャスト配信の対象となるクライアント端末はそのマルチキャストグループに登録される。ルータは、サーバから受け取ったマルチキャスト配信のパケットが別々のネットワークに所属するクライアント端末にそれぞれ送信されるべきパケットであれば、パケットをコピーしてそれぞれのネットワークに流す。ユニキャストにおいては、サーバはサービスを受けるべきクライアントのそれぞれに対して通信コネクションを張り、クライアントそれぞれに対して同一のパケットを送信する。これに対して、マルチキャストにおいては、サーバが送出したパケットをルータが必要に応じてコピーするので、ネットワーク全体としての通信トラフィックが軽減される。また、サーバはクライアントごとに通信コネクションを張るための処理が必要でないので、サーバ自体の負荷も軽減される。
【００２８】
マルチキャストの利点をまとめると以下のようになる。
（１）クライアントごとに通信コネクションを張る必要がないため、ネットワークの通信帯域消費量が減少する。このため、ネットワーク全体としての通信トラフィックも軽減される。
（２）クライアントごとに通信コネクションを張る必要がないため、サーバの負荷が軽減される。このため、コンテンツ配信システム全体としてのスループットが向上する。
（３）新規のクライアントに対しても、その新規クライアントをマルチキャストグループに登録するだけで対応できるため、コンテンツ配信システム全体としてのスケーラビリティが高い。
【００２９】
しかし、既存のマルチキャスト配信方法では、複数のクライアントが同じマルチキャストストリームに参加するために、サーバに対して同時刻にアクセスする必要がある。ゆえに、マルチキャストはユーザが様々な時刻にアクセスするＶＯＤシステムのようなアプリケーションには不向きとされ、ＩＰレベルでのマルチキャスト・ＶＯＤは普及しなかった。
【００３０】
現在のＶＯＤを取り巻く状況は必ずしも盤石ではなく、新しいＶＯＤアーキテクチャが求められている。本発明で提案するコンテンツ配信制御装置は、ＩＰレベルでのマルチキャストに注目し、新しいマルチキャスト・ＶＯＤ（以下、「ＭＶＯＤ：Ｍｕｌｔｉｃａｓｔ  ＶＯＤ」とよぶ）アーキテクチャを提案するものである。
【００３１】
マルチキャスト配信をＶＯＤに近づけるための方法としてバッチング方式とよばれる方法がある。本実施の形態においては、コンテンツ配信制御装置にこのバッチング方式を取り入れることによりＭＶＯＤを実現する。コンテンツ配信制御装置とは、ユーザからのコンテンツ取得要求を適切なキャッシュサーバへ振り分けるコンテンツ配信システムを制御するための装置である。
【００３２】
図１は、コンテンツ配信システム２００の概念図である。コンテンツ配信システム２００は、キャッシュサーバ群２１０、クライアント端末群２２０およびコンテンツ配信制御装置２３０を含んで構成される。キャッシュサーバ群２１０は、コンテンツの配信を行うキャッシュサーバの集合であり、クライアント端末群２２０はキャッシュサーバからコンテンツの配信サービスを受けるべきクライアント端末の集合である。コンテンツ配信制御装置２３０は両者の仲介を行う装置である。コンテンツ配信制御装置２３０は、クライアント端末が要求するコンテンツを保持するキャッシュサーバをキャッシュサーバ群２１０から探索する。また、その探索したキャッシュサーバのうち、クライアント端末に対して実際にコンテンツを配信すべきキャッシュサーバの選択も行う。さらに、その選択されたキャッシュサーバが要求されたコンテンツをクライアント端末に配信するタイミングの制御も行う。
【００３３】
以下では、まずバッチング方式について説明し、コンテンツ配信制御装置にバッチング方式を取り入れる利点について説明する。その後、コンテンツ配信システム全体の処理について説明する。
【００３４】
「バッチング方式」とは、ある一定時間において、同じコンテンツに対する複数のクライアントからのコンテンツ取得要求を、一つのマルチキャストストリームで処理する方法である。以下、この一定時間のことを「バッチング時間」とよぶ。また、バッチング時間中におけるコンテンツ取得要求の募集を行うことを「バッチング」とよぶ。コンテンツを配信するサーバにはクライアントからのコンテンツ取得要求を一時的に蓄えるキューを用意する。キューに蓄えられたコンテンツ取得要求の送信元である複数のクライアントにつき、要求されるコンテンツごとにマルチキャストグループを生成する。そして、設定されたバッチング時間を周期として定期的にマルチキャストストリームが生成され、クライアント端末へのコンテンツ配信が実現される。
【００３５】
バッチング方式によるマルチキャスト配信では、バッチング時間中に多くのコンテンツ取得要求があったとしても一つのマルチキャストストリームで対応できるため、クライアント数の増加に対するスケーラビリティが高い。ユニキャストに比べてサーバの負荷も軽減される。ユーザは、コンテンツ配信用のサーバにアクセスしたタイミングでいずれかのマルチキャストストリームにより、コンテンツを受信できる。バッチング時間が長いほど、コンテンツ配信システムのスループットが向上する。サーバがマルチキャストストリームを生成してコンテンツを配信する頻度が低下するため、サーバの負荷が軽減されるからである。また、同様の理由からネットワークにおける通信トラフィックも軽減される。バッチング時間を短く設定すれば、ユーザのコンテンツ取得要求に対する即時性が向上する。図２にバッチング方式の概念図を示す。
【００３６】
バッチング方式によれば、マルチキャストの利点を生かしつつ、コンテンツ配信を行うことができる。しかし、バッチング方式はコンテンツ配信用の各サーバ上での実装を前提としているため、それぞれのサーバにバッチングを行うための機能追加が必要であり設備コストが高い。また、コンテンツ配信用のサーバのそれぞれが、ユーザのコンテンツ取得要求についてのキュー管理やバッチング時間の管理などのさまざまな処理を行う必要がある。これにより、各サーバの処理負荷が高くなる。
【００３７】
バッチング方式においては、ユーザのリクエストを蓄えるキューの管理方式も重要な要素となる。代表的なキュー管理方式としてＦＣＦＳ（Ｆｉｒｓｔ  Ｃｏｍｅ  Ｆｉｒｓｔ  Ｓｅｒｖｅ）、ＭＱＬ（Ｍａｘｉｍｕｍ  Ｑｕｅｕｅ  Ｌｅｎｇｔｈ  ｆｉｒｓｔ）、ＭＦＱ（Ｍａｘｉｍｕｍ  Ｆａｃｔｏｒｅｄ  Ｑｕｅｕｅ  Ｌｅｎｇｔｈ  ｆｉｒｓｔ）がある。しかしこれらの方式は、コンテンツ数の多い環境では効率が悪く適さない。既存のキュー管理方式は、コンテンツ配信用のサーバにおけるキューの管理には適するが、本実施の形態におけるコンテンツ配信制御装置のように、クライアント端末からのコンテンツ取得要求を複数のキャッシュサーバに振り分ける装置について適合するものではないからである。なぜならば、コンテンツ配信制御装置のパフォーマンスは、各キャッシュサーバやネットワークの負荷などの要因の影響を受けるからである。これらの方式はそのような状況を想定したキュー管理方式ではない。したがってコンテンツ配信制御装置においては、これらの要因も考慮したキュー管理方式を取り入れる必要がある。コンテンツ配信制御装置のキュー管理については後に詳述する。
【００３８】
本実施の形態においては、バッチング方式を取り入れたコンテンツ配信制御装置とそれによるコンテンツ配信システムを提案する。コンテンツ配信制御装置にクライアントからのコンテンツ取得要求を一時的に蓄えるキューを用意し、次に提案するキュー管理方式にもとづいてキャッシュサーバの制御を行う。コンテンツ配信制御装置においてバッチング方式を取り入れる利点を６つにまとめ、以下に挙げる。
【００３９】
（１）低コストで実現できる。
キャッシュサーバにおいてバッチングに関する複雑な処理を必要としない。そのため、キャッシュサーバに機能追加が必要なく既存のキャッシュサーバをそのまま使える。キャッシュサーバ上でバッチングを行う場合にはキャッシュサーバ上でキューを保持しなければならないため、全てのキャッシュサーバにおいてそれぞれキューの容量をピーク設計しなければならない。しかし、コンテンツ配信制御装置においてバッチングを行う場合、コンテンツ配信制御装置においてのみピーク設計すればよい。前述したように、コストの問題はコンテンツ配信において非常に重要であるためこの利点は大きい。
【００４０】
（２）キュー管理を柔軟に行うことができる。
キャッシュサーバおよびネットワークの状況に応じてコンテンツ配信システムの稼働中であっても動的にキューの設定を変更できる。すなわち、キャッシュサーバやネットワークの負荷、コンテンツに対するコンテンツ取得要求の数、コンテンツ取得要求を行っているクライアント端末の分布状況などのさまざまな状況に鑑みてキューの制御を行うことができる。また、コンテンツ配信制御装置ですべてのコンテンツ取得要求を一元的に処理するので、キャッシュサーバ単体ではなく複数のキャッシュサーバで総合的なキュー管理が可能である。キューの管理方針などに関する設定を一元的に行うことができるため、システム全体としてのメンテナンス性も向上する。
【００４１】
（３）クライアント端末の状況に応じた制御が可能である。
コンテンツ配信制御装置にてクライアント情報を取得して、それを基にしたキャッシュサーバの割り当てが可能である。たとえば、コンテンツ配信を行うキャッシュサーバとサービスを受けるクライアント端末はネットワーク上である程度近接するように、キャッシュサーバを割り当てることにより、配信サービスの品質向上が図られる。あるいは、コンテンツの内容が地方のニュースなど、地域性を有するものであれば、そのコンテンツを必要とするクライアント端末の分布状況を予め予測することも可能である。このような場合には、コンテンツの内容とクライアント端末のネットワーク上の位置に基づいてキャッシュサーバを割り当てることにより、効率的なコンテンツ配信が可能となる。
【００４２】
（４）アドレス管理が容易となる。
コンテンツ配信制御装置にて、複数のキャッシュサーバにおいて使用中のマルチキャストアドレスを一元的に把握し管理できる。また、コンテンツ配信制御装置においてのみマルチキャストストリームの割り当てを行うことができる環境であれば、コンテンツ配信システム内における不正なマルチキャストアドレスの使用を防ぎやすい。
【００４３】
（５）規模拡張性が高い。
キャッシュサーバの増加に対して、コンテンツ配信制御装置の設定のみ変更すればよいので規模拡張性が高い。また、コンテンツ配信制御装置はキャッシュサーバのアドレスまたはＵＲＬ割り当てのみを行い、自らコンテンツ配信処理を行う必要がないので、マルチキャストプロトコルと独立した運用が可能である。
【００４４】
（６）部分適用性が高い。
コンテンツ配信制御装置はクライアント情報に基づいて、クライアント端末が属するネットワークがマルチキャストネットワークか非マルチキャストネットワークかを判別できる。この判別情報によりキャッシュサーバの割り当てを制御できる。コンテンツ配信制御装置がキャッシュサーバの割り当てを制御するため、コンテンツ配信システムにマルチキャスト非対応のキャッシュサーバが混在していていもまとめて管理できる。
【００４５】
図３はコンテンツ配信制御装置の処理の流れの大要を示す図である。同図においては、クライアント端末はマルチキャストに対応するネットワークに属すものもあれば、属さないものもある。
（１）クライアント端末はコンテンツ配信制御装置（ＣＲＳ  ｗｉｔｈ  Ｂａｔｃｈｉｎｇ）に対してコンテンツ取得要求（Ｑｕｅｒｙ  ｏｆ  Ｃｏｎｔｅｎｔｓ）を行う。この際、クライアント端末はコンテンツ配信制御装置の所在を事前にＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバにアクセスすることによって取得している。
（２）コンテンツ配信制御装置はバッチング時間中においてコンテンツ取得要求を募集、すなわちバッチングを行い、マルチキャストグループの生成を行う。クライアント端末がマルチキャストに対応したネットワークに所属していない場合には、バッチング対象外としてユニキャスト用のキャッシュサーバを割り当てる。
（３）コンテンツ配信制御装置がコンテンツ取得要求を募集した後、バッチング時間が経過すると、それまでに受け付けられたコンテンツ取得要求を行ったクライアント端末に対して、割り当てたキャッシュサーバへのリダイレクト指令を行う。リダイレクト指令とは、クライアント端末に対して、コンテンツを配信すべきキャッシュサーバの所在を知らせるものである。
（４）クライアント端末はリダイレクト指令によって指定されたキャッシュサーバへコンテンツの配信を要求する。以下、クライアント端末からコンテンツ配信装置へのコンテンツ取得要求と、クライアント端末からキャッシュサーバへのコンテンツの配信の要求を明示的に区別するため、場面に応じて特に前者を「第１リクエスト」、後者を「第２リクエスト」ともよぶものとする。
（５）キャッシュサーバは第２リクエストのあったコンテンツをマルチキャストまたはユニキャストにより要求元のクライアント端末に配信する。
以上、（１）〜（５）の処理によって複数のクライアント端末に対するＭＶＯＤが実現される。
【００４６】
コンテンツの増加や大容量化によってキャッシュサーバの処理能力を超えてコンテンツ取得要求がなされる場面が想定される。この場合、どのコンテンツ取得要求をどのキャッシュサーバにどの順番で割り当てを行うのかによって、ＶＯＤシステム全体において同時に対応可能なクライアント端末数は変わってくる。キュー管理方式は、割り当てスケジューリングに直結しているためバッチングにおいて重要な要素である。
【００４７】
代表的なキュー管理方式としてＦＣＦＳ、ＭＱＬ、ＭＦＱがあるが、これらはコンテンツ配信を行うサーバ上でのキュー管理を前提としている。そのため、コンテンツ配信制御装置において、これらのキュー管理方式をそのまま適用した場合、各キャッシュサーバやネットワークの負荷を考慮せずに、複数のクライアントからのコンテンツ取得要求を複数のキャッシュサーバに割り当てることになるため効率が良くない。そこで、本実施の形態におけるコンテンツ配信装置においては、キャッシュサーバとクライアント端末を結ぶネットワーク広域性とコンテンツ数を考慮したキュー管理方式を提案する。
【００４８】
まず、先述の各種のキュー管理方式について説明する。
（１）ＦＣＦＳ
キューの中で一番長い時間待たされたコンテンツ取得要求を次の割り当て対象とする。この方式の利点は、コンテンツの人気度を考慮しないため、すべてのクライアント端末のコンテンツ取得要求に対して公平であることである。しかし、この方式ではＶＯＤシステムのスループットが低くなる。
（２）ＭＱＬ
キューの中で最もコンテンツ取得要求の多いコンテンツを次の割り当て対象とする。この方式は、コンテンツ取得要求が行われた時刻やクライアント端末の状況については考慮せず、キューの中にあるコンテンツ取得要求の数だけをパラメタとするため公平性がない。より人気度の高いコンテンツについて優先的にコンテンツ配信が行われる。
（３）ＭＦＱ
キューの中で待たされる時間とコンテンツの人気度の両方を考慮したアクセス頻度によって次の割り当て対象を決定する。この方式は、ＭＱＬに近いスループットを、ある程度の公平性を保ったまま実現できる。
【００４９】
これまで、３つの既存のキュー管理方式について述べたが、これらは複数のキャッシュサーバが存在するシステムでは効率が悪く、コンテンツ配信制御装置においてバッチングを行う場合には不適当である。これらのキュー管理方式は、一つのコンテンツ配信用のサーバ上で実装されることを前提としているため、キャッシュサーバおよびクライアント端末を結ぶネットワークの広域性が考慮されないからである。具体的には、３つの問題点がある。まとめたものを下に挙げる。
（１）全てのコンテンツ取得要求が一つのキューによって管理されているため、コンテンツごとにキャッシュサーバの負荷やコンテンツ取得要求の数による細かなキュー管理ができない。
（２）キュー管理のパラメタがコンテンツ取得要求の数とその要求の処理までの待機時間だけであるため、キャッシュサーバおよびクライアント端末の位置情報を考慮することができず、キャッシュサーバ割り当てにキャッシュサーバとクライアント端末とのネットワーク上の距離に関する情報を反映させることができない。
（３）バッチングの周期が一定であることと、全コンテンツが同じバッチング時間であるため、一つのコンテンツに対するバッチング効率を考慮できない。
以上の問題点を考慮し、本実施の形態で提案する新しいキュー管理方式の概要を示したのが図４であり、図３のバッチング処理の部分に相当する。
【００５０】
図４はバッチングの処理の流れについて説明するための模式図である。バッチング処理部はユーザからのコンテンツ取得要求を集積し、各ユーザに対して所望のコンテンツを配信すべきキャッシュサーバの割り当てを行う。ここでは、バッチング処理部の機能ブロック図の説明に先立ち、その処理の概要について述べる。
【００５１】
クライアント端末からコンテンツ配信制御装置に送信した第１リクエスト（Ｑｕｅｒｙ）は、まず、共通のキューに入る。次に分類部（Ｃｌａｓｓｉｆｉｅｒ）がステータス情報（クライアント情報、サーバ情報、コンテンツ情報）に基づいてキューをコンテンツごとに生成し、対応するキャッシュサーバを割り当て、それぞれにバッチング時間を設定する。「コンテンツ情報」とはコンテンツの人気度やコンテンツに付属する情報をいう。バッチング時間がゼロになると、リダイレクション処理部（Ｒｅｄｉｒｅｃｔ  Ｅｎｇｉｎｅ）はキューにある第１リクエストの送信元であるクライアント端末を一つのマルチキャストグループとして、その各クライアント端末にリダイレクト指令を行う。リダイレクト指令を送信した後、割り当てたキャッシュサーバがコンテンツ配信を行うまでの処理については後に詳述する。
【００５２】
分類部における処理の流れを図５に示す。
受信した第１リクエストは分類部により取り出される。そして、取り出された第１リクエストを送信したクライアント端末が、マルチキャスト対応のネットワークに所属しているか否かを判断する。マルチキャスト非対応である場合には、適当なキャッシュサーバによりコンテンツをユニキャスト配信させるように制御する。クライアント端末がマルチキャスト対応のネットワークに所属していれば、その第１リクエストの要求するコンテンツの配信用として割り当てられているキャッシュサーバと、新たに受信した第１リクエストの送信元であるクライアント端末とのネットワーク距離を検査する。ネットワーク距離が所定の値より大きい場合には、新たにキューを生成し、妥当な近接度のキャッシュサーバをコンテンツ配信用に割り当てる。そして、その割り当てたキャッシュサーバのサーバ情報やコンテンツ情報、後に述べるポリシ情報に基づいて、バッチング時間を設定する。
【００５３】
一方、すでに割り当てられているキャッシュサーバと、新たに受信した第１リクエストの送信元であるクライアント端末のネットワーク距離が所定の値よりも小さい場合には、そのキャッシュサーバの負荷状況を検査する。キャッシュサーバの負荷が所定値以下であれば、そのままそのキャッシュサーバが割り当てられるキューに、新たに受信した第１リクエストを追加する。
【００５４】
分類部がキューを生成するときに設定するバッチング時間は、主としてキャッシュサーバの負荷状況とコンテンツの人気度によって決まる。キャッシュサーバの負荷が重くなる傾向にある場合には、バッチング時間を長くすることでキャッシュサーバが処理するマルチキャストストリーム数を減らして負荷の増加を抑える。これにより、一つのマルチキャストストリームで処理するユーザの数が増加するため、バッチングの効率が高くなる。逆にキャッシュサーバの負荷が軽い場合には、バッチング時間を短くすることで要求に対するコンテンツ配信の即時性を向上させる。
【００５５】
コンテンツ配信制御装置はキャッシュサーバとクライアント端末のネットワーク上の位置だけでなく、キャッシュサーバの負荷やコンテンツ名もパラメタにしてキャッシュサーバの割り当てを行うことができる。コンテンツ配信制御装置の構成を図６に示す。
【００５６】
コンテンツ配信制御装置の構成要素はＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）とポリシ、マッピング処理部、バッチング処理部の４つである。順に説明する。
（１）ＳＮＭＰ
ＳＮＭＰはエージェント、マネージャ、管理ブロック（ＭＩＢ：Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）の３つのコンポーネントで構成されており、ネットワーク上に点在するネットワーク機器の管理・状況把握などをおこなうプロトコルである。本実施の形態においては、各キャッシュサーバの状態を把握するために用いる。ＳＮＭＰマネージャは、キャッシュサーバ群（Ｎｅｉｇｈｂｏｒｉｎｇ  Ｓｅｒｖｅｒｓ）にアクセスし、それぞれのサーバ情報を取得してサーバ情報格納部に格納する。
（２）ポリシ
ポリシとは、コンテンツ配信制御装置がどのようにキャッシュサーバ割り当てを行えばよいかが記述されたものである。具体的には、サーバ情報やクライアント情報、コンテンツ情報をパラメタにキャッシュサーバ選択を行う関数のことである。ポリシはコンテンツ配信制御装置上に複数個実装可能で、管理者によって遠隔から動的に変更できる。
（３）マッピング処理部
マッピング処理部には２つの機能がある。一つは、ＳＮＭＰなどによって取得したステータス情報をポリシに基づいて処理し、割り当てるべきキャッシュサーバ選択を行う機能である。ステータス情報とは、クライアント情報格納部、コンテンツ情報格納部、サーバ情報格納部にそれぞれ格納されるクライアント情報、コンテンツ情報およびサーバ情報をいう。もう一つは、バッチング処理において分類部がキューイングを行う際に必要とするステータス情報を提供することである。
（４）バッチング処理部
バッチング処理部はクライアント端末とのインタフェースとなる。バッチング処理部は、クライアント端末よりコンテンツ取得要求を受け付け、バッチング後、リダイレクト指令を送信する。バッチング処理部は、前述したキュー管理方式を実際に具体化したものである。
【００５７】
図７は、クライアント端末が第１リクエストを行い、マルチキャストストリームを受信するまでのシーケンス図である。
まず、クライアントはコンテンツ配信制御装置へ第１リクエストをＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）により行う（ＧＥＴ：Ｃｏｎｔｅｎｔ）。コンテンツ配信制御装置はバッチングを行い、クライアント端末に対してメタファイルのリダイレクト指令を出す（Ｒｅｄｉｒｅｃｔ：Ｍｅｔａｆｉｌｅ）。メタファイルとはクライアント端末のブラウザがストリーミング再生を行うために必要な情報を記述したファイルのことである。メタファイルには、割り当てたキャッシュサーバやコンテンツの所在情報であるＵＲＬが含まれる。また、コンテンツの抄録やタイトル、著作権に関する情報が含まれてもよい。
【００５８】
クライアント端末はリダイレクト指令に従い、コンテンツ配信制御装置へメタファイルを要求し取得する（ＧＥＴ：Ｍｅｔａｆｉｌｅ、ＲＥＳ：Ｍｅｔａｆｉｌｅ）。このとき、同じマルチキャストストリームへバッチングされた全クライアント端末は同じメタファイルを取得することになる。クライアント端末はメタファイルに記述された内容に基づいて割り当てられたキャッシュサーバへ第２リクエストを行う（ＧＥＴ：Ｃｏｎｔｅｎｔ）。キャッシュサーバはその要求を受信した時点でマルチキャストストリーム配信を開始する。
【００５９】
コンテンツをユニキャストにより配信する場合には、コンテンツ配信制御装置はユニキャスト用のメタファイルをクライアント端末にダウンロードさせる。そして、クライアント端末は、指定されたキャッシュサーバにユニキャストにより第２リクエストを行う。
【００６０】
図８は、バッチング処理部２３２の機能ブロック図である。バッチング処理部２３２はコンテンツ取得要求受信部３１０、分類処理部３２０およびリダイレクション処理部３３０を含む。コンテンツ取得要求受信部３１０はクライアント端末からコンテンツ取得要求を受信し、これを一時的に保持する。分類処理部３２０は、コンテンツ取得要求受信部３１０が受信したコンテンツ取得要求群をステータス情報に基づいて分類する。分類処理部３２０は、分類制御部３２４およびバッチング時間演算部３２６を含む。分類制御部３２４は、コンテンツ取得要求受信部３１０が受信して保持するコンテンツ取得要求を適宜取り出して分類する。コンテンツ取得要求には、送信元であるクライアント端末のＩＰアドレス、要求するコンテンツなどの情報が含まれる。マッピング処理部３５０はこれらの情報をもとに、送信元であるクライアント端末に所望のコンテンツを配信するのに最適なキャッシュサーバを選択する。バッチング時間演算部３２６は、分類制御部３２４から受け取ったステータス情報を元にして最適なバッチング時間を計算する。
【００６１】
リダイレクション処理部３３０は、分類処理部３２０において指定されたキャッシュサーバによるクライアント端末へのコンテンツ配信を制御する。リダイレクション処理部３３０は、コンテンツ取得要求格納部３３２、コンテンツ取得要求処理部３３４、バッチング時間処理部３３６、メタファイル生成部３３８、リダイレクト指令送信部３４０、メタファイル送信部３４２およびメタファイル格納部３４４を含む。コンテンツ取得要求処理部３３４は分類制御部３２４が分類したコンテンツ取得要求を取得する。コンテンツ取得要求処理部３３４は、その分類に応じてコンテンツ取得要求をコンテンツ取得要求格納部３３２に格納する。コンテンツ取得要求処理部３３４からの指示をうけて、バッチング時間処理部３３６はバッチング時間をタイマー設定し、時間の管理を行う。メタファイル生成部３３８は、メタファイルを生成しメタファイル格納部３４４に格納する。
【００６２】
バッチング時間処理部３３６がバッチング時間の経過を検出すると、リダイレクト指令送信部３４０はクライアント端末に対してリダイレクト指令を行う。メタファイル送信部３４２は、クライアント端末からのメタファイル取得要求を受信すると、メタファイル格納部３４４に格納されるメタファイルを送信する。クライアント端末は受信したメタファイルの記述に従って、キャッシュサーバに第２リクエストを行い、コンテンツの配信がなされるのは前述の通りである。
【００６３】
図９は、マッピング処理部３５０の機能ブロック図である。マッピング処理部３５０は、ステータス情報取得部３５２、マルチキャストネットワーク判定部３５４およびキャッシュサーバ選択部３５６を含む。ステータス情報取得部３５２はステータス情報や設定されたポリシに関する情報を取得する。マルチキャストネットワーク判定部３５４は、第１リクエスト要求を行ってきたクライアント端末がマルチキャスト対応のネットワークに所属するか否かを判断する。キャッシュサーバ選択部３５６は、第１リクエストに対して、コンテンツ配信を行うべきキャッシュサーバの選択を行う。
【００６４】
以上、実施の形態においては、コンテンツ配信制御装置を既存のコンテンツ配信システムに追加するだけでよい。また、実装が容易であり低コストでかつ規模拡張性に優れる。このため、大規模なＶＯＤ配信を可能にするものと考えられる。
【００６５】
以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００６６】
そうした変形例として、バッチング時間を周期としてキャッシュサーバにマルチキャストストリームを生成させるのではなく、あるコンテンツに対する第１リクエストを所定数受信したことを契機として生成させてもよい。バッチング時間は、マルチキャスト配信を行う時間帯に応じて変更してもよい。たとえば、日中のネットワーク負荷が一般的に高い時間帯においてはバッチング時間を長く設定し、深夜のようにネットワーク負荷が一般的に低い時間帯においてはバッチング時間を短く設定しても良い。
【００６７】
また、バッチング時間の長さやキャッシュサーバの割り当て方法に関するポリシについては、複数の関数を組み合わせてプログラム形式で設定できてもよい。
【００６８】
【発明の効果】
本発明によれば、ネットワークまたはキャッシュサーバの負荷を抑制してコンテンツの配信を行うことができる。
【図面の簡単な説明】
【図１】本実施の形態におけるコンテンツ配信制御装置の役割を示す模式図である。
【図２】バッチング方式を説明するための模式図である。
【図３】コンテンツ配信制御装置によるキャッシュサーバの割り当てからコンテンツの配信までの概要を示す図である。
【図４】バッチング処理の流れの概要を示す図である。
【図５】図４の分類部における処理のフローチャートである。
【図６】コンテンツ配信制御装置の構成を示す図である。
【図７】クライアント端末がコンテンツ取得要求を行ってマルチキャストストリームを受信するまでのシーケンス図である。
【図８】コンテンツ配信制御装置におけるバッチング処理部の機能ブロック図である。
【図９】コンテンツ配信制御装置におけるマッピング処理部の機能ブロック図である。
【符号の説明】
２３０  コンテンツ配信制御装置、２３２  バッチング処理部、３１０  コンテンツ取得要求受信部、３２０  分類処理部、３２４  分類制御部、３２６  バッチング時間演算部、３３０  リダイレクション処理部、３３２  コンテンツ取得要求格納部、３３４  コンテンツ取得要求処理部、３３６  バッチング時間処理部、３４０  リダイレクト指令送信部、３４２  メタファイル送信部、３５０マッピング処理部、３５２  ステータス情報取得部、３５４  マルチキャストネットワーク判定部、３５６  キャッシュサーバ選択部。
【図１】
2005018293.tif 000003
【図２】
2005018293.tif 000004
【図３】
2005018293.tif 000005
【図４】
2005018293.tif 000006
【図５】
2005018293.tif 000007
【図６】
2005018293.tif 000008
【図７】
2005018293.tif 000009
【図８】
2005018293.tif 000010
【図９】
2005018293.tif 000011