JP3560556B2

JP3560556B2 - マルチキャスト・ビデオ・オンデマンドによる動画コンテンツの配送方法

Info

Publication number: JP3560556B2
Application number: JP2001056160A
Authority: JP
Inventors: 憲昭上山
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2001-03-01
Filing date: 2001-03-01
Publication date: 2004-09-02
Anticipated expiration: 2021-03-01
Also published as: JP2002262262A

Description

【０００１】
【発明の属する技術分野】
本発明は、伝送帯域が保証でき、マルチキャスト配送が可能なネットワークを介し、サーバに蓄積されたデジタル動画コンテンツをユーザ宅の端末（ＳＴＢ）に直接配送するビデオ・オンデマンド（ＶｏＤ）システムに係り、特にユーザがコンテンツの配送を受けながら視聴を行うストリーミング配送し、かつ同一コンテンツを視聴する複数のユーザに対し一本のマルチキャストセッションで配送を行うマルチキャストＶｏＤによる配送方法に関し、さらには早送りを除く任意のＶＴＲ操作を簡易に実現し、サーバ資源の有効利用を図るよう伝送帯域を制御する配送方法に関する。
【０００２】
【従来の技術】
家庭に居ながらにして好みのビデオタイトルを任意の時間に視聴できるＶｏＤサービスは、広帯域通信インフラを活用する有力な通信サービスの一つと考えられる。動画像データの情報量は大きく（ＮＴＳＣ，ＰＡＬのＴＶ放送品質で２１６Ｍｂｐｓ）、一般的な動画符号化方式であるＭＰＥＧ１（ＶＨＳビデオの品質相当）やＭＰＥＧ２（ＴＶ放送の品質相当）で圧縮後も、その平均ビットレートは前者が数１００ｋ〜１．５Ｍｂｐｓ、後者が４〜１０Ｍｂｐｓに達する。そのため、数Ｍｂｐｓ以上の高速なアクセス回線が必要となるが、ＣＡＴＶや衛星ネットワークといった広帯域アクセス回線の利用に加え、ｘＤＳＬや光アクセス回線の普及が始まり、高速なアクセス環境を利用できるユーザ数が今後は急速に増加していくものと思われる。
【０００３】
ＶｏＤシステムにおける動画コンテンツ配送方法としては、配信を受けながら視聴を行うもの（ストリーミング配送）と、コンテンツの全体を先に受信し配信完了後に視聴を開始するもの（バースト配信）の二つの形態を考えることができる。ＶｏＤサービスの中心的なコンテンツになると思われる映画タイトルの場合、平均的な作品の長さが１００分前後であることから、配送すべきコンテンツのサイズは数Ｇｂｙｔｅｓにも及ぶ。数Ｍｂｐｓのアクセス回線を用いた場合、コンテンツの配送に数時間を要することから、バースト配送では事前に視聴を予約するような予約配送型のサービスになるものと思われる。
【０００４】
一方、ストリーミング配送ではコンテンツの配送を待つことなく視聴を開始できることから、本来の意味でのオンデマンドにより近い配送形態といえる。ユーザ宅のＳＴＢ（Ｓｅｔ−Ｔｏｐ−Ｂｏｘ）に到着した画像フレームは一時的にバッファリングされ、画像フレーム再生レートに従い読み出される。一定間隔で画像フレームを再生し続けるためには、ＳＴＢにおけるバッファアンダーフローを回避する必要があり、配送開始から数１００ｍｓ〜数秒後に視聴を開始する（予備受信時間：Ｐｒｅ−ｌｏａｄｉｎｇ）と同時に、平均ビットレート以上の伝送帯域を確保する必要がある。コンテンツが蓄積されているビデオサーバには同時に多数のセッションが接続されるため、サーバのネットワークＩＯ帯域がシステム全体のボトルネックとなり、収容可能な最大ユーザ数が制限されることが知られている。そこでＳＴＢとサーバ間を一対一に配送する（Ｔｒｕｅ−ＶｏＤ（Ｔ−ＶｏＤ））のではなく、同一タイトルを要求したユーザをまとめマルチキャストセッションにより配送することが、収容可能ユーザ数を増加させる点で有効となる。複数のユーザを束ねるため、数分間のバッチング期間が必要となるが、サーバ資源を有効に活用することができる。
【０００５】
図１０にマルチキャストＶｏＤのシステム構成を示す。コンテンツプロバイダーもしくは通信キャリアが用意するＭＰＥＧ１やＭＰＥＧ２によりデジタル符号化されたビデオタイトルはビデオザーバ１００のディスク１０１に蓄積される。大規模なＶｏＤシステムの場合、数Ｍｂｐｓの配送ストリームを同時に数千〜数十万本サポートする必要があることから、例えばＳＧＩ２８００といった処理能力の大きなサーバを利用する必要がある。ＳＧＩ２８００の場合ディスクＩＯ帯域は１．６Ｔｂｐｓにもなるが、ネットワークＩＯ帯域はそれよりも数桁小さく、また大容量トラヒックを一拠点からネットワークに流入させることは困難であるため、サーバのネットワークＩＯ帯域がボトルネックとなる。
【０００６】
一方、ユーザ宅には配送されたビデオコンテンツを受信すると同時にメモリやＨＤＤに記憶し、並行してＴＶ受像機に複合画像を表示するＳＴＢ１０２、１０３、１０４が設置される。これまで検討されているストリーミング配送では、数秒間もしくは数分間にわたる画像フレームを一時的にバッファリングするのみで、再生済みのデータはバッファから除去していた。そのため、必要となる記憶装置容量は数１００ｋＢ〜数１０ＭＢであった。しかし、本発明に係る配送方法ではコンテンツの全体をＳＴＢに蓄積することを考えるため、ビデオタイトルの一本が３ＧＢ〜７．５ＧＢになることを考えると、数本〜数１０本のタイトルを保存するためには数１０ＧＢ〜数１００ＧＢの容量が必要になる。現在でも例えば６０ＧＢのＨＤＤが４万円弱で購入でき、今後も価格が低下することが予想されることから、そのコストは許容できる範囲であると思われる。また、ユーザが複数回の視聴を行うことやコピーを行う可能性があることから、著作権を保護するためにはこれらの行為に制限を加える必要があるが、例えばＩｎｔｅｒｔｒｕｓｔ社のＤＲＭ（ＤｉｇｉｔａｌＲｉｇｈｔｓＭａｎａｇｅｍｅｎｔ）を利用することにより、コンテンツプロバイダーは視聴毎に料金を徴収することが可能となる。
【０００７】
次に、サーバ１００とＳＴＢ１０２、１０３、１０４をつなぐネットワークについて考察する。本発明では動画データの配信を受けながら視聴を行うストリーミング配送を前提としているため、ＳＴＢのアンダーフローを回避する最小必要伝送帯域（数１００ｋ〜数Ｍｂｐｓ、画像フレームサイズとＰｒｅ−ｌｏａｄｉｎｇ時間から決まる）が存在する。そのため、ビデオサーバ１００からＳＴＢ１０２、１０３、１０４間のＥｎｄ−ｔｏーｅｎｄで数１００ｋ〜数Ｍｂｐｓの伝送帯域を割当てる必要がある。また、同一タイトルを要求した全ユーザに対し一本のセッションで配送を行うため、マルチキャストセッションを確立する必要がある。以上のことから、以下のネットワーク形態を考えることができる。
【０００８】
（１）ビデオサーバとＳＴＢを衛星ネットワークで直接つなぐ形態。ただし、限られた伝送帯域を全ユーザで共有することから、同時接続数を多くすることができず、収容ユーザ数と提供コンテンツ数が限られたものになる。
【０００９】
（２）ＭＰＬＳやＡＴＭをバックボーンとし、数１００ｋｂｐｓ以上の伝送速度が達成できるＸＤＳＬやＣＡＴＶ，ＦＴＴＨをアクセス網として利用する形態。ＸＤＳＬやＦＴＴＨは今後、急速に普及していくものと思われるため有望な網インフラとなる。
【００１０】
【発明が解決しようとする課題】
ビデオコンテンツの視聴要求は特定の人気タイトルに集中する傾向があり、収容ユーザ数が十分に多い場合、数分といった比較的短い時間内に同一タイトルに対する要求が発生する。そこで、個々の要求に対しユニキャストで配送する代わりに同一タイトルを要求した全ユーザに対してマルチキャストで配送すれば、サーバがサポートする同時接続セッション数を大幅に削減できるため、システム全体のボトルネックとなるサーバのネットワークＩＯ帯域にかかる負荷を低減でき、収容可能なユーザ数を向上させることが可能となる。マルチキャスト配送を行うには複数のユーザを束ねるバッチング処理を行う必要があるが、主な方法として、以下の二つが考えられる。
【００１１】
（１）Ｗｉｎｄｏｗ−ｓｉｚｅｂａｓｅｄ
対象コンテンツの待ちユーザのいない状態において、最初の視聴要求が発生した瞬間から、一定間隔Ｗの間だけバッチングを行う。すなわち、最初の要求からＷ後に配送が開始され、その間に発生した同一コンテンツに対する視聴要求が全て束ねられ、同一のマルチキャストセッションで配送を受ける。バッチサイズが不確定で特に人気のないコンテンツではマルチキャストの効果が小さくなるが、バッチング遅延時間の上限を時間Ｗで抑えられる長所がある。
【００１２】
（２）Ｂａｔｃｈ−ｓｉｚｅｂａｓｅｄ
一定数Ｆの視聴要求がバッチングされたときに配送を開始する。バッチサイズを一定数Ｆに保つことができるが、バッチング遅延時間が不定となり、視聴要求時にバッチング遅延時間が確定しない問題がある。
【００１３】
サービスを受けるユーザの観点からすれば、視聴を要求してから配送が開始されるまでの待ち時間が確定していることが好ましく、タイトルによって大きく変動するＢａｔｃｈ−ｓｉｚｅｂａｓｅｄは導入が難しいと思われる。
【００１４】
この場合、間隔Ｗの決め方が問題となるが、間隔Ｗが大きなほどバッチサイズが増加し、呼損率が低減する。しかし、間隔Ｗの増加は、視聴要求から配送が開始されるまでの待ち時間を悪化させる。一般に、平均５分前後の待ち時間は許容範囲と考えることができ、本発明でも数分オーダーの間隔Ｗを想定する。
【００１５】
次に、バッチング処理によるマルチキャスト配送は、サーバのネットワークＩＯ資源の消費を抑え、収容可能ユーザ数を向上させる点で有効であるが、ＶｏＤ特有のＶＴＲ操作に対する対処が問題である。
【００１６】
まず、一時停止操作と再スタート操作について考える。図１１の（ａ）に、画像フレーム１を表示中にユーザＣが一時停止操作をし（ａ）、３画像フレーム時間後に再スタート操作を行った（ｂ）場合のＳＴＢバッファの様子を例示する。画像フレームサイズは一般に変動するが、図では簡単のため同一サイズとしている。一時停止中は画像フレームが再生されないが、その間もマルチキャストセッションから画像データが到着し続けるためＳＴＢバッファは増加し続ける。
【００１７】
図１１の（ｂ）に示すように、ユーザＣのＳＴＢバッファが溢れる前に再生が再開されれば、問題なくマルチキャストセッションによる配送を継続することが可能である。すなわち、一時停止・再スタート処理を行ったユーザＣの再生ポイント（フレーム１）と、同一マルチキャストグループに属する他のユーザ（Ａ，Ｂ）の再生ポイント（フレーム４）にずれが生じるが、その差がＳＴＢバッファで吸収できる範囲であればマルチキャスト配送を継続することができる。しかし、停止時間が長期化し差が吸収できないほど大きくなった場合には、もはやユーザＣはマルチキャーストグループに留まることができない。
【００１８】
この際、もしユーザＣの新しい再生ポイントとの差がＳＴＢバッファで吸収可能なマルチキャストセッションが他にあれば、そこにユーザＣを移動させることができる。しかし、マルチキャストセッション間の移動という処理がサーバに発生することと、新たにＰｒｅ−ｌｏａｄｉｎｇを行う必要があり、遅延が生じる問題があるが、サーバの同時接続セッション数を増やすことなく配送を継続することができる。問題はそのようなセッションが他にない場合で、ユーザＣの視聴を継続させるためには、新たにユーザＣのみをサポートするユニキャストセッションを設ける必要がある。このことは、一本のセッションに束ねていたユーザを細分化することを意味し、マルチキャスト配送の利点が失われ、サーバのネットワークＩＯ帯域の消費量を増加させる。最悪の場合、空き資源不足から新たにユニキャストセッションを設けることができず、ユーザＣの視聴を中断させる結果になることが予想される。
【００１９】
また、Ｊｕｍｐ−ｆｏｒｗａｒｄやＪｕｍｐ−ｂａｃｋｗａｒｄといった再生点を直接指定して変更するようなＶＴＲ操作の場合（ＶＴＲにおける早送りと巻き戻しに相当。ＶｏＤではランダムな位置に直接移動可能）、やはり新たに生じる再生ポイントの差異がＳＴＢバッファで吸収できない場合には同様の問題が生じる。更に、早送り再生やスロー再生といった動画の再生レートが変更される場合にも、ユニキャストセッションが必要となる。
【００２０】
以上のことから、コンテンツの一部をＳＴＢにて保存する従来のマルチキャストＶｏＤシステムではＶＴＲ操作に対する対応が困難であり、マルチキャスト配送の効果が低減する。
【００２１】
本発明の目的は、マルチキャスト・ストリーミング配送型ＶｏＤシステムにおいて、マルチキャストセッションを維持したまま早送りを除く任意のＶＴＲ操作を可能とする配送方法を提供することにある。
【００２２】
本発明の他の目的は、各セッションに割当てる伝送帯域を固定ではなく、同時接続セッション数に応じて動的に更新し、良好な呼損率特性を達成することができる配送方法を提供することにある。
【００２３】
【課題を解決するための手段】
本発明は、コンテンツの全体をＳＴＢに蓄積すればマルチキャストセッションを維持したまま早送りを除く全てのＶＴＲ操作が容易に実現されることに着目したもので、以下の方法を特徴とする。
【００２４】
（１）サーバに蓄積されたデジタル動画コンテンツをユーザのセットトップボックスに直接配送するビデオ・オンデマンドサービス形態とし、かつ動画コンテンツを受信しながら並行して動画再生を行うストリーミング配送形態とし、かつサーバ資源の有効利用を図り呼損率を低減するマルチキャスト配送形態で動画コンテンツを配送する方法であって、
マルチキャストセッションを維持したまま早送りを除く任意のＶＴＲ操作を可能とするようコンテンツの全体をセットトップボックスに保持する手段と、
動画再生が中断するセットトップボックスのバッファアンダーフローを回避するのに必要な最小伝送帯域を算出する手段と、
前記必要最小伝送帯域に基づき呼受付判定を行う手段と、
前記必要最小伝送帯域以上かつアクセス回線容量以下になる同時接続セッション数に応じて割当て伝送帯域を動的に変更する手段と、
動画コンテンツの配送を開始したセッションの配送開始後の任意の時刻において転送中の画像フレームと、この画像フレームの配送済みデータサイズを基にして、定期的にコンテンツ配送中のセッションに対して前記必要最小伝送帯域を再計算することで消費資源量を削減する手段とを有して動画コンテンツを配送することを特徴とする。
【００２５】
（２）前記（１）に記載の配送方法において、動画コンテンツの全体を保持するのに十分な容量の記憶装置を前記セットトップボックスに用意し、一旦受信したデータを再生後も廃棄せずに該セットトップボックスに保存し、視聴完了時には動画コンテンツの全体を該セットトップボックスに保持しておく手段を有して動画コンテンツを配送することを特徴とする。
【００２６】
（３）前記（２）に記載の配送方法において、動画コンテンツの配送開始時刻から予備受信時間を経過した後に視聴を開始し、全画像フレームサイズシーケンスと前記予備受信時間の時間量から前記セットトップボックスバッファアンダーフローを回避するのに必要となる伝送帯域を算出する手段を有して動画コンテンツを配送することを特徴とする。
【００２７】
（４）前記（１）に記載の配送方法において、各セッションに前記（３）で算出した必要最小伝送帯域を確保するため、他に待ちユーザのいないコンテンツを要求した新規要求ユーザに対し、最小必要伝送帯域に基づいて呼受付判定を行う手段を有して動画コンテンツを配送することを特徴とする。
【００２８】
（５）前記（１）に記載の配送方法において、サーバ資源を有効利用するため、同時接続セッション数に応じて、各セッションに割当てる伝送帯域を動的に更新する手段を有して動画コンテンツを配送することを特徴とする。
【００３０】
【発明の実施の形態】
本発明の実施形態および実施形態に基づいたシミュレーションについて、以下に項分けして詳細に説明する。
【００３１】
（１）最小必要伝送帯域
サーバにはＭ個のビデオコンテンツが蓄積されており、コンテンツｍ（１≦ｍ≦Ｍ）の画像フレーム数をＮ_ｍ、コンテンツｍのｎ番目（１≦ｎ≦Ｎ_ｍ）の画像フレームサイズ〔ｂｉｔｓ〕をＸ_ｎ（ｍ）とする。ここでは、ＳＴＢバッファアンダーフロー（画像データの到着が間に合わず、一定間隔Ｔでの画像再生が継続できない状態）を回避するのに必要な最小伝送帯域α（ｍ）〔ｂｐｓ〕を導出する。
【００３２】
いま、コンテンツｍの伝送開始時刻をｔ_ｓ、Ｐｒｅ−ｌｏａｄｉｎｇ遅延量をＤ〔ｓｅｃ〕とすると（すなわちユーザは時刻ｔ_ｓ＋Ｄに再生を開始できる）、ＶＴＲ操作がなかった場合の画像フレームｎの再生時刻Ｓ_ｎは、
【００３３】
【数１】
Ｓ_ｎ＝ｔ_ｓ＋Ｄ＋（ｎ−１）Ｔ …（１）
となり、画像データの転送レートをｂ〔ｂｐｓ〕とすると、画像フレームｎの末尾がＳＴＢに到着する時刻Ｆ_ｎは、
【００３４】
【数２】

