JP2016519457A - コンテンツ配信ネットワークにおいて分散型コンテンツ・キャッシングを実現する方法および装置 - Google Patents

Abstract

コンテンツ配信サーバについて記載する。このコンテンツ配信サーバは、コンテンツ配信ネットワーク（ＣＤＮ）において使用することができる。また、分散型コンテンツ・キャッシング技法についても記載する。この分散型コンテンツ・キャッシング技法は、ＣＤＮ内部において効率的に低コストで実現することができる。種々の実施形態において、ネットワークにおけるコンテンツ配信に関連するコスト関数を減少させる（理想的には最少化する）ことによって、ＣＤＮ内部にある複数のゲートウェイ・デバイスにおけるキャッシュするために、コンテンツを識別する。コスト関数は、ゲートウェイ・デバイスからユーザにコンテンツを配信するコスト、およびＣＤＮの集中位置からユーザにコンテンツを配信することに関連するコストを考慮に入れることができる。【選択図】図１

Description

[0001] 本明細書において開示する主題は、一般には、データ配信に関し、更に特定すれば、１つ以上のコンテンツ・プロバイダから複数のエンド・ユーザへのディジタル・コンテンツ配信に関する。

[0002] コンテンツ配信ネットワーク（ＣＤＮ）は、ネットワークにおいてディジタル・コンテンツをエンド・ユーザに配信する(distribute)ために使用されるシステムである。ＣＤＮは、多くの場合、コンテンツ・プロバイダによってそれらのコンテンツを公衆に配信するために使用される。コンテンツ・プロバイダは、それら自体のＣＤＮを維持することもあり、またはそれらのコンテンツを配信するために独立したＣＤＮ運営会社に支払うこともできる。通常、ＣＤＮは一定のサービス品質（ＱｏＳ）でコンテンツをユーザに配信することに同意する。ＣＤＮは、通例、コンテンツ配信をサポートするために、１つ以上のデータ・センタを運用する。周知であろうが、データ・センタとは、ユーザへのディジタル・コンテンツの格納および配信に伴うコンピュータ・ハードウェア（例えば、サーバ、ルータ、ディスク・ドライブ等）を通例収容する大型設備である。ＣＤＮは、データ・センタ（１つまたは複数）を所有することもできるが、コンテンツ配信を容易にするために１つ以上の独立したデータ・センタと契約を結ぶこともできる。

[0003] 認められようが、ＣＤＮは非常に高価であり、運用するのが複雑である可能性がある。加えて、ディジタル・コンテンツに対する需要が増々増加することにより、ＣＤＮは、需要を満たすためそしてそれらのサービス品質の義務を果たすために、更に大きく更に多数のデータ・センタを維持することまたはサポートすることが求められている。ディジタル・コンテンツ配信に関連するコストおよびハードウェア要件を低減するために使用することができる技法、システム、およびデバイスが求められている。

[0004] 本明細書において説明する種々の実施形態において、分散型コンテンツ・キャッシング（ＤＣＣ）を使用してコンテンツ配信ネットワーク（ＣＤＮ）の性能および設計を向上させる技法およびシステムを提供する。本明細書において説明する特徴の一部は、例えば、ＣＤＮの運用の効率を高めるため、そしてこのようなシステムを実現するコストを低減するために使用することができる。ある実施形態では、ＣＤＮにおけるＤＣＣ性能を最適化するための最適化技法を提供する。例えば、ネットワークにおける異なるゲートウェイまたはエッジ・デバイスに跨がってファイルのシームレスな配信を可能にするために、ＣＤＮにコンテンツを格納するためのある実現例において、ネットワーク・コーディング技法（または他のコーディング技法）も、ある実施形態において提供する。ネットワーク・コーディングの使用は、個々のファイル・パーティショニングに関連する問題を迂回することを可能にし、こうして所与のファイルの異なる部分の特定の位置に関わる必要なく、ネットワークでファイルをシームレスに配信することを可能にすることができる。

[0005] 本明細書において説明する概念、システム、回路、および技法の１つの形態によれば、コンテンツを複数のユーザに配信するコンテンツ配信ネットワーク（ＣＤＮ）における使用のための機械実装方法を提供する。ＣＤＮは、コンテンツ配信サービスを管理するために中央サーバを使用し、更にユーザ位置の近くに位置する複数のゲートウェイ・デバイスを使用する。ゲートウェイ・デバイスは、ＣＤＮによって配信されるコンテンツの少なくとも一部をキャッシュするデータ格納能力を有する。更に具体的には、この方法は、ＣＤＮを記述する情報を収集するステップと、ユーザ・コンテンツ要件に対応するＣＤＮの動作の統計を集計するステップと、コンテンツ配信に関連するコスト関数を最小に抑えることによって、複数のゲートウェイ・デバイスにおいて格納されるコンテンツを決定するステップであって、コスト関数が、サーバからのコンテンツ配信に関連するコスト、およびゲートウェイ・デバイスからのコンテンツ配信に関連するコストを考慮に入れ、コンテンツを決定するステップが、収集した情報および集計した統計を使用するステップを含む、ステップと、格納されるコンテンツを決定するステップの結果にしたがって、キャッシュするためにコンテンツを複数のゲートウェイ・デバイスに送るステップとを含む。

[0006] 一実施形態では、収集するステップ、集計するステップ、決定するステップ、および送るステップは、中央サーバにおいて実行される。
[0007] 一実施形態では、この方法は、更に、ＣＤＮを効率的に運用するために、収集するステップ、集計するステップ、決定するステップ、および送るステップを連続的に繰り返すステップも含む。

[0008] 一実施形態では、コスト関数は、サーバの配信遅延を考慮する項を含む。
[0009] 一実施形態では、コスト関数は、サーバ負荷分散に対する制限を含む。
[0010] 一実施形態では、複数のゲートウェイ・デバイスにおいて格納するコンテンツを決定するステップは、コスト関数を最小に抑えるために以下の最適化手順の内少なくとも１つを使用するステップを含む。一般代理勾配方式(General Proxy Gradient Scheme)、内点法、ならびにＧＵＲＯＢＩおよびＣＶＸのような数値ソルバ(numerical solver)。

[0011] 一実施形態では、キャッシュするためにコンテンツを複数のゲートウェイ・デバイスに送るステップは、コンテンツをインターネットを介して送るステップを含む。
[0012] 一実施形態では、ＣＤＮに関連する複数のゲートウェイ・デバイスは、共通インターネット・サービス・プロバイダ（ＩＳＰ）を介してインターネットと通信し、中央サーバはインターネットに接続される。

[0013] 一実施形態では、コンテンツを複数のゲートウェイ・デバイスに送るステップは、中央サーバ位置に配置されていない１つ以上のデータ・センタからゲートウェイ・デバイスにコンテンツの少なくとも一部を送らせるステップを含む。

[0014] 一実施形態では、キャッシュするためにコンテンツを複数のゲートウェイ・デバイスに送るステップは、ネットワーク・コード化ファイル・セグメントをゲートウェイ・デバイスに送るステップを含む。

[0015] 本明細書において説明する概念、システム、回路、および技法の他の形態によれば、複数のユーザにコンテンツ配信サービスを提供するコンテンツ配信ネットワーク（ＣＤＮ）は、当該ＣＤＮのためにコンテンツ配信サービスを管理するコンテンツ配信サーバを含む。一実施形態例では、コンテンツ配信サーバは、ユーザ位置またはその近くにおいて配備された複数のゲートウェイ・デバイスにおいて、選択されたコンテンツをキャッシュするためのキャッシング方式をＣＤＮのために実行する(develop)ように構成される。ある実施形態では、キャッシング方式は、コンテンツをユーザに配信するときの効率を高めることができる。ある実施形態では、コンテンツ配信サーバは、コンテンツ配信に関連するコスト関数を最少化することによって、キャッシング方式を実行するように構成され、コスト関数が、ゲートウェイ・デバイスからのコンテンツ配信に関連するコストと、ＣＤＮの１つ以上の他のコンテンツ記憶位置からのコンテンツ配信に関連するコストとの双方を考慮に入れる。

