JP5325978B2 - 複数の受信器において利用できるコンテンツマップの配信システム及び方法 - Google Patents

Description

本発明は、ビデオ・オン・デマンドの配信に関し、特にビデオ・オン・デマンドを複数の受信器に配信する方法に関する。

このセクションは、以下に説明して特許を請求する本発明の様々な態様に関連する様々な態様の技術を読者に紹介することを意図するものである。この説明は、本発明の様々な態様の理解を容易にする背景情報を読者に提供する役に立つと思われる。従って、言うまでもなくこれらの記載は上記を考慮して読むべきであり、先行技術として認めるものではない。

DVB-IPコンテンツダウンロードシステムタスクフォースは、インターネットサービスプロバイダの管理の下に、DSLネットワークなどの管理されたIPネットワークにより、セットトップボックスやレジデンシャルホームゲートウェイなどのホームネットワークデバイスのローカル記憶へのコンテンツのダウンロードに基づく、ビデオ・オン・デマンドサービス用の標準策定をしている。CDS商用要件が編集され、DVB-CM IPTVグループのCM-IPTV０１０２r１５「IPTVコンテンツのダウンロード及びローカル記憶の管理に関する商用要件」にまとめられた。CDS仕様書はDVB-IPTV仕様書に組み込まれており、これは次のETSI TS １０２ ０３４ v１．４．１文書の公開までは、DVBブルーブックA０８６ Rev．７ September ２００８として入手可能である。

CDS仕様書の主な特徴は以下の通りである：
−２つのVODサービスモードを提供する：
−サービスプロバイダにより起動され、コンテンツ全体のダウンロードに基づくプッシュサービスモード；大ヒット作に適用される；
−ユーザ起動によるコンテンツダウンロードに基づくプルサービスモード；大ヒット作以外のすべてのコンテンツに適用される。
−これらの２つのサービスモードは３つの基本的なコンテンツダウンロードメカニズムに依存する：
−RFC３９２６で規定されたFile Delivery over Unidirectional Transport(FLUTE)プロトコルを用いるマルチキャスト；
−HTTPプロトコルを用いるユニキャスト；
−いくつかのピアクライアントによりコンテンツダウンロードを配信するために、これらのピアクライアントへのHTTPリクエストのリディレクションに基づく専用のプロトコルを用いるピア・ツー・ピア（Ｐ２Ｐと書く）。
−各サービスは複数のダウンロードメカニズムのいずれか、またはその組み合わせを用いることができる。例えば、プッシュサービスは、クライアントデバイスにコンテンツをプッシュするマルチキャストプロトコルと、マルチキャスト配信フェーズ中のエラーを回復するＰ２Ｐプロトコルとを用いて実現できる。プルサービスは、HTTPプロトコルを用い、１つのコンテンツに対するユーザ要求の数が大幅に増大した場合にマルチキャスト配信またはＰ２Ｐ配信にリディレクションして実現できる。
−SD&S/BCGを用いて、サービスタイプごとの利用できるコンテンツと、それをダウンロードするプロトコルとをアナウンスする。SD&S/BCGは、ユニキャスト(HTTP)またはマルチキャスト(DVB-STP)プロトコルベースの宣言をサポートする。CDSサービス宣言を許容するSD&S/BCG仕様は、DVBブルーブックA０８６ Rev．７ September ２００８に記載されている。

CDS仕様書は、クライアントのローカル記憶へのコンテンツ全体のプロアクティブダウンロードに基づくプッシュサービスモードを提案している。かかるサービスモードによりユーザはコンテンツに瞬時にアクセスできるので、大ヒット作の配信に非常に適している。しかし、コンテンツ全体が各クライアントで複製されるので、このサービスモードはデバイス記憶の利用に関して制約がある。一方、CDSは、プロアクティブコンテンツダウンロードを伴わないプルサービスモードも提案している。プルサービスはすべてのコンテンツの配信に利用される。しかし、大ヒット作は、ユーザがコンテンツにアクセスできる前に、ダウンロード遅延時間が必要である。