【００３５】
となる。１≦ｎ≦Ｎ_ｍにおいてＦ_ｎ≦Ｓ_ｎが満たされれば、ＳＴＢバッファアンダーフローが回避できる。すなわち、転送レートｂが全てのｎ（１≦ｎ≦Ｎ_ｍ）について、
【００３６】
【数３】

【００３７】
を満足すればよい。よって、コンテンツｍの最小必要伝送帯域α（ｍ）は以下のように求まる。
【００３８】
【数４】

【００３９】
この最小必要伝送帯域α（ｍ）はＯ（Ｎ_ｍ）の計算量で得られるが、ライブ中継とは異なりＶｏＤではＸ_ｎ ^（ｍ）は既知であるので、Ｐｒｅ−ｌｏａｄｉｎｇ時間量Ｄを予め与えればα（ｍ）を事前に計算しテーブルに用意しておくことも可能である。
【００４０】
早送り以外のＶＴＲ操作が発生した後の画像フレーム再生時刻は式（１）で示した値よりも大きくなるので、転送レートｂが最小必要伝送帯域α（ｍ）以上であればＶＴＲ操作後もＳＴＢアンダーフローを回避できる。
【００４１】
（２）伝送帯域の変更処理
ＶｏＤの伝送帯域に関する従来の研究では、ＳＴＢのバッファアンダーフローを回避するという伝送帯域の下限に関する制限と、ＳＴＢのバッファ溢れを回避するという伝送レートの上限に関する制限の双方を考慮する必要があった。
【００４２】
しかし、コンテンツの全体をＳＴＢに蓄積する場合にはバッファ溢れを考慮する必要がなく、前記の（１）で導出した最小必要伝送帯域α（ｍ）以上であれば任意のレートで伝送することが可能である。
【００４３】
ＷＷＷコンテンツのダウンロードやＦＴＰファイル転送といったサービスでは、転送スループットが待ち時間を決めるため、ユーザの感知する品質に直接影響するが、ＶｏＤサービスでは最小必要伝送帯域さえ満足していれば、ユーザの感知する品質に影響を与えない。
【００４４】
しかし、ＶｏＤサービスの需要は２４時間の周期で大きく変動し、特に夕方から深夜にかけてピークが訪れることが知られている。ピーク時間帯には数多くの視聴要求が発生するため、個々のセッションに割当てる伝送帯域が小さなほど呼損率が低減し、収容可能なユーザ数が増加する。しかし、それ以外の需要が少ないアイドル時間帯では、ネットワークＩＯ帯域の大部分が空いているにもかかわらず必要最小帯域のみが割当てられるため、セッション保留時間を短縮することができない。もし、アイドル時間帯に大きな伝送帯域を割当てることができれば、平均同時接続セッション数を抑えることができ、特にアイドル時間帯からピーク時間帯に入った時分の同時接続数が緩和され、更なる呼損率の低減が期待される。
【００４５】
そこで、本実施形態では、同時接続数に応じて各セッションに割当てる伝送帯域を変更し、可能な限り各セッションに割当てる伝送帯域を大きな値とする。図１に割当て帯域を視聴要求量に応じて変化させることの効果を概念的に示す。
【００４６】
以下、同時接続セッション数ｋが変化したとき（配送開始時と配送完了時）の、コンテンツｍ_ｓを配送するマルチキャストセッションｓの割当帯域（転送レート）ｂ_ｓの更新方法を示す。セッションｓには一人以上のユーザが収容されているが、そのユーザ集団のアクセス回線伝送容量のうち最小のものをＡ_ｓとすると、ｂ_ｎは、α（ｍ_ｓ）≦ｂ_ｓ≦Ａ_ｓの範囲で任意の値をとることができる。そこでｂ_ｓを、次のように再計算するものとする。
【００４７】
【数５】