[0016] 一実施形態では、ユーザ位置またはその近くに配備された複数のゲートウェイ・デバイスが、ＣＤＮの制御下にある。
[0017] また、ＣＤＮまたは他のネットワークにおいて使用することができるコンテンツ配信サービスを管理するコンテンツ配信サーバについても記載する。一実施形態例では、コンテンツ配信サーバは、ユーザ位置またはその近くに配備された複数のゲートウェイ・デバイスにおいて、選択されたコンテンツをキャッシュするために、ＣＤＮまたは他のネットワークのためにキャッシング方式を実行するように構成される。ある実施形態では、このキャッシング方式は、コンテンツをユーザに配信するときの効率を高めることができる。このキャッシング方式は、システムまたはコンテンツ配信サーバのようなサーバにおいて使用することができる。ある実施形態では、サーバ（例えば、コンテンツ配信サーバ）は、コンテンツ配信に関連するコスト関数を減少させる（そして理想的には最少化する）ことによって、キャッシング方式を実行するように構成され、コスト関数は、ゲートウェイ・デバイスからユーザにコンテンツを配信するコスト、およびＣＤＮの１つ以上の他のコンテンツ格納位置からの配信に関連するコストを考慮に入れる。一実施形態では、コンテンツ配信サーバは、キャッシング方式にしたがって、複数のゲートウェイ・デバイスにおける個々のゲートウェイ・デバイスにコンテンツを配信するように構成される。

[0018] 一実施形態では、コンテンツ配信サーバが、ＣＤＮにおける経時的な変化を考慮に入れるために、キャッシング方式を時々更新するように構成される。
[0019] 一実施形態では、コンテンツ配信サーバが、複数のゲートウェイ・デバイスにインターネットを介して結合される。

[0020] 一実施形態では、複数のゲートウェイ・デバイスが、全て共通のインターネット・サービス・プロバイダ（ＩＳＰ）に関連付けられる。
[0021] 一実施形態では、コンテンツ配信サーバが、ＣＤＮの現在の構成についての情報を収集し、ユーザ・コンテンツ要求に対応するＣＤＮの動作の統計を集計し、ＣＤＮのためにキャッシング方式を実行するために、収集した情報および集計した統計を使用するように構成される。

[0022] 一実施形態では、コスト関数が、コンテンツ配信サーバが１単位のコンテンツをゲートウェイに送信するコストと、ゲートウェイにおいて１単位のコンテンツをキャッシュするコストとを使用する。

[0023] 一実施形態では、コスト関数が、サーバにおける配信遅延を考慮に入れる項を含む。
[0024] 一実施形態では、コスト関数が、サーバ負荷分散に対する制限を含む。

[0025] 一実施形態では、コンテンツ配信サーバが、ネットワーク・コード化コンテンツを、複数のゲートウェイ・デバイスに、その中にキャッシュするために配信するように構成される。

[0026] 本明細書において説明する概念、システム、回路、および技法の更に他の態様によれば、命令が格納された１つ以上の非一時的コンピュータ読み取り可能媒体を含む製品を提供する。計算システムによってこの命令が実行されると、コンテンツを複数のユーザに配信するコンテンツ配信ネットワーク（ＣＤＮ）における使用のための方法を実行する。ＣＤＮは、コンテンツ配信サービスを管理する中央サーバと、ユーザ位置に近接して配置され、ＣＤＮにおいて配信されるコンテンツの少なくとも一部をキャッシュするときの使用のためにデータ記憶能力を有する複数のゲートウェイ・デバイスとを有する。更に特定すれば、この方法は、以下のステップ、ＣＤＮを記述する情報を収集するステップと、ユーザ・コンテンツ要件に対応するＣＤＮの動作の統計を集計するステップと、コンテンツ配信に関連するコスト関数を最少化することによって、複数のゲートウェイ・デバイスにおいて格納されるコンテンツを決定するステップであって、コスト関数が、サーバからのコンテンツ配信に関連するコストと、ゲートウェイ・デバイスからのコンテンツ配信に関連するコストとを考慮に入れ、コンテンツの決定が、収集された情報および集計された統計を使用することを含む、ステップと、格納するコンテンツを決定した結果にしたがって、複数のゲートウェイ・デバイスに、それによってキャッシュされるコンテンツを送るステップ、の内１つまたは組み合わせを含むこともできる。

[0027] 一実施形態では、コスト関数が、前記サーバにおける配信遅延を考慮に入れる項を含む。
[0028] 一実施形態では、コスト関数が、サーバ負荷分散に対する制限を含む。

[0029] 以上の特徴は、以下の図面の説明から一層深く理解することができよう。
図１は、実施形態によるコンテンツ配信ネットワーク（ＣＤＮ）を示すブロック図である。 図２は、ＣＤＮ内部で利用可能なムービー・ファイルの数（Ｍ）の関数として、ＣＤＮ内部における種々のゲートウェイ数（Ｎ）に対する最適コスト値を示すグラフである。 図３は実施形態による最適化プロセスの収束を示すグラフである。 図４は、実施形態によるＣＤＮに対するサーバ容量の関数として種々のコストを示すグラフである。 図５は、実施形態にしたがってＤＣＣを使用するＣＤＮを運用する方法例を示す流れ図である。

[0035] 本明細書では、ネットワークにおいてディジタル・コンテンツをユーザに効率的にそして価格効率的に配信することを可能にする技法、システム、およびデバイスについて説明する。これらの技法、システム、およびデバイスは、例えば、コンテンツ配信に関連するコスト、複雑さ、およびハードウェア要件を低減するために、コンテンツ・プロバイダ、コンテンツ配信ネットワーク（ＣＤＮ）運用会社、およびデータ・センタ運用会社によって使用することができる。種々の実施形態において、分散型コンテンツ・キャッシング（ＤＣＣ）技法が、ＣＤＮに関連するデータ・センタ内におけるハードアウェア要件を低減するために使用される。更に詳細に説明するが、ＤＣＣは、１つ以上の集中位置（例えば、データ・センタ等）の代わりに、ネットワークのエンド・ポイントの近く（即ち、ユーザ位置の近く）において、コンテンツの一部または全部を配信することを伴う。つまり、本明細書において説明するある実施形態では、ネットワークのユーザに関連し、ユーザ位置またはその付近に配置されたエッジ・デバイスまたはゲートウェイ内に、コンテンツが格納される。加えて、種々の実施形態において、ネットワーク内部における格納および通信制限のコストを仮定して、効率的なコンテンツ配信を達成するためにネットワークのゲートウェイ・デバイス内にキャッシュされるコンテンツをインテリジェントに選択するための技法を提供する。本明細書において説明する技法、システム、およびデバイスは、大型および小型双方のネットワーク、ならびにプライベートおよびパブリック双方のネットワークを含む、異なるタイプのネットワークにおいて、コンテンツを配信するために使用することができる。

[0036] ある実施形態では、ＤＣＣの運用の効率を高めるときに使用するために１つ以上のコスト関数を設ける。システムに関連する複数の決定変数に対して値を求めるコスト関数を最小化するために、最適化技法を利用することもできる。次いで、決定変数値は、ネットワークのユーザ・ゲートウェイ内に格納されるコンテンツを選択するために使用することができる。ある実施形態では、エッジ位置に格納されるコンテンツをエンコードするために、ネットワーク・コーディングを使用する。この手法を使用すると、コンテンツ・ファイルの部分（例えば、ビデオ・ムービー・ファイル等の別々の部分）のパーティショニングおよびシーケンシングを回避することができる。ネットワーク・コーディング技法を使用すると、コンテンツ・ファイルを複数のコード化セグメントに分けることができ、これらのコード化セグメントは、シーケンス番号を組み立て直して使用可能ファイルを得る必要がない。代わりに、デコーディングを行わせるためには、エンド・ユーザが、異なるソース位置から十分な数のこのようなコード化セグメントを単に収集するだけでよい。デコーディングを可能にする十分な数の線形独立コード化セグメントが受信される限り、コード化セグメントの実際のソースは関係ない。