目標を絞ったプロアクティブなコンテンツプッシュストラテジを伴うＰ２Ｐは、基本的に、ネットワーク上のピアにコンテンツフラグメントをプロアクティブに配信するユニキャストプロトコルを用いる。さらに、多くのＰ２Ｐプロトコルは、要求コンテンツを提供できるピアを探すフェーズにおいても、これらのピアから要求コンテンツをダウンロードするフェーズと同様に、ユニキャストプロトコルを用いる。(例えば、インターネットなどの管理されていない環境において)マルチキャストなど他のプロトコルが利用できない場合、またはソリューションの主な設計上の制約の１つがピア記憶の最適化であるが、それにより各ピアが異なるコンテンツフラグメントを記憶することとなり、結果としてマルチキャストプロトコルを利用することが効率的でないソリューションになってしまう場合には、ユニキャストプロトコルの利用は非常に妥当である。

本発明は、コンテンツ利用可否マップの配信方法を提供することにより、先行技術におけるコンテンツ配信に伴う問題の少なくとも一部を解消しようとするものである。

本発明は、サーバからコンテンツを受信するピア・ツー・ピアクライアントにおける方法である。該方法は、マルチキャストモードでサーバからコンテンツを受信する段階と、正しく受信したコンテンツを前記サーバに知らせる段階と、各ピアにおいて利用できるコンテンツを示すコンテンツ利用可否マップを、前記サーバからマルチキャストモードで受信する段階と、前記コンテンツ利用可否マップに示されたピアに欠けているコンテンツを要求する段階とを有する。

欠けているコンテンツをピア受信器から回復するために、受信器はピア受信器において利用できるコンテンツを知らされる。受信器は、欠けているファイルをサーバに要求する必要がない。受信器は、サーバに問い合わせせずに、正しいピアに直接問い合わせできる。

CDS仕様書は、マルチキャストプロトコルとＰ２Ｐプロトコルとを組み合わせる可能性をサポートしている。かかる組み合わせを用いて、「目標を絞ったプロアクティブなコンテンツプッシュを伴うＰ２Ｐ」配信モードに基づくCDSサービスを効率的に実現できる。かかるサービスは、適度に人気があるコンテンツの配信に適している。これによりサービスオペレータは、クライアントのローカル記憶をよりよく利用して、より多くのコンテンツを提供できる。オペレータが、より多くのコンテンツを含むサービスを提供する時、これは、CDSサービス展開の成功のための大きな問題である。

本発明の他の目的は、コンピュータで実行された時に本発明による方法のステップを実行するプログラムコード命令を有するコンピュータプログラム製品である。「コンピュータプログラム製品」とは、ディスケットやカセットなどの、プログラムを含む記憶スペースだけでなく、電気信号や光信号などの信号におけるコンピュータプログラムサポートを意味する。

開示した実施形態と同じ範囲の態様を以下に記載する。言うまでもなく、これらの態様は、読者に本発明が取り得る形態の簡単な概要を提供するためだけに記載するものであり、本発明の範囲を限定するものではない。実際、本発明は、以下に記載していない様々な態様を包含し得る。

本発明は、添付した図面を参照して以下の実施形態及び実施例により、よりよく理解でき、例示できるであろう。
実施形態によるネットワークアーキテクチャを示す図である。 実施形態による、ピアにおいて利用できるコンテンツを示す図である。 実施形態による、ローカルゾーンごとの、異なるタイプのクライアントデバイスのリパーティションを示す図である。 図１乃至３では、表示したブロックは純粋に機能的なものであり、必ずしも物理的なものとして分離していることを示すものではない。すなわち、これらのブロックは、ハードウェアやソフトウェアとして開発してもよいし、集積回路により実施してもよい。

例としての実施形態をCDSとFLUTEのフレームワークで説明するが、本発明はこの具体的な環境に限定されない。本発明は、複数の受信器にコンテンツを配信し、すべての受信器に各受信器で利用できるコンテンツマップを配信する他のフレームワークにも適用できる。受信器は、ピア受信器から、欠けているコンテンツを受信できる。

本発明の実施形態を、DVB-IP/CDSの要件を満たすコンテンツダウンロードシステムについて説明する。ネットワークアーキテクチャフレームワークは、図１に示した管理されたオペレータネットワークに基づく。そのフレームワークは次の構成要素よりなる：
−クライアントデバイスに対してコンテンツを効率的にプッシュできるマルチキャストコンテンツサーバ１
−クライアントデバイスに対して遠隔管理とレポート機能を提供する制御サーバ３
−サービスデリバリの詳細をクライアントにシグナリングする宣言サーバ２
−コンテンツを相互間で協調的に配信し、ユーザにオペレータサービスへのアクセスを提供できる複数のクライアントデバイス１１、１２、１３。