【００４８】
ただし、サーバのネットワークＩＯ帯域をＢ〔ｂｐｓ〕とする。すなわち、各セッションに最小必要伝送帯域α（ｍ_ｓ）をまず割当て、残ったＩＯ帯域資源を、最大可能伝送帯域Ａ_ｓを超えない範囲でＡ_ｓとα（ｍ_ｓ）の差に比例して配分する。
【００４９】
（３）呼受付処理
コンテンツｍを配送するセッションは最低でもα（ｍ）の伝送帯域を確保する必要がある。そこで、他に待ちユーザのいないコンテンツを要求したユーザ（新規要求ユーザ）に対し、空きＩＯ帯域がα（ｍ）以上あるかどうかに応じて要求の受付可否判定を行う。バッチング中であるコンテンツを要求したユーザに対しては呼受付処理は不要であり無条件に収容される。
【００５０】
さて、時刻ｔ_０にコンテンツｍに対する新規要求が発生した場合、このユーザに対する呼受付処理を説明する。視聴要求がサーバに到着してから、実際に配送が開始されネットワークＩＯ帯域が消費されるのはバッチング遅延時間であるＷ後である。そのため、呼受付判定は、時刻ｔ_０＋Ｗの空き資源量に基づき行う必要がある。時刻ｔ_０において、コンテンツを配送中のマルチキャストセッション集合をΦａとし、バッチング中のマルチキャストセッション侯補集合（配送を開始していないが将来配送予定）をΦ_ｂとする。バッチング時間Ｗは全コンテンツに対し一定であるとすると、ｔ_０においてバッチング中であったセッション侯補はｔ_０＋Ｗにおいて全て配送を開始している。よって、時刻ｔ_０＋Ｗにおける消費資源量は、
【００５１】
【数６】