[0037] 既に説明したように、ＣＤＮは、通例、エンド・ユーザへのコンテンツ配信を容易にするために、データ・センタを使用する。データ・センタは、効果的なコンテンツ配信のために必要とされる機器の多くを集中させた大型設備である。この機器の集中化は、維持および通信双方のコストを含む、全体的なコストを低減することを可能にする。しかしながら、このような集中化には、それに関連する問題もある。これらの問題は、過剰プロビジョニング、エネルギ消散、およびエンド・ユーザまでの距離に関連する問題を含むことができる。オンライン・サービスを提供する会社はいずれも、規模は関係なく、その業務モデルの肝要な構成要素(component)として、データ・センタに関連するコストを考慮しなければならない。

[0038] 過剰なプロビジョニングは、殆どのデータ・センタが、平均需要ではなく最大需要に合わせるように設計され、必要とされるサーバ数が大幅に増えるという事実に関係する。それらの物理的アーキテクチャ（例えば、大多数の同時に動作するプロセッサ等）のために、データ・センタは大量の望ましくない熱を発生する可能性があり、連続動作を確保するためにはこの熱を除去する必要がある。この熱の除去は、場合によっては、厄介なことになる可能性がある。また、データ・センタは、通例、ネットワークにおけるユーザ位置から遠ざけられている(far removed from)。これらの長距離は、通信のために帯域幅プロビジョニング増加を必要とする可能性があり、更に、ビデオ・ストリーミングのような、逼迫した遅延制限がある用途に対して、問題が生ずる可能性もある。

[0039] 分散型コンテンツ・キャッシング（ＤＣＣ）の使用は、ディジタル・コンテンツ配信を実行するときにデータ・センタに関連する問題の一部を軽減または解消する１つの方法である。先に説明したように、ＤＣＣは、ユーザ位置またはその近くに配置されたエッジまたはゲートウェイ・デバイスにおいて、ユーザに配信されるコンテンツの一部または全部を格納することを伴う。ストレージの価格が常に低下しているので、ゲートウェイは、ディジタル・コンテンツを格納するときに使用するために大量のディジタル・ストレージを装備することができる。また、これらのデバイスには、ある実施形態ではコンテンツ・キャッシングをサポートするために使用することができるあるレベルのディジタル計算パワーも装備することができる。加えて、このようなデバイスは、通例、ブロードバンド・リンクを介してインターネット（または他のネットワーク）に接続され、コンテンツ配信のための小規模なサーバとして機能する能力をこれらのデバイスに与える。あるシステムでは、異なるユーザに関連するゲートウェイ・デバイスは、比較的低いコストで、直接互いに通信すること、または対応するＩＳＰを介して互いに通信することができる。ある実施形態では、この低コスト通信能力は、ピア−ツー−ピア様式で他のゲートウェイにサーブするゲートウェイによって、ＣＤＮにおいてＤＣＣを実現するときに利用することができる。

[0040] 以上で説明した理念を例示するために、高解像度、オンデマンド・ビデオ・サービスをユーザに提供することを望むケーブル会社が直面する課題について考える。他方で、このケーブル会社は、一定のコストでコンテンツをユーザに配信するためにそのＤＣＮを使用することができ、このコストは、リソース要求量（例えば、トラフィック・ボリューム、データ・センタのコスト等）に依存する。代替案として、このケーブル会社は、ＣＤＮ機能の少なくとも一部を委託するために、そのネットワークにおける数千ものゲートウェイのメモリおよび接続(connectivity)を利用することができる。このようにゲートウェイを使用する場合、ケーブル会社は、例えば、ストレージのコスト、ネットワークの通信制限、およびネットワークの信頼性を仮定して、異なるゲートウェイを跨いでコンテンツ・ファイルをどのように配信するか決定しなければならない。既に説明したように、本明細書では、効率的に、価格効率的にゲートウェイ・デバイス間でコンテンツをどのように配信するか決定するために用いることができる技法、システム、およびデバイスについて説明する。

[0041] 図１は、実施形態によるコンテンツ配信ネットワーク（ＣＤＮ）１０を示すブロック図である。図示のように、ＣＤＮ１０は、コンテンツ配信サーバ１２を含む。コンテンツ配信サーバ１２は、インターネット２０または他のネットワークを介したディジタル・コンテンツの複数のユーザ１４ａ〜１４ｎへの配信を管理するために使用される。ディジタル・コンテンツは、要求に応答してエンド・ユーザに配信することができる任意のタイプのコンテンツを含むことができ、例えば、ビデオ・ファイル、オーディオ・ファイル、ソフトウェア・ダウンロード、ストリーミング・メディア、データ・ファイル、テキスト・ファイル、ニュース・コンテンツ、ビデオ・ゲーム、オンライン・ゲーム、および／またはその他を含む。以下に続く説明では、ムービー・オンデマンド型アプリケーションの一部として配信されるムービーのような、ビデオ・ファイルのコンテキストで、種々のコンテンツ配信技法およびシステムについて説明する。しかしながら、説明する技法およびシステムは、他の実現例における他のタイプのディジタル・コンテンツと使用されてもよいことは理解されてしかるべきである。

[0042] 図１に示すように、ＣＤＮ１０に関連するユーザ１４ａ〜１４ｎの各々は、もっと大きなネットワーク（例えば、インターネット２０）へのエントリ・ポイントとして機能する、対応ゲートウェイ・デバイス１６ａ〜１６ｎに結合される。ゲートウェイ・デバイス１６ａ〜１６ｎは、各々、ユーザがもっと大きなネットワークに接続することを可能にする任意のタイプのデバイスを含むことができる。例えば、ゲートウェイ・デバイスは、セット・トップ・ボックス、住居用ゲートウェイ、WiMaxゲートウェイ、セルラ・ゲートウェイ、ケーブル・モデム、ＤＳＬモデム、セルラ通信システムに関連するピコ−セル、ルータ、ゲーム・コンソール、またはストレージおよび所望の用途をサポートするための十分な計算パワーを有する任意の他のデバイス（デスクトップまたはラップトップ・コンピュータのような）を含むことができる。ある実施形態では、ゲートウェイ・デバイス１６ａ〜１６ｎの内１つ以上が、あるレベルのプロトコル、または異種ネットワーク間における信号フォーマット変換を設けてもよいが、これは必須ではない。加えて、ある実施形態では、異なるタイプのゲートウェイ・デバイス１６ａ〜１６ｎが異なるユーザ１４ａ〜１４ｎによって使用されてもよい。ある実施形態では、ＩＳＰ、コンテンツ・プロバイダ、またはＣＤＮ運用会社によってユーザに供給されるゲートウェイ・デバイス１６ａ〜１６ｎが配備されてもよいが、ユーザが所有するおよび／またはユーザが制御するゲートウェイ・デバイス１６ａ〜１６ｎが使用されてもよい。

[0043] 図示する実施形態では、ＣＤＮ１０に関連するユーザ１４ａ〜１４ｎの全てが、共通のインターネット・サービス・プロバイダ（ＩＳＰ）１８を介してインターネット２０に接続する。更に詳しく説明するが、ＩＳＰを共有するユーザにＣＤＮ１０を限定することによって、ゲートウェイ・デバイス１６ａ〜１６ｎ間における比較的低コストの通信を確保することができる。しかしながら、ある実施形態では、複数の異なるプロバイダを介してインターネット（または他のネットワーク）と通信するユーザがＣＤＮ内部に存在してもよい。図１を参照すると、ゲートウェイ・デバイス１６ａ〜１６ｎは、複数の通信リンク２２を介してＩＳＰ１８に結合される。ある実施形態では、ユーザ・ゲートウェイが、仲介するサービス・プロバイダ（即ち、ＩＳＰ等）を必要とせずに、直接もっと大きなネットワークに接続することもできる。