オペレータは、クライアントを登録し、各クライアントに「Client-Type」を割り当てる。クライアントタイプの数は「n」に制限される。この割り当ては、制御サーバとクライアントとの間で実現されるオペレータリモート管理システムにより行われる。

これらの条件では、「目標を絞ったプロアクティブコンテンツプッシュを伴うＰ２Ｐ」デリバリは次のステップで進められる：
ステップ１：コンテンツフラグメントのプロアクティブプッシュ
ステップ１．ａにおいて、このプロアクティブプッシュの各コンテンツは、クライアントタイプと同数のフラグメントに分割され、マルチキャストサーバを用いて、「Client-Type」が同じすべてのクライアントの各フラグメントをプッシュする。この「目標を絞ったプッシュ」は、すべてのタイプのクライアントにすべてのコンテンツフラグメントをトランスポートする１つのマルチキャストFLUTEセッションだけを用いて、またはクライアントタイプごとに１つのマルチキャストFLUTEセッションを用いて、実現できる。

各マルチキャストセッションは、RFC３９２６に記載されている、トランスポートされるコンテンツフラグメントを記述するFLUTEファイルデリバリテーブルインスタンス（FLUTE FDT）を担う。各コンテンツフラグメントは、FDTインスタンスの「Content_Location」フィールドの「Content-Fragment-URI」により特定される。かかるFDTインスタンスの例を表１に示す。

欧州特許出願第１９０１５２５号に記載されたようなストラテジと、マルチキャストデリバリとＰ２Ｐデリバリとの組み合わせを用いて、このプロアクティブコンテンツフラグメントプッシュの信頼性を高くできる。表１は、マルチキャストセッションでトランスポートされるコンテンツフラグメントを記載するFDTインスタンスを示す。

ステップ１．ｂにおいて、コンテンツフラグメントのダウンロード前に、宣言メカニズムを用いて、クライアントがコンテンツフラグメントにアクセスする詳細情報を、「Client-Type」に応じてマルチキャストセッションでクライアントにプッシュする。かかる宣言データの一例を、「目標を絞ったプッシュ」サービスのSD&S/BCG宣言を示す表２に示す。この宣言はSD&S/BCGプロトコルによりトランスポートされる。この例は、FLUTEマルチキャストデリバリを用い、「Client-Type」フィールドによりダウンロードしなければならないコンテンツフラグメントをクライアントが決定できるCDSサービスタイプの宣言に基づく。この表のその他のフィールドは、最新のCDS仕様書に記載されている。

ステップ１．ｃにおいて、クライアントタイプに対応するフラグメントと、「目標を絞ったプッシュ」セッションのすべてのコンテンツアイテムのフラグメントとを正しく受信すると、各クライアントは、これらのフラグメントを受信したことを制御サーバにレポートしなければならない。バックオフタイミングを用いて、レポート手順の時間にわたり制御サーバの負荷を分散する。この情報により、制御サーバは(クライアントのIPアドレスやClient-Typeなどのパラメータで)クライアントを特定することができる。制御サーバは、クライアントがダウンロードしたコンテンツフラグメント(Content-Fragment-URI)を知ることができる。

コンテンツフラグメント受信レポートメッセージの一例を表３に示す。このメッセージは、CDS仕様書で規定されたレポートメッセージと非常に近いものである。この表のフィールド「Multicast-Delivery-Session-List」と「Recovery-Delivery-Server-Source-List」の利用方法については、CDS仕様書に記載されている。

複数のサーバベースのコンテンツデリバリの場合には、server_source_IDフィールドが、どのサーバがコンテンツをアップロードしたかを示す。

ステップ２：コンテンツ利用可否マップのプロアクティブプッシュ
ステップ２．ａにおいて、クライアントが「Client-Type」に対応するコンテンツフラグメントをダウンロードし、受信をレポートすると、オペレータは、他のマルチキャストセッションを開始し、または前のマルチキャストセッションを用いて、各クライアントに、他のクライアントにプッシュしたコンテンツフラグメントが利用可能であることを示す情報をプッシュする。これらのコンテンツ利用可能性情報は、レポート手順により関連情報をすべて有している制御サーバにより構成できる。これらのコンテンツ利用可能性情報は、一旦構成されると、マルチキャストサーバに送られ、クライアントデバイスにプッシュされる。