【００５２】
でその上限を抑えられる。実際にはｔ_０からｔ_０＋Ｗの間に配送が完了し、割当て帯域を開放したセッションがある場合があり、これより少なくなるが、セッション保留時間に対してバッチング時間Ｗが十分に短いことから式（４）を用いて呼受付処理を行う。すなわち、サーバのネットワークＩＯ帯域Ｂに対し、
【００５３】
【数７】

【００５４】
を満足するときのみ、この新規要求を受け付ける。この結果、全てのセッションは各々の最小必要伝送帯域以上の転送レートを確保することができる。
【００５５】
なお、式（２）で求めたα（ｍ）は、コンテンツ転送開始時点から転送完了時点までの全期間において最小限必要になる伝送帯域であり、コンテンツの一部が既に転送されている場合には、それ以後の転送に必要となる伝送帯域はα（ｍ）よりも小さくなる。よって、接続中セッションの最小必要伝送帯域を定期的に再計算することにより、収容可能なセッション数がさらに向上することが予想されるが、これについては後述の（５）で説明する。
【００５６】
（４）処理プロセス
ここでは割当て帯域の更新例を図２に示し、前記までに述べた本実施形態における処理プロセスをまとめる。図２の例ではコンテンツ数Ｍを３とし（便宜上、各々のコンテンツをＡ，Ｂ，Ｃと表記する）、サーバのネットワークＩＯ帯域Ｂを１２Ｍｂｐｓとする。また、最小必要伝送帯域α（）を各々、α（Ａ）＝５Ｍｂｐｓ、α（Ｂ）＝３Ｍｂｐｓ、α（Ｃ）＝４Ｍｂｐｓとし、アクセス回線容量は全ユーザとも１０Ｍｂｐｓであるとする。
【００５７】
時刻ｔ_０において、セッションＳ１がコンテンツＡを配送中であるとする。他に配送中のセッションは無く、またバッチング中のセッション侯補もないことから、セッションＳ１は最大可能帯域である１０Ｍｂｐｓを割当てられている。時刻ｔ_１において、ユーザＵ１がコンテンツＢを要求したとする。コンテンツＢはバッチング中でなく、これは新規要求であることから呼受付判定処理が実施されるが、式（５）を満足することから収容される。コンテンツＢの配送はバッチング遅延Ｗ後（時刻ｔ_３）であり、ｔ_１においてはセッションＳ１の割当て帯域に変化はないことに注意する必要がある。
【００５８】
続いて、ユーザＵ２がコンテンツＢを要求しているが、既に同一コンテンツをユーザＵ１が要求し、バッチング中であることから呼受付判定は行わず、直ちに収容される（ユーザＵ４についても同様）。
【００５９】
続いて、時刻ｔ_２にユーザＵ３がコンテンツＣを要求しているが、これは新規要求であることから呼受付判定を行い、配送中セッションＳ１とバッチング中のセッション侯補Ｓ２の最小必要帯域和（α（Ａ）十α（Ｂ））とコンテンツＣの最小必要帯域α（Ｃ）の総和がＢ以下であることから、やはり収容される。
【００６０】
続いて、ユーザＵ５がコンテンツＡを要求しているが、新規要求であることから（コンテンツＡは配送中であるが、このマルチキャストセッションにユーザＵ５を途中から加えることはできない）呼受付判定を行う。式（５）を満たさないことから、この要求は呼損となる。
【００６１】
時刻ｔ_３にてユーザＵ１により起動されたコンテンツＢのバッチング処理が完了し、ユーザＵ１とこの間に同一コンテンツを要求したユーザＵ２，Ｕ４に対し、コンテンツＢのマルチキャスト配送が開始される。この瞬間、同時接続セッション数に変化が生じることから、式（３）に従いＳ１とＳ２の割当て帯域が設定される（例では６．６７Ｍｂｐｓと５．３３Ｍｂｐｓ）。Ｓ２にて配送を受ける三人のユーザは、配送開始からＰｒｅ−ｌｏｄｅｉｎｇ遅延である時間Ｄ後に視聴を開始する。
【００６２】
時刻ｔ_４にてセッションＳ１の配送が完了し、それが開放されるが、同時接続数に変化が生じることからセッションＳ２の割当て帯域が更新される。この場合、アクセス回線容量である１０Ｍｂｐｓを割当てられる。時刻ｔ_５にてユーザＵ３により起動されたバッチング処理が完了し、コンテンツＣの配送が開始される。このとき、式（３）に従いセッションＳ２とＳ３の割当て帯域が各々、５．６９Ｍｂｐｓ、６．３１Ｍｂｐｓと計算される。
【００６３】
（５）最小必要伝送帯域の再計算
前記の（３）呼受付処理で述べたように、新規要求に対する呼受付判定は転送処理中およびバッチング中のセッションの最小必要伝送帯域α（ｍ）の総和がサーバのＩＯ帯域Ｂ以内か否かで行っている。前記の（１）最小必要伝送帯域による設定ではα（ｍ）をコンテンツｍごとにＰｒｅ−ｌｏａｄｉｎｇ時間Ｄから求めていたが、これはコンテンツの転送開始時点において必要となる最小伝送帯域である。コンテンツの一部が転送された後の時点において、それ以後の転送での最小必要伝送帯域は式（２）より求めた値よりも小さくなるため、定期的に転送処理中セッションの最小必要伝送帯域を再計算すれば、より多くのセッションが収容できる可能性がある。
【００６４】
そこで、時刻ｔ_ｓにてコンテンツｍの配送を開始したセッションの時刻ｔ_０（ｔ_０＞ｔ_ｓ）における転送中の画像フレームがｋ_０、画像フレームｋ_０の配送済みデータサイズがσである場合の時刻ｔ_０以降の最小必要伝送帯域を求める。
【００６５】
画像フレームｎ（ｋ_０≦ｎ≦Ｎ_ｍ）の再生時刻Ｓ_ｎは、やはり式（１）で与えられる。画像データの転送レートがｂ〔ｂｐｓ〕のとき、画像フレームｎ（ｋ_０≦ｎ≦Ｎ_ｍ）の末尾がＳＴＢに到着する時刻Ｆ_ｎは、
【００６６】
【数８】