[0044] 図１に示すユーザ１４ａ〜１４ｎは、各々、それらに関連するユーザ機器を有することができ、ユーザ機器は、ユーザがディジタル・コンテンツを要求し、受信し、それらに配信されているディジタル・コンテンツを利用することを可能にする。ユーザ機器は、例えば、コンピュータ、テレビジョン受像機、メディア・プレーヤ、オーディオ・デバイス、および／またはその他を含むことができる。ビデオ・ストリーミングの用途では、例えば、ストリーミング・ビデオ・ファイルを生成することができるユーザ機器が使用されてもよい。加えてまたは代わりに、多くの他のタイプのユーザ機器が使用されてもよい。ある実現例では、ユーザに関連するユーザ機器は、例えば、ローカル・ネットワーキング機器を含んでもよい。例えば、ユーザ１４ａ〜１４ｎの１つ以上が、対応する住居または事務所の建物内部に、ローカル・エリア・ネットワーク（ＬＡＮ）を維持することもできる。ＬＡＮに関連するルータまたはワイヤレス・アクセス・ポイント（ＷＡＮ）が、ＬＡＮをインターネットに接続するために、対応するゲートウェイ・デバイスに接続されてもよい。認められようが、このようなＬＡＮは、複数のユーザにゲートウェイ・デバイスを共有させることができる。

[0045] ある実施形態では、ユーザ１４ａ〜１４ｎが、各々、対応する建物、住居、または他の固定構造体内というような、固定ユーザ位置におけるユーザを表すこともできる。他の実現例では、ユーザ１４ａ〜１４ｎの一部または全部が、移動体ユーザ機器を有する移動体ユーザであってもよい。これらの実現例では、コンテンツをキャッシュするためにローカル・ストレージを含むゲートウェイは、例えば、移動体ユーザのためにネットワークへのアクセスを与えるワイヤレス基地局（例えば、セルラ・システムにおけるセルラ基地局、WiMaxネットワークにおけるWiMax基地局等）を含むことができる。他のある実施形態では、ワイヤレス基地局が中央サーバとして機能してもよく、移動体デバイス自体は、コンテンツをローカルに格納するローカル・ゲートウェイとして機能してもよい。

[0046] ＣＤＮサーバ１２は、とりわけ、ユーザからのディジタル・コンテンツを求める要求を受けて処理するために動作することができる。つまり、ＣＤＮサーバ１２は、例えば、ユーザ１４ｈから、特定のムービーの配信を求める要求を受けることもある。すると、ＣＤＮサーバ１２は、要求されたムービーがＣＤＮ１０内のどこに格納されているか判定し、その位置から要求元ユーザにムービーを配信させることができる。他の実現例では、ゲートウェイ・デバイス１６ａ〜１６ｎ自体が、ユーザからの要求の一部または全部を受け、近隣のゲートウェイ・デバイス内における要求されたムービーの位置を判定し、要求されたムービー・ファイルの要求元ユーザへの配信を容易にすることもできる。あらう実施形態では、１つの要求ファイルを、ＣＤＮ１０内部における複数の異なる格納位置間で分割することもできる。この場合、ＣＤＮサーバ１２および／またはゲートウェイは、ファイルの異なる部分の全部をユーザに配信させることができる。ディジタル・コンテンツを格納するためにネットワーク・コーディングが使用される実現例では、特定のファイルに対応するコード化ファイル・セグメントを、ＣＤＮ１０内部の複数の場所に格納することもできる。このシナリオでは、ＣＤＮサーバ１２またはゲートウェイが、コード化パケットを、種々の異なるソースから要求元ユーザに配信させることができる。ある実現例では、所定数の独立したコード化セグメントがユーザに送られるまで、またはユーザが承認メッセージを送って、デコーディングを行うことを可能にするだけの十分なコード化パケット（即ち、十分な自由度）が受信されたことを示すまで、コード化セグメントの転送が続くことができる。既に説明したように、ある実現例では、種々のゲートウェイ１６ａ〜１６ｎは互いに通信することができる。この通信は、有線でもワイヤレス通信でもよい。ワイヤレス通信がサポートされるとき、この通信はシングル・ホップ通信およびマルチ・ホップ通信の双方を含んでもよい。ある実施形態では、ゲートウェイが互いに、ＩＳＰ１８を介して、または他の何らかの低コストの経路（例えば、インターネット以外の経路）を介して通信してもよい。

[0047] ある実施形態では、要求されたムービー・ファイルが、ゲートウェイ・デバイス１６ａ〜１６ｎの内の１つに格納されていない場合もあり、または現在入手可能でない場合もある。このシナリオでは、ＣＤＮサーバ１２は、要求されたファイルをユーザに、それ自体のローカル・ストレージから、またはＣＤＮ１０に関連する１つ以上のデータ・センタ２６、２８から配信することを決定すればよい。ある実施形態では、中央サーバ１２が、全ての可能なムービー・ファイルを、サーバ位置においてローカルに格納している。ある他の実施形態では、ムービー・ファイルが、中央サーバとは同じ位置にない１つ以上のデータ・センタ内に格納されてもよい。更に他の実施形態では、ムービー・ファイルの一部がサーバ位置に格納され、一部が１つ以上の他の場所に格納されてもよい。要求されたファイルが、ＣＤＮ１０に関連するいずれのソースからも入手可能でない場合、ＣＤＮサーバ１２は要求を拒否することができる。

[0048] 本明細書において説明するある実施形態によれば、ＣＤＮ内部において効率的なデータ・コンテンツ配信を提供するためには、コンテンツをどのようにＣＤＮ内において効率的に配列すべきか決定するための技法およびシステムを提供する。更に具体的には、比較的低コストの動作を生成するためには、どのコンテンツをネットワークの種々のゲートウェイ内部に格納すべきか、ＣＤＮが決定することを可能にする技法を提供する。少なくとも１つの実現例では、ＣＤＮサーバ１２が、効率的および低コストの動作を実行するために、どのゲートウェイ・デバイス１６ａ〜１６ｎ内にどのコンテンツを格納するか決定するように構成されてもよい。尚、この機能は、代わりに、ＣＤＮ１０内部の１つ以上の他の位置において実行されてもよいことは認められてしかるべきである。ある実施形態では、この機能は、ＣＤＮ１０内部の複数の場所において分散形式で実行されてもよい。

[0049] 更に詳しく説明するが、ある実施形態では、コンテンツをＣＤＮ内部に格納することに伴う種々のコストを計る１つ以上のコスト関数を定める。ＣＤＮ内部でコンテンツをどのように配列するか決定するために、コスト関数を最小化するために１つ以上の最適化プログラムを使用することができる。最小のコスト関数に到達するために最適化プロセスの間変化することができる決定変数を定める。次いで、決定変数の最終値は、ＣＤＮ１０のどのゲートウェイ・デバイス内にどのコンテンツを格納すべきか決定するために使用することができる。これより、実施形態にしたがって使用することができる最適化技法の例について説明するときに使用する数学的枠組みについて説明する。

[0050] 最初に、ＣＤＮの複数のシステム変数を定める。システム変数は、例えば、下記を含むことができる。
X = {1, ..., N}: ホーム・ゲートウェイのインデックス集合。ゲートウェイの総数はＮである。

M = {1, ..., M}:ＣＮＤにおいて入手可能なムービー・ファイルのインデックス集合。別々のムービー・ファイルの総数はＭで与えられる。また、各ムービーのインデックスは、ムービーの人気度(rank of popularity)でもある。

y = (y₁, ... , y_M)：ムービー・ファイルの各々のサイズを有するベクトル。行列は、Y= [y, ... , y]のように、ｙを繰り返すことによって形成することができる。
C = {c_1,... ,C_N}: 出立送信に対するゲートウェイｉの送信容量。

P_m,i：ゲートウェイｉにおいてムービーｍに対する需要がある確率。ＰはＭ×Ｎ行列であり、その位置（ｍ,ｉ）におけるエントリは、P_m,iによって与えられる（即ち、行列Ｐのｉ番目の列が、ゲートウェイｉにおける各ムービーを要求する確率を与える）。ある実施形態では、ムービーに対する要求は、Ｚｉｐｆ分布に従うと仮定することができる。これは、ビデオ・ファイルの人気を測定するための正しい近似として定着している（例えば、"I Tube, You Tube, Everybody Tubes: Analyzing the World's Largest User Generated Content Video System"（アイチューブ、ユーチューブ、エブリボディチューブ：世界最大のユーザ生成コンテンツ・ビデオ・システムの分析）、by Cha et al., Proc. of the 7th ACM SIGCOMM Conference on Internet Measurement, ser. IMC '07, New York, NY, USA; ACM, 2007, pp. 1 -14を参照のこと）。具体的には、人気度ｊ（ｊでインデックスされる）ムービーは、