かかるコンテンツ利用可能性情報の例を表４に示す。この表は「CAM：Content Availability Map」と呼ぶ。この表は、フラグメントをプロアクティブにダウンロードした各コンテンツを記述している。各コンテンツに対して、この表は、コンテンツのフラグメントをダウンロードしたピアを示すピアのリスト(「Peer-List」)を含む。このピアリストは、コンテンツの同じフラグメントを記憶するピアからなるサブセット(「Peer-Subset」)に分割される。各ピアサブセットにおいて、ダウンロードされたコンテンツフラグメントは、利用できるコンテンツのチャンクを示す「Available-Chunk-List」フィールドにより示される。コンテンツアイテムごとのチャンクのサイズを、表の「Content-Map」フィールドに示す。

コンテンツフラグメントとコンテンツチャンクは、一般的には異なるものであり、その間の関係(フラグメントごとのチャンク数、最終フラグメント中のチャンク数など)はアプリオリに知られる。コンテンツフラグメントは、マルチキャストデリバリによるコンテンツの配信のためのものであり、コンテンツチャンクはＰ２Ｐデリバリによるコンテンツの配信のためのものである。一般的に、コンテンツフラグメントのサイズはコンテンツチャンクのサイズよりも大きく、コンテンツフラグメントは複数のコンテンツチャンクを連続または非連続につなげたものである。

ステップ２．ｂにおいて、CAMのプッシュに用いるマルチキャストセッションは、前出のSD&S/BCG宣言に、表５に示したマルチキャストセッション宣言を加えて、宣言される。この宣言には「Client-Type」フィールドはない。これは、各クライアントデバイスが、その「Client-Type」が何であってもこの「Content Availability Map」をダウンロードしなければならないことを意味する。

マルチキャストセッションでトランスポートされ、「Content Availability Map」を記述するFLUTE FDTインスタンスを表６に示す。

ステップ３：コンテンツ要求
ステップ３．ａにおいて、クライアントデバイスは、「Content Availability Map」を受け取ると、ダウンロードを要求できるユーザにコンテンツを提案できる。

ステップ３．ｂにおいて、要求するクライアントデバイスは、必要なコンテンツフラグメントをすべては記憶していないので、他のクライアントデバイスに記憶されている、欠けているフラグメントを読み出す必要がある。これらのピアクライアントデバイスを特定するため、要求するクライアントは、中央サーバまたは他のピアに問いあわせずに、直接「Content Availability Map」を用いる。この表を用いて、要求するクライアントは、それが事前に記憶しているコンテンツチャンクと、欠けているコンテンツチャンクを提供できるピアのリストを知ることができる。

実施形態を図２に示した。この図は、コンテンツフラグメントとコンテンツ利用可否マップ(CAM)のプッシュ後のピアの状態を示す。クライアントデバイス「Peer １b」は、コンテンツ「B」のダウンロードを望むが、「Content Availability Map」を用いて：
−すでにダウンロードしたコンテンツチャンク(Chk２、Chk３)を判断する、
−ダウンロードしなければならないコンテンツチャンク(ChkO、Chk１、Chk４．．．Chk１１)を判断する、
−ピアを選択してコンテンツチャンクをダウンロードする(例えば、POa→ChkO、POb→Chk１、P２a→Chk４．．．、P５b→Chk１１)。

ローカルに行われ、DSLネットワークにおけるDSLAMで行われる場合があるＰ２Ｐによる情報交換を制限するために、実施形態を改良する。

「Content Availability Map」は各ローカルエリアで異なる。「Local Content Availability Map」(LCAM)は、「Client-Locality-Id」により特定されるすべてのクライアントデバイスにプッシュされる。この識別子は、「Client-Type」識別子と同様に、オペレータリモートシステム制御により管理される。図３は、ローカルゾーン(「Client-Locality-Id」)ごとの、異なるタイプ(「Client-Type」)のクライアントデバイスのリパーティションを示す図である。

制御サーバによる「LCAM」の構成をする方法は、下表に示したように、コンテンツフラグメント受信レポートメッセージにローカリティ識別子(「Client-Locality-Id」)を加えることである。

各「Local Content Availability Map」は、クライアントデバイスにコンテンツフラグメントをプッシュするために用いるのと同じ、目標を絞ったマルチキャストセッションにおいて、「Client-Locality-Id」識別子に基づき、ローカルにプッシュされる。