【００６７】
となる。ｋ_０≦ｎ≦Ｎ_ｍにおいてＦ_ｎ≦Ｓ_ｎが満たされればＳＴＢバッファアンダーフローが回避できる。よって、時刻ｔ_０においてコンテンツｍの画像フレームｋ_０を転送中のセッションにおける最小必要伝送帯域はδ＝ｔ_ｓ−ｔ_０＋Ｄとすると以下のように求まる。
【００６８】
【数９】

【００６９】
（６）シミュレーション
以上までの各項を基にした本実施形態の配送方法のシミュレーションを行った。このシミュレーションについて以下に詳細に説明する。
【００７０】
（ａ）シミュレーション条件
Ｗｕｅｒｚｂｕｒｇ大学にて公開されているＭＰＥＧ１によりエンコードされた１８本の動画コンテンツの画像フレームサイズシーケンスを用いる。以下の表１にＭＰＥＧ１のエンコードパラメータを示す。また、表２に１８本のソース各々の平均フレームサイズＸとフレームサイズの変動係数ＣｏＶをまとめる。
【００７１】
【表１】

【００７２】
【表２】

【００７３】
シミュレーションで用いたＭ個のコンテンツ各々について、ランダムにこれら１８本のソースの中から１本を選択し、固定的に割当てる。コンテンツの長さは平均１２０分とし、１０５分〜１３５分の間からランダムに選択した。ただし、動画ソースのランダム数が４００００（２７．８分相当）であるため、最後の４フレームを削除した３９９９６フレーム（３３３３ＧｏＰ）を繰り返すことにより任意時間長のコンテンツを作成した。
【００７４】
次に、適切なＰｒｅ−ｌｏａｄｉｎｇ遅延時間Ｄを調べるため、ＭＰＥＧソースを１２０分に拡大した場合のＤに対する最小必要伝送帯域αを式（２）により計算した結果を図３に示す。図示のように、１００ミリ秒あたりまでは遅延時間Ｄの増加に対し、最小必要伝送帯域αは大きく低減するが、その後は５〜１０秒あたりまで緩やかに低減し、それよりも大きくなると特性の改善はほとんど見られなくなる。ユーザの待ち時間はＤ以上、Ｄ＋Ｗ以下となるが、Ｗを５分前後に選定することを考えると、Ｄは数秒に設定するのが望ましい。そこで、以下の評価では、Ｄ＝５秒とした。なお、煩雑になるのを避けるため図では６本のＭＰＥＧソースについてのみ示しているが、他の１２本についても同様な傾向が得られた。表２にＤ＝５秒としたときの最小必要伝送帯域αをまとめる。
【００７５】
ユーザからの視聴要求は到着率λ（ｔ）〔／ｓｅｃ〕のポアソン過程に従いサーバに到着する。ＶｏＤサービスに対する需要は２４時間周期で大きく変動することが知られており、到着率は時間ｔ〔ｈｏｕｒｓ〕の関数となる。ここでは図４に示すモデルでλ（ｔ）を与える。これは二つのＶｏＤ試験サービスで得られた視聴要求の発生パターンをモデル化したものであり、アイドル期間中は一定レートで要求が発生し、６時間にわたるピーク時間帯では三角形特性を呈する。試験サービスの観測結果から、ピーク時の到着率はアイドル時の５倍としている、一日あたりの平均発生要求数をＵとすると、Ｕ＝３６×３６００λ_０となる。シミュレーションでは、平均発生要求数Ｕを与えることによりλ_０を決定する。
【００７６】
サーバに到着した視聴要求は、各々独立にパラメータθ＝０．２７１のＺｉｐｆ分布に従い、Ｍ個のコンテンツ中から確率ｐ_ｍ＝ｃ／（ｍの１−θ乗）でコンテンツｍを選択する。アクセス回線容量は全ユーザとも同一で１０Ｍｂｐｓとした。
【００７７】
（ｂ）時系列特性
図５にαの再計算を行わない場合における平均同時接続数と各セッションに対する平均割当て伝送帯域の時系列特性を示す。ただし、コンテンツ数Ｍ＝５００、一日の平均要求数Ｕ＝１５００００、ネットワークＩＯ帯域Ｂ＝２．４８８Ｇｂｐｓ、バッチング間隔Ｗ＝２９５秒（Ｐｒｅ−ｌｏａｄｉｎｇ遅延が５秒なのでユーザの最大待ち時間は５分）とした。シミュレーションは三日分行い、そのうちの第二日目と第三日目を図示している。また、統計は１５分間隔で行い、その間の平均値をプロットしてある。
【００７８】
図４に示すパターンで需要を変化させたが、需要の増加する１８時〜２１時において同時接続セッション数も増加している。一方、０時〜６時の範囲で同時接続セッション数は減少しているが、需要の減少する２１時〜２４時の期間とは、３時間から６時間のずれがある。これは、ピーク時の割当て帯域が小さく、セッション保留時間が数時間に及ぶことが原因である。同時接続セッション数の少ないアイドル時間帯では、各セッションに最大割当て可能伝送レートであるアクセス回線容量１０Ｍｂｐｓが確保されていることがわかる。需要が増加するにつれ割当て帯域が減少し、ピーク時には最小必要帯域である数１００ｋｂｐｓにまで割当て帯域が減少している。そして需要が減少し、同時接続セッション数が減少するにつれ、割当て帯域は増加される。
【００７９】
以上のことから、本実施形態では需要の変動に対して各セッションに割当てる伝送帯域が適切に修正されることが確認された。
【００８０】
（ｃ）αの再計算による効果
コンテンツを配送中の全セッションに対する最小必要伝送帯域を、式（６）により固定間隔Ｔαで再計算する。図６にＭ＝５００、Ｕ＝１５０００、Ｂ＝６２２Ｍｂｐｓ、Ｗ＝２９５秒、Ｄ＝５秒としたときの、修正間隔Ｔαに対する平均必要伝送帯域和（コンテンツを配送中の全セッションに対する最小必要伝送帯域の総和の時間平均値）を示す。修正間隔Ｔαが短いほど最小必要伝送帯域和が低減するが、再計算を行わない場合（初期値利用）と比較して約２８％小さくなっている（Ｔα＝３０の場合）。続いて、以下の表３にＴαに対する呼損率をまとめる（Ｔ_０＝∞はαの再計算を行わない場合）。
【００８１】
【表３】