の需要確率を有する。
ここで、γは分布を特徴付ける。γ→０となるに連れて、分布は均一に近づく。特に指定されなければ、ここでは P_m,i は全てのｉに対して同じであると仮定する。

ｃ_ｓ：中央サーバが１単位のコンテンツを任意のゲートウェイに送信するためのコスト。
ｃ_ｇ：任意のゲートウェイにおいて１単位のコンテンツをキャッシュするコスト。

Ｓ_Ｃ：サーバの容量。これは、サーバから全てのユーザに送信することができるコンテンツの最大平均総ボリュームである。
δ_ｓ：サーバ負荷分散の上限。

α：サーバにおける遅延コスト。
[0051] 既に説明したように、図１のＣＤＮ１０におけるユーザの全てが共通ＩＳＰを介してインターネットに接続するので、ＣＤＮ１０内のゲートウェイ間におけるトラフィックは、殆どまたは全くコストがないと仮定することができる。この仮定は、ＩＰＳにおけるコストの殆どがＩＳＰ間トラフィックから発生されるので、ＩＳＰの視点からは実用的である。ゲートウェイ間のトラフィック負荷が容量より低い限り、ＩＳＰのコストは大したことはない。

[0052] 実施形態による最適化プロセス例の決定変数について、以下に説明する。

：ホーム・ゲートウェイｉにおいてキャッシュされた各ムービー・ファイルＭの断片。

：ベクトルx_iの行列。
ａ_i,j,m：ゲートウェイｉにおいてｍを求める要求がある場合における、ゲートウェイｉからゲートウェイｊに対するコンテンツｍの要求。ａ_i,j,mの単位は、コンテンツｍの断片に関する。ファイルｍに対する「接続行列」を指定するために、変数Ａ_ｍを使用することができる。即ち、エントリａ_i,j,mは、ゲートウェイｉがファイルｍを要求した場合における、ユーザｊからゲートウェイｉによって要求されるファイルｍの百分率を表す。

Ｌ_m,i：ゲートウェイｉによってサーバに要求されるファイルｍの断片。ｉ∈χ,ｉ≦ｍ≦Ｍ。対応する行列はＬである。
ｇ_ｉ：ゲートウェイｉ∈χにおいて、Ｍ個のムービーの任意のコンテンツをキャッシュするために使用される記憶空間。

：ｇ_ｉ値のベクトル。
ｓ_ｍ：サーバからのファイルｍの要求の平均総ボリューム。

：ｓ_ｉ値のベクトル。

：中央サーバによってユーザにサーブされるコンテンツの平均総ボリューム。

[0053] 実施形態例にしたがって、以下に、複数の異なる最適化問題の定式化を示す。第１の定式化は、問題の基準線線形プログラム（ＬＰ：linear problem）定式化である。次いで、ＬＰ定式化の上に、非線形制限および目的を追加して、異なるＣＤＮ要求に対する所望の解を生成する（即ち、非線形定式化）。更に詳細に説明するが、定式化の各々において、コスト関数は、種々の制限および条件を決定変数に課しながら、最少化されなければならない。尚、本明細書において説明する技法および戦略は、本明細書において説明する種々の定式化と共に使用することに限定されないことは、認められてしかるべきである。即ち、本明細書において説明するものの機能、結果、または利点の内１つ以上の達成するために、他の定式化を代わりに実行してもよい。

[0054] これより、基準線線形プログラム（ＬＰ）定式化について説明する。少なくとも１つの実施形態では、ＬＰ定式化は、次のように表現することができる。
定式化１（Ｐ１：ＬＰ定式化）

以上において種々の変数が定義された。最適化プロセスによって最少化されるコスト関数は、

である。明白であろうが、この関数は、中央サーバからのコンテンツ配信に関連するコスト項と、ゲートウェイ・デバイスにおけるコンテンツ格納に関連するコスト項とを含む。以上で列挙した種々の制限は、実施形態においてネットワークおよびノードに対して課することができる記憶および送信の制限を取り込む(capture)。これらの制限は、ネットワーキング・デバイスおよびユーザ要求の異なる制限を取り込むように一般化することができ、異なる場合に合わせることができる。最適化プロセスは、このコスト関数を最少化する種々の決定パラメータに対して値を求める。次いで、これらの値を使用して、どのコンテンツをどのゲートウェイに格納すべきか決定することができる。ある実現例では、ゲートウェイの数、各ゲートウェイ背後のユーザに対するムービー要求配信（movie demand distribution）、ファイルの数およびサイズが既知であることを仮定してもよい。つまり、目標は、ネットワークを介したムービー流通(dissemination)のコストを最少化するためにゲートウェイにおける最適な（またはほぼ最適な）キャッシング戦略を発見することである。

[0055] 以上で説明したＬＰ定式化では、サーバ平均負荷容量に強いられる制限はない。これは、この実現例では、ｃ_ｓ・１^Ｔｓを使用する目的関数において、サーバ負荷の使用を抑えれば(penalize)十分であるからである。ＬＰ定式化は、サーバにおける遅延コストを無視する。これは、シナリオによっては、非常に望ましくない場合もある。したがって、変更した定式化では、遅延を考慮するために、コスト関数にペナルティ項を追加してもよい。待ち行列理論から、サーバのサービス遅延は、

として、調整することが知られている。ここで、

は、サーバの負荷係数である。新たな定式化は、次のようになる。
定式化２（Ｐ２、サービス遅延ペナルティ適用）

上の定式化２において示される制限は、定式化１に関して先に説明したものを簡略化したバージョンとなる。以前と同様、これらの制限は、異なる設定およびユーザ要求に合わせることができる。

[0056] 大規模ＣＤＮサーバまたはデータ・センタでは、例えば、システムの安定性および／またはパワー・グリッドの安定性を維持するために、サーバ負荷の変動を制限することが望ましい場合が多い。このような要因を考慮して、サーバ負荷の分散をδsによって制限することができ、ある実施形態による非線形プログラミング（ＮＬＰ）技法を使用して解くことができる。この定式化は、次のように表すことができる。
定式化３（Ｐ３、サーバ負荷分散の制限）

ある実現例では、同じゲートウェイに対して、異なるムービー・ファイルを求める要求は独立であると仮定することができる。その結果、サーバ負荷の分散は、次のように表現することができる。

[0057] ＬＰ定式化から始めて、以上で説明した定式化を解く技法について、これより説明する。１つの解決手法では、ＬＰ定式化を以下の形式の標準的なＬＰ問題に変換するアルゴリズムを実行した。

決定変数の数は、この手法を使用すると、ＮおよびＭと共に急速に増大する。即ち、元の定式化には、近似的にＮ^２Ｍ＋２ＭＮ＋Ｍ＋Ｎ個の変数があり、この問題を標準的な形式に変換するためには、更に２Ｎ^２Ｍ＋ＭＮ＋Ｎ個の遊びの変数を必要とする。その結果、行列Ａは急速に増大し、問題のサイズが増大するに連れて、計算および操作するのが困難になる。

[0058] この問題の基準線ＬＰ定式化は、少なくとも２つの異なるソルバによって、解くことができる。 中点方法(interpoint method) は、対数バリア関数によって比較的小さい問題（Ｎ＝１０およびＮ＝１５、Ｍ＜６０）を解くために、ＬＰに対して使用することができる。もっと大きなサイズの問題には、ＣＶＸソルバを使用することができる（例えば、CVX: Matlab Software for Disciplined Convex Programming（自制凸プログラミング用Matlabソフトウェア）, version 2.0, July 2013, http://cvxr.com/cvx/; および "Graph Implementations for Nonsmooth Convex Programs"（非平滑凸プログラムについてのグラフ実現例）、 by Grant et al., Recent Advances in Learning and Control, ser. Lecture Notes in Control and Information Sciences, Springer Verlag Limited, 2008, pp. 95-1 10, http://www.stanford.edu/~boyd/papers/pdf/graph_dcp.pdfを参照のこと）。これらの問題は、Ｎが１０から４０まで変化しＭが２５から２００までの範囲を取る場合に、解決された。最適化問題に関与する変数の数は、約５，０００から６８０，０００個の範囲である。実際の設定において直面するものと比較すると、これらの例示解のサイズは比較的小さいが、これらの分析したシナリオは、貴重な知見を今後の大規模な実現例に提供することを確信する。

