コンテンツ配信システムと方法およびプログラム
【課題】ピーク時の配信サーバ負荷とネットワーク負荷の低減可能なコンテンツ配信システムを提供する。
【解決手段】配信サーバ１０１は、ユーザの配信要求に応じて即時にコンテンツをユニキャスト配信すると共に、配信要求の多いコンテンツを、配信スケジュール設計装置２００において予め定められた配信スケジュールに従い、事前に、全てのユーザ端末装置１０２（セットトップボックス：STB）にブロードキャスト配信（事前配信）する。
【解決手段】配信サーバ１０１は、ユーザの配信要求に応じて即時にコンテンツをユニキャスト配信すると共に、配信要求の多いコンテンツを、配信スケジュール設計装置２００において予め定められた配信スケジュールに従い、事前に、全てのユーザ端末装置１０２（セットトップボックス：STB）にブロードキャスト配信（事前配信）する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネット等のＩＰ（Internet Protocol）ネットワークにおけるコンテンツの配信技術に係り、特に、VoD（Video On Demand）サービス等の大容量のコンテンツを効率的に配信するのに好適な技術に関するものである。
【背景技術】
【０００２】
近年、アクセス回線の大容量化に伴い、動画コンテンツをユーザの配信要求に対してオンデマンドに配信するVoDサービスの普及が目覚ましい。VoDサービスは、サービスプロバイダが配信サーバをネットワーク（NW）上に設置し、また、配信された動画データを一時蓄積して再生するための装置（STB:Set Top Box）をユーザ宅内に設置することで実現される。
【０００３】
また、動画配信サービスは、ユーザが作成した小サイズの動画コンテンツをユーザ間で交換するYouTube等のUGC（User Generated Content）を対象とするものと、映画やTVドラマなど、コンテンツ制作会社が制作した高品質の動画コンテンツ（リッチコンテンツ）を対象とするもの、に大きく分けることができる。
【０００４】
前者（UGC配信）はCDN（Contents Delivery Network）サービスを用いて、ISP（Internet Service Provider）とは独立したサービスプロバイダが提供する形態が一般的であるのに対して、後者（リッチコンテンツ）はコンテンツが大容量であることから、主にNWの品質を管理、制御することが可能なISPが提供する形態が一般的である。
【０００５】
多くのISPは、自身のNWサービスを差別化するキラーサービスとしてVoDサービスを位置付けており、今後もリッチコンテンツを対象としたVoDサービスの普及が予想される。以下、このような大容量コンテンツ配信となるVoDサービスを対象に説明する。
【０００６】
一般に、動画コンテンツの視聴は夜間に集中する傾向があり、一日の周期で大きく変動する。しかし、ISPにはピーク時間帯にも安定したサービス品質を維持することが求められるため、ISPでは、ピーク時の需要量を考慮して配信システムを設計する必要がある。
【０００７】
そのためピーク時以外の多くの時間帯においては、過剰な配信システム設計となり、ISPの収益を低下させる要因となる。
【０００８】
ISPの収益を向上させ、ユーザに対して安価なVoDサービス提供を可能とするためには、ピーク時のサーバ負荷低減がISPにとって大きな課題である。また、リッチコンテンツは大容量であるため、配信によって生じるトラヒックがNWに与える影響を抑えることも重要である。
【０００９】
ピーク時のサーバ負荷を低減する技術として様々なものが検討され実用化されているが、主に、キャッシュサーバを用いる技術（CDN）、マルチキャスト配信、P２P型配信、の３つに分類できる。
【００１０】
キャッシュサーバを用いる技術では、ISPが自身のNW上に複数配置したキャッシュサーバ上にコンテンツのコピーを配置し、ユーザの配信要求に対して、当該ユーザに近接するキャッシュサーバから配信を行う。この技術によれば、ユーザのレスポンス時間向上とオリジナルサーバの負荷低減効果が期待できる。
【００１１】
また、マルチキャスト配信は、同一のコンテンツを要求した複数のユーザに対して、マルチキャスト配信ツリーを用いて単一の配信セッションで配信するもので、ユーザ集約度の向上に比例してサーバ負荷の低減効果が期待できる。
【００１２】
また、P２P型配信システムは、ユーザ間で保有するコンテンツを交換することでコンテンツ配信を実現するもので、BitTorrent（登録商標）等、広く普及している。従来は、UGCの交換を目的に利用されてきたが、近年、リッチコンテンツを配信する手段としてもP２P配信技術が用いられている。
【００１３】
このP２P型配信システムにおいては、各ピア（ユーザ）は、配信を受け視聴中のコンテンツを他のピアに対してアップロードするため、人気が高いコンテンツほどサーバ機能を提供するピアが増加するため、スケーラビリティに優れたサーバ負荷低減効果の高い配信技術である。
【００１４】
また、近年、ハードディスクドライブの価格低下は目覚ましく、現在、１T（テラ）バイト程度のものを１００USD（米国ドル）程度で購入することが可能である。そのため、ユーザ宅内に設置されたSTBやGW（Gate Way）を、ISPの管理下でキャッシュとして運用することが広く検討されている。
【００１５】
このような上述の技術については、非特許文献１〜３に記載されている。
【００１６】
しかし、キャッシュを用いた配信技術では、ISPが用意するキャッシュサーバを含めたサーバ設備から配信される総量は一定であるため、ユーザ数の増加に対してISPはサーバ設備を常に増設し続ける必要があり、設備コストの大きな低減効果は期待できない。
【００１７】
これに対して、マルチキャスト配信は、同一のコンテンツを要求する複数のユーザに対して、配信サーバを根とし配信先ユーザを葉とする一本のマルチキャスト配信ツリーを用いて同時に配信する技術であり、配信サーバとNWの負荷を低減する技術として有効であり、近年、広く普及しつつある地上波テレビ放送をインターネット上で提供するIPTVにおいては、一般にマルチキャスト配信が用いられている。
【００１８】
しかしIPTVにおいては、ユーザが視聴時刻をサービス提供者に合わせ、またVCR（Video Cassette Recorder）操作を伴わないため、容易にマルチキャスト配信を適用することが可能であるのに対して、ユーザが任意のタイミングで任意のコンテンツの視聴を要求するVoDサービスにおいては、ユーザの配信要求時刻の不一致性への対応と、VCR操作への対応が課題となる。
【００１９】
このような、ユーザの配信要求の不一致性に対する対処技術として様々なものが検討されているが、ユーザの配信要求に基づくPull型配信と、ユーザの配信要求とは無関係に事前に配信スケジューリングを設計するPush型配信とに分類することができる。
【００２０】
Pull型配信は、ユーザの配信要求に対して、即時には配信を開始せず、待ち合わせ期間を設けることで、その間に発生した同一コンテンツに対する配信要求を一つのマルチキャスト配信に集約する。最も簡易な技術では、ユーザのレスポンス時間に上限値Ｄを設け、他に待ち中のユーザが存在しないコンテンツに対する要求が生じた時刻からＤ後にそのコンテンツを配信する。
【００２１】
他にもFIFO（First In First Out）で配信コンテンツを選択するものや、待ちユーザ数が最大のコンテンツを配信コンテンツに選択するもの、平均レスポンス時間が最小化するよう配信コンテンツを選択するものなど、様々な技術が検討されている。
【００２２】
一方Push型配信は、サービスプロバイダが事前に各コンテンツを配信するタイミングを配送スケジュールとして静的に設計する技術であり、通常、全ユーザを配信先とするブロードキャスト配信が用いられる。
【００２３】
この場合、ユーザの配信要求のタイミングは考慮されず、ユーザは配信スケジュールに合わせて視聴したいコンテンツを視聴することになるため、オンデマンド性は損なわれ、VoDよりもIPTVに近いサービス実現形態となる。配信スケジュールの設計技術としては様々なものが検討されているが、いずれもレスポンス時間を低減する観点から考察されている。
【００２４】
Pull型配信においては、サーバやNWの負荷低減効果を得るためには、配信ツリーのユーザ多重度を上げる必要があり、レスポンス時間の悪化が避けられない。
【００２５】
またPush型配信においては、高人気のコンテンツを除き、配信周期が長くなる傾向があり、やはりオンデマンド性が犠牲になる。
【００２６】
本来、オンデマンド性を重視するVoDサービスにおいては、ユーザの配信要求に対して即時に配信を開始することが望ましく、レスポンス時間の悪化がマルチキャスト配信の大きな問題である。
【００２７】
また、VCR操作に対して、VCR操作後の再生点に近い他のマルチキャスト配信ツリーに該当ユーザを移行させる必要がある。
【００２８】
また、完全に再生タイミングが一致する配信ツリーが存在しない可能性が高いため、タイミングの誤差分をユニキャスト配信するなど、複雑な処理が必要となる。
【００２９】
P２P配信システムでは、配信要求ユーザに対して、要求コンテンツを視聴中の他のユーザから配信する。同一コンテンツを視聴するユーザが他に存在しない場合や、存在してもアップロード帯域が不足するような場合には、配信サーバより配信する。人気の高いコンテンツほど視聴中ユーザの数が増加するため、スケーラビリティに優れた配信システムである。
【００３０】
このP２P配信システムでは、元々はファイル全体を受信後に利用するファイルダウンロードにおいて用いられていたが、動画ストリーミングサービスへの適用が広がり、商用システムとしても用いられている。またVCR操作に対応したVoDの商用システムへの適用も見られる。
【００３１】
しかし、ユーザはコンテンツ視聴終了後に配信システムから離脱する可能性が高く、また視聴中であっても視聴を中断して離脱する可能性もある。
【００３２】
このような、離脱ユーザの存在やVCR操作に伴う再生点の移動に対しても配信を継続させる処理が必要となり、各ユーザの再生点の管理や配信元の切り替え処理等、複雑な処理が必要となる。
【００３３】
また、各ユーザのアップリンク容量にシステム全体の性能が大きく依存する。ADSL等、ユーザのアクセス回線のアップリンク容量はダウンリンク容量と比較して小さいことが多く、アップリンク容量が小さい場合には十分な効果が得られない。またサーバ機能の多くを自律的に行動するユーザに依存するため、システムの全体最適化が困難である。
【００３４】
このようなP２P型配信システムの問題点に対して、ユーザ宅内に設置されたSTBやGWを、ISPが集中的に管理するキャッシュ装置として活用し、P２P配信を行うVoDシステムが検討されている。以後、これらISPが集中的に管理するSTBを用いたP２P配信システムをISP制御型P２P配信と呼ぶ。
【００３５】
このISP制御型P２P配信においては、ユーザ宅内のSTBはISPの管理下にあるため、他のユーザに対して常時、保有コンテンツの配信を行うことが可能である。そのため、従来のP２P配信システムで問題であった、ユーザのシステム離脱に起因する配信元の切り替え処理が不要となり、各STBのキャッシュコンテンツと配信元STB選択を最適化することで、全体最適化が可能となる。
【００３６】
しかし、他のユーザに対してコンテンツを配信する際に必要となる電力を各ユーザが負担する必要があり、ISPが制御するSTBを宅内に設置するインセンティブをユーザに与える必要がある。
【００３７】
また、配信サーバの負荷は低減されるものの、ユーザ間のP２P配信によってNW内にトラヒックが発生するため、NWの負荷低減効果は得られない。
【先行技術文献】
【非特許文献】
【００３８】
【非特許文献１】M.Allen, B.Zhao, and R.Wolski,"Deploying Video-on-Demand Services on Cable Networks,"IEEE ICDCD 07.
【非特許文献２】H.Ma and K.Shin,"Multicast Video-on-Demand Services,"ACM SIGCOMM CCR,32(1),pp.31-43,2002.
【非特許文献３】B.Cheng, L.Stein, H.Jin, and Z.Zhang,"Towards Cinematic Internet Video-on-Demand,"ACM EuroSys 08.
【発明の概要】
【発明が解決しようとする課題】
【００３９】
解決しようとする問題点は、従来の技術では、インターネット等のＩＰネットワークにおいてコンテンツを配信するサーバの負荷の低減とネットワーク負荷の低減を共に図ることができない点である。
【００４０】
本発明の目的は、これら従来技術の課題を解決し、VoDサービス等の大容量のコンテンツの効率的な配信を可能とすることである。
【課題を解決するための手段】
【００４１】
上記目的を達成するため、本発明では、VoDサービス等において、ユーザの配信要求に対して即時にユニキャスト配信する配信形態に加えて、ユーザからの配信要求とは無関係に、予め定めた配信スケジュールに従い、人気の高いコンテンツを常時、全てのユーザに対してブロードキャスト配信し、ユーザ宅内に設置されたSTBに事前配信する。
【発明の効果】
【００４２】
本発明によれば、VoDサービス等によるコンテンツの配信に伴う、配信サーバの負荷とネットワークの負荷を低減し、コンテンツの効率的な配信が可能となる。
【図面の簡単な説明】
【００４３】
【図１】本発明に係るコンテンツ配信システムの構成例を示すブロック図である。
【図２】図１における配信スケジュール設計装置の構成例を示すブロック図である。
【図３】本発明に係るコンテンツ配信システムの処理動作例を示すシーケンス図である。
【図４】本発明に係るコンテンツ配信システムの評価例を示す説明図である。
【図５】図１における配信スケジュール設計装置によるTDLT推定処理の精度を示す説明図である。
【図６】図１における配信スケジュール設計装置によるコンテンツ選択処理の効率特性を示す説明図である。
【図７】本発明に係るコンテンツ配信システムによるセッション数の時系列変化を示す説明図である。
【図８】本発明に係るコンテンツ配信システムによる配信処理の効率を示す説明図である。
【図９】本発明に係るコンテンツ配信システムによる配信処理の効果を示す説明図である。
【発明を実施するための形態】
【００４４】
以下、図を用いて本発明を実施するための形態例を説明する。図１において、１０１はコンテンツの配信を行う配信サーバ、１０２はSTBを具備したユーザ端末装置、２００は本発明に係るコンテンツの配信制御を行う配信スケジュール設計装置であり、配信サーバ１０１とユーザ端末装置１０２はインターネットを介して接続され、配信サーバ１０１と配信スケジュール設計装置２００はＬＡＮ（Local Area Network）等で接続されている。
【００４５】
配信サーバ１０１とユーザ端末装置１０２および配信スケジュール設計装置２００のそれぞれは、ＣＰＵ（Central Processing Unit）や主メモリ、表示装置、入力装置、外部記憶装置等を具備したコンピュータ装置からなり、光ディスク駆動装置等を介してＣＤ−ＲＯＭ等の記憶媒体に記録されたプログラムやデータを外部記憶装置内にインストールした後、この外部記憶装置から主メモリに読み込みＣＰＵで処理することにより、各処理部の機能を実行する。
【００４６】
例えば、配信スケジュール設計装置２００は、図２に示すように、プログラムされたコンピュータ処理を実行する処理手段として、設定パラメタ入力部２０１、ＢＣ事前配信レートとチャネル数の設定部２０２、各コンテンツのＴＤＬＴ測定部２０３、翌日の各コンテンツのＴＤＬＴ推定部２０４、各ＢＣ配信チャネルへの配信コンテンツ割当部２０５、配信スケジュール部２０６を具備している。
【００４７】
尚、図１において、配信サーバ１０１は、ユーザ端末装置１０２以外の図示していない多数のユーザ端末装置に接続される。また、配信サーバ１０１と配信スケジュール設計装置２００をそれぞれ個別のコンピュータ装置で構成しても、１つのコンピュータ装置内に配信サーバ１０１と配信スケジュール設計装置２００の機能を設けた構成としても良い。
【００４８】
このような構成において、本例のコンテンツ配信システムでは、配信サーバ１０１は、ユーザの配信要求に応じて即時にコンテンツをユニキャスト配信すると共に、配信要求の多いコンテンツを、配信スケジュール設計装置２００において予め定められた配信スケジュールに従い、事前に、全てのユーザ端末装置１０２（セットトップボックス：STB）にブロードキャスト配信（事前配信）する。
【００４９】
配信スケジュール設計装置２００は、各コンテンツのＴＤＬＴ測定部２０３において、各コンテンツの一日の総ダウンロード時間（TDLT:Total DownLoad Time）を計測し、配信スケジュール部２０６において、STBに事前配信したユーザ視聴可能期間内のコンテンツを除く各コンテンツから、TDLTの大きいコンテンツを優先して順に、事前配信対象として選択し、選択したコンテンツを、一日を周期に事前配信するようスケジュール設定する。
【００５０】
また、配信スケジュール設計装置２００は、翌日の各コンテンツのＴＤＬＴ推定部２０４において、各コンテンツのＴＤＬＴ測定部２０３が計測した各コンテンツの過去のTDLTの実測値から指数移動平均を用いて翌日の各コンテンツのTDLTを求め、配信スケジュール部２０６において、指数移動平均を用いて求めたTDLTに基づき、事前配信するコンテンツの選択を行う。
【００５１】
また、配信スケジュール設計装置２００は、配信スケジュール部２０６において、アクセス回線のダウンリンク容量Ａｄ（bps）と、コンテンツの再生レートと同じユニキャスト配信の配信レートＲ（bps）を用いて、事前配信の配信レートＲｂ（bps）を、任意の事前配信チャネル数Ｂに対して、Ｒｂ=（Aｄ-R）/Ｂに設定し、設定した配信レートで事前配信を行うようスケジュール設定する。
【００５２】
また、配信スケジュール設計装置２００は、ＢＣ事前配信レートとチャネル数の設定部２０２において、空き配信時間のある事前配信チャネルに、空き配信時間が大きい順次に、コンテンツ長が空き時間以下のコンテンツを、TDLTの推測値が大きい順に割り当てる。
【００５３】
そして、配信スケジュール設計装置２００は、配信スケジュール部２０６において、ＢＣ事前配信レートとチャネル数の設定部２０２により各事前配信チャネルに割当てたコンテンツから、各コンテンツのTDLTの推定値をコンテンツ長で除した値が大きな順に選択して、事前配信するようスケジュール設定する。
【００５４】
以下、このような本例のコンテンツ配信システムによるコンテンツの配信技術について説明する。
【００５５】
近年のインターネットにおけるアクセス回線のダウンリンク容量の増加は目覚ましく、リッチコンテンツの再生レートと比較しても十分に大きな帯域が利用できる環境が一般的になることが予想される。
【００５６】
例えばSD（Standard Definition）品質の動画像の再生レートが２Mbpsであるのに対して、複数ユーザでの共有ではあるものの、下り方向は最大で２００Mbpsもの伝送帯域が利用できる環境が一部では提供されている。
【００５７】
ユーザが常にダウンリンク容量を使用し続ける可能性は低く、またコンテンツ配信を受ける間も依然として大きな伝送帯域が未使用となる。そのため、ユーザの配信要求に対してオンデマンドで配信サーバより配信を行う通常の配信に加え、未使用の伝送容量を活用し、ユーザの配信要求とは無関係にコンテンツを常時配信しSTBに蓄積することが有効である。
【００５８】
すなわち、ユーザの配信要求時、事前配信によって要求コンテンツが既にSTBに蓄積されている場合、配信サーバからの配信を回避でき、配信サーバやネットワークのピーク時の負荷を低減することが可能となる。
【００５９】
一般に、アクセス回線の伝送資源は多数のユーザで共有され、複数のユーザが同時に異なるコンテンツの配信を受けた場合、スループットが低下する。しかし、ユーザの配信要求とは無関係にSTBに対して配信を行う場合、ISPが自由に配信コンテンツや配信のタイミングを設定でき、全ユーザに対して同一のコンテンツをブロードキャストすることで、ダウンリンクのスループット低下を回避できる。
【００６０】
そこで、本例では、VoDサービスにおいて、ブロードキャストにより所定のコンテンツを所定のユーザに事前に配信する。
【００６１】
このような本例のコンテンツ配信技術では、P２P型配信とは異なり、STBにキャッシュされたコンテンツは各STBを保有するユーザのみが視聴するため、ユーザにコンテンツを他ユーザにアップロードさせるインセンティブを与える必要がなく、また、STBに事前に配信されたコンテンツを視聴する際にはネットワークにトラヒックが発生しないため、ピーク時のサーバ負荷に加えてネットワーク負荷の低減も期待できる。さらにVCR操作に対しても容易に対応できる。
【００６２】
図１に示すコンテンツ配信システムの構成において、ユーザ端末装置１０２のユーザは、視聴したいコンテンツが自身のユーザ端末装置１０２に設けたSTB内に事前配信されている場合には、ローカルにキャッシュされたコンテンツを再生することで視聴する。
【００６３】
視聴したいコンテンツが自身のユーザ端末装置１０２のSTB内に存在しない場合には、ユーザ端末装置１０２から配信サーバ１０１に対して配信を要求する。
【００６４】
ユーザ端末装置１０２からの配信要求を受けた配信サーバ１０１は、直ちにユニキャストで要求元のユーザ端末装置１０２に対して、要求されたコンテンツを配信する。
【００６５】
配信スケジュール設計装置２００は、各コンテンツのＴＤＬＴ測定部２０３において、配信サーバ１０１から配信されるコンテンツごとに総ダウンロード時間（TDLT）を計測し、その計測結果を用いて、翌日の各コンテンツのＴＤＬＴ推定部２０４において、例えば、一日の開始時点（午前０時）毎に、翌日の各コンテンツのTDLTを推測する。
【００６６】
また、設定パラメタ入力部２０１において、コンテンツの平均長Ｓ（秒）、アクセス回線のダウンリンク容量Ａｄ（bps）、コンテンツの再生レートＲ（bps）をBC事前配信レートとチャネル数の設定部２０２に対して入力し、BC事前配信レートとチャネル数の設定部２０２において、得られた設定パラメタを用いて、BC事前配信レートとチャネル数を設定する。
【００６７】
そして、各BC配信チャネルへの配信コンテンツ割当部２０５において、翌日の各コンテンツのTDLT推定部２０４において推定された各コンテンツのTDLTを用いて、BC事前配信レートとチャネル数の設定部２０２において設定した各BC配信チャネル上で配信するコンテンツを割当て、配信スケジュール部２０６において、各BC配信チャネルに割当てられたコンテンツの順序（ブロードキャスト事前配信スケジュール）を決定する。
【００６８】
このようにして、配信スケジュール設計装置２００において決定されたブロードキャスト事前配信スケジュールに基づき、配信サーバ１０１は、予め登録された各ユーザ端末装置（１０２）に対してコンテンツをブロードキャストする。
【００６９】
このような本例のコンテンツ配信システムにおけるVoDサービスでのブロードキャスト事前配信処理動作の手順を、図３を用いて説明する。
【００７０】
図３において、サービスプロバイダ３１は図２における配信スケジュール設計装置２００に相当し、配信サーバ３２は図２における配信サーバ１０１、ユーザ３３は図２におけるユーザ端末装置１０２に相当する。
【００７１】
サービスプロバイダ３１から配信サーバ３２に対してBC事前配信レートとチャネル数の設定を行い（ステップＳ３０１）、サービス運用の開始（ステップＳ３０２）となる。
【００７２】
第１日目において、ユーザ３３からのコンテンツ配信要求（ステップＳ３０３）に対して配信サーバ３２から当該コンテンツの配信（ステップＳ３０４）が行われると、そのコンテンツの総ダウンロード時間が計測され（ステップＳ３０５）、第１日の終わりに、サービスプロバイダ３１において決定されたＢＣ事前配信スケジュールが配信サーバ３２に通知される（ステップＳ３０６）。
【００７３】
第２日目において、配信サーバ３２は、前日にサービスプロバイダ３１から通知されたスケジュールに従って、該当するユーザ３３に対して、通知されたコンテンツをブロードキャストにより配信する（ステップＳ３０７）と共に、第１日目と同様に、ユーザ３３からのコンテンツ配信要求（ステップＳ３０８）に対して当該コンテンツの配信（ステップＳ３０９）を行い、そのコンテンツの総ダウンロード時間が計測され（ステップＳ３１０）、第２日の終わりに、サービスプロバイダ３１において決定されたＢＣ事前配信スケジュールが配信サーバ３２に通知される（ステップＳ３１１）。以上の処理を毎日繰り返す。
【００７４】
以下、このような本例のコンテンツ配信システムによるVoDサービスにおけるブロードキャスト事前配信技術の詳細を説明する。
【００７５】
まず、その＜概要＞について説明する。尚、ここでは、図１における配信サーバ１０１内に配信スケジュール設計装置２００が設けられた構成として説明する。
【００７６】
本例のコンテンツ配信システムは、ISPが用意する配信サーバと配信ネットワーク、そしてSTBとTV等の動画視聴装置を有する複数のユーザ（ユーザ端末装置）から構成される。
【００７７】
配信サーバには、提供するM個の全コンテンツが蓄積されており、ユーザからの配信要求に対して配信サーバは即時に要求コンテンツをユニキャスト配信する。
【００７８】
ユーザは、配信されたコンテンツをSTBに蓄積しつつ再生する。ユニキャスト配信であるため、任意のVCR操作に容易に対応することが可能である。
【００７９】
また、このようなオンデマンドのユニキャスト配信に加えて、配信サーバは、常時、コンテンツをユーザに対して事前配信し、ユーザはSTBにおいて受信した事前配信コンテンツを常時蓄積する。
【００８０】
VoDにおける配信要求には、一日を周期とする強い周期性が見られることから、事前配信コンテンツは、ユーザの配信要求とは無関係に、配信サーバが一日を周期に決定し、配信のタイミングをスケジュールする。
【００８１】
事前配信に用いるチャネル数と配信レートの積は、アクセス回線のダウンリンク容量の空き帯域以下となる必要があるが、ダウンリンク回線は、複数のユーザで共有され、複数のユーザに異なるコンテンツを同時に配信する場合、各ユーザのダウンリンク容量が低下する。
【００８２】
しかし、事前配信において、どのコンテンツをどのタイミングで配信するかは、配信サーバが自由に設定できるため、同一のコンテンツを全ユーザにブロードキャスト（BC）することで、ダウンリンクのスループット低下を回避する。
【００８３】
ユーザは、視聴したいコンテンツが自身のSTBに存在する場合には、配信サーバに要求することなく視聴することが可能である。
【００８４】
STBに事前配信されたコンテンツを視聴する際にはネットワークにトラヒックが発生せず、また、任意のVCR操作に容易に対応することができる。
【００８５】
そのため、人気が高いコンテンツをBC事前配信することで、配信サーバとネットワークの負荷を大きく低減できる。
【００８６】
尚、一般に、著作権保護の観点から、STBに蓄積されたコンテンツには再生可能な期間が設定されることから、再生可能期間を過ぎたコンテンツをSTBから消去する。
【００８７】
そのため、同一のコンテンツであっても、常時、STBにキャッシュさせるためには、再生可能期間の周期で繰り返しBC事前配信する必要がある。
【００８８】
BC事前配信は、配信要求の少ない早朝等の時間帯も含めて常時行えるため、配信サーバやネットワークの空き資源を有効活用しつつ、ピーク時の負荷低減が可能となる。
【００８９】
また、電力消費量が時間的に平滑化される結果、オフピーク時の余剰電力を活用することができ、二酸化炭素排出量の削減効果も期待できる。
【００９０】
以下、既存の配信システムであるマルチキャスト配信とP２P配信と、本例でのBC事前配信との主な相違点について説明する。
【００９１】
まず、＜マルチキャスト配信との相違点＞について説明する。
【００９２】
マルチキャスト配信ではレスポンス時間が増大し即時配信性が損なわれるのに対して、本例のBC事前配信では、全ての配信要求において即時に視聴を開始することができオンデマンド性が完全に実現される。
【００９３】
また、マルチキャスト配信はVCR操作に対応するため配信ツリー切り替えの複雑な処理が必要であるのに対して、本例のBC事前配信では、ユーザはSTBに事前配信されたコンテンツを視聴するか、もしくは配信サーバから即時にユニキャスト配信されるコンテンツを視聴するため、いずれの場合も容易にVCR操作に対応できる。
【００９４】
次に、＜P２P配信との相違点＞について説明する。
【００９５】
従来のP２P配信の場合、ユーザの自律的な行動にサーバ機能が依存するため、ユーザの離脱やVCR操作に対しても配信を継続させる処理や、ユーザにコンテンツを他のユーザにアップロードさせるインセンティブが必要であり、また全体最適化が困難である。
【００９６】
ISP制御型P２P配信の場合、これらの問題を解決することができるが、P２P型の配信を用いている点は変わらず、他のユーザへのコンテンツ配信によって生じる電力コストを負担するインセンティブを与える必要があることや、ユーザ間の配信によりトラヒックがネットワーク内に発生するため、ネットワーク負荷の低減効果は期待できない。
【００９７】
これに対して、本例のBC事前配信は、STBをキャッシュとして用いる点は同じであるが、各STBにキャッシュされたコンテンツは各STB所有するユーザのみが視聴するため、ユーザに何らかの協力を求めるためのインセンティブが不要であり、また、STBにキャッシュされたコンテンツの視聴によってネットワーク内にはトラヒックが発生しない。
【００９８】
次に、本例のコンテンツ配信システムでの処理を実施する際の＜前提条件＞について説明する。＜前提条件＞として以下の（Ａ）〜（Ｇ）が掲げられる。
【００９９】
前提条件（Ａ）：アクセス回線のダウンリンク容量は全てＡｄ（bps）であり、コンテンツの再生レートは全てＲ（bps）である。
【０１００】
前提条件（Ｂ）：ユーザの配信要求に対して配信サーバからユニキャストで配信する際、再生レートＲに等しい配信レートで配信する。
【０１０１】
前提条件（Ｃ）：BC配信の配信レートは、各BC配信チャネルにおいて常時Ｒｂ（bps）に設定する。
【０１０２】
前提条件（Ｄ）：コンテンツをSTBに配信後、配信日を含めてＬ日が経過した午前０時に消去する。
【０１０３】
前提条件（Ｅ）：STBのストレージ容量は十分に大きく、BC事前配信された全コンテンツをSTBに蓄積可能とする。
【０１０４】
前提条件（Ｆ）：ユーザがBC事前配信コンテンツを視聴したログ情報（コンテンツIDと視聴時刻）を配信サーバに通知する。
【０１０５】
前提条件（Ｇ）：第ｎ日目の開始時点（午前０時）において、第ｎ日目の２４時間の間にBC事前配信するコンテンツをスケジューリングする。
【０１０６】
次に、本例のコンテンツ配信システムにおける＜配信制御法＞について説明する。
【０１０７】
まず、図２の設定パラメタ入力部２０１とＢＣ事前配信レートとチャネル数の設定部２０２における＜BC事前配信レートとチャネル数の設定＞について説明する。
【０１０８】
VoDサービスの運用開始に先立ち、ISPは、以下のようにして、BC事前配信の配信レートＲｂと、BC事前配信チャネル数Ｂを設定する。まず、コンテンツの平均長をＳ（秒）とし、正の実数パラメタγに対してＲｂ=γＲに設定する。
【０１０９】
各ユーザに対してオンデマンドのユニキャスト配信の伝送帯域を確保するためには、「Ｂ≦（Aｄ-R）/γＲ」を満たす必要がある。よって、床関数（floor）を用いて「Ｂ=floor（（Aｄ-R）/γR）」に設定する。
【０１１０】
また、一日に一つのBC事前配信チャネルから配信可能なコンテンツ数の平均値Ｘは、「Ｘ=２４×３６００γ/Ｓ」となる。
【０１１１】
ＢとＸの積（「Ｂ×Ｘ」）が一日にBC事前配信可能な平均コンテンツ数となるため、「Ｂ×Ｘ」が最大となるようγを設定することが望ましい。すなわち、「（Aｄ-R）/γＲ」が整数となるよう、任意のＢに対して「γ=（Aｄ-R）/ＢＲ」に設定することで「Ｂ×Ｘ」を最大化できる。
【０１１２】
次に、図２の各コンテンツのＴＤＬＴ測定部２０３と翌日の各コンテンツのＴＤＬＴ推定部２０４における＜BC事前配信コンテンツの選択優先度＞について説明する。
【０１１３】
本例のBC事前配信の効果を高めるには、BC事前配信によりSTBにキャッシュされたコンテンツを用いて各ユーザが視聴可能な時間の、全視聴時間に対する比率を高める必要がある。
【０１１４】
一般にコンテンツの長さは様々であり、また、全てのユーザがコンテンツの全体を視聴するとは限られない。一方、第ｎ日目の２４時間に発生したコンテンツｍに対する配信要求の集合をＱm,nとし、配信要求ｑの視聴時間をｔq（秒）とするとき、第ｎ日目におけるコンテンツｍに対する総ダウンロード時間（TDLT）Ｄm,n（秒）は「Ｄm,n=Σq∈Qm,ntq」となるが、Ｄm,nが大きなコンテンツを優先的に第ｎ日目においてBC事前配信するほど、第ｎ日目において配信サーバ負荷が低減される。
【０１１５】
第ｎ日目の開始時点において設定された配信スケジューリングにより、第ｎ日目の２４時間にBC事前配信されるコンテンツが決定されるが、これらコンテンツは第ｎ日目から第n+L-１日目のＬ日間、STBに存在する。そのため、これらＬ日間にわたるＤm,nの総和が大きなコンテンツを、第ｎ日目の配信スケジューリングにおいて優先的に選択することが望ましい。
【０１１６】
しかしｎ日目の開始時点において、「i≧n」のＤm,iを得ることはできないため、何らかの方法でＤm,nを推定する必要がある。
【０１１７】
本例では、金融工学や気象予測等の分野で広く用いられている指数移動平均（EMA:Exponential Moving Average）を用いてＤm,nを推定する。
【０１１８】
指数移動平均（EMA）は、時間の経過に伴い指数関数的に減少する重み付けを行った過去の実測値の平均を推定値とし、直近のデータを重視すると共に古いデータを完全には切り捨てない。平滑化係数αと第n-１日目の実測値Ｄm,n-１を用いて、第ｎ日目の推定値D’m,nを、次の式（１）を用いて得る。
【０１１９】
「D’m,n=αＤm,n−１+（１-α）D’m,n-１」 …（式１）
【０１２０】
平滑化係数αは０から１の値をとり、１に近いほどより直近のデータを重視する。一般的には、任意に設定した２以上の整数値をとるパラメタＮに対して、直近のＮ個の時系列データが８６％の重みを持つよう「α=２/（N+１）」で設定する。
【０１２１】
本例の配信サーバにおいて、各コンテンツｍに対して最新の推定値Ｄ’（m,n）を保存しておき、Ｄ（m,n-１）を実測することで、配信スケジューリング時に、上述の式（１）を用いて推定されたTDLT値Ｄ’（m,n）が大きな順に優先的に、第ｎ日目においてBC事前配信を行う。
【０１２２】
ただし、第n-L日から第n-１日においてBC事前配信されたコンテンツは第ｎ日目においてSTBにキャッシュされているため、ｎ日目のスケジューリング対象から除いて考える。
【０１２３】
次に、図２の各BC配信チャネルへの配信コンテンツ割当部２０５と配信スケジュール部２０６における＜BC事前配信スケジューリング＞について説明する。
【０１２４】
従来、BC配信やPush型マルチキャスト配信を対象に様々な配信スケジューリング方式が検討されているが、いずれもレスポンス時間を低減する観点から考察されている。
【０１２５】
これに対して、本例のコンテンツ配信システムでのBC事前配信においては、ユーザの配信要求に対して要求コンテンツがSTBに存在しない場合、ユニキャストにより配信サーバから即時に配信されるため、配信スケジューリングを設計する際にレスポンス時間を考慮する必要がない。
【０１２６】
そこで、本例では、以下のように、各日の開始時点でBC事前配信を行う配信スケジューリングとする。
【０１２７】
STBにキャッシュされていないコンテンツの中でTDLTの推定値Ｄ’（m,n）が大きなコンテンツを優先的にBC事前配信する。また、コンテンツｍの長さをSm（秒）とすると、コンテンツｍの第ｎ日目における配信要求数は「Ｄ’（m,n）/Sm」で推定できるが、この値が大きなコンテンツほど早いタイミングで配信することで、より多くの視聴要求に対して事前配信されたコンテンツを用いることが可能となる。
【０１２８】
このような考察から、以下の（イ）〜（ホ）のようにして配信スケジューリングを行う。
【０１２９】
（イ）各ブロードキャスト配信チャネルiの空き時間Ｅiを「２４×３６００」秒に初期化する。
【０１３０】
（ロ）第n-L〜n-１日にBC事前配信されたものを除いたコンテンツを対象にＤ’（m,n）の降順に優先順位を設定する。
【０１３１】
（ハ）空き時間Eiが最大の配信チャネルoに対して、未割当でSm≦Eoを満たすコンテンツの中で優先順位が最高のコンテンツを割当る。
【０１３２】
（ニ）割当可能なコンテンツが存在する限り、上述の割当処理を反復する。
【０１３３】
（ホ）各配信チャネルに対して、割当られたコンテンツの配信順序を「Ｄ’（m,n）/Sm」の降順に設定する。
【０１３４】
次に、本例のコンテンツ配信システムの実際の＜性能評価＞について説明する。
【０１３５】
まず、China Telecomが提供する商用VoDサービスであるPowerInfo（商標） VoDシステムにおいて収集されたアクセスログデータを用いて、本例のコンテンツ配信システムの有効性を評価する。
【０１３６】
本評価例で用いたログデータには２００４年６月から１２月の７ヶ月間に発生した２０,９２１,６５７の全配信要求が含まれており、総コンテンツ数は６,７３５、総ユーザ数は３７,３６０である。
【０１３７】
図４（ａ）において、コンテンツ長Smの累積輔分布（CCD:Complementary Cumulative Distribution）を示す。４５分と９０分の長さを有するコンテンツが各々、全体の約４０％ずつを占めており、平均コンテンツ長Ｓは３,５１０秒である。
【０１３８】
また、図４（ｂ）において、一日あたりの総ダウンロード時間TDLTを各ユーザもしくはコンテンツごとに集計した値の、全期間にわたる平均値のCCDを、ユーザ集合とコンテンツ集合の各々に対して示す。
【０１３９】
各ユーザやコンテンツの一日あたりのTDLTの差異は大きく、少数のユーザが大量の配信を行っていること、また特定のコンテンツに配信要求が集中していることが確認できる。また多くのユーザは一日あたり平均して数１０分〜１時間程度、コンテンツを視聴しており、多くのコンテンツの一日あたりの延べ配信時間は１時間〜１０時間程度である。
【０１４０】
BC事前配信チャネル数Ｂは任意に設定可能であるが、Ｂの増加に伴い分割損の影響が増すため、より優先度の低いコンテンツがBC事前配信対象として選択される。よって評価ではＢ=１に設定する。
【０１４１】
またBC事前配信を行ったことでユーザの視聴パタンは影響を受けず、アクセスログに従い配信要求が発生することを想定する。
【０１４２】
またアクセス回線のダウンリンク容量をＡｄ=１０Mbps、コンテンツの再生レートをＲ=２Mbpsに設定する。このとき、γ=４となりBC事前配信レートはＲｂ=８Mbps、一日あたりの平均BC事前配信コンテンツ数XはX=９８.４６となる。
【０１４３】
次に、＜総ダウンロード時間の推定精度＞について説明する。本例では指数移動平均（EMA）を用いた各コンテンツのTDLTの推定精度を評価する。
【０１４４】
図５（ａ）においては、７つのラグd（日）の各々に対して、各コンテンツの日単位のTDLTの自己相関係数のCDをプロットしている。dが大きく間隔が開くほど、各コンテンツのTDLTの自己相関性は低下するが、ラグ１日の場合、約３割程度のコンテンツのTDLTの自己相関係数は０.５以上あり、高い相関性が見られる。
【０１４５】
コンテンツの保存期間をL=１（日）に設定したときに、各ｎ日目の開始時点において上述の式（１）で推定されたＤ’（m,n）の上位floor（X）=９８個のコンテンツの第ｎ日目におけるTDLTの総和を、第ｎ日目の実際のTDLTの降順に上位９８個のコンテンツのTDLTの総和で除した値の全期間にわたる平均値を、EMA推定精度ηeと定義する。
【０１４６】
図５（ｂ）においては、EMAの平滑化パラメタαを定める系列長Ｎを変えた場合のηeをまとめている。図５（ａ）で見たように、ラグの増加に伴ない各コンテンツのTDLTの自己相関性が低下するため、Ｎの増加に伴い推定精度ηeは緩やかに減少する。よって以後の評価ではN=２に設定する。
【０１４７】
コンテンツ保存期間Ｌが２日以上の場合、STBにキャッシュされるコンテンツの一部は２日以上前のTDLT予測値に基づき事前配信されたコンテンツとなる。
【０１４８】
そこで、L≧２におけるBC事前配信コンテンツの選択効率を評価するため、図６（ａ）において、d日間離れた日におけるTDLTの上位x個のコンテンツのうち、両日において共通して上位x以内となったコンテンツの割合の全期間における平均値を、７つのdの値を対象にxに対してプロットした結果を示す。
【０１４９】
図６（ａ）に示すように、xが小さい領域では、間隔dが増加するに伴い上位x個のコンテンツの一致度は低下するが、xの増加に伴い一致度が増加する結果、xが１,０００程度以上になるとdによる一致度の差異はなくなる。
【０１５０】
コンテンツ保存期間Ｌの増加に伴い、STBにキャッシュされたコンテンツのBC事前配信時からの平均経過日数が増加するが、一方でキャッシュコンテンツ数はＬの増加に伴い増加するため、Ｌが事前配信コンテンツの選択効率に与える影響は小さいことが予想される。
【０１５１】
図６（ｂ）においては、各日にx個のコンテンツをBC事前配信できる場合に、EMAで推定したTDLTに基づき事前配信コンテンツを選択した結果、各日においてSTBに存在するLx個のコンテンツに対するTDLTの合計を、実際のTDLTの上位Lx個のコンテンツに対するTDLTの合計で除した値の全期間にわたる平均値を、Ｌの３つの場合を対象にxに対してプロットした結果を示す。
【０１５２】
xが小さい場合、図６（ａ）で見たように、Ｌの増加に伴いTDLT上位コンテンツの一致度が大きく低下する結果、事前配信コンテンツの選択効率はＬの増加に伴い低下する。しかし、選択効率の低下度合いは小さく、図６（ｂ）に示すように、例えばＬが７日程度であれば、７０％程度の選択効率が得られる。
【０１５３】
また、選択効率はxの増加に伴い増加し、xが１０程度以上大きい領域では８５％〜９０％程度となる。コンテンツ数Mに対してx≧M/Ｓにおいては、全コンテンツがSTBにキャッシュされるため選択効率は１となる。
【０１５４】
以上のことから、EMAを用いたTDLTの推定値に基づきBC事前配信コンテンツを選択することで、十分な選択効率が達成され、配信サーバやNWの負荷低減効果が期待できる。
【０１５５】
以下、このような評価データを用いた本例のコンテンツ配信システムの＜効果＞について説明する。
【０１５６】
全期間の全ユーザのTDLTの合計をY１（秒）と定義し、また、第ｎ日の開始時点において第ｎ日のTDLTが大きな上位floor（X）=９８個のコンテンツを一瞬で全STBに配送した理想的なキャッシュ状態において、STBキャッシュコンテンツを視聴した全ユーザのTDLTの全期間の合計をY２（秒）と定義し、同様に、本例のコンテンツ配信システムにより第ｎ日にBC事前配送スケジュールされた全コンテンツを一瞬で第ｎ日の開始時点において全STBに配送したキャッシュ状態において、STBキャッシュコンテンツを視聴した全ユーザのTDLTの全期間の合計をY３（秒）と定義し、本例のコンテンツ配信システムにより実際にBC事前配信されたコンテンツを視聴した全ユーザのTDLTの全期間の合計をY４（秒）と定義する。ただし最初のＬ日間は対象外とする。
【０１５７】
図８において、Ｌの７つの値に対して、「Y２/Y１」、「Y３/Y２」、「Y４/Y３」、「Y４/Y１」の値を各々まとめている。「Y２/Y１」は、BC事前配信によって達成可能な性能限界を表すが、Ｌの増加に比例してキャッシュされるコンテンツ数が増加するため、Ｌの増加に伴い大きく向上する。
【０１５８】
また、「Y３/Y２」は、EMAを用いたTDLTの推定精度を表すが、図６（ｂ）で見たように、Ｌの値による影響は小さく８５％〜９０％程度の高い推定精度が達成される。
【０１５９】
実際には配送予定のコンテンツを各日の開始時点で瞬時に配送することはできず、設定したスケジュールに応じて順次配送するため事前配信の効率は低下するが、その低下に相当する効率「Y４/Y３」は、L=１の場合で０.８程度、L≧２の場合で０.９程度以上と高い。
【０１６０】
また、「Y４/Y１」は、実際の事前配信の効果に相当するが、「Y４/Y１=Y２/Y１×Y３/Y２×Y４/Y３」であり、これら３つの評価値の積となるが、「Y２/Y１」が最もＬの影響を強く受けるため、Ｌの増加に伴い事前配信の効率は大きく向上する。
【０１６１】
ISPは、ピーク需要に基づき配信サーバを設計する必要があり、配信サーバのピーク負荷を抑えることが総コストを抑えるために重要である。
【０１６２】
そこで、図７（ａ）において、配信サーバからの同時配信セッション数の、各日における最大値を全期間にわたりプロットした結果を示す。ただし、配信サーバは、常時、BC配信を行う必要があるため、そのための負荷をユニキャスト配信のためのセッション数に換算した「（Aｄ-R）Ｒ」を加算している。
【０１６３】
図７（ａ）に示すように、全期間にわたり、事前配信を行わない場合（L=０）と比較して、事前配信を行うことで最大同時セッション数が大きく低減され、その効果はＬが大きいほど大きくなる。
【０１６４】
また、図７（ｂ）においては、１２/１〜１２/７の７日間を対象に、１時間ごとの最大同時セッション数を同様にプロットした結果を示している。
【０１６５】
この図７（ｂ）に示すように、配信需要には日単位の強い周期性が見られ、また週末（１２/４と１２/５）は増加するが、いずれの時間帯においても、最大同時セッション数が事前配信を用いることで削減できること、また、その効果は需要が高い時間帯ほど高いことが確認できる。
【０１６６】
図９において、全期間における最大同時セッション数Kmaxと、各日において配信サーバが配信したTDLTの平均値V（秒）を、事前配信を行わない場合（L=０）と行う場合のＬの７つの場合について各々まとめる。
【０１６７】
図９に示すように、Ｌの増加に伴いKmaxとVは低減し、例えばL=４のとき、事前配信を行わない場合と比較して約半分に低減できる。
【０１６８】
このように、VoDサービスにおいて、本例のコンテンツ配信システムによるBC事前配信を行うことで、配信サーバのピーク負荷やネットワークに加わる負荷を大きく低減でき、ISPのサービス提供コストを大きく削減することができる。
【０１６９】
しかし一方で、ユーザの配信要求とは無関係に大量のコンテンツをBC配信するため、STBに大容量のストレージが必要となる。図９においては、本例のコンテンツ配信システムによる事前配信コンテンツの利用率ηと、STBの最大必要ストレージ容量Zmax（Tbyte）をあわせて示す。ただし、ηを、事前配信されたコンテンツの中で各ユーザが実際に視聴したものの割合の全期間にわたる平均値で定義する。
【０１７０】
以上、図１〜図９を用いて説明したように、本例のコンテンツ配信システムでは、VoDサービスにおいて、ユーザの配信要求に対して即時にユニキャスト配信する配信形態に加えて、配信要求とは無関係に、予め定めた配信スケジュールに従い、人気の高いコンテンツを常時、全てのユーザに対してブロードキャスト配信し、ユーザ宅内に設置されたSTBに事前配信する。
【０１７１】
このことにより、ピーク時の配信サーバ負荷とネットワーク負荷の低減を図ることができる。
【０１７２】
尚、事前配信されたコンテンツをユーザが視聴可能な期間がＬ日であるとき、過去Ｌ日に事前配信されたコンテンツを除き、各コンテンツの一日の総ダウンロード時間（TDLT）が大きな順に優先的にブロードキャスト事前配信するよう、一日を周期に事前配信スケジュールを設計する。
【０１７３】
また、指数移動平均を用いて過去のTDLTの実測値から推測した、翌日の各コンテンツのTDLTに基づきブロードキャストで事前配信するコンテンツを選択する。
【０１７４】
また、アクセス回線のダウンリンク容量が全てＡｄ（bps）、コンテンツの再生レートが全てＲ（bps）、配信要求に対して配信サーバからユニキャストで配信する際、再生レートＲに等しい配信レートで配信するとき、ブロードキャスト事前配信の配信レートＲｂ（bps）とブロードキャスト事前配信チャネル数Ｂを、一日あたりの事前配信コンテンツ数が最大化するよう、任意のＢに対してＲｂ=（Aｄ-R）/Ｂに設定する。
【０１７５】
また、空き配信時間が最大の事前配信チャネルに、未割当でコンテンツ長が空き時間以下となるコンテンツの中でTDLTの推測値が最大のコンテンツを順次に割当てる処理を反復することで、各事前配信チャネルにおいて配信するコンテンツを割当てる。
【０１７６】
また、各事前配信チャネルに割当てられたコンテンツを、TDLTの推定値をコンテンツ長で除した値が大きな順番に配信スケジュールを設定する。
【０１７７】
尚、本発明は、図１〜図９を用いて説明した例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。例えば、本例では、配信サーバ１０１と配信スケジュール設計装置２００をそれぞれ個別のコンピュータ装置で構成しているが、１つのコンピュータ装置内に配信サーバ１０１と配信スケジュール設計装置２００の機能を設けた構成としても良い。
【０１７８】
また、本例のコンピュータ構成に関しても、キーボードや光ディスクの駆動装置の無い構成としても良い。また、プログラムを記録する記録媒体に関しても、光ディスクに限らず、ＦＤ（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ）等を記録媒体として用いることでも良い。また、プログラムのインストールに関しても、通信装置を介してネットワーク経由でプログラムをダウンロードしてインストールすることでも良い。
【符号の説明】
【０１７９】
３１：サービスプロバイダ、３２：配信サーバ、３３：ユーザ、１０１：配信サーバ装置、１０２：ユーザ端末装置、２００：配信スケジュール設計装置、２０１：設定パラメタ入力部、２０２：ＢＣ事前配信レートとチャネル数の設定部、２０３：各コンテンツのＴＤＬＴ測定部、２０４：翌日の各コンテンツのＴＤＬＴ推定部、２０５：各ＢＣ配信チャネルへの配信コンテンツ割当部、２０６：配信スケジュール部。
【技術分野】
【０００１】
本発明は、インターネット等のＩＰ（Internet Protocol）ネットワークにおけるコンテンツの配信技術に係り、特に、VoD（Video On Demand）サービス等の大容量のコンテンツを効率的に配信するのに好適な技術に関するものである。
【背景技術】
【０００２】
近年、アクセス回線の大容量化に伴い、動画コンテンツをユーザの配信要求に対してオンデマンドに配信するVoDサービスの普及が目覚ましい。VoDサービスは、サービスプロバイダが配信サーバをネットワーク（NW）上に設置し、また、配信された動画データを一時蓄積して再生するための装置（STB:Set Top Box）をユーザ宅内に設置することで実現される。
【０００３】
また、動画配信サービスは、ユーザが作成した小サイズの動画コンテンツをユーザ間で交換するYouTube等のUGC（User Generated Content）を対象とするものと、映画やTVドラマなど、コンテンツ制作会社が制作した高品質の動画コンテンツ（リッチコンテンツ）を対象とするもの、に大きく分けることができる。
【０００４】
前者（UGC配信）はCDN（Contents Delivery Network）サービスを用いて、ISP（Internet Service Provider）とは独立したサービスプロバイダが提供する形態が一般的であるのに対して、後者（リッチコンテンツ）はコンテンツが大容量であることから、主にNWの品質を管理、制御することが可能なISPが提供する形態が一般的である。
【０００５】
多くのISPは、自身のNWサービスを差別化するキラーサービスとしてVoDサービスを位置付けており、今後もリッチコンテンツを対象としたVoDサービスの普及が予想される。以下、このような大容量コンテンツ配信となるVoDサービスを対象に説明する。
【０００６】
一般に、動画コンテンツの視聴は夜間に集中する傾向があり、一日の周期で大きく変動する。しかし、ISPにはピーク時間帯にも安定したサービス品質を維持することが求められるため、ISPでは、ピーク時の需要量を考慮して配信システムを設計する必要がある。
【０００７】
そのためピーク時以外の多くの時間帯においては、過剰な配信システム設計となり、ISPの収益を低下させる要因となる。
【０００８】
ISPの収益を向上させ、ユーザに対して安価なVoDサービス提供を可能とするためには、ピーク時のサーバ負荷低減がISPにとって大きな課題である。また、リッチコンテンツは大容量であるため、配信によって生じるトラヒックがNWに与える影響を抑えることも重要である。
【０００９】
ピーク時のサーバ負荷を低減する技術として様々なものが検討され実用化されているが、主に、キャッシュサーバを用いる技術（CDN）、マルチキャスト配信、P２P型配信、の３つに分類できる。
【００１０】
キャッシュサーバを用いる技術では、ISPが自身のNW上に複数配置したキャッシュサーバ上にコンテンツのコピーを配置し、ユーザの配信要求に対して、当該ユーザに近接するキャッシュサーバから配信を行う。この技術によれば、ユーザのレスポンス時間向上とオリジナルサーバの負荷低減効果が期待できる。
【００１１】
また、マルチキャスト配信は、同一のコンテンツを要求した複数のユーザに対して、マルチキャスト配信ツリーを用いて単一の配信セッションで配信するもので、ユーザ集約度の向上に比例してサーバ負荷の低減効果が期待できる。
【００１２】
また、P２P型配信システムは、ユーザ間で保有するコンテンツを交換することでコンテンツ配信を実現するもので、BitTorrent（登録商標）等、広く普及している。従来は、UGCの交換を目的に利用されてきたが、近年、リッチコンテンツを配信する手段としてもP２P配信技術が用いられている。
【００１３】
このP２P型配信システムにおいては、各ピア（ユーザ）は、配信を受け視聴中のコンテンツを他のピアに対してアップロードするため、人気が高いコンテンツほどサーバ機能を提供するピアが増加するため、スケーラビリティに優れたサーバ負荷低減効果の高い配信技術である。
【００１４】
また、近年、ハードディスクドライブの価格低下は目覚ましく、現在、１T（テラ）バイト程度のものを１００USD（米国ドル）程度で購入することが可能である。そのため、ユーザ宅内に設置されたSTBやGW（Gate Way）を、ISPの管理下でキャッシュとして運用することが広く検討されている。
【００１５】
このような上述の技術については、非特許文献１〜３に記載されている。
【００１６】
しかし、キャッシュを用いた配信技術では、ISPが用意するキャッシュサーバを含めたサーバ設備から配信される総量は一定であるため、ユーザ数の増加に対してISPはサーバ設備を常に増設し続ける必要があり、設備コストの大きな低減効果は期待できない。
【００１７】
これに対して、マルチキャスト配信は、同一のコンテンツを要求する複数のユーザに対して、配信サーバを根とし配信先ユーザを葉とする一本のマルチキャスト配信ツリーを用いて同時に配信する技術であり、配信サーバとNWの負荷を低減する技術として有効であり、近年、広く普及しつつある地上波テレビ放送をインターネット上で提供するIPTVにおいては、一般にマルチキャスト配信が用いられている。
【００１８】
しかしIPTVにおいては、ユーザが視聴時刻をサービス提供者に合わせ、またVCR（Video Cassette Recorder）操作を伴わないため、容易にマルチキャスト配信を適用することが可能であるのに対して、ユーザが任意のタイミングで任意のコンテンツの視聴を要求するVoDサービスにおいては、ユーザの配信要求時刻の不一致性への対応と、VCR操作への対応が課題となる。
【００１９】
このような、ユーザの配信要求の不一致性に対する対処技術として様々なものが検討されているが、ユーザの配信要求に基づくPull型配信と、ユーザの配信要求とは無関係に事前に配信スケジューリングを設計するPush型配信とに分類することができる。
【００２０】
Pull型配信は、ユーザの配信要求に対して、即時には配信を開始せず、待ち合わせ期間を設けることで、その間に発生した同一コンテンツに対する配信要求を一つのマルチキャスト配信に集約する。最も簡易な技術では、ユーザのレスポンス時間に上限値Ｄを設け、他に待ち中のユーザが存在しないコンテンツに対する要求が生じた時刻からＤ後にそのコンテンツを配信する。
【００２１】
他にもFIFO（First In First Out）で配信コンテンツを選択するものや、待ちユーザ数が最大のコンテンツを配信コンテンツに選択するもの、平均レスポンス時間が最小化するよう配信コンテンツを選択するものなど、様々な技術が検討されている。
【００２２】
一方Push型配信は、サービスプロバイダが事前に各コンテンツを配信するタイミングを配送スケジュールとして静的に設計する技術であり、通常、全ユーザを配信先とするブロードキャスト配信が用いられる。
【００２３】
この場合、ユーザの配信要求のタイミングは考慮されず、ユーザは配信スケジュールに合わせて視聴したいコンテンツを視聴することになるため、オンデマンド性は損なわれ、VoDよりもIPTVに近いサービス実現形態となる。配信スケジュールの設計技術としては様々なものが検討されているが、いずれもレスポンス時間を低減する観点から考察されている。
【００２４】
Pull型配信においては、サーバやNWの負荷低減効果を得るためには、配信ツリーのユーザ多重度を上げる必要があり、レスポンス時間の悪化が避けられない。
【００２５】
またPush型配信においては、高人気のコンテンツを除き、配信周期が長くなる傾向があり、やはりオンデマンド性が犠牲になる。
【００２６】
本来、オンデマンド性を重視するVoDサービスにおいては、ユーザの配信要求に対して即時に配信を開始することが望ましく、レスポンス時間の悪化がマルチキャスト配信の大きな問題である。
【００２７】
また、VCR操作に対して、VCR操作後の再生点に近い他のマルチキャスト配信ツリーに該当ユーザを移行させる必要がある。
【００２８】
また、完全に再生タイミングが一致する配信ツリーが存在しない可能性が高いため、タイミングの誤差分をユニキャスト配信するなど、複雑な処理が必要となる。
【００２９】
P２P配信システムでは、配信要求ユーザに対して、要求コンテンツを視聴中の他のユーザから配信する。同一コンテンツを視聴するユーザが他に存在しない場合や、存在してもアップロード帯域が不足するような場合には、配信サーバより配信する。人気の高いコンテンツほど視聴中ユーザの数が増加するため、スケーラビリティに優れた配信システムである。
【００３０】
このP２P配信システムでは、元々はファイル全体を受信後に利用するファイルダウンロードにおいて用いられていたが、動画ストリーミングサービスへの適用が広がり、商用システムとしても用いられている。またVCR操作に対応したVoDの商用システムへの適用も見られる。
【００３１】
しかし、ユーザはコンテンツ視聴終了後に配信システムから離脱する可能性が高く、また視聴中であっても視聴を中断して離脱する可能性もある。
【００３２】
このような、離脱ユーザの存在やVCR操作に伴う再生点の移動に対しても配信を継続させる処理が必要となり、各ユーザの再生点の管理や配信元の切り替え処理等、複雑な処理が必要となる。
【００３３】
また、各ユーザのアップリンク容量にシステム全体の性能が大きく依存する。ADSL等、ユーザのアクセス回線のアップリンク容量はダウンリンク容量と比較して小さいことが多く、アップリンク容量が小さい場合には十分な効果が得られない。またサーバ機能の多くを自律的に行動するユーザに依存するため、システムの全体最適化が困難である。
【００３４】
このようなP２P型配信システムの問題点に対して、ユーザ宅内に設置されたSTBやGWを、ISPが集中的に管理するキャッシュ装置として活用し、P２P配信を行うVoDシステムが検討されている。以後、これらISPが集中的に管理するSTBを用いたP２P配信システムをISP制御型P２P配信と呼ぶ。
【００３５】
このISP制御型P２P配信においては、ユーザ宅内のSTBはISPの管理下にあるため、他のユーザに対して常時、保有コンテンツの配信を行うことが可能である。そのため、従来のP２P配信システムで問題であった、ユーザのシステム離脱に起因する配信元の切り替え処理が不要となり、各STBのキャッシュコンテンツと配信元STB選択を最適化することで、全体最適化が可能となる。
【００３６】
しかし、他のユーザに対してコンテンツを配信する際に必要となる電力を各ユーザが負担する必要があり、ISPが制御するSTBを宅内に設置するインセンティブをユーザに与える必要がある。
【００３７】
また、配信サーバの負荷は低減されるものの、ユーザ間のP２P配信によってNW内にトラヒックが発生するため、NWの負荷低減効果は得られない。
【先行技術文献】
【非特許文献】
【００３８】
【非特許文献１】M.Allen, B.Zhao, and R.Wolski,"Deploying Video-on-Demand Services on Cable Networks,"IEEE ICDCD 07.
【非特許文献２】H.Ma and K.Shin,"Multicast Video-on-Demand Services,"ACM SIGCOMM CCR,32(1),pp.31-43,2002.
【非特許文献３】B.Cheng, L.Stein, H.Jin, and Z.Zhang,"Towards Cinematic Internet Video-on-Demand,"ACM EuroSys 08.
【発明の概要】
【発明が解決しようとする課題】
【００３９】
解決しようとする問題点は、従来の技術では、インターネット等のＩＰネットワークにおいてコンテンツを配信するサーバの負荷の低減とネットワーク負荷の低減を共に図ることができない点である。
【００４０】
本発明の目的は、これら従来技術の課題を解決し、VoDサービス等の大容量のコンテンツの効率的な配信を可能とすることである。
【課題を解決するための手段】
【００４１】
上記目的を達成するため、本発明では、VoDサービス等において、ユーザの配信要求に対して即時にユニキャスト配信する配信形態に加えて、ユーザからの配信要求とは無関係に、予め定めた配信スケジュールに従い、人気の高いコンテンツを常時、全てのユーザに対してブロードキャスト配信し、ユーザ宅内に設置されたSTBに事前配信する。
【発明の効果】
【００４２】
本発明によれば、VoDサービス等によるコンテンツの配信に伴う、配信サーバの負荷とネットワークの負荷を低減し、コンテンツの効率的な配信が可能となる。
【図面の簡単な説明】
【００４３】
【図１】本発明に係るコンテンツ配信システムの構成例を示すブロック図である。
【図２】図１における配信スケジュール設計装置の構成例を示すブロック図である。
【図３】本発明に係るコンテンツ配信システムの処理動作例を示すシーケンス図である。
【図４】本発明に係るコンテンツ配信システムの評価例を示す説明図である。
【図５】図１における配信スケジュール設計装置によるTDLT推定処理の精度を示す説明図である。
【図６】図１における配信スケジュール設計装置によるコンテンツ選択処理の効率特性を示す説明図である。
【図７】本発明に係るコンテンツ配信システムによるセッション数の時系列変化を示す説明図である。
【図８】本発明に係るコンテンツ配信システムによる配信処理の効率を示す説明図である。
【図９】本発明に係るコンテンツ配信システムによる配信処理の効果を示す説明図である。
【発明を実施するための形態】
【００４４】
以下、図を用いて本発明を実施するための形態例を説明する。図１において、１０１はコンテンツの配信を行う配信サーバ、１０２はSTBを具備したユーザ端末装置、２００は本発明に係るコンテンツの配信制御を行う配信スケジュール設計装置であり、配信サーバ１０１とユーザ端末装置１０２はインターネットを介して接続され、配信サーバ１０１と配信スケジュール設計装置２００はＬＡＮ（Local Area Network）等で接続されている。
【００４５】
配信サーバ１０１とユーザ端末装置１０２および配信スケジュール設計装置２００のそれぞれは、ＣＰＵ（Central Processing Unit）や主メモリ、表示装置、入力装置、外部記憶装置等を具備したコンピュータ装置からなり、光ディスク駆動装置等を介してＣＤ−ＲＯＭ等の記憶媒体に記録されたプログラムやデータを外部記憶装置内にインストールした後、この外部記憶装置から主メモリに読み込みＣＰＵで処理することにより、各処理部の機能を実行する。
【００４６】
例えば、配信スケジュール設計装置２００は、図２に示すように、プログラムされたコンピュータ処理を実行する処理手段として、設定パラメタ入力部２０１、ＢＣ事前配信レートとチャネル数の設定部２０２、各コンテンツのＴＤＬＴ測定部２０３、翌日の各コンテンツのＴＤＬＴ推定部２０４、各ＢＣ配信チャネルへの配信コンテンツ割当部２０５、配信スケジュール部２０６を具備している。
【００４７】
尚、図１において、配信サーバ１０１は、ユーザ端末装置１０２以外の図示していない多数のユーザ端末装置に接続される。また、配信サーバ１０１と配信スケジュール設計装置２００をそれぞれ個別のコンピュータ装置で構成しても、１つのコンピュータ装置内に配信サーバ１０１と配信スケジュール設計装置２００の機能を設けた構成としても良い。
【００４８】
このような構成において、本例のコンテンツ配信システムでは、配信サーバ１０１は、ユーザの配信要求に応じて即時にコンテンツをユニキャスト配信すると共に、配信要求の多いコンテンツを、配信スケジュール設計装置２００において予め定められた配信スケジュールに従い、事前に、全てのユーザ端末装置１０２（セットトップボックス：STB）にブロードキャスト配信（事前配信）する。
【００４９】
配信スケジュール設計装置２００は、各コンテンツのＴＤＬＴ測定部２０３において、各コンテンツの一日の総ダウンロード時間（TDLT:Total DownLoad Time）を計測し、配信スケジュール部２０６において、STBに事前配信したユーザ視聴可能期間内のコンテンツを除く各コンテンツから、TDLTの大きいコンテンツを優先して順に、事前配信対象として選択し、選択したコンテンツを、一日を周期に事前配信するようスケジュール設定する。
【００５０】
また、配信スケジュール設計装置２００は、翌日の各コンテンツのＴＤＬＴ推定部２０４において、各コンテンツのＴＤＬＴ測定部２０３が計測した各コンテンツの過去のTDLTの実測値から指数移動平均を用いて翌日の各コンテンツのTDLTを求め、配信スケジュール部２０６において、指数移動平均を用いて求めたTDLTに基づき、事前配信するコンテンツの選択を行う。
【００５１】
また、配信スケジュール設計装置２００は、配信スケジュール部２０６において、アクセス回線のダウンリンク容量Ａｄ（bps）と、コンテンツの再生レートと同じユニキャスト配信の配信レートＲ（bps）を用いて、事前配信の配信レートＲｂ（bps）を、任意の事前配信チャネル数Ｂに対して、Ｒｂ=（Aｄ-R）/Ｂに設定し、設定した配信レートで事前配信を行うようスケジュール設定する。
【００５２】
また、配信スケジュール設計装置２００は、ＢＣ事前配信レートとチャネル数の設定部２０２において、空き配信時間のある事前配信チャネルに、空き配信時間が大きい順次に、コンテンツ長が空き時間以下のコンテンツを、TDLTの推測値が大きい順に割り当てる。
【００５３】
そして、配信スケジュール設計装置２００は、配信スケジュール部２０６において、ＢＣ事前配信レートとチャネル数の設定部２０２により各事前配信チャネルに割当てたコンテンツから、各コンテンツのTDLTの推定値をコンテンツ長で除した値が大きな順に選択して、事前配信するようスケジュール設定する。
【００５４】
以下、このような本例のコンテンツ配信システムによるコンテンツの配信技術について説明する。
【００５５】
近年のインターネットにおけるアクセス回線のダウンリンク容量の増加は目覚ましく、リッチコンテンツの再生レートと比較しても十分に大きな帯域が利用できる環境が一般的になることが予想される。
【００５６】
例えばSD（Standard Definition）品質の動画像の再生レートが２Mbpsであるのに対して、複数ユーザでの共有ではあるものの、下り方向は最大で２００Mbpsもの伝送帯域が利用できる環境が一部では提供されている。
【００５７】
ユーザが常にダウンリンク容量を使用し続ける可能性は低く、またコンテンツ配信を受ける間も依然として大きな伝送帯域が未使用となる。そのため、ユーザの配信要求に対してオンデマンドで配信サーバより配信を行う通常の配信に加え、未使用の伝送容量を活用し、ユーザの配信要求とは無関係にコンテンツを常時配信しSTBに蓄積することが有効である。
【００５８】
すなわち、ユーザの配信要求時、事前配信によって要求コンテンツが既にSTBに蓄積されている場合、配信サーバからの配信を回避でき、配信サーバやネットワークのピーク時の負荷を低減することが可能となる。
【００５９】
一般に、アクセス回線の伝送資源は多数のユーザで共有され、複数のユーザが同時に異なるコンテンツの配信を受けた場合、スループットが低下する。しかし、ユーザの配信要求とは無関係にSTBに対して配信を行う場合、ISPが自由に配信コンテンツや配信のタイミングを設定でき、全ユーザに対して同一のコンテンツをブロードキャストすることで、ダウンリンクのスループット低下を回避できる。
【００６０】
そこで、本例では、VoDサービスにおいて、ブロードキャストにより所定のコンテンツを所定のユーザに事前に配信する。
【００６１】
このような本例のコンテンツ配信技術では、P２P型配信とは異なり、STBにキャッシュされたコンテンツは各STBを保有するユーザのみが視聴するため、ユーザにコンテンツを他ユーザにアップロードさせるインセンティブを与える必要がなく、また、STBに事前に配信されたコンテンツを視聴する際にはネットワークにトラヒックが発生しないため、ピーク時のサーバ負荷に加えてネットワーク負荷の低減も期待できる。さらにVCR操作に対しても容易に対応できる。
【００６２】
図１に示すコンテンツ配信システムの構成において、ユーザ端末装置１０２のユーザは、視聴したいコンテンツが自身のユーザ端末装置１０２に設けたSTB内に事前配信されている場合には、ローカルにキャッシュされたコンテンツを再生することで視聴する。
【００６３】
視聴したいコンテンツが自身のユーザ端末装置１０２のSTB内に存在しない場合には、ユーザ端末装置１０２から配信サーバ１０１に対して配信を要求する。
【００６４】
ユーザ端末装置１０２からの配信要求を受けた配信サーバ１０１は、直ちにユニキャストで要求元のユーザ端末装置１０２に対して、要求されたコンテンツを配信する。
【００６５】
配信スケジュール設計装置２００は、各コンテンツのＴＤＬＴ測定部２０３において、配信サーバ１０１から配信されるコンテンツごとに総ダウンロード時間（TDLT）を計測し、その計測結果を用いて、翌日の各コンテンツのＴＤＬＴ推定部２０４において、例えば、一日の開始時点（午前０時）毎に、翌日の各コンテンツのTDLTを推測する。
【００６６】
また、設定パラメタ入力部２０１において、コンテンツの平均長Ｓ（秒）、アクセス回線のダウンリンク容量Ａｄ（bps）、コンテンツの再生レートＲ（bps）をBC事前配信レートとチャネル数の設定部２０２に対して入力し、BC事前配信レートとチャネル数の設定部２０２において、得られた設定パラメタを用いて、BC事前配信レートとチャネル数を設定する。
【００６７】
そして、各BC配信チャネルへの配信コンテンツ割当部２０５において、翌日の各コンテンツのTDLT推定部２０４において推定された各コンテンツのTDLTを用いて、BC事前配信レートとチャネル数の設定部２０２において設定した各BC配信チャネル上で配信するコンテンツを割当て、配信スケジュール部２０６において、各BC配信チャネルに割当てられたコンテンツの順序（ブロードキャスト事前配信スケジュール）を決定する。
【００６８】
このようにして、配信スケジュール設計装置２００において決定されたブロードキャスト事前配信スケジュールに基づき、配信サーバ１０１は、予め登録された各ユーザ端末装置（１０２）に対してコンテンツをブロードキャストする。
【００６９】
このような本例のコンテンツ配信システムにおけるVoDサービスでのブロードキャスト事前配信処理動作の手順を、図３を用いて説明する。
【００７０】
図３において、サービスプロバイダ３１は図２における配信スケジュール設計装置２００に相当し、配信サーバ３２は図２における配信サーバ１０１、ユーザ３３は図２におけるユーザ端末装置１０２に相当する。
【００７１】
サービスプロバイダ３１から配信サーバ３２に対してBC事前配信レートとチャネル数の設定を行い（ステップＳ３０１）、サービス運用の開始（ステップＳ３０２）となる。
【００７２】
第１日目において、ユーザ３３からのコンテンツ配信要求（ステップＳ３０３）に対して配信サーバ３２から当該コンテンツの配信（ステップＳ３０４）が行われると、そのコンテンツの総ダウンロード時間が計測され（ステップＳ３０５）、第１日の終わりに、サービスプロバイダ３１において決定されたＢＣ事前配信スケジュールが配信サーバ３２に通知される（ステップＳ３０６）。
【００７３】
第２日目において、配信サーバ３２は、前日にサービスプロバイダ３１から通知されたスケジュールに従って、該当するユーザ３３に対して、通知されたコンテンツをブロードキャストにより配信する（ステップＳ３０７）と共に、第１日目と同様に、ユーザ３３からのコンテンツ配信要求（ステップＳ３０８）に対して当該コンテンツの配信（ステップＳ３０９）を行い、そのコンテンツの総ダウンロード時間が計測され（ステップＳ３１０）、第２日の終わりに、サービスプロバイダ３１において決定されたＢＣ事前配信スケジュールが配信サーバ３２に通知される（ステップＳ３１１）。以上の処理を毎日繰り返す。
【００７４】
以下、このような本例のコンテンツ配信システムによるVoDサービスにおけるブロードキャスト事前配信技術の詳細を説明する。
【００７５】
まず、その＜概要＞について説明する。尚、ここでは、図１における配信サーバ１０１内に配信スケジュール設計装置２００が設けられた構成として説明する。
【００７６】
本例のコンテンツ配信システムは、ISPが用意する配信サーバと配信ネットワーク、そしてSTBとTV等の動画視聴装置を有する複数のユーザ（ユーザ端末装置）から構成される。
【００７７】
配信サーバには、提供するM個の全コンテンツが蓄積されており、ユーザからの配信要求に対して配信サーバは即時に要求コンテンツをユニキャスト配信する。
【００７８】
ユーザは、配信されたコンテンツをSTBに蓄積しつつ再生する。ユニキャスト配信であるため、任意のVCR操作に容易に対応することが可能である。
【００７９】
また、このようなオンデマンドのユニキャスト配信に加えて、配信サーバは、常時、コンテンツをユーザに対して事前配信し、ユーザはSTBにおいて受信した事前配信コンテンツを常時蓄積する。
【００８０】
VoDにおける配信要求には、一日を周期とする強い周期性が見られることから、事前配信コンテンツは、ユーザの配信要求とは無関係に、配信サーバが一日を周期に決定し、配信のタイミングをスケジュールする。
【００８１】
事前配信に用いるチャネル数と配信レートの積は、アクセス回線のダウンリンク容量の空き帯域以下となる必要があるが、ダウンリンク回線は、複数のユーザで共有され、複数のユーザに異なるコンテンツを同時に配信する場合、各ユーザのダウンリンク容量が低下する。
【００８２】
しかし、事前配信において、どのコンテンツをどのタイミングで配信するかは、配信サーバが自由に設定できるため、同一のコンテンツを全ユーザにブロードキャスト（BC）することで、ダウンリンクのスループット低下を回避する。
【００８３】
ユーザは、視聴したいコンテンツが自身のSTBに存在する場合には、配信サーバに要求することなく視聴することが可能である。
【００８４】
STBに事前配信されたコンテンツを視聴する際にはネットワークにトラヒックが発生せず、また、任意のVCR操作に容易に対応することができる。
【００８５】
そのため、人気が高いコンテンツをBC事前配信することで、配信サーバとネットワークの負荷を大きく低減できる。
【００８６】
尚、一般に、著作権保護の観点から、STBに蓄積されたコンテンツには再生可能な期間が設定されることから、再生可能期間を過ぎたコンテンツをSTBから消去する。
【００８７】
そのため、同一のコンテンツであっても、常時、STBにキャッシュさせるためには、再生可能期間の周期で繰り返しBC事前配信する必要がある。
【００８８】
BC事前配信は、配信要求の少ない早朝等の時間帯も含めて常時行えるため、配信サーバやネットワークの空き資源を有効活用しつつ、ピーク時の負荷低減が可能となる。
【００８９】
また、電力消費量が時間的に平滑化される結果、オフピーク時の余剰電力を活用することができ、二酸化炭素排出量の削減効果も期待できる。
【００９０】
以下、既存の配信システムであるマルチキャスト配信とP２P配信と、本例でのBC事前配信との主な相違点について説明する。
【００９１】
まず、＜マルチキャスト配信との相違点＞について説明する。
【００９２】
マルチキャスト配信ではレスポンス時間が増大し即時配信性が損なわれるのに対して、本例のBC事前配信では、全ての配信要求において即時に視聴を開始することができオンデマンド性が完全に実現される。
【００９３】
また、マルチキャスト配信はVCR操作に対応するため配信ツリー切り替えの複雑な処理が必要であるのに対して、本例のBC事前配信では、ユーザはSTBに事前配信されたコンテンツを視聴するか、もしくは配信サーバから即時にユニキャスト配信されるコンテンツを視聴するため、いずれの場合も容易にVCR操作に対応できる。
【００９４】
次に、＜P２P配信との相違点＞について説明する。
【００９５】
従来のP２P配信の場合、ユーザの自律的な行動にサーバ機能が依存するため、ユーザの離脱やVCR操作に対しても配信を継続させる処理や、ユーザにコンテンツを他のユーザにアップロードさせるインセンティブが必要であり、また全体最適化が困難である。
【００９６】
ISP制御型P２P配信の場合、これらの問題を解決することができるが、P２P型の配信を用いている点は変わらず、他のユーザへのコンテンツ配信によって生じる電力コストを負担するインセンティブを与える必要があることや、ユーザ間の配信によりトラヒックがネットワーク内に発生するため、ネットワーク負荷の低減効果は期待できない。
【００９７】
これに対して、本例のBC事前配信は、STBをキャッシュとして用いる点は同じであるが、各STBにキャッシュされたコンテンツは各STB所有するユーザのみが視聴するため、ユーザに何らかの協力を求めるためのインセンティブが不要であり、また、STBにキャッシュされたコンテンツの視聴によってネットワーク内にはトラヒックが発生しない。
【００９８】
次に、本例のコンテンツ配信システムでの処理を実施する際の＜前提条件＞について説明する。＜前提条件＞として以下の（Ａ）〜（Ｇ）が掲げられる。
【００９９】
前提条件（Ａ）：アクセス回線のダウンリンク容量は全てＡｄ（bps）であり、コンテンツの再生レートは全てＲ（bps）である。
【０１００】
前提条件（Ｂ）：ユーザの配信要求に対して配信サーバからユニキャストで配信する際、再生レートＲに等しい配信レートで配信する。
【０１０１】
前提条件（Ｃ）：BC配信の配信レートは、各BC配信チャネルにおいて常時Ｒｂ（bps）に設定する。
【０１０２】
前提条件（Ｄ）：コンテンツをSTBに配信後、配信日を含めてＬ日が経過した午前０時に消去する。
【０１０３】
前提条件（Ｅ）：STBのストレージ容量は十分に大きく、BC事前配信された全コンテンツをSTBに蓄積可能とする。
【０１０４】
前提条件（Ｆ）：ユーザがBC事前配信コンテンツを視聴したログ情報（コンテンツIDと視聴時刻）を配信サーバに通知する。
【０１０５】
前提条件（Ｇ）：第ｎ日目の開始時点（午前０時）において、第ｎ日目の２４時間の間にBC事前配信するコンテンツをスケジューリングする。
【０１０６】
次に、本例のコンテンツ配信システムにおける＜配信制御法＞について説明する。
【０１０７】
まず、図２の設定パラメタ入力部２０１とＢＣ事前配信レートとチャネル数の設定部２０２における＜BC事前配信レートとチャネル数の設定＞について説明する。
【０１０８】
VoDサービスの運用開始に先立ち、ISPは、以下のようにして、BC事前配信の配信レートＲｂと、BC事前配信チャネル数Ｂを設定する。まず、コンテンツの平均長をＳ（秒）とし、正の実数パラメタγに対してＲｂ=γＲに設定する。
【０１０９】
各ユーザに対してオンデマンドのユニキャスト配信の伝送帯域を確保するためには、「Ｂ≦（Aｄ-R）/γＲ」を満たす必要がある。よって、床関数（floor）を用いて「Ｂ=floor（（Aｄ-R）/γR）」に設定する。
【０１１０】
また、一日に一つのBC事前配信チャネルから配信可能なコンテンツ数の平均値Ｘは、「Ｘ=２４×３６００γ/Ｓ」となる。
【０１１１】
ＢとＸの積（「Ｂ×Ｘ」）が一日にBC事前配信可能な平均コンテンツ数となるため、「Ｂ×Ｘ」が最大となるようγを設定することが望ましい。すなわち、「（Aｄ-R）/γＲ」が整数となるよう、任意のＢに対して「γ=（Aｄ-R）/ＢＲ」に設定することで「Ｂ×Ｘ」を最大化できる。
【０１１２】
次に、図２の各コンテンツのＴＤＬＴ測定部２０３と翌日の各コンテンツのＴＤＬＴ推定部２０４における＜BC事前配信コンテンツの選択優先度＞について説明する。
【０１１３】
本例のBC事前配信の効果を高めるには、BC事前配信によりSTBにキャッシュされたコンテンツを用いて各ユーザが視聴可能な時間の、全視聴時間に対する比率を高める必要がある。
【０１１４】
一般にコンテンツの長さは様々であり、また、全てのユーザがコンテンツの全体を視聴するとは限られない。一方、第ｎ日目の２４時間に発生したコンテンツｍに対する配信要求の集合をＱm,nとし、配信要求ｑの視聴時間をｔq（秒）とするとき、第ｎ日目におけるコンテンツｍに対する総ダウンロード時間（TDLT）Ｄm,n（秒）は「Ｄm,n=Σq∈Qm,ntq」となるが、Ｄm,nが大きなコンテンツを優先的に第ｎ日目においてBC事前配信するほど、第ｎ日目において配信サーバ負荷が低減される。
【０１１５】
第ｎ日目の開始時点において設定された配信スケジューリングにより、第ｎ日目の２４時間にBC事前配信されるコンテンツが決定されるが、これらコンテンツは第ｎ日目から第n+L-１日目のＬ日間、STBに存在する。そのため、これらＬ日間にわたるＤm,nの総和が大きなコンテンツを、第ｎ日目の配信スケジューリングにおいて優先的に選択することが望ましい。
【０１１６】
しかしｎ日目の開始時点において、「i≧n」のＤm,iを得ることはできないため、何らかの方法でＤm,nを推定する必要がある。
【０１１７】
本例では、金融工学や気象予測等の分野で広く用いられている指数移動平均（EMA:Exponential Moving Average）を用いてＤm,nを推定する。
【０１１８】
指数移動平均（EMA）は、時間の経過に伴い指数関数的に減少する重み付けを行った過去の実測値の平均を推定値とし、直近のデータを重視すると共に古いデータを完全には切り捨てない。平滑化係数αと第n-１日目の実測値Ｄm,n-１を用いて、第ｎ日目の推定値D’m,nを、次の式（１）を用いて得る。
【０１１９】
「D’m,n=αＤm,n−１+（１-α）D’m,n-１」 …（式１）
【０１２０】
平滑化係数αは０から１の値をとり、１に近いほどより直近のデータを重視する。一般的には、任意に設定した２以上の整数値をとるパラメタＮに対して、直近のＮ個の時系列データが８６％の重みを持つよう「α=２/（N+１）」で設定する。
【０１２１】
本例の配信サーバにおいて、各コンテンツｍに対して最新の推定値Ｄ’（m,n）を保存しておき、Ｄ（m,n-１）を実測することで、配信スケジューリング時に、上述の式（１）を用いて推定されたTDLT値Ｄ’（m,n）が大きな順に優先的に、第ｎ日目においてBC事前配信を行う。
【０１２２】
ただし、第n-L日から第n-１日においてBC事前配信されたコンテンツは第ｎ日目においてSTBにキャッシュされているため、ｎ日目のスケジューリング対象から除いて考える。
【０１２３】
次に、図２の各BC配信チャネルへの配信コンテンツ割当部２０５と配信スケジュール部２０６における＜BC事前配信スケジューリング＞について説明する。
【０１２４】
従来、BC配信やPush型マルチキャスト配信を対象に様々な配信スケジューリング方式が検討されているが、いずれもレスポンス時間を低減する観点から考察されている。
【０１２５】
これに対して、本例のコンテンツ配信システムでのBC事前配信においては、ユーザの配信要求に対して要求コンテンツがSTBに存在しない場合、ユニキャストにより配信サーバから即時に配信されるため、配信スケジューリングを設計する際にレスポンス時間を考慮する必要がない。
【０１２６】
そこで、本例では、以下のように、各日の開始時点でBC事前配信を行う配信スケジューリングとする。
【０１２７】
STBにキャッシュされていないコンテンツの中でTDLTの推定値Ｄ’（m,n）が大きなコンテンツを優先的にBC事前配信する。また、コンテンツｍの長さをSm（秒）とすると、コンテンツｍの第ｎ日目における配信要求数は「Ｄ’（m,n）/Sm」で推定できるが、この値が大きなコンテンツほど早いタイミングで配信することで、より多くの視聴要求に対して事前配信されたコンテンツを用いることが可能となる。
【０１２８】
このような考察から、以下の（イ）〜（ホ）のようにして配信スケジューリングを行う。
【０１２９】
（イ）各ブロードキャスト配信チャネルiの空き時間Ｅiを「２４×３６００」秒に初期化する。
【０１３０】
（ロ）第n-L〜n-１日にBC事前配信されたものを除いたコンテンツを対象にＤ’（m,n）の降順に優先順位を設定する。
【０１３１】
（ハ）空き時間Eiが最大の配信チャネルoに対して、未割当でSm≦Eoを満たすコンテンツの中で優先順位が最高のコンテンツを割当る。
【０１３２】
（ニ）割当可能なコンテンツが存在する限り、上述の割当処理を反復する。
【０１３３】
（ホ）各配信チャネルに対して、割当られたコンテンツの配信順序を「Ｄ’（m,n）/Sm」の降順に設定する。
【０１３４】
次に、本例のコンテンツ配信システムの実際の＜性能評価＞について説明する。
【０１３５】
まず、China Telecomが提供する商用VoDサービスであるPowerInfo（商標） VoDシステムにおいて収集されたアクセスログデータを用いて、本例のコンテンツ配信システムの有効性を評価する。
【０１３６】
本評価例で用いたログデータには２００４年６月から１２月の７ヶ月間に発生した２０,９２１,６５７の全配信要求が含まれており、総コンテンツ数は６,７３５、総ユーザ数は３７,３６０である。
【０１３７】
図４（ａ）において、コンテンツ長Smの累積輔分布（CCD:Complementary Cumulative Distribution）を示す。４５分と９０分の長さを有するコンテンツが各々、全体の約４０％ずつを占めており、平均コンテンツ長Ｓは３,５１０秒である。
【０１３８】
また、図４（ｂ）において、一日あたりの総ダウンロード時間TDLTを各ユーザもしくはコンテンツごとに集計した値の、全期間にわたる平均値のCCDを、ユーザ集合とコンテンツ集合の各々に対して示す。
【０１３９】
各ユーザやコンテンツの一日あたりのTDLTの差異は大きく、少数のユーザが大量の配信を行っていること、また特定のコンテンツに配信要求が集中していることが確認できる。また多くのユーザは一日あたり平均して数１０分〜１時間程度、コンテンツを視聴しており、多くのコンテンツの一日あたりの延べ配信時間は１時間〜１０時間程度である。
【０１４０】
BC事前配信チャネル数Ｂは任意に設定可能であるが、Ｂの増加に伴い分割損の影響が増すため、より優先度の低いコンテンツがBC事前配信対象として選択される。よって評価ではＢ=１に設定する。
【０１４１】
またBC事前配信を行ったことでユーザの視聴パタンは影響を受けず、アクセスログに従い配信要求が発生することを想定する。
【０１４２】
またアクセス回線のダウンリンク容量をＡｄ=１０Mbps、コンテンツの再生レートをＲ=２Mbpsに設定する。このとき、γ=４となりBC事前配信レートはＲｂ=８Mbps、一日あたりの平均BC事前配信コンテンツ数XはX=９８.４６となる。
【０１４３】
次に、＜総ダウンロード時間の推定精度＞について説明する。本例では指数移動平均（EMA）を用いた各コンテンツのTDLTの推定精度を評価する。
【０１４４】
図５（ａ）においては、７つのラグd（日）の各々に対して、各コンテンツの日単位のTDLTの自己相関係数のCDをプロットしている。dが大きく間隔が開くほど、各コンテンツのTDLTの自己相関性は低下するが、ラグ１日の場合、約３割程度のコンテンツのTDLTの自己相関係数は０.５以上あり、高い相関性が見られる。
【０１４５】
コンテンツの保存期間をL=１（日）に設定したときに、各ｎ日目の開始時点において上述の式（１）で推定されたＤ’（m,n）の上位floor（X）=９８個のコンテンツの第ｎ日目におけるTDLTの総和を、第ｎ日目の実際のTDLTの降順に上位９８個のコンテンツのTDLTの総和で除した値の全期間にわたる平均値を、EMA推定精度ηeと定義する。
【０１４６】
図５（ｂ）においては、EMAの平滑化パラメタαを定める系列長Ｎを変えた場合のηeをまとめている。図５（ａ）で見たように、ラグの増加に伴ない各コンテンツのTDLTの自己相関性が低下するため、Ｎの増加に伴い推定精度ηeは緩やかに減少する。よって以後の評価ではN=２に設定する。
【０１４７】
コンテンツ保存期間Ｌが２日以上の場合、STBにキャッシュされるコンテンツの一部は２日以上前のTDLT予測値に基づき事前配信されたコンテンツとなる。
【０１４８】
そこで、L≧２におけるBC事前配信コンテンツの選択効率を評価するため、図６（ａ）において、d日間離れた日におけるTDLTの上位x個のコンテンツのうち、両日において共通して上位x以内となったコンテンツの割合の全期間における平均値を、７つのdの値を対象にxに対してプロットした結果を示す。
【０１４９】
図６（ａ）に示すように、xが小さい領域では、間隔dが増加するに伴い上位x個のコンテンツの一致度は低下するが、xの増加に伴い一致度が増加する結果、xが１,０００程度以上になるとdによる一致度の差異はなくなる。
【０１５０】
コンテンツ保存期間Ｌの増加に伴い、STBにキャッシュされたコンテンツのBC事前配信時からの平均経過日数が増加するが、一方でキャッシュコンテンツ数はＬの増加に伴い増加するため、Ｌが事前配信コンテンツの選択効率に与える影響は小さいことが予想される。
【０１５１】
図６（ｂ）においては、各日にx個のコンテンツをBC事前配信できる場合に、EMAで推定したTDLTに基づき事前配信コンテンツを選択した結果、各日においてSTBに存在するLx個のコンテンツに対するTDLTの合計を、実際のTDLTの上位Lx個のコンテンツに対するTDLTの合計で除した値の全期間にわたる平均値を、Ｌの３つの場合を対象にxに対してプロットした結果を示す。
【０１５２】
xが小さい場合、図６（ａ）で見たように、Ｌの増加に伴いTDLT上位コンテンツの一致度が大きく低下する結果、事前配信コンテンツの選択効率はＬの増加に伴い低下する。しかし、選択効率の低下度合いは小さく、図６（ｂ）に示すように、例えばＬが７日程度であれば、７０％程度の選択効率が得られる。
【０１５３】
また、選択効率はxの増加に伴い増加し、xが１０程度以上大きい領域では８５％〜９０％程度となる。コンテンツ数Mに対してx≧M/Ｓにおいては、全コンテンツがSTBにキャッシュされるため選択効率は１となる。
【０１５４】
以上のことから、EMAを用いたTDLTの推定値に基づきBC事前配信コンテンツを選択することで、十分な選択効率が達成され、配信サーバやNWの負荷低減効果が期待できる。
【０１５５】
以下、このような評価データを用いた本例のコンテンツ配信システムの＜効果＞について説明する。
【０１５６】
全期間の全ユーザのTDLTの合計をY１（秒）と定義し、また、第ｎ日の開始時点において第ｎ日のTDLTが大きな上位floor（X）=９８個のコンテンツを一瞬で全STBに配送した理想的なキャッシュ状態において、STBキャッシュコンテンツを視聴した全ユーザのTDLTの全期間の合計をY２（秒）と定義し、同様に、本例のコンテンツ配信システムにより第ｎ日にBC事前配送スケジュールされた全コンテンツを一瞬で第ｎ日の開始時点において全STBに配送したキャッシュ状態において、STBキャッシュコンテンツを視聴した全ユーザのTDLTの全期間の合計をY３（秒）と定義し、本例のコンテンツ配信システムにより実際にBC事前配信されたコンテンツを視聴した全ユーザのTDLTの全期間の合計をY４（秒）と定義する。ただし最初のＬ日間は対象外とする。
【０１５７】
図８において、Ｌの７つの値に対して、「Y２/Y１」、「Y３/Y２」、「Y４/Y３」、「Y４/Y１」の値を各々まとめている。「Y２/Y１」は、BC事前配信によって達成可能な性能限界を表すが、Ｌの増加に比例してキャッシュされるコンテンツ数が増加するため、Ｌの増加に伴い大きく向上する。
【０１５８】
また、「Y３/Y２」は、EMAを用いたTDLTの推定精度を表すが、図６（ｂ）で見たように、Ｌの値による影響は小さく８５％〜９０％程度の高い推定精度が達成される。
【０１５９】
実際には配送予定のコンテンツを各日の開始時点で瞬時に配送することはできず、設定したスケジュールに応じて順次配送するため事前配信の効率は低下するが、その低下に相当する効率「Y４/Y３」は、L=１の場合で０.８程度、L≧２の場合で０.９程度以上と高い。
【０１６０】
また、「Y４/Y１」は、実際の事前配信の効果に相当するが、「Y４/Y１=Y２/Y１×Y３/Y２×Y４/Y３」であり、これら３つの評価値の積となるが、「Y２/Y１」が最もＬの影響を強く受けるため、Ｌの増加に伴い事前配信の効率は大きく向上する。
【０１６１】
ISPは、ピーク需要に基づき配信サーバを設計する必要があり、配信サーバのピーク負荷を抑えることが総コストを抑えるために重要である。
【０１６２】
そこで、図７（ａ）において、配信サーバからの同時配信セッション数の、各日における最大値を全期間にわたりプロットした結果を示す。ただし、配信サーバは、常時、BC配信を行う必要があるため、そのための負荷をユニキャスト配信のためのセッション数に換算した「（Aｄ-R）Ｒ」を加算している。
【０１６３】
図７（ａ）に示すように、全期間にわたり、事前配信を行わない場合（L=０）と比較して、事前配信を行うことで最大同時セッション数が大きく低減され、その効果はＬが大きいほど大きくなる。
【０１６４】
また、図７（ｂ）においては、１２/１〜１２/７の７日間を対象に、１時間ごとの最大同時セッション数を同様にプロットした結果を示している。
【０１６５】
この図７（ｂ）に示すように、配信需要には日単位の強い周期性が見られ、また週末（１２/４と１２/５）は増加するが、いずれの時間帯においても、最大同時セッション数が事前配信を用いることで削減できること、また、その効果は需要が高い時間帯ほど高いことが確認できる。
【０１６６】
図９において、全期間における最大同時セッション数Kmaxと、各日において配信サーバが配信したTDLTの平均値V（秒）を、事前配信を行わない場合（L=０）と行う場合のＬの７つの場合について各々まとめる。
【０１６７】
図９に示すように、Ｌの増加に伴いKmaxとVは低減し、例えばL=４のとき、事前配信を行わない場合と比較して約半分に低減できる。
【０１６８】
このように、VoDサービスにおいて、本例のコンテンツ配信システムによるBC事前配信を行うことで、配信サーバのピーク負荷やネットワークに加わる負荷を大きく低減でき、ISPのサービス提供コストを大きく削減することができる。
【０１６９】
しかし一方で、ユーザの配信要求とは無関係に大量のコンテンツをBC配信するため、STBに大容量のストレージが必要となる。図９においては、本例のコンテンツ配信システムによる事前配信コンテンツの利用率ηと、STBの最大必要ストレージ容量Zmax（Tbyte）をあわせて示す。ただし、ηを、事前配信されたコンテンツの中で各ユーザが実際に視聴したものの割合の全期間にわたる平均値で定義する。
【０１７０】
以上、図１〜図９を用いて説明したように、本例のコンテンツ配信システムでは、VoDサービスにおいて、ユーザの配信要求に対して即時にユニキャスト配信する配信形態に加えて、配信要求とは無関係に、予め定めた配信スケジュールに従い、人気の高いコンテンツを常時、全てのユーザに対してブロードキャスト配信し、ユーザ宅内に設置されたSTBに事前配信する。
【０１７１】
このことにより、ピーク時の配信サーバ負荷とネットワーク負荷の低減を図ることができる。
【０１７２】
尚、事前配信されたコンテンツをユーザが視聴可能な期間がＬ日であるとき、過去Ｌ日に事前配信されたコンテンツを除き、各コンテンツの一日の総ダウンロード時間（TDLT）が大きな順に優先的にブロードキャスト事前配信するよう、一日を周期に事前配信スケジュールを設計する。
【０１７３】
また、指数移動平均を用いて過去のTDLTの実測値から推測した、翌日の各コンテンツのTDLTに基づきブロードキャストで事前配信するコンテンツを選択する。
【０１７４】
また、アクセス回線のダウンリンク容量が全てＡｄ（bps）、コンテンツの再生レートが全てＲ（bps）、配信要求に対して配信サーバからユニキャストで配信する際、再生レートＲに等しい配信レートで配信するとき、ブロードキャスト事前配信の配信レートＲｂ（bps）とブロードキャスト事前配信チャネル数Ｂを、一日あたりの事前配信コンテンツ数が最大化するよう、任意のＢに対してＲｂ=（Aｄ-R）/Ｂに設定する。
【０１７５】
また、空き配信時間が最大の事前配信チャネルに、未割当でコンテンツ長が空き時間以下となるコンテンツの中でTDLTの推測値が最大のコンテンツを順次に割当てる処理を反復することで、各事前配信チャネルにおいて配信するコンテンツを割当てる。
【０１７６】
また、各事前配信チャネルに割当てられたコンテンツを、TDLTの推定値をコンテンツ長で除した値が大きな順番に配信スケジュールを設定する。
【０１７７】
尚、本発明は、図１〜図９を用いて説明した例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。例えば、本例では、配信サーバ１０１と配信スケジュール設計装置２００をそれぞれ個別のコンピュータ装置で構成しているが、１つのコンピュータ装置内に配信サーバ１０１と配信スケジュール設計装置２００の機能を設けた構成としても良い。
【０１７８】
また、本例のコンピュータ構成に関しても、キーボードや光ディスクの駆動装置の無い構成としても良い。また、プログラムを記録する記録媒体に関しても、光ディスクに限らず、ＦＤ（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ）等を記録媒体として用いることでも良い。また、プログラムのインストールに関しても、通信装置を介してネットワーク経由でプログラムをダウンロードしてインストールすることでも良い。
【符号の説明】
【０１７９】
３１：サービスプロバイダ、３２：配信サーバ、３３：ユーザ、１０１：配信サーバ装置、１０２：ユーザ端末装置、２００：配信スケジュール設計装置、２０１：設定パラメタ入力部、２０２：ＢＣ事前配信レートとチャネル数の設定部、２０３：各コンテンツのＴＤＬＴ測定部、２０４：翌日の各コンテンツのＴＤＬＴ推定部、２０５：各ＢＣ配信チャネルへの配信コンテンツ割当部、２０６：配信スケジュール部。
【特許請求の範囲】
【請求項１】
ネットワーク経由でコンテンツの配信を行うコンテンツ配信システムであって、
ユーザの配信要求に応じて即時にコンテンツをユニキャスト配信する第１の配信手段と、
配信要求の多いコンテンツを、予め定められた配信スケジュールに従い事前に、全てのユーザのセットトップボックス装置（STB）にブロードキャスト配信（事前配信）する第２の配信手段と
を有することを特徴とするコンテンツ配信システム。
【請求項２】
請求項１に記載のコンテンツ配信システムであって、
上記第２の配信手段は、
各コンテンツの一日の総ダウンロード時間（TDLT）を計測する第１の手段と、
上記STBに事前配信したユーザ視聴可能期間内のコンテンツを除く各コンテンツから、上記TDLTの大きいコンテンツを優先して順に選択する第２の手段と
を有し、
一日を周期に、上記選択したコンテンツを事前配信することを特徴とするコンテンツ配信システム。
【請求項３】
請求項２に記載のコンテンツ配信システムであって、
上記第２の配信手段は、
上記第１の手段で計測した、各コンテンツの過去のTDLTの実測値から指数移動平均を用いて翌日の各コンテンツのTDLTを求める第３の手段を有し、
上記第２の手段は、上記指数移動平均を用いて求めたTDLTに基づき事前配信するコンテンツの選択を行う
ことを特徴とするコンテンツ配信システム。
【請求項４】
請求項２もしくは請求項３のいずれかに記載のコンテンツ配信システムであって、
上記第２の配信手段は、
アクセス回線のダウンリンク容量Ａｄ（bps）と、
コンテンツの再生レートと同じユニキャスト配信の配信レートＲ（bps）を用いて、
事前配信の配信レートＲｂ（bps）を、任意の事前配信チャネル数Ｂに対して、Ｒｂ=（Aｄ-R）/Ｂに設定する第４の手段を有し、
該第４の手段で設定した配信レートで事前配信を行うことを特徴とするコンテンツ配信システム。
【請求項５】
請求項２から請求項４のいずれかに記載のコンテンツ配信システムであって、
上記第２の配信手段は、
空き配信時間のある事前配信チャネルに、空き配信時間が大きい順次に、
コンテンツ長が空き時間以下のコンテンツを、TDLTの推測値が大きい順に割り当てる第５の手段
を有することを特徴とするコンテンツ配信システム。
【請求項６】
請求項５に記載のコンテンツ配信システムであって、
上記第２の配信手段は、
上記第５の手段により各事前配信チャネルに割当てたコンテンツから、各コンテンツのTDLTの推定値をコンテンツ長で除した値が大きな順に選択して、事前配信する第６の手段
を有することを特徴とするコンテンツ配信システム。
【請求項７】
コンピュータを、請求項１から請求項６のいずれかに記載のコンテンツ配信システムにおける各手段として機能させるためのプログラム。
【請求項８】
コンピュータ装置によりネットワーク経由でコンテンツの配信を行うコンテンツ配信システム方法であって、
上記コンピュータ装置は、プログラムされたコンピュータ処理を実行する手段として、
請求項１から請求項６のいずれかに記載のコンテンツ配信システムにおける第１の配信手段と第２の配信手段を具備し、
上記第１の配信手段により、
ユーザの配信要求に応じて即時にコンテンツをユニキャスト配信し、
上記第２の配信手段により、
配信要求の多いコンテンツを、予め定められた配信スケジュールに従い事前に、全てのユーザのセットトップボックス装置（STB）にブロードキャスト配信（事前配信）する
ことを特徴とするコンテンツ配信方法。
【請求項１】
ネットワーク経由でコンテンツの配信を行うコンテンツ配信システムであって、
ユーザの配信要求に応じて即時にコンテンツをユニキャスト配信する第１の配信手段と、
配信要求の多いコンテンツを、予め定められた配信スケジュールに従い事前に、全てのユーザのセットトップボックス装置（STB）にブロードキャスト配信（事前配信）する第２の配信手段と
を有することを特徴とするコンテンツ配信システム。
【請求項２】
請求項１に記載のコンテンツ配信システムであって、
上記第２の配信手段は、
各コンテンツの一日の総ダウンロード時間（TDLT）を計測する第１の手段と、
上記STBに事前配信したユーザ視聴可能期間内のコンテンツを除く各コンテンツから、上記TDLTの大きいコンテンツを優先して順に選択する第２の手段と
を有し、
一日を周期に、上記選択したコンテンツを事前配信することを特徴とするコンテンツ配信システム。
【請求項３】
請求項２に記載のコンテンツ配信システムであって、
上記第２の配信手段は、
上記第１の手段で計測した、各コンテンツの過去のTDLTの実測値から指数移動平均を用いて翌日の各コンテンツのTDLTを求める第３の手段を有し、
上記第２の手段は、上記指数移動平均を用いて求めたTDLTに基づき事前配信するコンテンツの選択を行う
ことを特徴とするコンテンツ配信システム。
【請求項４】
請求項２もしくは請求項３のいずれかに記載のコンテンツ配信システムであって、
上記第２の配信手段は、
アクセス回線のダウンリンク容量Ａｄ（bps）と、
コンテンツの再生レートと同じユニキャスト配信の配信レートＲ（bps）を用いて、
事前配信の配信レートＲｂ（bps）を、任意の事前配信チャネル数Ｂに対して、Ｒｂ=（Aｄ-R）/Ｂに設定する第４の手段を有し、
該第４の手段で設定した配信レートで事前配信を行うことを特徴とするコンテンツ配信システム。
【請求項５】
請求項２から請求項４のいずれかに記載のコンテンツ配信システムであって、
上記第２の配信手段は、
空き配信時間のある事前配信チャネルに、空き配信時間が大きい順次に、
コンテンツ長が空き時間以下のコンテンツを、TDLTの推測値が大きい順に割り当てる第５の手段
を有することを特徴とするコンテンツ配信システム。
【請求項６】
請求項５に記載のコンテンツ配信システムであって、
上記第２の配信手段は、
上記第５の手段により各事前配信チャネルに割当てたコンテンツから、各コンテンツのTDLTの推定値をコンテンツ長で除した値が大きな順に選択して、事前配信する第６の手段
を有することを特徴とするコンテンツ配信システム。
【請求項７】
コンピュータを、請求項１から請求項６のいずれかに記載のコンテンツ配信システムにおける各手段として機能させるためのプログラム。
【請求項８】
コンピュータ装置によりネットワーク経由でコンテンツの配信を行うコンテンツ配信システム方法であって、
上記コンピュータ装置は、プログラムされたコンピュータ処理を実行する手段として、
請求項１から請求項６のいずれかに記載のコンテンツ配信システムにおける第１の配信手段と第２の配信手段を具備し、
上記第１の配信手段により、
ユーザの配信要求に応じて即時にコンテンツをユニキャスト配信し、
上記第２の配信手段により、
配信要求の多いコンテンツを、予め定められた配信スケジュールに従い事前に、全てのユーザのセットトップボックス装置（STB）にブロードキャスト配信（事前配信）する
ことを特徴とするコンテンツ配信方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１１−１５１５３５（Ｐ２０１１−１５１５３５Ａ）
【公開日】平成２３年８月４日（２０１１．８．４）
【国際特許分類】
【出願番号】特願２０１０−９９７２（Ｐ２０１０−９９７２）
【出願日】平成２２年１月２０日（２０１０．１．２０）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２３年８月４日（２０１１．８．４）
【国際特許分類】
【出願日】平成２２年１月２０日（２０１０．１．２０）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]