(57)【特許請求の範囲】
【請求項１】
一組のコンテンツ・プロバイダ入口点と、中間層であるセット・リフレクタと、ユーザー端末が要求する公開されたライブ・データ・ストリームを得るために選択的に差し向けられる一組のエッジ・ノードとより成り、エッジ・ノードはライブ・データ・ストリームを要求しているユーザー端末に配信するためのストリーミング・サーバー手段を有する、コンテンツ配信網（ＣＤＮ）において使用されるサブスクリプション機構であって、
（ａ）ユーザー端末が要求するライブ・データ・ストリームを、エッジ・ノードが、要求のあった時点で、既に受信中であるか否かをチェックし、（ｂ）エッジ・ノードが該ライブ・データ・ストリームを既に受信中でなければ、前記エッジ・ノードへの該ライブ・データ・ストリームの配信を要求するサブスクリプション要求を前記エッジ・ノードで作成して、前記エッジ・ノードから少なくとも１つのセット・リフレクタに発送するように、前記エッジ・ノードで作動する手段と、
（ｃ）ユーザー端末が要求する該ライブ・データ・ストリームを前記少なくとも１つのセット・リフレクタが既に受信中であるか否かをチェックし、（ｄ）前記少なくとも１つのセット・リフレクタが該ライブ・データ・ストリームを既に受信中でなければ、該ライブ・データ・ストリームの配信を要求するサブスクリプション要求を前記少なくとも１つのセット・リフレクタで作成して、前記少なくとも１つのセット・リフレクタから所与のコンテンツ・プロバイダ入口点に発送し、（ｅ）前記少なくとも１つのセット・リフレクタが該ライブ・データ・ストリームを既に受信中であれば、前記少なくとも１つのセット・リフレクタから前記エッジ・ノードへ該ライブ・データ・ストリームが配信される経路を指定するべく前記少なくとも１つのセット・リフレクタのコンフィギュレーションを前記エッジ・ノードからの前記サブスクリプション要求に応じて決定するように、前記少なくとも１つのセット・リフレクタで作動する手段と、
（ｆ）前記所与のコンテンツ・プロバイダ入口点から前記少なくとも１つのセット・リフレクタへ該ライブ・データ・ストリームが配信される経路を指定するべく前記所与のコンテンツ・プロバイダ入口点のコンフィギュレーションを前記少なくとも１つのセット・リフレクタからの前記サブスクリプション要求に応じて決定するように、前記所与のコンテンツ・プロバイダ入口点で作動する手段とより成ることを特徴とするコンテンツ配信網
（ＣＤＮ）において使用されるサブスクリプション機構。
【請求項２】
前記エッジ・ノードで作動する前記手段は、一組のエッジ・ノードのうちいずれかのエッジ・ノードが該ライブ・データ・ストリームを既に受信中であれば、該ライブ・データ・ストリームを要求するユーザー端末が差し向けられた他のエッジ・ノードの前記ストリーミング・サーバー手段への該ライブ・データ・ストリームの経路を指定する手段も含む請求項１記載のサブスクリプション機構。
【請求項３】
前記エッジ・ノードで作動する前記手段は、前記サブスクリプション要求を発送すべき好ましい一組のセット・リフレクタを決定するように作動する手段も含む請求項１記載のサブスクリプション機構。
【請求項４】
一組のコンテンツ・プロバイダ入口点と、中間層であるセット・リフレクタと、ユーザー端末が要求する公開されたライブ・データ・ストリームを得るために選択的に差し向けられる一組のエッジ・ノードとより成り、エッジ・ノードはライブ・データ・ストリームを要求しているユーザー端末に配信するためのストリーミング・サーバー手段を有する、コンテンツ配信網（ＣＤＮ）において使用されるサブスクリプション機構であって、
（ａ）ユーザー端末が要求するライブ・データ・ストリームを、エッジ・ノードが、要求のあった時点で、既に受信中であるか否かをチェックし、（ｂ）一組のエッジ・ノードのうちいずれのエッジ・ノードも該ライブ・データ・ストリームを既に受信中でなければ、該ライブ・データ・ストリームの配信を要求するサブスクリプション要求を前記エッジ・ノードで作成して、前記エッジ・ノードから少なくとも１つのセット・リフレクタに発送し、（ｃ）一組のエッジ・ノードのうちいずれかのエッジ・ノードが該ライブ・データ・ストリームを既に受信中であれば、該ライブ・データ・ストリームを要求するユーザー端末が差し向けられた他のエッジ・ノードの前記ストリーミング・サーバー手段への該ライブ・データ・ストリームの経路を指定するように、前記エッジ・ノードで作動する手段と、
（ｄ）ユーザー端末が要求する該ライブ・データ・ストリームを前記少なくとも１つのセット・リフレクタが既に受信中であるか否かをチェックし、（ｅ）前記少なくとも１つのセット・リフレクタが該ライブ・データ・ストリームを既に受信中でなければ、該ライブ・データ・ストリームの配信を要求するサブスクリプション要求を前記少なくとも１つのセット・リフレクタで作成して、前記少なくとも１つのセット・リフレクタから所与のコンテンツ・プロバイダ入口点に発送し、（ｆ）前記少なくとも１つのセット・リフレクタが該ライブ・データ・ストリームを既に受信中であれば、前記少なくとも１つのセット・リフレクタから前記エッジ・ノードへ該ライブ・データ・ストリームが配信される経路を指定するべく前記少なくとも１つのセット・リフレクタのコンフィギュレーションを前記エッジ・ノードからの前記サブスクリプション要求に応じて決定するように、前記セット・リフレクタで作動する手段と、
（ｇ）前記所与のコンテンツ・プロバイダ入口点から前記少なくとも１つのセット・リフレクタへ該ライブ・データ・ストリームが配信される経路を指定するべく前記所与のコンテンツ・プロバイダ入口点のコンフィギュレーションを前記少なくとも１つのセット・リフレクタからの前記サブスクリプション要求に応じて決定するように、前記所与のコンテンツ・プロバイダ入口点で作動する手段とより成ることを特徴とするコンテンツ配信網（ＣＤＮ）において使用されるサブスクリプション機構。
【請求項５】
前記エッジ・ノード、前記セット・リフレクタ及び前記コンテンツ・プロバイダ入口点で作動する前記手段はそれぞれ、経路を指定するＵＤＰパケット・ルータを含む請求項４記載のサブスクリプション機構。
【請求項６】
前記エッジ・ノードで作動する前記手段は、サブスクリプション要求を発送すべき好ましい一組のセット・リフレクタを決定するように作動する手段も含む請求項４記載のサブスクリプション機構。
【発明の詳細な説明】
【０００１】
（技術分野）
本発明は、一般に、コンテンツ配信網（ＣＤＮ）におけるストリーミング・メディアの高速で耐障害性のある配信に関する。
【０００２】
（関連技術の説明）
ストリーミング・メディアは、まだダウンロードしながらの再生が可能であるという重要な特性を有しているインターネット・コンテンツの１型式である。クライアントは、第３パケットを受信しつつ、ストリームの第１パケットを再生し、第２パケットを解凍することが可能である。従って、エンドユーザーは送信の終了を待つことなくマルチメディアを楽しむことが可能である。メディア・ファイルは、プログラムの継続時間が増加すると特に大きくなる傾向があるため、ストリーミングはメディア配信に非常に有用である。実際、ライブ・イベントでは、ファイルのサイズは事実上無限である。ストリーミングされていないメディア・ファイルを見るためには、ユーザーは最初にこのファイルをローカルのハードディスクにダウンロードしなければならず、これには数分かかるかもしれず数時間かかるかもしれない。次いでファイル形式に適合するプレーヤ・ソフトウェアによりファイルをオープンしなければならない。ストリーミング・メディアを見るためには、ユーザーのブラウザがプレーヤ・ソフトウェアを開き、このソフトウェアがファイルを数秒間バッファし、これをダウンロードしつつファイルをプレイする。ソフトウェア・ダウンロードと異なり、ストリーミング・メディア・ファイルはユーザーのハードディスクのローカルには記憶されない。コンテンツを表現するビットがひとたび使用されると、プレーヤは通常これを廃棄する。
【０００３】
ストリーミング・メディア品質は、配信されるメディアの型式、ユーザーのインターネット接続速度、ネットワーク条件、コンテンツをコード化するときのビットレート、使用するフォーマットに従って様々である。一般に、ストリーミング・オーディオはＦＭの品質であるが、通常の制限された帯域幅では、ストリーミング・ビデオはＴＶの標準規格より劣っており、画面は小さく、解像度は低く、秒当たりのフレーム数は少ない。ストリーミング・メディアのソースは、ＶＨＳまたはベータ形式のテープ、音声カセット、ＤＡＴ、ＭＰＥＧビデオ、ＭＰ３音声、ＡＶＩ等を含む、任意の形式のメディアが可能である。ストリーミングの前に、コンテンツは最初にコード化されなければならないが、この過程では、必要に応じて、アナログからディジタル形式へのコンテンツの変換、ストリーミング・メディア・サーバーとプレーヤにより認識される形式でのファイルの作成、実時間の所与の限定された帯域で配信可能なコンテンツの豊富度を最大化するためのファイルの圧縮、メディアを配信するビットレートの確立の４段階を実行する。高速接続のユーザーが可能な限り良好な体験を得られるように、かつ低速接続のユーザーもコンテンツをアクセス可能なように、コンテンツ所有者は通常複数のレートでメディアをコード化する。
【０００４】
非ストリーミング・コンテンツは、アパッチ・サーバー、マイクロソフト・インターネット・エクスプローラ、ネットスケープ・コミュニケータ等のような、異なるベンダにより開発されたサーバーとクライアント・ソフトウェアが一般的に互いにうまく動作すると言う意味で、規格に基づいている。しかしながら、ストリーミング・メディアは、独自のサーバーとクライアント・ソフトウェアに通常依存している。ストリーミング・ソフトウェア・ベンダにより開発されたサーバー、クライアント、製品、コード化ツールは一括してフォーマットと呼ばれる。特定のフォーマットによりコード化されたストリーミング・メディアはその形式のメディア・サーバーにより提供され、その形式のクライアントにより再生されなければならない。ストリーミング・メディア・クライアントはしばしばプレーヤと呼ばれ、通常のウェブブラウザへのプラグインとして存在する。ストリーミング・メディア・クライアントは、ＷＡＶまたはＡＶＩのような、規格に基づいた非ストリーミング・メディアをしばしば再生可能である。
【０００５】
現在使用されている３つの主要なストリーミング・メディア・フォーマットは：リアルネットワークのリアルシステムＧ２（ＲｅａｌＮｅｔｗｏｒｋｓ ＲｅａｌＳｙｓｔｅｍ Ｇ２（登録商標））、マイクロソフトのウィンドウズ・メディア・テクノロジ（「ＷＭＴ」）、及びアップルのクイックタイムである。リアルシステムＧ２は、音声、ビデオ、アニメーション、さらに静止画とテキストを含む全てのメディアを処理する。リアルシステムＧ２とクイックタイム（登録商標）は、コンテンツ・プロバイダがプレーヤのウィンドウ内でメディアを調時し位置決めすることを可能とするＸＭＬベースの言語であるＳＭＩＬをサポートする。メディアを実時間で配信するため、リアルとクイックタイムはＲＴＳＰを使用する。ＷＭＴのアドバンスト・ストリーミング・フォーマットでストリーミングするためには、コンテンツ・プロバイダは通常マイクロソフトＮＴ４サーバーをインストールしなければならない。ＷＭＴはＳＭＩＬまたはＲＴＳＰをサポートしないが、ＨＴＭＬ＋Ｔｉｍｅと呼ぶ独自のプロトコルを有する。アップルのクイックタイムは最近ストリーミング・メディアを提供する機能を追加した。クイックタイムはＶＲ、３Ｄ、Ｆｌａｓｈ、ＭＰ３を含む多数のフォーマットをサポート可能である。
【０００６】
コンテンツ配信網（ＣＤＮ）を使用してストリーミング・メディアを配信することは公知である。ＣＤＮは、第３者のコンテンツ・プロバイダに代わってディジタル・コンテンツ（例えば、ウェブ・コンテンツ、ストリーミング・メディア及びアプリケーション）を効率的に配信するために地理的に分散配置されたコンテンツ配信ノードの自己編成網である。所与のコンテンツを要求するエンドユーザーからの要求は、「最良の」複製に差し向けられが、ここで「最良」とは、コンテンツ・プロバイダの元のサーバーから持ってくるのにかかる時間と比較して、クライアントに迅速にアイテムをサービス出来ることを通常意味する。
【０００７】
通常、ＣＤＮは、コンテンツ配信インフラ、要求を経路設定する機構、及び分配インフラの組み合わせとして構築される。コンテンツ配信インフラは、要求エンドユーザーにコンテンツの複製を配信するため戦略的な位置（例えば、インターネット網アクセスポイント、インターネット・ポップ等）に配置した一組の「代理の（ｓｕｒｒｏｇａｔｅ）」配信元サーバーを通常含む。要求を経路設定する機構は、ウェブ・コンテンツ配信に対しては特定のクライアントの応答時間を最小とするように、ストリーミング・メディア配信に対しては最高品質を提供するように、要求クライアントにコンテンツ配信インフラ中のサーバーを割当てる。分配インフラは、配信元サーバーから代理サーバーへコンテンツを移動するオンデマンドまたはプッシュ式機構から構成される。効率的なＣＤＮは、頻繁にアクセスされるコンテンツを最適な代理サーバーから所与の要求クライアントに提供する。通常のＣＤＮでは、単一のサービスプロバイダが要求ルータ、代理サーバー及びコンテンツ・ディストリビュータを操作する。さらに、このサービスプロバイダはコンテンツ発行者とビジネス関係を設立し、その配信元サーバーサイトの代わりに分散配信システムを提供する。ウェブ・コンテンツとメディア・ストリーミングを提供する公知の商用ＣＤＮサービスは、マサチューセッツ州ケンブリッジのアカマイ・テクノロジ社により提供される。
【０００８】
ＣＤＮは、コンテンツ・プロバイダのコンテンツを配信するべくタグ付けするためにコンテンツ変更を行なう。コンテンツ変更は、特別のスイッチング装置またはディレクトリ・サービスを必要とせずに要求クライアントと配信元サーバーとの間の要求の経路設定をコンテンツ・プロバイダが直接制御することを可能とする。通常、コンテンツ・オブジェクトは、別の、埋め込みコンテンツ・オブジェクトの参照を含む基本構造から構成される。例えば、大部分のウェブページは、単純なテキストと共に．ｇｉｆまたは．ｊｐｇ画像のようないくつかの埋め込みオブジェクトを含むＨＴＭＬ文書から構成される。埋め込みオブジェクトは埋め込みＨＴＭＬ指示を使用して参照される。例えば、ＳＭＩＬ文書内に埋め込まれたいくつかの型式のストリーミング・コンテンツに対しても同様の方式が使用される。埋め込みＨＴＭＬまたはＳＭＩＬ指示は配信元サーバーから埋め込みオブジェクトをフェッチするようにクライアントに指示する。ＣＤＮコンテンツ変更方式を使用して、コンテンツ・プロバイダは、最良の代理サーバーから（配信元サーバーの代わりに）埋め込みオブジェクトをフェッチするようクライアントに指示するように埋め込みオブジェクトへの参照を変更可能である。
【０００９】
動作時に、ＣＤＮから提供中のオブジェクトに対してクライアントが要求すると、エッジにある最適のまたは「最良の」コンテンツ・サーバーが同定される。クライアントのブラウザはそのサーバーからのコンテンツに対して要求を出す。要求されたオブジェクトがその同定サーバーから手に入らない時は、オブジェクトは他のＣＤＮコンテンツ・サーバーから入手するが、これに失敗した時は、配信元サーバーから入手する。
【００１０】
（発明の要約）
リフレクタ網をコンテンツ配信網（ＣＤＮ）と関連して使用することにより、要求エンドユーザーはＣＤＮ入口点へ公開されたライブ・ストリームの配信を受けることが出来る。リフレクタは一般化されたパケット・ルータ・プログラムである。リフレクタ網はリフレクタの階層構造、すなわち、ＣＤＮへの各入口点に配置した少なくとも１つのリフレクタと、ライブ・ストリームを得るためにＣＤＮが要求ユーザーを差し向ける各エッジ・ノードのリフレクタと、入口点とエッジ・ノードとの間の（階層内の）少なくとも１つの中間層に位置する各種の「リフレクタ」ノードのリフレクタと、を含むことが望ましい。中間層は、高度な要求があるストリームの配信を容易にするために有用である。エッジ・ノードと各リフレクタ・ノードはまた供給（ｆｅｅｄ）を段取りするマネージャ・プログラムを含む。エンドユーザーが未だ所要のストリームを受信していないエッジ・ノードに差し向けられた時、エッジ・ノードのマネージャは一組のリフレクタ・ノードにサブスクリプション要求を発送する。リフレクタ・ノードが既に所要ストリームを受信している場合、リフレクタはこれを要求エッジ・ノードに送信し始める。しかしながら、リフレクタ・ノードが未だ所要ストリームを受信していない場合、そのマネージャ・プログラムはサブスクリプション要求を階層上位に発送し、最終的に入口点に到達させて供給を開始させる。
【００１１】
以上に本発明の重要な特徴のいくつかを概観した。これらの特徴は単に例示的なものであることを認識すべきである。開示発明を異なる方法で適用することによりまたは以下で説明するように本発明を変更することにより、多数のその他の利点が達成可能である。従って、本発明のその他の特徴と完全な理解は、以下の望ましい実施例の詳細な説明を参照することにより得られる。
【００１２】
（望ましい実施例の詳細な説明）
図１は、本発明のコンテンツ配信サービスの実施例を示す線図である。本発明はその他の既知の、または以後設計されたまたは構築されたコンテンツ配信サービスまたはシステムで同様に実施可能である。図示実施例では、コンテンツ配信サービスは、コンテンツ配信サービス領域１０２ａ−ｎの望ましくはグローバル・コンテンツ配信網（ＣＤＮ）１００、ドメインネーム・サービス（ＤＮＳ）システム１０４、コンテンツをタグを付することを可能とするコンテンツ変更すなわち「イニシエータ」ツール１０６を含む。ＤＮＳシステム１０４はマップメーカ１０７から網マッピングデータを受取り、このマップメーカはインターネット上に分散されている監視エージェント１０９から入力信号を受取る。エージェントは通常各種のテストを実施し、トラヒック状態を監視してインターネット輻輳の問題の存否を識別する。マップメーカ１０７はエージェントからデータを受け取ってインターネット・トラヒック状態の詳細を示す１つ以上のマップを発生する。一般に、コンテンツ配信サービスはコンテンツ配信サーバー領域１０２ａ−ｎの網が多数のクライアントを効率的にサービスすることを可能とする。各領域は１つ以上のコンテンツ・サーバーを含み、複数のコンテンツ・サーバーは通常ローカルエリア・ネットワーク（ＬＡＮ）バックボーンを共有する。限定する意図はないが、通常のサーバーは、大量のＲＡＭとディスク記憶を有するＬｉｎｕｘオペレーティングシステムを実行するインテルのペンティアム（登録商標）ベースのキャッシング装置である。これも図１に示すように、コンテンツ配信サービスは、重要なプロセスが動作していること、システムが容量を超えていないこと、コンテンツ・サーバーのサブセット（いわゆるＣＤＮ領域１０２）が正しく相互作用していることを保証するため網を監視する網動作制御センター（ＮＯＣＣ）１１２を含んでもよい。コンテンツ・プロバイダは、要求エンドユーザーがインターネットを経由してそこからコンテンツ・プロバイダのウェブサイトを通常アクセスする配信元サーバー（またはサーバー・ファーム）１１５を操作する。ＣＤＮの使用は、以下で説明するように選択されたコンテンツについてはインターネットを介する転送を回避させる。コンテンツ・プロバイダは、顧客データの実時間及び履歴解析用のツールを含む監視スイート１１４へのアクセスも有してよい。あるツールは、網と顧客固有のトラヒック情報への迅速なアクセスを可能とする複数監視ビューを提供するトラヒック・アナライザである。リポータは履歴データの閲覧を可能とする。課金ツールを使用して、ＣＤＮにより配信されたコンテンツの量の関数としてサービスに通常支払う、コンテンツ・プロバイダへの適切な課金情報を生成する。
【００１３】
高性能コンテンツ配信は、ウェブ・オブジェクト（例えば、グラフィック、画像、ストリーミング・メディア、ＨＴＭＬ等）への要求をコンテンツ配信サービス網へ差し向けることにより行なわれる。アカマイ・フリーフロー（Ａｋａｍａｉ ＦｒｅｅＦｌｏｗ）コンテンツ配信として知られる、ある既知の技術では、コンテンツは最初に、例えばコンテンツ・プロバイダのウェブ・サイト１１５でコンテンツ・プロバイダにより実行されるツール１０６により配信用にタグ付けされる。ストリーミング・コンテンツに対しては、イニシエータ・ツール１０６がストリーミング・コンテンツを参照するＵＲＬを、便宜上ＡＲＬと呼ばれる変更リソース・ロケータに変換するため、前記メディアへの要求は配信元サーバーの代わりにＣＤＮから優先的にサービスされる。例えば、ツールは、各ストリーミングＵＲＬの前にＣＤＮドメインを含む文字列を、そしてオプションとして追加制御情報を付加する。例えば、ＵＲＬ ｒｔｓｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／ｍｏｖｉｅ／ｍｏｖに対しては、対応するＡＲＬは以下の通りとなる：
ライブまたはブロードキャスト：
0004723170.tif 000002
オンデマンドのビデオまたは音声：
0004723170.tif 000003
【００１４】
もちろん、上記フォーマットは単なる例示である。インターネット・ユーザーがＣＤＮ顧客サイト（例えば、配信元サーバー１１５）を訪れてリンクを選択してストリーミング・メディアを見たり聞いたりする時、ユーザーのシステムがＡＲＬのドメインをＩＰアドレスに変換する。特に、コンテンツはＣＤＮにより配信用にタグ付けされているため、ユーザーに対して透過的なＵＲＬ変更はインターネットの標準であるドメインネーム・サービス（ＤＮＳ）をキューに入れ、ＣＤＮネームサーバー（またはネームサーバーの階層）１０４に問い合わせして、ストリームを入手する適切なメディア・サーバーを同定する。ＣＤＮは通常、要求の経路設定機構（例えば、監視エージェント１０９とマップメーカ１０７から発生されたマップの制御下で）により、所与の時間に各ユーザーにとって最適のサーバーを同定する。各ユーザーは、望ましくは実時間のインターネット条件を基づき最適のストリーミング・サーバーからサービスされるため、ストリーミング・メディア・コンテンツは確実に、かつ最小のパケット損失で、従って最高の品質で提供される。望ましいＤＮＳベースの要求経路設定機構のこれ以上の詳細は米国特許第６、１０８、７０３号に記載され、これは引用により本明細書に含まれる。
【００１５】
これも引用により本明細書に含まれるが、共願の米国特許出願第０９/４７８，５７１号に記載されているように、ライブ・ストリーミングは、ＣＤＮ入口点からインターネットのエッジの最適ストリーミング・サーバーへ異なるルートを介して同一ストリームの複数コピーをＣＤＮに送信させることによりさらに拡張可能である。これらのコピーは次いで組み合わされて１つの完全な元の品質のストリームを形成し、これがストリーミング・サーバーからエンドユーザーに送信される。図２はこの過程をより詳細に図示している。ブロードキャスト・ストリーム２００がＣＤＮ入口点２０２へ送信される。例えば、入口点は２台のサーバー（冗長用）を含み、各サーバーは複数のコンテンツ・プロバイダからの多数のストリームを処理可能である。入口点が一旦ストリームを受信すると、これはストリームのコピーをセット・リフレクタ２０４ａ−ｎへ再ブロードキャストする。ストリームは望ましくはＵＤＰ（例えば、ＩＰ上でＵＤＰにカプセル化されたＲＴＳＰにカプセル化されたＷＭＴ）を介してセット・リフレクタへ多重化され配信される。これらのセット・リフレクタは耐障害性を保証するために網と地理的観点から分散されることが望ましい（例えば、分散されたインターネット・バックボーンのデータセンターに）。各セット・リフレクタは、次いで、そのストリームのコピーを一組の領域２０６ａ−ｎのうちの各配信領域、例えば２０６ｄへ再ブロードキャストする。配信領域２０６ｄは、ＣＤＮの要求経路設定機構によりユーザーが経路設定された１つ以上のストリーミング・エッジ・ノード２０８ａ−ｎを含むＣＤＮ領域である。言い換えると、セット・リフレクタはそのストリームを必要とされる各エッジ領域へ送信する。この例では、ＣＤＮ領域は、共通のバックボーン２０９、例えばローカルエリア・ネットワーク（ＬＡＮ）により接続された一組のエッジ・ノードを含む。通常、エッジ・ノード、例えばノード２０８ｄはストリーミング・サーバー２１２を含み、またキャッシュ２１０を含んでもよい。代表的なサーバーはインテルのプロセッサ、リナックスのオペレーティングシステム及びリアルメディアまたはクイックタイム・サーバーを実行する。ウィンドウズ・ベースのプラットフォームでは、代表的なサーバーはインテルのプロセッサ、ウィンドウズＮＴ（登録商標）またはウィンドウズ２０００（登録商標）、及びウィンドウズ・メディア・サーバーを実行する。以下で説明するように、エッジ・ノードはまた制御プログラム２１４も実行して本発明のサブスクリプション機構を実現する。
【００１６】
次いで、各配信領域はストリーミングされたコンテンツの複数コピーを同時に受信する。これらのコピーはインターネット上の別々のルートを介して送信されたものであるため、従ってパケットの欠落を発生させる輻輳がストリームの各コピーに同様な影響を与えることは考えられない。共願の出願番号第０９／４７８、５７１号に記載されているように、各領域は入口点へ送信されたストリームの元のヴァージョンを実時間で再作成する機構を有することが望ましい。この方法で、本技術が本質的に不完全なインターネットと本質的に損失のあるＵＤＰトランスポート・プロトコルとを補償する。各領域内の再組み立て機構は元の全く同一なストリームを領域内の全ストリーミング・メディア・サーバーが入手可能にする。ユーザーがＣＤＮタグのストリームをクリックすると、ＣＤＮの要求経路設定機構により同定された最適エッジ・ノード（及び、特にそのノードのストリーミング・メディア・サーバー）からそのストリームが配信される。ＣＤＮが、そのブロードキャストされたストリームが配信されていない領域のノードにユーザーを差し向けた場合（例えば、その領域からサービスされる最初の接続）、その領域は、以下で説明するように、セット・リフレクタに自動的に通知して、本発明を使用してそのストリームの配信を受ける。
【００１７】
本発明のサブスクリプション機構は、相対的に保守と配置が容易な、一組の一般化されたモジュラー・プログラムを含むことが望ましい。これは「ライブ」ストリーミングに使用することが望ましい。これは、多かれ少なかれ実時間で操作されることを意図しているデータを担持しているデータ・ストリームを意味する。ビデオ・オンデマンド（ＶＯＤ）は任意の点で操作可能なデータである。例えば、ＴＶ局はライブで、ビデオテープはＶＯＤである。ビデオテープまたはＶＯＤはそれがライブであるかのようにブロードキャストまたはストリーミング可能であるため、何らかのオーバーラップはある。ここで使用するように、「ライブ」はこれら両方の使用を包含する。
【００１８】
ここで図３を参照すると、リフレクタと呼ばれる主プログラムは、基本的にはＵＤＰパケットのアプリケーション・レベル・ルータである、汎用パケット移動エンジンである。リフレクタはユニキャスト、マルチキャスト、またはブロードキャストを使用してパケットを移動する。また、リフレクタ・プログラムは特定のストリームを特定の場所へ条件的に送信する。リフレクタは、静的なコンフィグレーションファイルを介して、または本発明によると、網上のサブスクリプションメッセージを介してコンフィグレーションを知ることによりこれを実行するよう構成可能である。図３から分かるように、入口点３００はリフレクタ・プログラム３０２ａを含み、各セット・リフレクタ・マシン３０４はリフレクタ・プログラム３０２ｂを含み、各エッジ・ノード３０６はリフレクタ・プログラム３０２ｃを含む。エッジ・ノード３０６はまた以前に説明したようにストリーミング・メディア・サーバー３０５も含む。入口点３００もまたストリーミング・メディア・サーバーを実行する。
【００１９】
このように、望ましい実施例では、リフレクタ・プログラムは、最上層の入口点、中間層のセット・リフレクタ、及び下層レベルの１つ以上のエッジ・ノードの領域を含むストリーミング網階層の３つの異なる層で実行する。追加のセット・リフレクタ層もまたスケーラビリティのために実装可能である。一般に、リフレクタ・プログラムは以下のように「リスナ（ｌｉｓｔｅｎｅｒ）」方法と「目的地（ｄｅｓｔｉｎａｔｉｏｎ）」方法とを使用して動作する。リスナはこれらの型式の１つである：
リスナ型式
ＲＴＰ−実時間プロトコル
ＲＦＣ１８８９による実時間プロトコル。リフレクタに関しては、パケット一連番号を使用して統計を保持すること以外、これはデータの任意のチャンク（ＮＯＯＰと同様）として処理される。このリスナ型式は、規格準拠であるアップルのクイックタイムで使用される。
ＮＯＯＰ−演算なし
パケットを移動するだけで、内部の任意の情報に作用しない。これは統計を除いてはＲＴＰと基本的に同じである。ＮＯＯＰは一連番号が無いため、消失、順序異常、または複製パケットの統計を取る手段がない。これはパケット内部でアプリケーションがそれ自身の一連番号を提供することを妨げない。このリスナ型式はＷＭＳで使用される。
ＭＵＭ−マルチプレックス
これはＭＵＸ目的地（以下を参照）により発生されるパケット型式である。これはＲＴＰまたはＮＯＯＰ型式のどちらかのパケットを含む。
【００２０】
代表的な実施例では、リスニング・ポート当り１つのＲＴＰと１つのＮＯＯＰリスナとがある。このポート範囲はコンフィグレーションファイルで指定される。ＭＵＸリスナは常に専用ポート、例えばポート１４５５で待ち受けている。待ち受けている特定のアドレスは、ユニキャスト、マルチキャスト、またはブロードキャストである。一般に、階層の入口点はＲＴＰ及び／またはＮＯＯＰリスナを有し、一方セット・リフレクタはＭＵＸリスナを有する。
目的地は以下の型式の１つである：
目的地型式
ＮＯＯＰ−演算なし
以前と同様に、パケットを移動するだけで、内部の情報には作用しない。
ＭＵＸ−マルチプレックス
任意の型式のデータを取り、これをマルチプレックス化した「メガストリーム」で送信する。
ＤＥＭＵＸ−デマルチプレックス
マルチプレックス化パケットを取り（ＭＵＸ目的地により発生）、配信元のＲＴＰまたはＮＯＯＰパケットをこれから再構成する。
ＳＭＡＲＴＤＥＭＵＸ−（更に）インテリジェントにデマルチプレックス
これは、ローカル・サーバーからのサブスクリプションリスト（ポート情報ライブラリ）を参照して現在受信している供給の一部分である場合にパケットのみを送信する点を除いては、ＤＥＭＵＸと同じである。これはエッジ・ノードでの高性能を可能とする。
【００２１】
一般に、複数入力ストリーム（リスナを通して受信）は特定の目的地への送信用に単一のメガストリームに組合される。例えば、２つの別々なＲＴＰポートに２つのＲＴＰリスナがいる場合、これらは単一の目的地への転送用に単一のマルチプレックス化メガストリームに組合わせてもよい。ＲＴＰ目的地型式がないことに注意されたい。代わりに、ＮＯＯＰを使用して、パケットに処理をしてはならないことを指示する。便宜上、リフレクタはＲＴＰを目的地として受け入れ、代わりに、ＮＯＯＰを内部的に使用する。
【００２２】
リフレクタが、動的に作動し、かつ（コンフィグレーションファイルからではなく）網からコンフィグレーションを知ることができるようにするため、本発明はサブスクリプション）機能を実行する。望ましい実施例では、サブスクリプションはデータの意図したレシーバからセンダへ流れ、従ってレシーバはセンダの「目的地」コンフィグレーションを制御する。サブスクリプションを使用するため、メッセージがリフレクタに送信され、このリストは受信者が望むポートのリストを含む。リフレクタが既にその特定の目的地へ供給を開始している場合、これはサブスクリプションメッセージに対応するよう変更される。しかしながら、リフレクタがその特定の目的地へ供給を開始していない場合、新たな目的地が追加される。リフレクタは、オプションとして、サブスクリプションのソース・アドレスを新たな目的地アドレスとして使用するか、またはこれが不可能な状況（マルチキャストまたはブロードキャスト・アドレス、または単に加入者にとってローカルでないアドレス）では、リフレクタは目的地としてどのアドレスを使用すべきかを告げることが可能である。リフレクタを「鎖状」に繋ぐため、リフレクタ・プログラムは自己サーバー・モードで動作可能である。これはリフレクタをそれ自身のサーバーとして動作させ、リフレクタが供給用のサブスクリプションを得た時に、それが、今度は、それ自身で配信を受信する。この機能はセット・リフレクタで使用されて、以下で説明するようにサブスクリプションを入口点まで次々に転送する。図示実施例では、サブスクリプションメッセージは、例えば、適切な認証キーを組み込んだシステムからのみサブスクリプションメッセージを受入れることを保証する暗号署名システムを使用して認証される。
【００２３】
各セット・リフレクタ３０４と各エッジ・サーバー３０６はサブマネージャ・プログラム３０８も含むことが望ましい。従って、例えば、セット・リフレクタ３０４はサブマネージャ・プログラム３０８ａを含み、一方エッジ・サーバー３０６はサブマネージャ・プログラム３０８ｂを含む。サブマネージャは供給を手配するツールである。一般に、サブマネージャは同一マシン上で実行するサーバーを聞いていて、これは要求を使用してサブスクリプションメッセージをリフレクタへ（階層上のより高位へ）送信して供給を開始する。サブマネージャは高利用度を保証するよう動作する。サブマネージャ単独でまたはクラスタで使用してもよく、通常複数エッジ・サーバーを有するＣＤＮ領域内のコンフィグレーションである。クラスタで使用する時、サブマネージャは以下の「リーダー」アルゴリズムを実装する。
リーダー・アルゴリズム
１．全ての他のサブマネージャにローカルサブスクリプションリストをアナウンスし、領域中の他のサブマネージャからのリストを聞き取る。
２．領域中の他のサブマネージャから受信したリストを共にマージする。
３．以下に従って何人か（例えば３人）のリーダーを選出する：
ＩＰアドレスにより応答のリストをソートする
特定期間（例えば、２０秒）聞かれなかったマシンを除去する
先頭の３人を取る
４．全てのリーダーは領域の供給をオンとするためサブスクリプションメッセージを送信する。
結果として、各領域に入来する３つの供給がある。
単独で使用する時、このリーダー・アルゴリズムは使用されない。代わりに、ローカル・サーバーにより要求された各ポートについて単純なサブスクリプションの送信が行われる。クラスタで使用する時、リーダー選出アルゴリズムを使用して故障マシンを除去する。マシンが故障した場合、これはマシンのリストから消え去る。リーダーが故障した場合、リスト上のその後から来る全てのマシンが１段階昇進する。これは領域中の全てのサーバーへの良好なサービスを保証する助けとなる。
【００２４】
限定する意図ではないが、サブマネージャが特定のポートへのサブスクリプションに何をなすべきか決定する場合２つの方法があることが望ましい。
ＤＮＳ
ＤＮＳシステムを使用する時、サブマネージャは形式：ｎリーダー番号．ｒ領域番号．ｒｅｆ．ａｋａｍａｉ．ｃｏｍのアドレスを検索しようとする。（例えば、領域５のリーダー２はｎ２．ｒ５．ｒｅｆ．ａｋａｍａｉ．ｃｏｍを検索する。）全てのサブスクリプションはこのアドレスに送信される。これはサブマネージャが最良のセット・リフレクタに動的にマップされることを可能とするため、エッジ・リフレクタとセット・リフレクタとの間で使用されることが望ましい方法である。
ポートテーブル
ポートテーブル構造はメモリに（そして例えばポートリスンにより分布されて）組み込まれる。このテーブルはポート当りのＩＰアドレスを含み、従って各供給は単一ポート粒状性（ｇｒａｎｕｌａｒｉｔｙ）により異なるソースから来ることが可能である。これはセット・リフレクタと入口点との間で使用される方法である。
【００２５】
ここで図３に戻ると、各入口点３００は、リフレクタの入力を監視し、セット・リフレクタ上で実行する対応するポートリスン機能３１２へこのリフレクタを通して利用可能な全てのポートをアナウンスするポートアナウンス機能３１０（これはリフレクタ・プロセス内の別なプログラムまたはスレッドでよい）も含むことが望ましい。ポートリスン機能３１２は各種のポートアナウンス機能３１０（入口点）からのメッセージを待ち受けし、サブスクリプションプロセスで使用するためサブマネージャ・プログラムにポートテーブルを構築する。ポート情報ライブラリ３１４は、エッジ・サーバー・プラットフォーム上で実行する任意のストリーミング・メディア・サーバー・プログラムにリンク可能なライブラリである。これは、サブマネージャがサブスクリプションを設定可能なように、サーバーが望むポートのリストをサブマネージャ（エッジ・サーバー・プラットフォーム上で実行）に提供するために使用される。ルートマスタ・プログラム３１６はリフレクタと通信し、どのストリームがどこで必要とされるかを学習する。必要に応じて、ストリームの品質、特定の経路のコスト等を元にシステムを最良に最適化するためいかにストリームを経路設定するかについて実時間決定を行う。
【００２６】
従って、図示実施例では、入口点はリフレクタとポートアナウンスを実行し、各セット・リフレクタはリフレクタ、ポートリスン及びサブマネージャを実行し、各エッジ・サーバー・プラットフォームはリフレクタ、サブマネージャ、及びポート情報ライブラリを使用するストリーミング・サーバーを実行する。多数のリフレクタをインターネット内の戦略的な場所に配置して入口点を作成することが望ましい。ゴールはコンテンツ・プロバイダの近傍に入口点を有することである。コンテンツ・プロバイダはそのライブ・ストリームを入口点へ送信し、この入口点はポートアナウンスを使用してセット・リフレクタに新たなストリームの利用可能性をアナウンスする。入口点は、リフレクタを実行する単なるマシンであり、特別なハードウェアを含まないため、迅速な配置は容易である。入口点は共有バックエンドを有する２台のコンピュータを含むことが望ましいが、これは必要条件ではない。入口点は利用可能性を保証するためフェイルオーバー機構を実行することが望ましい。セット・リフレクタも同様に配置され、世界中の、戦略的位置が望ましい。各セット・リフレクタはそのサブマネージャを使用して、必要に応じて配信、すなわちエッジ・ノードにより要求された配信のためにサブスクリプションを入口点へ発送する。各セット・リフレクタのリフレクタは自己サーバー・モードで動作し、一方その中のサブマネージャはポートテーブル・モードで実行し、ポートテーブルはポートリスンにより作成されることが望ましい。エッジ・ノードは実際のユーザーにサービスするものである。上記したように、エッジ・ノードはリフレクタとサブマネージャと共に、メディア・サーバー（例えば、ＱＴＳＳ、ＷＭＳ、またはリアル・メディア）を実行する。エッジ・ノードは領域を形成するように配置されることが望ましいが、これは必要条件ではない。特定の領域は、共通のバックボーンを共有する約１０台のエッジ・マシンを含む。
【００２７】
これも図３に図示するように、所与の領域３２０は、リフレクタ３０２ｄとサブマネージャ３０８ｃを実行する衛星アップリンク・ノード３１５を実行する衛星領域を含んでもよい。一般に、衛星アップリンク・ノードはサーバーを実行せず、ルートマスタ・プログラムにより制御されて、ルートマスタが、ノードに接続された特定の衛星に載せることを決定したものにつきサブスクリプション要求するよう言い渡される。アップリンク領域でリフレクタにより受信したデータは衛星へ送信される。
【００２８】
限定する意図ではないが、所与のセット・リフレクタ・ノードはペンティアムＩＩＩ（登録商標）クラスのプロセッサ、リナックス・オペレーティングシステム・カーネルを実行し、及び上記したアプリケーション・プログラムをサポートする適切なシステムメモリとディスク記憶を含むマシンである。所与の入口点は、ライブ・ストリームをＣＤＮへ公開するのに必要な追加プログラム（例えば、エンコーダ、コンテンツ・イニシエータ・ツール、等）と共に、同様な構成を有する。セット・リフレクタはセット・リフレクタ・ノードから構成される。
【００２９】
図４は望ましい実施例におけるエッジ・ノードでのサブスクリプション機構の動作を図示する流れ図である。例えば、ＣＤＮ要求経路設定機構を使用してユーザーがエッジ・ノードに接続してきた時に、ルーティンが段階４００で開始する。特に、この流れ図は、ストリーミング・メディアがストリーミングＣＤＮを通して配信準備が出来ていて、要求をするユーザーがストリームを同定するリンクをクリックして、かつそのユーザーがＣＤＮにより最適サーバーへ経路設定されたと仮定している。これらの条件を達成する特定の方法は本発明の範囲外であり、任意の都合のよい既知のまたは以後開発されるＣＤＮ技術及びサービスをこの目的のために使用してもよい。段階４０２で、ユーザーが経路設定された特定のエッジ・ノードのストリーミング・メディア・サーバーが要求を受取り、ユーザーがどのライブ・ストリームを必要としているかを決定する。段階４０４で、エッジ・ノードのストリーミング・メディア・サーバーはポート情報ライブラリを使用してストリームを要求する。段階４０６で、エッジ・ノードのストリーミング・メディア・サーバーがストリームを既に受信しているかどうか（例えば、他のユーザーがそのサーバー、または同一領域のサーバーからストリームを再生しているかどうか）を決定する検査を実行する。特定のストリームへの複数のサブスクリプションが単一のサブスクリプション要求として処理される場合はこの段階は削除してもよい。検査の結果が肯定である場合、ルーティンは終了する。しかしながら、段階４０６の検査が否定である場合、ルーティンは段階４０８を続行する。
【００３０】
この段階で、エッジ・ノードで実行するサブマネージャは、上記したように、領域中の他のエッジ・ノード上で実行するサブマネージャと接触して一組のリーダーを決定することを含む、そのリーダー・アルゴリズムを実行する。次いでルーティンは段階４１０を続行し、ＤＮＳサブスクリプション方法を使用してサブスクリプションをセット・リフレクタに送信する。このサブスクリプション方法によると、サブマネージャが所与のドメイン名、例えばｎ＜リーダー（ｌｅａｄｅｒ）＞．ｒ＜物理領域＞．ｒｅｆ．ａｋａｍａｉ．ｃｏｍを検索する時、ＤＮＳサーバーは要求されたメガストリームを最良に提供可能なセット・リフレクタを返し、ドメイン名のｎ１、ｎ２またはｎ３ホスト名を基にした３つのＩＰアドレスのうちの１つを返す。流れ図に戻ると、次いでルーティンは段階４１２を続行し、セット・リフレクタは３人のリーダー用にそのサブスクリプションリストを変更し、新たな要求ストリームの送信を開始する。
【００３１】
処理は次いで階層を上方へ移動する。特に、図５は特定のセット・リフレクタでのサブスクリプション機構の動作を図示した流れ図である。セット・リフレクタが既にストリームを受信しているかどうか（例えば、このセット・リフレクタを使用しているどこかの領域が既にこれを受信しているかどうか）を決定する検査により、ルーティンは段階５００で開始する。特定のストリームへの複数のサブスクリプションを単一のサブスクリプション要求として処理する場合この段階はオプションである。検査の結果が肯定である場合、ルーティンは終了する。しかしながら、段階５００の検査の結果が否定である場合、ルーティンは５０２を続行し、自己サービス機能を使用して、セット・リフレクタはローカル・サブマネージャ（すなわち、セット・リフレクタ・マシンで実行するサブマネージャ）にそのサブスクリプションリストを通知する。段階５０４で、サブマネージャ（ポートリスンにより作成されたポートテーブルを使用して）はどの入口点がストリームを有するかを検索する。段階６０６で、サブマネージャは配信メッセージを選択した入口点へ送信して、要求セット・リフレクタへの供給を開始する。これで各セット・リフレクタでの処理は完了する。
【００３２】
図６は特定の入口点でのサブスクリプション機構の動作を図示する流れ図である。ルーティンは段階６００から開始し、コンテンツ・プロバイダまたは他の第３者がライブ・コンテンツを含む信号を得る。信号は公衆インターネット、ＩＳＤＮ、衛星またはその他の都合のよい手段で送信可能である。段階６０２で、プロバイダはＣＤＮと接触し、リフレクタ・ポートと最良の入口点アドレスを得る。通常、ＣＤＮはインターネット上に入口点を配置し、ＣＤＮはプロバイダのエンコーダに対して最良の入口点を指定可能であり、段階６０２により、そのＩＰアドレスを提供する。特定の顧客に一意のユーザー名とパスワードを割り当てて、入口点でそのストリームを認証する。さらに、入口点は、インターネット上のどのＣＩＤＲブロックがデータを入口点へストリーミングするかに関して指令される。段階６０４で、ストリーミングされるコンテンツがコード化される。もちろん、コード化機能は使用するストリーミング・フォーマットに依存する。ウィンドウズ・ベースのメディアでは、プロバイダはウィンドウズ・メディア・エンコーダを実行して、コンテンツを所要のビットレートとフォーマットにコード化する。リアル・コンテンツでは、プロバイダはリアルプロデューサー（ＲｅａｌＰｒｏｄｕｃｅｒ）エンコーダを使用可能である。アップルのクイックタイムでは、プロバイダはクイックタイム・ストリーミング・サーバー上でソレンセン・ブロードキャスタ（Ｓｏｒｅｎｓｅｎ Ｂｒｏａｄｃａｓｔｅｒ）を実行可能である。段階６０６で、コンテンツ初期化ツールが実行されてストリーミング・メディア・オブジェクトを参照するＵＲＬを変更する。この過程により発生された代表的なＡＲＬは上記に図示されている。段階６０８で、ＡＲＬが公開される。このように、例えば、ウィンドウズ・メディアでは、ＡＲＬはＡＳＸファイルとウェブページを介して公開される。リアル・コンテンツでは、ＡＲＬはＲＡＭファイル、ＳＭＩＬファイルまたはウェブページに埋め込まれる。アップルのクイックタイムでは、ＡＲＬはウェブページに、または参照された映画または有線映画に埋め込まれる。
【００３３】
段階６１０で、入口点リフレクタ・プログラムが初期化されセット・リフレクタからのサブスクリプション要求を受信するよう待機する。段階６０６と６０８を段階６１０と並列に実行してもよい。ポートアナウンス機能により要求を受信したかどうか段階６１２で検査を実行する。否定の場合、ルーティンは再開する。段階６１２の検査の結果が肯定の時、ポートアナウンスはセット・リフレクタの対応するポートリスンからサブスクリプション要求を受信している。段階６１４で、リフレクタはサブスクリプション要求を発送したセット・リフレクタへの供給を開始する。
【００３４】
本発明のサブスクリプション機構はいくつかの変形を有してもよい。もちろん、改善された耐障害性を提供するため中間層内に任意の数のセット・リフレクタを使用してもよい。さらに、静的コンフィグレーションを使用する代わりに、この機構がセット・リフレクタを動的に選択してもよい（ＤＮＳを使用してプールから一定数のセット・リフレクタを選択する）。さらに、単なるハード的なコンフィグレーションの代わりに、すなわち、ＩＰアドレスをコンテンツ・プロバイダ顧客に提供することにより、入口点も動的に選択してもよい。さらに、多数のライブ供給につきサブスクリプション要求を出している領域がこれ以上のストリームを受信不能となった時に、インテリジェントな領域オーバーフローを実施することも望ましい。繁忙な領域はライブ・トラヒックを他の領域へオーバーフローしてもよい。さらに、一定数の入力ストリームを要求するため所与のエッジ・ノードにサブマネージャを有することは、特に良好に接続される区域では、不要かもしれない。従って、入力ストリームの現在の数が不足している場合にのみストリームを要求するようサブマネージャをプログラムしてもよい。
【００３５】
衛星動作
公知のように、インターネット・プロトコル（ＩＰ）データの衛星トランスポートは陸上トランスポートとは非常に異なるセマンティックスを有する。データの１回のアップリンクは追加作業なしに無限の場所へダウンリンク可能である。この「１対多数」セマンティックは衛星トランスポートをライブ・ストリームの配信に理想的なものとする。さらに、衛星は一般に公衆インターネットほど損失がない、従って、きれいなストリームをアップリンク可能である場合、これは公衆インターネットを通過してきたものよりダウンリンク上で一般的にはよりきれいである。しかしながら、不運にも、衛星はいくつかの欠点があり、第１に、陸上線路と比較したその高コストである。全てのトランスポート機構と同様に、ヘッドエンドの任意の損失がテールエンドに忠実に配信される。従って、多数の可能なダウンリンクを与えると、この損失は負担するには非常に高価である。
【００３６】
衛星トランスポートの低損失特性は共願の出願番号第０９／４７８、５７１号に記載した技術を使用することにより活用可能である。上述したように、特定のＣＤＮ領域は、リフレクタとサブマネージャを実行する衛星アップリンク・ノードを実行する衛星領域を含んでもよい。リフレクタ・ベースの衛星システムは衛星トランジットの特定部分の有用性を最大化する。（リフレクタは衛星のコストに関しては何も出来ないが、高価な帯域を最高に使用するよう配置可能である。）図７に図示するように、アップリンク・センター７００は標準のＣＤＮ領域構成を含み、ここでマシン７０２ａ−ｎはプライベートなバックエンド網７０４を共有する。これらのマシンは上述したようにリフレクタとサブマネージャを実行する。一般に、これらのマシンはストリーミング・サーバーを実行せず、ユーザーはこれらにはマップされない。ダウンリンクでは、すなわちいくつかのその他のＣＤＮエッジ領域７０６、衛星アンテナ７０８及びその関連ハードウェア７１０が、領域のバックエンド網へ、望ましくはマルチキャストでそのデータを提供するよう接続される。マシン７１４ａ−ｎはエッジ・ノードであり、各々が前述したようにストリーミング・サーバーと共にリフレクタとサブマネージャを実行する。
【００３７】
セット・リフレクタはシステムの状態に関する大量の情報を有する。特に、これらは各領域がどのストリームを要求しているかを知っている。この知識をどの領域が衛星ダウンリンク能力を有しているか（そしてどの衛星ベンダから）のリストと、さらに特定時間に各衛星ベンダを使用するコストと組合わせて、あるストリームをアップリンクするのがもっともかどうか計算可能となる。そうである場合、アップリンク・メッセージがアップリンク領域８００に送信され、これはあたかも通常の領域のように、上述したサブスクリプション方法を使用してストリームを配信することにより、応答する。これはきれいなストリームをアップリンクすることを保証する。次いでデータはマルチキャストに変換されて衛星アップリンクに注入される。データがダウンリンク側に見え始めると、公衆インターネットを通して到着するデータと混合されたきれいなストリームを見て、リフレクタとサブマネージャは、ストリームの陸上線路ヴァージョンからの配信を止めて衛星のみを使用することが望ましい。システムは陸上線路と衛星使用（そして損失がある場合は２者の任意の混合）を非常に迅速に（秒単位）切り換え可能である。このように、例えば天候またはハードウェア故障による衛星故障は直ちにかつ自動的に修復される。以下は、特定のストリームをアップリンクするかどうか、またどこからアップリンクするかを決定する１つの技術を説明する。上記したように、計算はルートマスタにより実施され、異なる衛星会社のコスト（ＣＤＮへの）、ストリームをアップリンク・センターへ持ち込むコスト（これは通常陸上線路を介して生じる必要がある）、ストリームを見る領域数、衛星アンテナを有する領域数、アンテナがどの衛星に向けられているか、のような各種の情報部分を使用してもよい。具体的な例として、１００領域がストリームを見ていて、これらの領域のうちの５０が衛星アンテナを有し、これらのアンテナの内の２０が第１衛星（例えばローラル（Ｌｏｒａｌ））に向けられ、他の３０は第２衛星（例えばヒューズ）に向けられていて、ＣＤＮは第１衛星に一定の第１料金（例えば、メガバイト当り＄．５０）を、第２衛星に一定の第２料金（例えば、メガバイト当り＄．８０）を支払うものとする。また、陸上線路を経由してストリームを配信するコストは一定料（例えば、＄．１０）であるものと仮定する。従って、ストリームを陸上線路を経由して１００領域に配信するためにはＣＤＮは１００＊（．１０）＝＄１０をメガバイト当り支払う。ＣＤＮが第１衛星に切り換えた場合、衛星アンテナを有しない領域にはメガバイト当り８０＊（．１０）＝＄８、加えることの、単一のローラル・アップリンクにはメガバイト当り１＊（．５０）＝＄．５０、全体で＄８．５０を支払う。第２衛星を見ると、ＣＤＮはアンテナのない領域に７０＊（．１０）＝＄７、加えることの、単一のヒューズ・アップリンクには１＊（．８０）＝＄．８０を、全体でメガバイト当り＄７．８０を支払う。従って、ヒューズ・リンクはローラル・リンクより安価である。この種の計算は、どれかの衛星にアップリンクされているストリームのコストを連続的に再評価するため定常的に実行されてもよい。ＣＤＮをさらに節約する他のストリームがある場合には、ＣＤＮはそのストリームをアップリンクすることも可能である。上例ではコストが重要な基準であるが、何時アップリンクするかを評価するために他の要因もルートマスタ・アルゴリズムにより考慮されてもよい。従って、例えば、（入来側のインターネット問題のため）多数の領域が高品質ストリームを得ることが不可能な場合、ルートマスタはこの輻輳をバイパスするため衛星にアップリンク可能である。または、多数の海外領域がある場合、米国線路よりしばしば損失が多く、遅い大洋横断線路を避けるために衛星アップリンクを使用してもよい。もちろん、以上は単なる例示である。
【００３８】
衛星帯域が固定料金（ｃａｐ）を有している場合、衛星帯域を充填することも望ましい。ＣＤＮが衛星帯域に固定コストを支払っている場合、ＣＤＮは出来る限りその帯域を使用したい。上記技術を使用することにより、異なるビットレートの各種ストリームを選択してＣＤＮが出来る限り帯域を充填させることも可能である。ＣＤＮが前記帯域に対して可変のコストを支払っているかどうかも考慮に入れてもよい。衛星会社はその衛星で「使用または未使用」決定を行う有効な手段を有しておらず、特定のストリームをアップリンする過程はしばしば手動で実行されるため、上記技術は非常に有用である。この技術は自動化され、衛星をその最大利点まで使用するよう常に探している。
【００３９】
上述した多数の機能は、個別のプログラムとして説明し図示してきた。当業者には、その代わりに特定の機能が他のプログラムの一部を含んでもよいことが認められる。従って、本明細書でのあるプログラムへの引用は、プログラム、プロセス、実行スレッド、またはその他の上記プログラミング構成概念への参照と広範囲に認めるべきである。具体的な例として、サブマネージャ及びリフレクタとして上述したプログラムは、大きなプログラムの別々なスレッドとして実行してもよい。一般化すると、上述した各機能は、コンピュータ・コード、すなわち、従来の装置、例えば、プロセッサ、マシン、接続マシンの組、システム、等を使用したそのコードの実行を介して記載した機能性を実行するコンピュータ命令の組として、実装されてもよい。
【００４０】
要約すると、図示実施例では、リフレクタ網配置は３層、すなわち入口点、セット・リフレクタ及びエッジ・ノードを含むことが望ましい。各入口点はセット・リフレクタに複数のユニキャストを送信し、各セット・リフレクタは複数の入口点からストリームを受信し、次いでマルチプレックス化されたストリームをエッジ・ノードのサブセットへ送信し、各エッジ・ノードはストリーミング・サーバーをホストするＣＤＮ領域内にあり、セット・リフレクタのあるサブセットからマルチプレックス化ストリームの複数コピーを受信し、次いで領域中の全てのサーバーが全てのストリームを見れるようにそのバックエンド網を通してこれをブロードキャストする。もちろん、特定の領域は１台のストリーミング・サーバーのみ（すなわち、単一のエッジ・ノード）を含んでもよく、これは、リーダー・アルゴリズムの実行を不要とする程度以外は、上述したサブスクリプション機構に影響を与えない。さらに、需要が少ないストリームへのサブスクリプション要求に関しては中間層の使用は不要でもよいことが当業者には理解できる。
【００４１】
さらに、本明細書で記載したリフレクタ網とその関連サブスクリプション機構は任意の型式のデータの一般化配信に使用してもよい。従って、例えば、コンテンツ・プロバイダのメタデータをＣＤＮエッジ・ノードへ公開するためリフレクタがネットワークする。他の例として、ＣＤＮからサービスされるコンテンツによりエッジ・ノード・キャッシュに信号を送るツールとして網とサブスクリプション機構を使用してもよい。
【図面の簡単な説明】
【００４２】
【図１】  本発明を実装する既知のコンテンツ配信網のブロック線図を示す。
【図２】  ＣＤＮ入口点からインターネットのエッジの最適ストリーミング・サーバーへの異なるルートを通して同一ストリームの複数コピーをＣＤＮに送信させることによりライブ・ストリーミングがいかにさらに強化されるかを図示する簡略化ブロック線図を示す。
【図３】  本発明によるリフレクタサブスクリプション機構を図示する簡略化線図を示す。
【図４】  ＣＤＮにより要求エンドユーザーが差し向けられたエッジ・ノードの本発明によるサブスクリプション機構の動作を図示する流れ図を示す。
【図５】  本発明によるセット・リフレクタ・ノードのサブスクリプション機構の動作を図示する流れ図を示す。
【図６】  本発明による入口点のサブスクリプション機構の動作を図示する流れ図を示す。
【図７】  衛星領域がいかに本発明のリフレクタサブスクリプション機構を利用するかを図示する簡略化ブロック線図を示す。
【図１】
0004723170.tif 000004
【図２】
0004723170.tif 000005
【図３】
0004723170.tif 000006
【図４】
0004723170.tif 000007
【図５】
0004723170.tif 000008
【図６】
0004723170.tif 000009
【図７】
0004723170.tif 000010