[0059] 図２は、ムービー・ファイルの数が２５から２００まで増えるときの、γ＝０．２５に対する、Ｎの種々の値に対する最適コスト値を示すグラフである。この設定では、各ゲートウェイはランダムに８００および９００メガバイトの間で選択されるが、各ゲートウェイは、ネットワークにおける全ての他のゲートウェイに対して、１つのムービー・サイズの約１／３から１／２のトラフィック・ボリュームをサーブすることを許される。１単位のコンテンツをゲートウェイにおいてキャッシュするコストは、１単位のコンテンツをサーバからサーブするコストよりは遙かに低いことは確実である。予想されるように、最適コストはＮおよびＭ双方の増加関数である。他方では、他のピアにサーブする容量が多いゲートウェイ程、より多いコンテンツが格納される傾向がある。

[0060] 分散の制限があると、この問題は単純な二次プログラムとなる。この問題は、標準的な二次プログラミング技法を使用して解決される。しかしながら、入力行列のサイズのために、比較的小さい寸法の設定のみが検査された。サーバ負荷の分散が厳しく制限されるので、サーバ負荷は急速に減少することが観察される。ゲートウェイにおいてキャッシュされるコンテンツの量が増大し、コンテンツ配信の大部分がピア・ゲートウェイ間で行われるので、この結果は非常に直観的である。

[0061] 少なくとも１つの実施形態では、以上で説明した第２定式化を解くために、一般化された一次方法を使用することができる（即ち、サービス遅延のペナルティがある定式化２）。この問題は凸である(convex)が、目的関数は実現可能な領域内において無限である。１つの手法では、加速一般近似勾配方式を使用することもできる。近似関数は、例えば、標準的なユークリッド・ノルム（自己双対である）を考慮して、平方ノルム（即ち、

）を含むことができる。目的関数の無限性によって発生するかもしれないあらゆる問題を解くために、Ｓ≦０．９５Ｓ_Cと仮定してもよい。尚、このアルゴリズムの初期ポイントはＳ≦０．９５Ｓ_Cを満たさなければならないことを注記しておく。

[0062] 使用される表記を簡略化すると、第２定式化は以下の一般的な形式を有する。

ここで、χは定式化１の実現可能な領域である。尚、以上の目的関数はＰ（Ｓ）＋ｆ（Ｓ）として表現できることを注記しておく。ここで、Ｐ（Ｓ）は線形プログラムの最適値であり、ｆ（Ｓ）は非線形ペナルティである。０≦Ｓ≦０．９５Ｓ_Cと仮定すると、Ｌ＝４００／Ｓ_Cに対して、

となることを注記しておく。
[0063] 勾配降下法方式の繰り返し毎に、標準的な二次プログラムが解かれる。各繰り返しの主要なステップを以下に示す。

以上の問題は、標準的な凸問題であり、任意の凸プログラミング・ツールを使用して解くことができる。一実現例では、速度制限のためにＣＶＸが使用された。図３は、５００回の繰り返しに対する本方法の展開(evolution)の収束を示す。このアルゴリズムは、予想通りに、明らかに最適解に収束する。

[0064] 図４は、Ｓ_Cの異なる値に対する異なるコスト

を示すグラフである。尚、コストは遅延ペナルティを含まないことを注記しておく。明らかに、Ｓ_Cが増大するに連れて、総コストはペナルティ制限がないコストに収束する。更に、サーバ負荷によるコストの成分は、ゲートウェイにおける格納コストの減少よりも低いレートで増大する。これが示すのは、実用的な設計では、遅延に対する重大なペナルティを考慮しても、ゲートウェイにおいて格納要求を委託するときに、サーバが重要な役割を果たすということである。加えて、正当な遅延制限を保証しつつ、最適値からせいぜい１０％であるコストを達成することができる。

[0065] 図５は、実施形態によるＤＣＣを使用するＣＤＮを動作させる方法例１００を示す流れ図である。
[0066] ここでは、矩形エレメント（図５におけるエレメント１０２によって代表される）は「処理ブロック」を示し、コンピュータ・ソフトウェア命令または命令のグループを表すことができる。尚、図５の流れ図は、本明細書において説明した設計の一実施形態例を表し、概要を説明したプロセスに全体的に従うこのような図における変形(variations)は、本明細書において説明し特許請求する概念、システム、および技法の範囲内に該当すると見なすことは、注記してしかるべきである。

[0067] あるいは、処理ブロックは、ディジタル信号プロセッサ回路、特定用途集積回路（ＡＳＩＣ）、またはフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）のような、機能的に等価な回路によって実行される動作を表すこともできる。ある処理ブロックは手動で実行されてもよく、一方他の処理ブロックはプロセッサまたは他の回路によって実行されてもよい。この流れ図は、いずれの特定のプログラミング言語のシンタックスも示さない。むしろ、この流れ図は、当業者が回路を製作するためおよび／または特定の装置の要求される処理を実行するコンピュータ・ソフトウェアを生成するために必要とする機能的情報を示す。尚、ループおよび変数の初期化、ならびに一時的変数の使用というような、決まり切ったプログラム・エレメントは示されない場合もあることは、注記してしかるべきである。本明細書において別段示されない限り、説明する特定のシーケンスは、例示に過ぎず、本明細書において説明および／または特許請求する概念の主旨から逸脱することなく変更できることは、当業者には認められよう。つまり、別段述べられない限り、以下で説明するプロセスは順不問であり、可能であれば、図５に示すシーケンスを任意の便利なまたは望ましい順序で実行できることを意味する。

[0068] 図５の方法１００は、対象のＣＤＮが、コンテンツをキャッシュするために使用する広いディジタル記憶空間を有するユーザ位置またはその近くに配置された複数のゲートウェイを有することを仮定する。これより図５を参照すると、ＣＤＮの構成全体に関係する情報をＣＤＮによって集めることができる（ブロック１０２）。この情報は、例えば、ＣＤＮに関連するネットワーク・ゲートウェイの数および識別についての情報、ＣＤＮに関連するムービー・ファイル（および／または他のタイプのファイル）の数、識別、およびサイズについての情報、ＣＤＮに関連するゲートウェイの送信容量についての情報、サーバの容量についての情報、中央サーバからのコンテンツの配信に関するコスト情報、ゲートウェイにおいてコンテンツをキャッシュすることに関するコスト情報、および／または他の情報を含むことができる。また、ＣＤＮの動作のある統計に関係する情報を集計することもできる（ブロック１０４）。この統計情報の一部または全部が、ＣＤＮにおけるユーザの好みおよび要求に関連する統計に関係してもよい。この情報は、例えば、ＣＤＮに関連する種々のゲートウェイにおけるムービーの需要に関する確率、種々のムービー・ファイルの人気度、１つのゲートウェイにおいて異なるゲートウェイにキャッシュされている特定のムービーを求める要求に関する情報、ムービー・コンテンツをキャッシュするために種々のゲートウェイにおいて使用される記憶空間に関する情報、異なるムービーを求める要求の平均総ボリューム、および／または他の情報を含むこともできる。