【００８２】
予想に反して、αを再計算した場合も呼損率はほとんど変化しないことがわかる。呼損が発生するＰｅａｋ時間帯には、各セッションに割当てられる伝送帯域は必要最小伝送声域α（ｍ，ｋ_０，δ，σ）に近づくが、α（ｍ，ｋ_０，δ，σ）を再計算することにより、配送中セッションの消費伝送帯域を削減できる。しかし、伝送すべきデータ量に変化はなく、その分、セッション保留時間が増加する。
【００８３】
一方、新規要求の要求帯域は全データが未転送なため、式（２）で算出されるα（ｍ）となり再計算の恩恵はない。よって、呼損率に変化がみられないものと思われる。
【００８４】
以上の考察から、特に最小必要伝送帯域の更新を行う必要はないことがわかった。
【００８５】
（ｄ）他方式との比較
図７に一日あたりの平均視聴要求数Ｕに対する平均バッチサイズ（一本のマルチキャストセッションに収容されるユーザ数）を示す。ネットワークＩＯ帯域Ｂを６２２Ｍｂｐｓとし、コンテンツ数Ｍを２０、１００、５００、バッチング期間Ｗを２９５秒（最大待ち時間５分）、５９５秒（最大待ち時間１０分）とした。ユニキャスト配送を行うＴ−ＶｏＤではバッチサイズが１になることから、マルチキャスト配送における平均セッション数はＴ−ＶｏＤに対して平均バッチサイズの逆数倍となる。よって、マルチキャスト配送を行うことにより、セッション数が大きく抑えられることがわかる。特に、バッチング期間を長くするほどより多くの視聴要求を束ねられることから、またコンテンツ数が少ないほど同一のコンテンツに対して要求が集中することから、バッチサイズは大きくなる。ただし、収容ユーザ数が少ない場合にはバッチングによる効果は小さい。
【００８６】
図８にＵに対する呼損率特性を示す。Ｍ＝２０のときと、Ｍ＝１００，Ｗ＝５９５のときは呼損が観測されなかった。図より、マルチキャスト配送を行うことにより呼損が大きく低減していることがわかる。例えば、呼損率０．０１を満足させるためには、Ｔ−ＶｏＤでは一日あたりの要求が約７，５００になるよう収容ユーザ数を抑える必要があるが、マルチキャスト配送では約３０，０００の要求に対応することができる（Ｗ＝２９５，Ｍ＝１００の場合）。
【００８７】
以上のことから、用意するサーバのネットワークＩＯ帯域に対して収容ユーザ数が少なく、ユニキャスト配送を用いても呼損率を十分に低く抑えられる場合には即時配送が可能なＴ−ＶｏＤを採用し、収容ユーザ数が多い場合にはマルチキャスト配送を採用するのが望ましく、ＶＴＲ操作に対応するために本実施形態を用いることが有効である。
【００８８】
次に、マルチキャストセッションｓ上のコンテンツ転送レートは、Ｐｒｅ−ｌｏａｄｉｎｇ時間から決まるコンテンツ毎に固有の最小必要伝送帯域α（ｍ_ｓ）以上、最小アクセス回線容量Ａ_ｓ以下の範囲で任意の値をとることができるが、本実施形態では伝送帯域を有効利用する目的から、同時接続セッション数に応じて動的に伝送帯域を設定している。そこで、動的割当ての有効性を明らかにするため、帯域を固定的にα（ｍ_ｓ）に設定する場合（最小帯域割当て方式）と、固定的にＡ_ｓに設定する場合（最大帯域割当て方式）とで呼損率を比較評価する。
【００８９】
図９に、一日あたりの平均視聴要求数Ｕに対する呼損率特性を示す。ただし、Ｍ＝５００、Ｕ＝１５０，０００，Ｂ＝２，４８８Ｇｂｐｓとした。帯域を固定に割当てる場合には、保留時間が長くなっても各セッションが消費する伝送帯域の少ない最小帯域割当て方式が良好な特性を示している。
【００９０】
しかし、動的に帯域を割当てる本実施形態では、最小帯域割当て方式よりも、さらに良好な特性を示している。例えば、呼損率０．０１を満たす一日当たりの許容可能要求数は、最小帯域割当て方式が約６２，０００であるのに対し、本実施形態では約１１６，０００である。
【００９１】
【発明の効果】
以上説明したように、本発明は、マルチキャスト・ストリーミング配送型のＶｏＤシステムにおいて、コンテンツ全体をＳＴＢに保持することにより、早送りを除いた任意のＶＴＲ操作がマルチキャストセッションを維持したまま可能とし、同時接続セッション数に応じて割当て伝送帯域を更新することにより呼損率を低減するという効果がある。
【図面の簡単な説明】
【図１】本発明の実施形態における動的帯域制御の効果を説明するための図。
【図２】実施形態における割当て帯域の更新例。
【図３】本発明のシミュレーションにおけるＰｒｅ−ｌｏａｄｉｎｇに対する最小必要帯域特性。
【図４】本発明のシミュレーションにおける需要パターン。
【図５】本発明のシミュレーションにおける時系列特性。
【図６】本発明のシミュレーションにおける再計算周期・最小必要伝送帯域和の平均値特性。
【図７】本発明のシミュレーションにおける平均バッチサイズ特性。
【図８】本発明のシミュレーションにおけるバッチングの有無による呼損率比較結果。
【図９】本発明のシミュレーションにおける帯域割当て方式間の呼損率比較結果。
【図１０】マルチキャストＶｏＤシステム構成。
【図１１】マルチキャストストリームを継続できる例。
【符号の説明】
１００…ビデオサーバ
１０１…ディスク
１０２、１０３、１０４…ＳＴＢ