この場合に「Local Content Availability Map」をプッシュするマルチキャストセッション宣言の例を下表に示す：

マルチキャストセッションでトランスポートされ、「Local Content Availability Map」を記述するFLUTE FDTインスタンスを表６に示す。ここで「Content-Location」を「LCAM-URI」に設定されている。

実施形態の第１の変形例では、CAMはアプリオリに求められ、コンテンツフラグメントとともにFLUTEセッションに送られる。ネットワークオペレータはそのネットワークトポロジを熟知している。このトポロジに基づき、クライアントからの受信レポートメッセージを待たずに、理論的に理想的なCAMを構成することができる。このCAMを、１つのFLUTEセッションで、対応するすべてのコンテンツフラグメントとともに、プッシュできる。

この変形例は、SD&Sを介した１つの宣言と、(２つではなく)１つのFLUTEセッションのみを用いる。クライアントＰ２Ｐダウンロードを確実にするための集中制御サーバへのクライアント受信レポートは、必要なくなる。他の目的のためにレポートが必要であれば、CDSには完了ポーリングメカニズム（completion polling mechanism）があり、クライアントのサブセットのみが集中制御サーバに正しく受信できたことをレポートする。

実施形態の第２の変形例では、ピア間の近接性情報を導入する。「Client-Locality-Id」は、ピアリストの記載の一部、すなわちローカリティが同じピアであり、ピアは自分の近くのピアを特定し、それだけにコンタクトして、他のすべてのフラグメントをダウンロードできる。

近傍の概念を拡張して領域すなわちローカリティが近いもののリストを生成する。これらの新しいフィールドを下表８に示すように、CAMに挿入する：

領域を用いて、ネットワークトポロジに近づき、必要に応じて(接続やCPU負荷などの点でクライアントにアクセスできない場合など)、クライアントデバイスが近いクライアントから遠いクライアントに階層的にアクセスすることを可能とする。

一般的に、この階層には２つより多いレベルがあり、オペレータにより構成されたレベルにおけるネットワークトポロジを抽象化したものを表すツリー状のデータ構造となるであろう。「Region」フィールドは、表８では「Region-Level-１」という名称になっている。

CAMを拡張して、各ローカリティの特性、上記のすべての質的データ（ダウンロードとアップロード用の平均ビットレートキャパシティ）、貴重な情報を含み、必要な時に、クライアントが最良のローカリティを選択できるようにしてもよい。

CAMは定期的に更新され、ネットワークにおけるダウンロードの進行状況を反映する。オペレータは、チャンクレベルで精密に、または(完全なフラグメントを有するピアについてのみ)フラグメントレベルでマクロ的に、更新のレベルを選択して、ピアをその接続状態に応じてCAMに追加したり削除したりできる。この更新は元のCAMが理論的なものであってもなくても適用できる。

明細書、特許請求の範囲、及び図面に開示した内容（references）は、独立に設けることもできるし、適切に組み合わせて設けることもできる。必要に応じて、ハードウェア、ソフトウェア、またはこれらの組み合わせで機能を実施することができる。

本明細書において「一実施形態」とは、その実施形態に関して説明する具体的な機能、構造、特徴などが本発明の少なくとも１つの実施形態に含まれ得ることを意味している。本明細書ではいろいろな箇所で「一実施形態とは」と記載するが、必ずしも同じ実施形態を指すものではなく、別の、または代替的な実施形態は、必ずしも他の実施形態と互いに排他的なものではない。

特許請求の範囲に示す参照符号は例示であり、請求項の範囲を限定するものではない。

Claims (3)

1. クライアントにおけるコンテンツを受信する方法であって、
   コンテンツの複数の断片を、第１のサーバからマルチキャストモードで受信するステップと、
   正しく受信したコンテンツの断片を、第２のサーバに知らせるステップと、
   各ピアクライアントにおいて利用できるコンテンツの断片を示すコンテンツ利用可否マップを、第３のサーバからマルチキャストモードで受信するステップと、
   前記コンテンツ利用可否マップに示された、前記コンテンツの断片が利用可能なピアクライアントに、受信していないコンテンツの断片を要求するステップと、
   を有する方法。
2. 前記クライアントはその所在を前記第２のサーバに知らせる、請求項１に記載の方法。
3. 前記コンテンツの複数の断片を受信した第１のサーバの識別子を、前記第２のサーバに知らせるステップをさらに有する、請求項１に記載の方法。

Images