[0069] 次に、サーバ・ベースのコンテンツ配信およびゲートウェイ・ベースのコンテンツ配信の双方に関連するコストを考慮に入れる、ＣＤＮ動作についてのコスト関数を最少化することによって、ユーザに対するコンテンツの効率的な配信が得られる結果となるＣＤＮのゲートウェイにおけるコンテンツ・キャッシング戦略を実行することができる（ブロック１０６）。コスト関数最少化プロセスは、通例、１つ以上の決定変数に対して値を生成し、次いでどのコンテンツ項目をどのゲートウェイ内にキャッシュすべきか決定するためにその値を使用することができる。ある実施形態では、コスト関数を最少化するために、１つ以上の周知の最適化技法を使用することもできる。これらの最適化技法は、例えば、一般近似勾配方式、内点法、ならびにＧＵＲＯＢＩおよびＣＶＸのような数値ソルバを含むことができる。かわりに、カスタムの最適化手順を実行してもよい。ある実現例では、本明細書において説明した定式化の内の１つ（即ち、定式化１、２、または３）を、コスト関数に使用することもできる。代わりに、他の定式化を使用してもよい。使用される特定の定式化は、実現されるＣＤＮの具体的な特性に依存してもよい。例えば、サーバ遅延が重大であり得るＣＤＮでは、運用会社は、サーバ遅延ペナルティを含む、前述した定式化２を使用することを決定してもよい。サーバ負荷の分散が問題になり得るＣＤＮでは、運用会社は、サーバ負荷分散に制限を課する定式化３を使用することを決定してもよい。

[0070] 異なる決定変数に対する値を生成した後、これらの値の一部または全部をＣＤＮのゲートウェイに送信することができる（ブロック１０８）。前述のように、決定変数値は、ＣＤＮ（例えば、中央サーバ）が、ゲートウェイ内においてコンテンツをどのようにキャッシュするか決定するために使用される。次いで、キャッシングのために、所望の様態でコンテンツを種々のゲートウェイ・デバイスに配信する（ブロック１１０）。新たなキャッシュ・コンテンツがゲートウェイによって受信されたとき、ある実施形態では、このゲートウェイは、この新たなコンテンツを格納する前に、これまで格納されていたキャッシュ・コンテンツを破棄することができる。ある実施形態では、中央サーバは、現在特定のゲートウェイ内に格納されているコンテンツの内どれを削除すべきか、そしてどの新しいコンテンツを追加すべきか決定し、ゲートウェイにこれを行うように命令することができる。この手法を使用すると、新たなコンテンツだけをゲートウェイに配信すれば済む。

[0071] ある実施形態では、図５の方法１００は、ＣＤＮの寿命の間繰り返し実行されてもよい。例えば、ＣＤＮは、周期的に、連続的に、または決められた時点で方法１００を繰り返すように構成されてもよい。あるいは、または加えて、ＣＤＮは、所定の条件が検出されたときはいつでも、方法１００を繰り返すように構成されてもよい。ある実現例では、ＣＤＮは、運用会社がＣＤＮ内に非効率が存在するかもしれないと感じたときに、運用会社が手動で方法１００を開始できるように構成されてもよい。方法１００の目標は、ＣＤＮのゲートウェイにおいて、ユーザに対する効率的なコンテンツ配信が得られるコンテンツ・キャッシング方式を達成することであればよい。この効率的なコンテンツ配信は、ユーザが高いサービス品質（ＱｏＳ）のコンテンツに適時アクセスすることを可能にすればよい。理想的なのは、ＣＤＮにおけるムービー普及のコストを最少化する最適キャッシング戦略を実行することであるが、最適未満の効率的なキャッシング方式が生成されてもよい。

[0072] １つの手法では、対応するＣＤＮの中央サーバ内において方法１００を主に実行する。しかしながら、複数の位置における分散型実行を含む、他の位置における実行を使用してもよい。ある実施形態では、ネットワークにおいてキャッシュされ送信されるムービー・ファイルはいずれも、既にネットワーク・コード化されていると仮定することもできる。

[0073] 前述のように、ある実施形態では、ＣＤＮ内に格納されるコンテンツをエンコードするために、ネットワーク・コーディングまたは何らかの他のコーディング技法を使用することができる。ユーザが後にコンテンツを要求するとき、ユーザにはコード化されたコンテンツを配信することができ、ユーザは、それを使用する前に、コンテンツをデコードしなければならない。例えば、格納されたムービー・ファイルをエンコードするためにネットワーク・コーディングを使用するＣＤＮでは、各ムービー・ファイルを複数の異なるセグメントに分割することができる。次いで、セグメントの各々にランダム係数を生成することができる。次いで、異なるセグメントの線形組み合わせを、ランダム係数で重み付けして生成し、以下のようにコード化セグメントを形成することができる。

ここで、ａ_ｉはランダム変数、Ｓ_ｉはファイル・セグメント、そしてＮはファイル・セグメントの数である。次いで、同じファイル・セグメントを異なるランダム係数と共に使用して、複数の追加のコード化セグメントを生成することができる。ランダム係数を生成するために、乱数発生器を使用してもよい。コード化セグメントを生成するために使用される実際の係数は、デコーディングにおける最終的な使用のために、各コード化セグメントに添付されてもよい。次いで、コード化セグメントをＣＤＮ内部の種々の位置に格納することができる。尚、ＣＤＮにおいてネットワーク・コーディングを実現するための以上で説明した技法は、ネットワーク・コーディングを使用する１つの可能な方法を表すことは認められてしかるべきである。他の手法も可能である。

[0074] 後にユーザが特定のムービー・ファイルを要求すると、ＣＤＮは、そのムービー・ファイルに対応するコード化パケットを、それらが格納されているいずれかの場所からユーザに配信することができる。重要なのは、セグメントがコード化されているので、セグメントをユーザに配信するときに必要なシーケンシングがないことである。即ち、任意の位置からセグメントを引き出し、シーケンス番号を追跡する必要なく、ユーザに配信することができる。ユーザは、首尾良く一定数のコード化セグメントを受信し、コンテンツをデコードすることができなければならない。必要とされるコード化セグメントの数は、通例、ファイルが最初に分割されたセグメントの数Ｎと同一である。加えて、受信されるコード化セグメントは、デコーディング・プロセスにおいて有用であるためには、互いに線形に独立していなければならない。ランダムに生成される係数の使用は、通例、格納されていた各コード化セグメントが、他のコード化セグメントとは線形に独立する結果になる。デコーディング・プロセスは、通例、Ｎ個の未知数に対するＮ個の線形方程式を解くことを伴う。

[0075] １つの可能な手法では、承認（ＡＣＫ）メッセージをユーザから受信して、十分なセグメントが受信されたことを示すまで、ＣＤＮがコード化セグメントを要求元ユーザに送り続けてもよい。あるいは、ＣＤＮが最初に固定数のコード化セグメント（例えば、Ｎ個以上）をユーザに送り、ユーザが更に必要であることを示す場合にのみ更に送るのでもよい。認められようが、コード化セグメントの配信を管理する他の技法を代わりに使用してもよい。

[0076] Ｎ個のコード化パケットをデコードする必要があるので、ＣＤＮは特定のファイルに対してＮ個よりも多いコード化パケットを生成し格納すればよい。使用されるセグメントの数、およびセグメントのサイズは異なってもよい。以上で説明した方法１００，および同様の方法では、コスト関数を最少化するプロセスは、ＣＤＮに対してキャッシング方式を決定するためにＣＤＮにおけるネットワーク・コーディングの使用、または利用可能性を考慮に入れてもよい。次いで、特定のコンテンツ・ファイルに関連するコード化セグメントをどのゲートウェイがキャッシュするのか識別するキャッシング方式を実行してもよい。尚、ネットワーク・コーディング以外のコーディング方式も他の実現例では使用されてもよいことは認められてしかるべきである。使用してもよい他のコーディング方式には、例えば、リード・ソロモン（ＲＳ）コードおよび他のＭＤＳコードが含まれるが、ランダム線形コードはエンコーディングを一層容易にする。

[0077] 以上の説明では、種々の実施形態例について述べた。尚、開示した主題の主旨および範囲から逸脱することなく、これらの実施形態例には変更および変形がなされてもよいことは、当業者には明白であろう。これらの変更および変形は、添付した請求項の趣旨および範囲(purview and scope)内に入ると見なす。

Claims (24)