Claims

サーバに蓄積されたデジタル動画コンテンツをユーザのセットトップボックスに直接配送するビデオ・オンデマンドサービス形態とし、かつ動画コンテンツを受信しながら並行して動画再生を行うストリーミング配送形態とし、かつサーバ資源の有効利用を図り呼損率を低減するマルチキャスト配送形態で動画コンテンツを配送する方法であって、
マルチキャストセッションを維持したまま早送りを除く任意のＶＴＲ操作を可能とするようコンテンツの全体をセットトップボックスに保持する手段と、
動画再生が中断するセットトップボックスのバッファアンダーフローを回避するのに必要な最小伝送帯域を算出する手段と、
前記必要最小伝送帯域に基づき呼受付判定を行う手段と、
前記必要最小伝送帯域以上かつアクセス回線容量以下になる同時接続セッション数に応じて割当て伝送帯域を動的に変更する手段と、
動画コンテンツの配送を開始したセッションの配送開始後の任意の時刻において転送中の画像フレームと、この画像フレームの配送済みデータサイズを基にして、定期的にコンテンツ配送中のセッションに対して前記必要最小伝送帯域を再計算することで消費資源量を削減する手段と、
を有して動画コンテンツを配送することを特徴とするマルチキャスト・ビデオ・オンデマンドによる動画コンテンツの配送方法。
請求項１に記載の配送方法において、動画コンテンツの全体を保持するのに十分な容量の記憶装置を前記セットトップボックスに用意し、一旦受信したデータを再生後も廃棄せずに該セットトップボックスに保存し、視聴完了時には動画コンテンツの全体を該セットトップボックスに保持しておく手段を有して動画コンテンツを配送することを特徴とするマルチキャスト・ビデオ・オンデマンドによる動画コンテンツの配送方法。
請求項２に記載の配送方法において、動画コンテンツの配送開始時刻から予備受信時間を経過した後に視聴を開始し、全画像フレームサイズシーケンスと前記予備受信時間の時間量から前記セットトップボックスバッファアンダーフローを回避するのに必要となる伝送帯域を算出する手段を有して動画コンテンツを配送することを特徴とするマルチキャスト・ビデオオンデマンドによる動画コンテンツの配送方法。
請求項１に記載の配送方法において、各セッションに請求項３で算出した必要最小伝送帯域を確保するため、他に待ちユーザのいないコンテンツを要求した新規要求ユーザに対し、最小必要伝送帯域に基づいて呼受付判定を行う手段を有して動画コンテンツを配送することを特徴とするマルチキャスト・ビデオ・オンデマンドによる動画コンテンツの配送方法。
請求項１に記載の配送方法において、サーバ資源を有効利用するため、同時接続セッション数に応じて、各セッションに割当てる伝送帯域を動的に更新する手段を有して動画コンテンツを配送することを特徴とするマルチキャスト・ビデオ・オンデマンドによる動画コンテンツの配送方法。