1. コンテンツを複数のユーザに配信するコンテンツ配信ネットワーク（ＣＤＮ）における使用のための機械実装方法であって、前記ＣＤＮが、コンテンツ配信サービスを管理する中央サーバと、ユーザ位置に近接して配置され、前記ＣＤＮにおいて配信される前記コンテンツの少なくとも一部をキャッシュするときの使用のためにデータ記憶能力を有する複数のゲートウェイ・デバイスとを有し、前記方法が、
   前記ＣＤＮを記述する情報を収集するステップと、
   ユーザ・コンテンツ要件に対応する前記ＣＤＮの動作の統計を集計するステップと、
   コンテンツ配信に関連するコスト関数を最少化することによって、前記複数のゲートウェイ・デバイスにおいて格納されるコンテンツを決定するステップであって、前記コスト関数が、前記サーバからのコンテンツ配信に関連するコストと、前記ゲートウェイ・デバイスからのコンテンツ配信に関連するコストとを考慮に入れ、前記コンテンツの決定が、前記収集された情報および集計された統計を使用することを含む、ステップと、
   格納するコンテンツを決定した結果にしたがって、前記複数のゲートウェイ・デバイスに、それによってキャッシュされるコンテンツを送るステップと、
   を含む、方法。
2. 請求項１記載の方法において、
   収集する、集計する、決定する、および送るステップが、前記中央サーバにおいて実行される、方法。
3. 請求項１記載の方法であって、更に、
   前記ＣＤＮを効率的に動作させるために、収集する、集計する、決定する、および送るステップを連続的に繰り返すステップを含む、方法。
4. 請求項１記載の方法において、
   前記コスト関数が、前記サーバにおける配信遅延を考慮に入れる項を含む、方法。
5. 請求項１記載の方法において、
   前記コスト関数が、サーバ負荷分散に対する制限を含む、方法。
6. 請求項１記載の方法において、
   前記複数のゲートウェイ・デバイスに格納するコンテンツを決定するステップが、前記コスト関数を最少化するために、一般近似勾配方式、内点法、ならびにＧＵＲＯＢＩおよびＣＶＸのような数値ソルバの最適化手順の内少なくとも１つを使用するステップを含む、方法。
7. 請求項１記載の方法において、
   前記複数のゲートウェイ・デバイスに、それによってキャッシュされるコンテンツを送るステップが、前記コンテンツをインターネットを介して送るステップを含む、方法。
8. 請求項７記載の方法において、
   前記ＣＤＮに関連する前記複数のゲートウェイ・デバイスが、共通インターネット・サービス・プロバイダ（ＩＳＰ）を介してインターネットと通信し、前記中央サーバがインターネットに接続される、方法。
9. 請求項１記載の方法において、
   前記複数のゲートウェイ・デバイスにコンテンツを送るステップが、前記コンテンツの少なくとも一部を、前記中央サーバ位置に配置されていない１つ以上のデータ・センタから前記ゲートウェイ・デバイスに送らせるステップを含む、方法。
10. 請求項１記載の方法において、
    前記複数のゲートウェイ・デバイスにコンテンツを、それによってキャッシュするために送るステップが、ネットワーク・コード化ファイル・セグメントをゲートウェイ・デバイスに送るステップを含む、方法。
11. コンテンツ配信サービスを複数のユーザに提供するコンテンツ配信ネットワーク（ＣＤＮ）であって、
    前記ＣＤＮのためにコンテンツ配信サービスを管理するコンテンツ配信サーバを含み、
    前記コンテンツ配信サーバが、ユーザ位置またはその近くにおいて配備された複数のゲートウェイ・デバイスにおいて、選択されたコンテンツをキャッシュするためのキャッシング方式を前記ＣＤＮのために実行するように構成され、前記キャッシング方式が、コンテンツをユーザに配信するときの効率を高めるためにあり、前記コンテンツ配信サーバが、コンテンツ配信に関連するコスト関数を最少化することによって、前記キャッシング方式を実行するように構成され、前記コスト関数が、前記ゲートウェイ・デバイスからのコンテンツ配信に関連するコストと、前記ＣＤＮの１つ以上の他のコンテンツ記憶位置からのコンテンツ配信に関連するコストとの双方を考慮に入れる、コンテンツ配信ネットワーク。
12. 請求項１１記載のＣＤＮにおいて、
    前記ユーザ位置またはその近くに配備された前記複数のゲートウェイ・デバイスが、前記ＣＤＮの制御下にある、ＣＤＮ。
13. 請求項１１記載のＣＤＮにおいて、
    前記コンテンツ配信サーバが、前記キャッシング方式にしたがって前記複数のゲートウェイ・デバイスにおける個々のゲートウェイ・デバイスにコンテンツを格納のために配信するように構成される、ＣＤＮ。
14. 請求項１１記載のＣＤＮにおいて、
    前記コンテンツ配信サーバが、前記ＣＤＮにおける経時的な変化を考慮に入れるために、前記キャッシング方式を時々更新するように構成される、ＣＤＮ。
15. 請求項１１記載のＣＤＮにおいて、
    前記コンテンツ配信サーバが、前記複数のゲートウェイ・デバイスにインターネットを介して結合される、ＣＤＮ。
16. 請求項１５記載のＣＤＮにおいて、
    前記複数のゲートウェイ・デバイスが、全て共通のインターネット・サービス・プロバイダ（ＩＳＰ）に関連付けられる、ＣＤＮ。
17. 請求項１１記載のＣＤＮにおいて、前記コンテンツ配信サーバが、
    前記ＣＤＮの現在の構成についての情報を収集し、
    ユーザ・コンテンツ要求に対応する前記ＣＤＮの動作の統計を集計し、
    前記ＣＤＮのために前記キャッシング方式を実行するために、前記収集した情報および前記集計した統計を使用する、
    ように構成される、ＣＤＮ。
18. 請求項１１記載のＣＤＮにおいて、
    前記コスト関数が、前記コンテンツ配信サーバが１単位のコンテンツをゲートウェイに送信するコストと、ゲートウェイにおいて１単位のコンテンツをキャッシュするコストとを使用する、ＣＤＮ。
19. 請求項１１記載のＣＤＮにおいて、
    前記コスト関数が、前記サーバにおける配信遅延を考慮に入れる項を含む、ＣＤＮ。
20. 請求項１１記載のＣＤＮにおいて、
    前記コスト関数が、サーバ負荷分散に対する制限を含む、ＣＤＮ。
21. 請求項１１記載のＣＤＮにおいて、
    前記コンテンツ配信サーバが、ネットワーク・コード化コンテンツを、前記複数のゲートウェイ・デバイスに、その中にキャッシュするために配信するように構成される、ＣＤＮ。
22. 命令が格納された１つ以上の非一時的コンピュータ読み取り可能媒体を含む製品であって、計算システムによって前記命令が実行されると、コンテンツを複数のユーザに配信するコンテンツ配信ネットワーク（ＣＤＮ）における使用のための方法を実行し、前記ＣＤＮが、コンテンツ配信サービスを管理する中央サーバと、ユーザ位置に近接して配置され、前記ＣＤＮにおいて配信されるコンテンツの少なくとも一部をキャッシュするときの使用のためにデータ記憶能力を有する複数のゲートウェイ・デバイスとを有し、前記方法が、
    前記ＣＤＮを記述する情報を収集するステップと、
    ユーザ・コンテンツ要件に対応する前記ＣＤＮの動作の統計を集計するステップと、
    コンテンツ配信に関連するコスト関数を最少化することによって、前記複数のゲートウェイ・デバイスにおいて格納されるコンテンツを決定するステップであって、前記コスト関数が、前記サーバからのコンテンツ配信に関連するコストと、前記ゲートウェイ・デバイスからのコンテンツ配信に関連するコストとを考慮に入れ、前記コンテンツの決定が、前記収集された情報および集計された統計を使用することを含む、ステップと、
    格納するコンテンツを決定した結果にしたがって、前記複数のゲートウェイ・デバイスに、それによってキャッシュされるコンテンツを送るステップと、
    を含む、製品。
23. 請求項２２記載の製品において、
    前記コスト関数が、前記サーバにおける配信遅延を考慮に入れる項を含む、製品。
24. 請求項２２記載の製品において、
    前記コスト関数が、サーバ負荷分散に対する制限を含む、製品。

Images