(57)【特許請求の範囲】
【請求項１】
データパケットのストリームとして所与のメディアフォーマットで利用可能なライブメディアコンテンツの耐障害性配信方法であって、
各データセンタに１個配置された１組のスプリッタにデータパケットのストリームを受信させ、
各スプリッタから１組のサーバ領域へストリームの各パケットのコピーを出力させ、
各サーバ領域はコンセントレータと、所与のメディアフォーマットに関連する１組のメディアサーバとを含み、
各サーバ領域のコンセントレータに各スプリッタからのデータパケットを処理させて、冗長なデータパケットであれば捨てさせ、冗長なデータパケットでなければ受信後遅滞なく送信させることにより、データパケットのストリームを再編成させ、
コンセントレータから送信されてきたデータパケットを、データパケットのストリームとして、所与のメディアフォーマットに関連する１組のメディアサーバの各々に供給させることにより、サーバ領域の１組のメディアサーバの各々がデータパケットのストリームを供給できるようにし、
各サーバ領域の１組のメディアサーバの各々に、コンセントレータから送られてきたデータパケットのストリームを受信させ、
コンセントレータから送られてきたデータパケットのストリームを受信しているサーバ領域の１組のメディアサーバのうちの１つに差し向けられたエンドユーザの要求に応答して、サーバ領域の所与のメディアサーバからデータパケットのストリームを出力させるステップより成り、
データパケットは各スプリッタから各サーバ領域へ非ストリーミングメディアプロトコルにより配信され、データパケットのストリームは所与のメディアサーバから所与のストリーミングプロトコルにより出力される、ライブメディアコンテンツの耐障害性配信方法。
【請求項２】
ストリーミングプロトコルはＲＴＳＰである請求項１の方法。
【請求項３】
非ストリーミングメディアプロトコルはＵＤＰである請求項１の方法。
【請求項４】
データパケットのストリームを配信する所与のポイントでデータパケットのストリームを符号化し、データパケットのストリームを配信するその後のポイントで符号化済みデータパケットのストリームを復号するステップをさらに含む請求項１の方法。
【請求項５】
データパケットのストリームは、所与のメディアサーバから、エンドユーザーマシン上で実行されるブラウザに関連するメディアプレイヤへ出力される請求項１の方法。
【請求項６】
データパケットのストリームとして所与のメディアフォーマットで利用可能なライブメディアコンテンツを１組の配信ソースの各々からインタネットを介して配信する耐障害性配信方法であって、
１組のサーバ領域の各々に、１組の配信ソースの１つから１つのコピーを受信させることにより、データパケットのストリームの２またはそれ以上のコピーを受信させ、
各サーバ領域でデータパケットを受信させ処理させて、冗長なデータパケットであれば捨てさせ、冗長なデータパケットでなければ受信後遅滞なく送信させることにより、データパケットの新しいストリームを編成させ、
データパケットの新しいストリームを所与のメディアフォーマットに関連する１組のメディアサーバの各々に供給させることにより、サーバ領域の１組のメディアサーバの各々がデータパケットの新しいストリームを供給できるようにし、
各サーバ領域の１組のメディアサーバの各々に、データパケットの新しいストリームを受信させ、
データパケットの新しいストリームを受信したサーバ領域の１組のメディアサーバのうちの１つのサーバへ差し向けられたエンドユーザの要求に応答して、サーバ領域の所与のメディアサーバからデータパケットの新しいストリームを出力させるステップより成り、
データパケットの各ストリームはＵＤＰにより各サーバ領域へ配信され、データパケットの新しいストリームは所与のメディアサーバからメディアフォーマット特定アプリケーションレベルストリーミングプロトコルにより出力される、ライブメディアコンテンツの耐障害性配信方法。
【発明の詳細な説明】
【０００１】
（技術分野）
本発明は一般にコンピュータネットワーク上のディジタル信号伝送に関するものであり、特にインタネット上でライブメディアコンテンツをストリーミング配信するフォールトトレラントな、即ち耐障害性のある配信方法に関するものである。
【０００２】
（関連技術の説明）
ほとんどのインタネットユーザはインタネットに対する充分に高速のアクセスをそなえていないので、大きなマルチメディアファイルを素早くダウンロードすることはできない。ストリーミングは、通常、マイクロソフト（Ｍｉｃｒｏｓｏｆｔ）のネットプレイヤ（ＮｅｔＰｌａｙｅｒ（Ｒ））、アップル（Ａｐｐｌｅ）のクイックタイム（Ｑｕｉｃｋｔｉｍｅ（Ｒ））、リアルネットワークス（Ｒｅａｌ  Ｎｅｔｗｏｒｋｓ）のリアルシステム（ＲｅａｌＳｙｓｔｅｍ（Ｒ））等のようなブラウザプラグインを使用して、ウェブに基づくビデオ、オーディオ、およびマルチメディアのファイルを、要求しているクライアントで定常的で連続したストリームとして処理できるように、これらのファイルを配信するための手法である。たとえば、ビデオのストリーミングは、インタネットのユーザにオーディオとビデオを提供し、コンテントがユーザのハードドライブに完全にダウンロードされるのをユーザが待つ必要のないオンラインビデオ配信機構である。キャッシュ方式により、コンテントは受信されると再生され、バッファリング機構によりコンテントが滑らかに再生される。理論的には、ビデオのストリーミングは、エンドユーザすなわち視聴者に対して即時で進行しているブロードキャストとして作用する。
【０００３】
ネットワークの見地からは、インタネットのコンテントのストリーミングを行う伝統的なアプローチでは、送信源からスプリッタ（またはレピータ、反射器、または反射鏡）として知られている機器にストリーミング信号が送信され、この機器はソース信号を複写して多数の信号を作成する。多数の信号は各々同じであり、各々が別の宛て先に送られる。スプリッタをトリー状に縦続接続することにより、単一のソースストリームを複写して数千以上の同一のコピーを作成することができる。このようにして、インタネット上の多数の視聴者は同じストリーミング信号を同時に受信することができる。
【０００４】
この型の既存のストリーミング方法の重大な問題は、それらがフォールトトレラントでないということである。図１はその理由を示す。この例では、ソース信号（Ａ）がスプリッタ（Ｂ）に送られ、次にスプリッタ（Ｂ）は信号のコピーを１０個のスプリッタ（Ｃ１，．．．，Ｃ１０）に送る。次に、第二レベルのスプリッタは各々、信号のコピーを５人のエンドカストマ（Ｄ１，．．．，Ｄ５０）に送る。したがって、たとえば、スプリッタＣ１はコピーをエンドユーザＤ１−Ｄ５に送り、スプリッタＣ２はコピーをエンドユーザＤ６−Ｄ１０に送り、以下同様に送る。しかし、与えられたスプリッタでの通信が失敗した場合、あるユーザはもとの信号を受信することができない。図１のネットワークでは、Ｃ２が失敗した場合にユーザＤ６−Ｄ１０について、これは当てはまる。この問題を克服するために、エンドユーザがもはやストリーミング信号を受信していないことをエンドユーザが検出することができ、そしてこのようなユーザが信号のもう一つのコピーを得ようとして代わりのスプリッタ（たとえば、Ｃ３）にコンタクトしょうとすることができるようにすることも当業者には知られている。しかし、このようなアプローチでは、信号が中断されることがあり、実現すると高価になる。
【０００５】
したがって、フォールトトレラントな改善されたストリーミング手法を提供することが当業者により、なお求められている。本発明はこの重要な問題を解決する。
【０００６】
（発明の簡単な概要）
本発明は、コンピュータネットワークのストリーミング信号にフォールトトレランスを
与えるための複写プロセスを提供する。一実施例では、もとの信号すなわちソース信号が数個のスプリッタに送られる。スプリッタは各々、信号のコピーを作成して、「コンセントレータ」と呼ばれる第二層の装置内にコピーを送る。与えられたコンセントレータは入力としてソース信号の一つ以上のコピーを受信する。好適実施例では、与えられたコンセントレータは少なくとも二つのスプリッタからソース信号の二つのコピーを受信する。コンセントレータは、たとえば、与えられた処理アルゴリズムに従って、入力ストリーミング信号のコピーを合体してもとのソース信号の単一の、すなわち合成のコピーとすることにより、入力ストリーミング信号のコピーを処理する。このようにして、好ましくは、与えられたコンセントレータは、多数のソースからストリームを受信し、重複したパケットを除去した後、単一のストリームを出力する。次に、与えられたコンセントレータの出力はスプリッタに与えることができる。このとき、信号の任意に多数のコピーを作成したい場合には、プロセスが反復される。複写プロセスの終わりに、スプリッタまたはコンセントレータの出力は直接または間接にエンドユーザに与えられる。複写プロセスはフォールトトレラントであるので、配信機構の中の信号または装置の問題にかかわらず、エンドユーザの信号は中断されない。
従って、本発明は、データパケットのストリームとして所与のメディアフォーマットで利用可能なライブメディアコンテンツの耐障害性配信方法であって、各データセンタに１個配置された１組のスプリッタにデータパケットのストリームを受信させ、各スプリッタから１組のサーバ領域へストリームの各パケットのコピーを出力させ、各サーバ領域はコンセントレータと、所与のメディアフォーマットに関連する１組のメディアサーバとを含み、各サーバ領域のコンセントレータに各スプリッタからデータパケットを受信させ処理させて、冗長なデータパケットであれば捨てさせ、冗長なデータパケットでなければ受信後遅滞なく送信させることにより、データパケットのストリームを再編成させ、コンセントレータから送信されてきたデータパケットを、データパケットのストリームとして、所与のメディアフォーマットに関連する１組のメディアサーバの各々に供給させることにより、サーバ領域の１組のメディアサーバの各々がデータパケットのストリームを供給できるようにし、各サーバ領域の１組のメディアサーバの各々に、コンセントレータから送られてきたデータパケットのストリームを受信させ、コンセントレータから送られてきたデータパケットのストリームを受信しているサーバ領域の１組のメディアサーバのうちの１つに差し向けられたエンドユーザの要求に応答して、サーバ領域の所与のメディアサーバからデータパケットのストリームを出力させるステップより成り、データパケットは各スプリッタから各サーバ領域へ非ストリーミングメディアプロトコルにより配信され、データパケットのストリームは所与のメディアサーバから所与のストリーミングプロトコルにより出力される、ライブメディアコンテンツの耐障害性配信方法を提供する。
【０００７】
コンセントレータで実行される処理アルゴリズムの一つの型は、単に信号ストリーム内の各パケットの最初のコピーを送信するものである。既に送信されたパケットのコピーは単に捨てられる。このアルゴリズムは、ストリーム内のパケットｉが転送されている場合には第一の値（たとえば、「１」）をそなえ、そうでない場合には第二の値（たとえば、「０」）をそなえるデータアレーｆ（ｉ）を維持することにより実行してもよい。入力ストリームの一つからパケットｉのコピーが受信されたとき、それが転送されるのは、ｆ（ｉ）が第二の値に等しい場合であり、その場合だけに限られる。この手法は、二つ以上の部分ストリームから完全なストリームを再構成することができるので、都合がよい。したがって、ストリームの入力コピーが全体としてもとのストリームのすべてのパケットを含む間は、コンセントレータはもとのストリームのコピーを作成する。
【０００８】
コンセントレータで実行し得る処理アルゴリズムのもう一つの型はバッファリング手法を使用する。このアプローチでは、ｎ次元のアレーを作成するため、各入力ストリームに対して、与えられたサイズのバッファが設けられる。ここで、ｎは入力ストリームの個数である。与えられたサイクルレートで、コンセントレータはどのストリームバッファにも含まれている最小のインデックスのパケット（すなわち、ストリームシーケンスの中で最も早いパケット）を送信する。各パケットが送信されると、アレー内のデータは更新されるので、同じパケットの将来のコピーは捨てることができる。このプロトコルにより、コンセントレータはストリーム内のパケットを整理しなおすことができるので、パケットは正しい順番に出力される。
【０００９】
上記のような一つ以上のコンセントレータにより、インタネット、イントラネット、仮想専用網等のようなコンピュータネットワーク上のフォールトトレラントなメディアのストリーミングが可能となる。
【００１０】
以上、本発明の、より適切な目的と特徴のいくつかの概略を説明した。これらの目的は、本発明の、より顕著な特徴と適用のいくつかを表すに過ぎないものと考えられるべきである。開示された発明を別の仕方で適用するか、または後で説明するように発明を変形することにより、他の多くの有益な結果を得ることができる。したがって、後の「好適実施例の詳細な説明」を参照することにより他の目的と、発明の、より完全な理解が得られよう。
【００１１】
本発明とその利点の、より完全な理解のため、付図とともに後の「詳細な説明」を参照されるべきである。
【００１２】
ストリーミングメディアは、まだダウンロードされる過程にある間に再生できるという重要な特徴をそなえるインタネットコンテントの型である。クライアントはストリームの第一のパケットを再生し、第二のパケットを伸長しつつ、第三のパケットを受信することができる。したがって、ユーザは送信の終了まで待つことなくマルチメディアを楽しみ始めることができる。ストリーミングはメディアを配信するのに非常に有用である。特にプログラミングの継続時間が長くなるにつれて、メディアファイルは大きくなりがちであるからである。ストリーミングされていないメディアファイルを視聴するためには、ユーザはまずファイルをローカルハードディスクにダウンロードし−これには数分から数時間かかることさえある−、その後、ファイルフォーマットに適合するプレイヤソフトウェアでファイルを開く。ストリーミングメディアを視聴するため、ユーザのブラウザはプレイヤソフトウエアを開き、プレイヤソフトウエアは２、３秒の間ファイルをバッファした後、ファイルを同時にダウンロードしつつ、ファイルを再生する。ソフトウエアのダウンロードとは異なり、ストリーミングメディアファイルはユーザのハードディスクに局部的に記憶されない。コンテントを表すビットが使用されると、プレイヤはそれらのビットを捨てる。
【００１３】
ストリーミングメディアの品質は、配信されつつあるメディアの型、ユーザのインタネット接続の速度、ネットワーク条件、コンテントが符号化されるビットレート、および使用されるフォーマットに応じて広範囲に変動する。これらの最後の二つの概念については、後で更に詳しく説明する。一般に、ストリーミングオーディオはＦＭ品質とすることができるが、ストリーミングビデオはテレビ規格から判断すると貧弱であり、画面がより小さく、解像度がより低く、毎秒フレーム数が少ない。ストリーミングメディアに対するソースは、ＶＨＳまたはベータのテープ、オーディオカセット、ＤＡＴ、ＭＰＥＧビデオ、ＭＰ３オーデイォ、ＡＶＩ等を含む、ほぼどの形式のメディアであってもよい。コンテントのストリーミングの前に、コンテントをまず符号化しなければならない。これは次の四つのことを行うプロセスである。すなわち、必要な場合に、コンテントをアナログ形式からディジタル形式へ変換すること、ストリーミングメディアのサーバとプレイヤによって認識されるフォーマットでのファイルの作成、実時間の与えられた限定された帯域幅で配信され得るコンテントのリッチネスを最大にするためのファイルの圧縮、およびメディアを配信するビットレートの設定である。ストリーミングメディアは「損失のある圧縮」を使用する。これは、クライアントエンドでの伸長後に、コンテントのいくつかの部分は保持されないということを意味する。たとえば、圧縮は毎秒３０フレームのＶＨＳビデオクリップを毎秒１５フレームに下げることができる。通常、メディアは、特定のビットレート、たとえば、２８ｋｂｐｓ、５６ｋｂｐｓ、１００ｋｂｐｓ等で符号化されなければならない。コンテントオーナは通常、多レートでメディアを符号化することを選択する。したがって、高速接続のユーザはできる限り良い経験を得るが、低速接続のユーザはコンテントにアクセスすることもできる。明らかに、符号化レートが低くなるほど、圧縮時に、より多くのもとのコンテントが捨てられなければならない。
【００１４】
異なるベンダによって開発されたサーバとクライアントのソフトウェア−Ａｐａｃｈｅ、マイクロソフトのインタネットエクスプローラ（Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ）（Ｒ）、ネットスケープコミュニケータ（Ｎｅｔｓｃａｐｅ  Ｃｏｍｍｕｎｉｃａｔｏｒ）（Ｒ）等−が一緒に良好に動作するという意味で、非ストリーミングのコンテントは規格に基づいている。しかし、ストリーミングメディアは通常、所有者であるサーバおよびクライアントのソフトウェアに依存している。ストリーミングソフトウェアベンダによって開発されたサーバ、クライアント、プロダクションと符号化のツールはまとめてフォーマットと呼ばれる。特定のフォーマットで符号化されたストリーミングメディアはそのフォーマットのメディアサーバのサービスを受け、そのフォーマットのクライアントによって再生されなければならない。ストリーミングメディアのクライアントはしばしばプレイヤと呼ばれ、通常、ウェブブラウザに対するプラグインとして存在する。ストリーミングメディアのクライアントはしばしば、ＷＡＶまたはＡＶＬのような規格に基づく非ストリーミングのメディアファイルを再生することもできる。
【００１５】
今日使用されている三つの主要なストリーミングメディアフォーマットは、リアルネットワークス（ＲｅａｌＮｅｔｗｏｒｋｓ）のリアルシステムＧ２（ＲｅａｌＳｙｓｔｅｍ  Ｇ２）（Ｒ）、マイクロソフトのウィンドウズメディアテクノロジーズ（Ｗｉｎｄｏｗｓ  Ｍｅｄｉａ  Ｔｓｃｈｎｏｌｏｇｉｅｓ−ＷＭＴ）（Ｒ）、およびアップル（Ａｐｐｌｅ）のクイックタイム（ＱｕｉｃｋＴｉｍｅ）（Ｒ）である。リアルシステムＧ２（ＲｅａｌＳｙｓｔｅｍ  Ｇ２）（Ｒ）はオーディオ、ビデオ、アニメーション、静止画像、およびテキストを含むすべてのメディア型を取り扱うが、ＨＴＭＬはサポートしない。リアルシステムＧ２（ＲｅａｌＳｙｓｔｅｍ  Ｇ２）（Ｒ）は、コンテントプロバイダがプレイヤウィンドウの中でメディアの時間と位置を決めることを許すＸＭＬに基づくＳＭＩＬをサポートする。実時間でメディアを配信するために、リアル（Ｒｅａｌ）はＲＴＳＰを使用する。ＷＭＴのアドバンストストリーミングフォーマット（Ａｄｖａｎｃｅｄ  Ｓｔｒｅａｍｉｎｇ  Ｆｏｒｍａｔ）でストリーミングするために、コンテントプロバイダはマイクロソフトのＮＴ４サーバ（ＮＴ４  Ｓｅｒｖｅｒ）（Ｒ）をインストールしなければならない。ＷＭＴはＳＭＩＬまたはＲＴＳＰをサポートしないが、それがＨＴＭＬ＋Ｔｉｍｅを呼び出すそれ自身のプロトコルをそなえている。アップル（Ａｐｐｌｅ）のクイックタイム（ＱｕｉｃｋＴｉｍｅ）（Ｒ）は最近、ストリーミングメディアに機能を追加した。クイックタイム（ＱｕｉｃｋＴｉｍｅ）（Ｒ）はＶＲ、３Ｄ、Ｆｌａｓｈ、およびＭＰ３を含む多数のフォーマットをサポートすることができる。クイックタイム（ＱｕｉｃｋＴｉｍｅ）（Ｒ）のストリーミングはＲＴＳＰを使用して映画を実時間で配信し、専用のメディアサーバが必要とされる。
【００１６】
もう一つの背景として、ＲＴＳＰすなわちリアルタイムストリーミングプロトコル（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）は、ＩＰネットワーク上のストリーミングされたマルチメディアの制御された配信を可能にするためのクライアント−サーバのマルチメディア表現プロトコルである。ＲＴＳＰは、停止、早送り、巻き戻し、絶対位置決めのような、オーディオおよびビデオのストリームに対する「ＶＣＲスタイル」の遠隔制御機能を提供する。データのソースはライブデータフィードと記憶されたクリップの両方を含む。ＲＴＳＰはＲＴＰ（リアルタイムトランスポートプロトコル−Ｒｅａｌｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）とＲＡＶＰ（リソースリザベーションプロトコル−Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）のような、より低レベルのプロトコルと一緒に動作して、インタネット上で完全なストリーミングサービスを提供するように設計されたアプリケーションレベルのプロトコルである。ＲＴＳＰは（ＵＤＰ、マルチキャストＵＤＰ、マルチキャストＴＣＰのような）配信チャネル、およびＲＴＰに基づく配信機構を選択するための手段を提供する。ＲＴＳＰはメディアサーバとクライアントとの間の連続したオーディオとビデオのメディアのストリームを確立し、制御する。ＲＴＳＰでは、各プリゼンテーションとメディアのストリームはＲＴＳＰのＵＲＬで表される。メディアの全体のプリゼンテーションとプロパティはプリゼンテーションデスクリプションファイルで定義され、プリゼンテーションデスクリプションファイルは符号化、言語、ＲＴＳＰのＵＲＬ、宛て先アドレス、ポート、および他のパラメータを含むことができる。プリゼンテーションデスクリプションファイルは、ＨＴＴＰ、イーメール（ｅｍａｉｌ）または他の手段を使用してクライアントが入手することができる。ＲＴＳＰはいくつかの理由でＨＴＴＰと異なる。第一に、ＨＴＴＰはステートレスプロトコルであるが、ＲＴＳＰサーバはＲＴＳＰ要求をストリームと相関させるために「セション」ステートを維持しなければならない。第二に、ＨＴＴＰは基本的に、クライアントが要求を発し、サーバが応答する非対称なプロトコルであるが、ＲＴＳＰではメディアサーバとクライアントの両方が要求を発することができる。たとえば、サーバはストリームの再生パラメータを設定するために要求を発することができる。
【００１７】
非ストリーミングコンテントのトランスポート層はトランスミッションコントロールプロトコルすなわちＴＣＰを使用する。これは接続指向のプロトコルである。接続指向のプロトコルとは、コンテントが完全に受信されるまでサーバとクライアントとの間の接続が確立されて維持されるということを意味する。この接続の一つの理由は、どれかＩＰパケットが受信されない場合にクライアントが報告することができ、その後、ＩＰパケットがサーバによって再送信されるということである。その結果、ＴＣＰ上で成功裏に送信されるファイル、たとえばロゴは常にそれのソースと同一であるが、送信に必要とされる時間はインフラストラクチャに応じて広範囲に変わり得る。
【００１８】
逆に、非ストリーミングメディアに対するトランスポート層はユーザデータグラムプロトコルすなわちＵＤＰを使用する。ＵＤＰはコネクションレスプロトコルであり、コネクションレスプロトコルのもとではコネクションを確立することなくＩＰパケットがサーバからクライアントに送られる。このプロトコルはストリーミングメディアの実時間性を可能とし、脱落したパケットの再送出を待つ必要はない。しかし、それは、サーバとクライアントとの間でコンテント品質が著しく低下するかも知れないということ、あるいは二人の異なるユーザが非常に異なる経験をするかも知れないということをも意味する。
【００１９】
本発明は、どのストリーミングメディアソース、符号化方式、メディアフォーマット、およびストリーミング（または他のトランスポート）プロトコルとも一緒に使用されるように設計される。
【００２０】
次に図２に示すように、本発明が実行されるパケット交換ネットワーク２００は信号ソースＡ、一組のスプリッタＢ１−Ｂｎ、および一組のエンドユーザＤ１−Ｄｎを含む。本発明に従って、ネットワークは本発明の信号複写プロセスを容易にする、一組のいわゆる「コンセントレータ」Ｃ１−Ｃｎをも含む。このプロセスにより、配信システムの他の要素の中で生じ得る、たとえば、装置、機器、または通信の故障による伝送の中断にかかわらず、各エンドユーザが常にソース信号のコピーを確実に受信する。
【００２１】
好ましくは、コンセントレータＣはネットワークの中で、スプリッタＢとエンドユーザＤとの間にある物理層、論理層の一方または両方に配置される。図２に示される物理構成はもちろん、例を示すに過ぎない。もちろん、エンドユーザは通常、ストリーミング信号コンテントに対するプラグインまたはネイティブサポートをそなえたブラウザまたは他のグラフィックスビュアー（ｖｉｅｗｅｒ）を含むクライアントコンピュータである。好適実施例では、コンセントレータＣはソフトウェアプログラム、すなわち、プロセッサの中で実行し得る一つ以上のプロセスを含む一組のコンピュータ命令である。図２に示されるように、各コンセントレータＣは入力としてソース信号データストリームの一つ以上のコピーを受信する。本発明の好適実施例では、各コンセントレータＣは少なくとも二つ（２個）の異なるスプリッタＢからソース信号データストリームのコピーを受信する。したがって、たとえば、この実施例では、もとの信号は数個のスプリッタＢ１，．．．．，Ｂ５に送られる。これらのスプリッタは信号のコピーを作成し、それらをコンセントレータＣ１，．．．，Ｃ２０に送る。スプリッタＢ１はソースＡから受信した信号のコピーをコンセントレータＣ１，．．．，Ｃ８の各々に送る。スプリッタＢ２はソースＡから受信した信号のコピーをコンセントレータＣ９，．．．，Ｃ１６の各々に送る。スプリッタＢ３はコピーをコンセントレータＣ１７，．．．，Ｃ２０およびＣ１，．．．，Ｃ４に送るのに対して、Ｂ４はコピーをＣ５，．．．，Ｃ１２に送り、Ｂ５はコピーをＣ１３，．．．，Ｃ２０に送る。再び、これらの例はいかなる意味でも本発明を限定するものと考えるべきではない。しかし、各々の場合に、すべてのコンセントレータはソース信号データストリームのコピーを正確に二つのスプリッタから受信することがわかる。換言すれば、各コンセントレータはもとのソースストリームのコピーを表す二つのストリームＵＤＰ１とＵＤＰ２を受信する。
【００２２】
一般に、コンセントレータの機能は入力ストリームを処理し、入力ストリームのマージングを行った後、ソース信号データストリームの単一の、すなわち合成のコピーをコンセントレータから出力することである。コンセントレータは重複したパケットを除去し、好ましくは単一のストリームフィード（ｆｅｅｄ）を出力する。この処理は全く都合がよい。特に、あるストリームの数個のコピーが与えられた場合、たとえ、それらのすべてに損失があっても、重複したストリームの残りから単一のもとのストリームを作成することができる。この手法は非常に強健であり、エンドユーザの経験が損なわれる前に多数の故障をとり得る。
【００２３】
データストリームの処理は多数の異なる仕方で行うことができる。たとえば、図３は、コンセントレータがストリーム内の各パケットの第一のコピーだけを送信する処理ルーチンの第一の実施例を示すフローチャートである。既に送信されたパケットのコピーは単に捨てられる。図４は、ストリームの多重コピーがバッファリングされて、出力が作成されるにつれて順が狂ったパケットを整理し直すことができる、処理ルーチンの第二の実施例を示す。次に、実施例の各々を詳細に説明する。
【００２４】
次に図３に示すように、処理ルーチンの第一の実施例はソース信号に対するアレーｆ（ｉ）を利用する。データアレーの要素は、ストリームのパケットｉがコンセントレータから転送されていれば、与えられた第一の値、たとえば１をそなえ、そうでなければ、第二の値、たとえば０をそなえている。ルーチンはステップ３００で始まる。ステップ３０２で、通常、ストリームの第一のパケットがコンセントレータに到達したとき、処理ルーチンのインスタンスが起動される。ステップ３０４で、アレーが初期設定される。次に、処理ルーチンはステップ３０６で続行されて、入力ストリームの一つからパケットｉが受信されたか否かがテストされる。しかし、ステップ３０６でのテストの結果が正で、パケットが受信されたことが示されている場合には、ステップ３０８でｆ（ｉ）＝０であるか判定するためのテストが行われる。（これがパケットｉの最初の出現であるので）ｆ（ｉ）＝０である場合には、ルーチンはステップ３１０で続行されて、遅延なしにコンセントレータからのパケットを転送する。ステップ３１２でルーチンは、アレー内のパケットｉの値を０に設定することにより、アレーを更新する。次に、制御はステップ３０６に戻る。しかし、ステップ３０８でのテスト結果がｆ（ｉ）が０に等しくないということを示す場合には、ルーチンはステップ３１４で続行されて、（既に転送されているので）パケットが捨てられる。
【００２５】
したがって、事実上、パケットがコンセントレータに到達するとき、処理ルーチンはパケットを解析する。パーサ（ｐａｒｓｅｒ）が既にストリームパケットを見ている場合にはパケットは捨てられ、そうでない場合にはパケットは転送される。
【００２６】
図３の処理ルーチンは、実現が簡単で、ストリームにいかなる遅延（これは、たとえば、パケットの特定のコピーが到着するのを待つことによって生じ得る）も導入しないという点で都合がよい。このルーチンは、二つ以上の部分ストリームから完全なストリームを再構成することができるという望ましい特徴をもそなえている。したがって、ストリームの入力コピーが集合体としてもとのストリームのすべてのパケットを含む限り、コンセントレータはもとのストリームのコピーを作成する。
【００２７】
たとえば、再び図２で、スプリッタの一つ（たとえば、Ｂ１）が機能しなくなった場合、コンセントレータＣ１，．．．，Ｃ４の各々がなおスプリッタＢ３からストリームを受信し、コンセントレータＣ５，．．．，Ｃ８の各々がなおスプリッタＢ４からストリームを受信する。この説明の例では、どのコンセントレータが送信する信号も決して中断されない。この性質は、どのスプリッタが機能していないかにかかわりなく維持される。実際、たとえ二つのスプリッタ（たとえば、Ｂ１およびＢ３）にパケット損失が生じても、（パケット損失が５０％より小さければ）上記のプロセスを使用してコンセントレータＣ１，．．．，Ｃ４の各々がなお、もとの信号を再構成することができる。
【００２８】
次に、図４には、コンセントレータでの各入力ストリームがそれに対応するバッファをそなえる、代替実施例が示される。ストリームパケットをバッファリングすることにより、コンセントレータは出力前にストリーム内のパケットを整理し直すことができる。ルーチンはステップ４００で始まる。ステップ４０２で、バッファは初期設定される。次にステップ４０４でルーチンは続行され、与えられたサイクルが経過したかテストされる。経過していない場合には、（各ストリームに対する）ステップ４０６でルーチンは続行され、（そのストリームに対する）与えられた入力パケットが既に転送されたかテストされる。ステップ４０６でのテストの結果が肯定的である場合には、ルーチンはステップ４０８でパケットを捨てる。与えられた入力パケットが転送されていない場合には、ステップ４１０でパケットはバッファリングされる。次に、制御はステップ４０４に戻る。バッファリング方式を使用して、たとえば、ストリームＵＤＰ１からのパケットは第一のバッファにバッファリングされ、ストリームＵＤＰ２からのパケットは第二のバッファにバッファリングされ、以下同様である。与えられたサイクルが経過したことをステップ４０４でのテストの結果が示すときには、制御はステップ４１２に分岐し、ストリームシーケンスの中で最も早いパケットが識別される。ステップ４１４で、このパケットがシーケンスからはずれているか判定するためにテストが行われる。このパケットがシーケンスからはずれている場合には、ルーチンはステップ４１６で必要に応じてパケットを整理し直す。次に、ステップ４１８で、結果として得られたストリームがコンセントレータから出力される。ステップ４２０で、転送されたパケットを反映するようにアレーが更新される。ステップ４１４で否定的な結果が得られた場合にも、ステップ４１８に達する。
【００２９】
したがって、図４のルーチンでは、各入力ストリームコピーに対して与えられたサイズのバッファが保持される。各サイクルで、コンセントレータはどのバッファにも含まれる最小のインデックスのパケットを送信する。各パケットが送信されるにつれて、アレー内のデータが更新されるので、同じパケットの将来のコピーはコンセントレータに到達したとき捨てることができる。わかるように、図４のプロトコルは図３のプロトコルと類似しているが、ストリーム内のパケットを正しい順で出力されるように整理し直すことができるという付加的な望ましい特徴をそなえている点が異なる。バッファのサイズが大きいほど、順が狂ったパケットを順序正しく出力できる可能性が高くなる。このようにして、ネットワークで遅くなったパケットはバッファで追いつく機会がある。
【００３０】
次に、与えられたコンセントレータＣでどちらの手法（図３または図４）が使用されるかにかかわりなく、与えられたコンセントレータの出力をスプリッタまたはエンドユーザに直接帰還することができる。コンセントレータがスプリッタに出力されるとき、プロセスを反復して、ソース信号データストリームの任意に多数のコピーを作成することができる。複写プロセスの終わりに、スプリッタまたはコンセントレータ（または何か他の機器）の出力は直接、視聴者に与えられる。結果として得られる複写プロセスは完全にフォールトトレラントである。特に、どの信号が破壊されるかにかかわりなく、エンドユーザの信号は中断されない。
【００３１】
各コンセントレータに入力される信号の数は、分散システムが許容することができる障害システムの数を決める。たとえば、すべてのコンセントレータが少なくともｋ個の異なるスプリッタから信号を受信する場合には、システムはどのエンドユーザが受信する信号もあやうくすることなくｋ−１個の信号のどのサブセットの障害も許容することができる。信号（またはシステムの構成要素）の障害がランダムである場合には、システムはどのエンドユーザの信号が中断される前にもＦ個の障害を許容することができる。ここで、Ｆは約Ｎ｛１−１／ｋ｝であり、Ｎはシステム内の構成要素の数である。各ストリームで経験されるパケット損失率がｐである場合には、コンセントレーション後の損失率はｐk×ストリーム数となる。
【００３２】
好適実施例では、与えられたコンセントレータに二つ（２個）の入力ストリームを入力することが望ましい。もちろん、ストリーム数を多くすると、そのコストとして配信機構のためのネットワーク帯域幅が大きくなる。多重入力ストリームがコンセントレータに供給される（すなわちスプリッタから出力される）場合には、本発明の変形は与えられた符号化方式をスプリッタ／コンセントレータの中に組み込むことにより、多重データストリームを送信するために使用される帯域幅の幾分かを取り戻す。この変形では、与えられた機器（たとえば、スプリッタ）からストリームが出力されるとき、それは符号化ルーチンを使用して符号化される。ストリームが下層のコンセントレータに入るとき、それは上記のように復号化され、処理される。符号化手法が使用されるとき、スプリッタから出力されるデータストリームのコピーは同一である必要はない。むしろ、与えられた機器の中で使用される符号化アルゴリズムの結果として、コピーは変動し得る。
【００３３】
説明している実施例では、有用な符号化方式はラビン情報分散アルゴリズム（Ｒａｂｉｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｄｉｓｐｅｒｓａｌ  Ａｌｇｏｒｉｔｈｍ）である。情報分散では、パケットがサブパケットの集合に分解されて、サブパケットがエッジディスジョイント（ｅｄｇｅ  ｄｉｓｊｏｉｎｔ）パスに沿ってそれらの共通の宛て先に大食い的に（ｇｒｅｅｄｙ  ｌｉｋｅ  ｆａｓｈｉｏｎ）送られる。情報分散の利点は、大きなパケットを多数の小さなサブパケットに分散することによりネットワークのエッジに非常に均衡した通信負荷が加わるという結果が生じる傾向になるということである。その結果、ネットワークの最大輻輳は非常に低くなりそうであり、パケットが全然遅延しない充分な見込みがある。更に、パケットのコンテントが冗長にサブパケットの集合に符号化されれば、情報分散アルゴリズムはよりフォールトトレラントになる。もとのパケットを再構成するためには、サブパケットの一部分だけが宛て先に届けばよいからである。情報分散アルゴリズムについての更に詳しい情報は、次の文献に見出すことができる。レイトン著「並列アルゴリズムとアーキテクチャ入門、アレイ、トリー、超立方体」、モルガンカウフマン（Ｌｅｉｇｈｔｏｎ，Ｉｎｔｒｏｄｕｃｔｉｏｎ  Ｔｏ  Ｐａｒａｌｌｅｌ  Ａｌｇｏｒｉｔｈｍｓ  ａｎｄ  Ａｒｃｈｉｔｅｃｔｕｒｅｓ：Ａｒｒａｙｓ，Ｔｒｅｅｓ，Ｈｙｐｅｒｃｕｂｅｓ，Ｍｏｒｇａｎ  Ｋａｕｆｍａｎｎ（１９９２），Ｓｅｃｔｉｏｎ３．４．８）。これはここに引用することにより本明細書の一部として組み入れられる。したがって、説明している実施例では、与えられたスプリッタと与えられたコンセントレータの中でラビン情報分散アルゴリズムが実行される。
【００３４】
上記のように、本発明で使用するためのコンセントレータはコンピュータ上で実行できるソフトウェアプログラムである。図５は、マネジャルーチン５０２、アレイマネジャプロセス５０４、および一組のストリームコンセントレーションプロセス５０６ａ−ｎを含む代表的なコンセントレータ５００を示す。上記の変形で説明したように、一つ以上の符号化／復号化ルーチン５０８を設けてもよい。動作については、コンセントレータの始動時にマネジャルーチン５０２が初期設定される。入力データストリームが受信されると、マネジャルーチン５０２はストリームコンセントレーションプロセス５０６のインスタンスを開始する。ストリームコンセントレーションプロセス５０６は個々のデータストリームをマージングしてストリームとした後、これをコンセントレータから出力することを管理する。アレイマネジャプロセスはマネジャルーチン５０２によって呼び出されて、与えられたストリームコンセントレーションプロセス５０６が使用するためのアレイ（または他のデータ構造または同等のワークエリア）を確立する。多重ストリームコンセントレーションプロセスを使用することにより、マネジャルーチンの制御のもとに、与えられたコンセントレータを使用して異なるコンテントストリームをコンセントレーションすることができる。
【００３５】
本発明のフォールトトレラントな配信機構は、従来のクライアント−サーバの分散演算環境の中で実現してもよい。図６は、ストリーミングフレームワークをその中で実現することができるクライアント−サーバの環境を示す。この例では、複数のインタネットクライアントマシン６１０は電話ネットワーク６１４のようなネットワークを介してコンピュータネットワークサービスプロバイダ６１２に接続され得る。サービスプロバイダ６１２はクライアントマシン６１０をネットワーク６１８の残りの部分にインタフェースし、ネットワーク６１８の残りの部分は複数のウェブコンテントサーバマシン６２０を含み得る。ネットワーク６１８は通常、ドメインネーム導出演繹、ルーチング、および他の制御機能の制御のために他のサーバ（図示しない）を含む。クライアントマシンは通常、公知のインタネットツールの組を含む。種々の公知のインタネットプロトコルがこれらのサービスのために使用される。
【００３６】
与えられたクライアントマシンとサーバは公衆インタネット、イントラネット、または他の任意のコンピュータネットワーク上で通信を行うことができる。希望される場合には、与えられた通信を機密接続上で行ってもよい。したがって、たとえば、クライアントは、ネットスケープのセキュアソケットレイヤ（ＳＳＬ）プロトコル（Ｒ）等のようなネットワークセキュリティプロトコルを使用してサーバと通信を行ってもよい。
【００３７】
代表的なクライアントはパソコン、ノートパソコン、インタネット機器、またはｘ８６−（Ｒ）、ペンティアム（Ｐｅｎｔｉｕｍ）（Ｒ）−、パワーＰＣ（Ｒ）、またはＲＩＳＣに基づく普及する演算装置（たとえば、ＰＤＡまたはパームコンピュータ）である。クライアントはマイクロソフトのウィンドウズ９８（Ｒ）、マイクロソフトのＮＴ（Ｒ）、ウィンドウズＣＥ（Ｒ）、またはパームＯＳ（Ｒ）のようなオペレーティングシステムを含む。クライアントは、ジャババーチャルマシン（ＪＶＭ）（Ｒ）およびアプリケーションプラグインまたはヘルパアプリケーションに対するサポートをそなえる、ネットスケープナビゲータ（Ｒ）またはマイクロソフトのインタネットエクスプローラ（Ｒ）のようなウェブブラウザを含むインタネットツールの組を含む。
【００３８】
代表的なウェブサーバはプロセッサ６２２、オペレーティングシステム６２４（たとえば、リナックス、ウィンドウズＮＴ（Ｒ）、ユニックス（Ｒ）等）、およびウェブサーバプログラム６２６を含む。ＯＳ６２４とウェブサーバプログラム６２６はシステムメモリ６２３（たとえばＲＡＭ）でサポートされる。もちろん、任意の都合のよいサーバプラットホーム（たとえば、Ａｐａｃｈｅ（Ｒ）、ＷｅｂＳｐｈｅｒｅ（Ｒ）等）がサポートされてもよい。プラグイン、ＣＧＩプログラム、サーブレッツ（ｓｅｒｖｌｅｔｓ）等を含むソフトウェアプログラムを介してコア機能性の拡張やカスタマイズをアプリケーション開発者が行えるような拡張を提供するアプリケーションプログラミングインタフェース（ＡＰＩ）６２８をサーバは含んでもよい。
【００３９】
代表的なコンセントレータはオペレーティングシステムおよびネットワーク結合性に対するサポートをそなえたコンピュータまたはコンピュータプラットホームである。したがって、たとえば、代表的なコンセントレータはコンピュータを動かすウィンドウズＮＴ（Ｒ）（インテルとＤＥＣのＡｌｐｈａ（Ｒ））、ＩＢＭのＡＩＸ（Ｒ）、ＨＰ−ＵＸ（Ｒ）、Ｓｕｎ  Ｓｏｌａｒｉｓ（Ｒ）（ＳＰＡＲＣおよびインテルエディション）、ＮｏｖｅｌｌのＮｅｔＷａｒｅ（Ｒ）またはウィンドウズ９８（Ｒ）を含む。
【００４０】
図７は本発明の実現を示す。システム７００は、たとえばストリーミングビデオプロダクションファシリティ７０６に常駐する一対のリレーサーバ７０２および７０４を含む。これらのサーバは各々、たとえば二つの（２個の）ネットワークカードをそなえている。その中の一方の組はエンコーダマシン７０８とともに共通ネットワーク上に配線され、他方の組はインタネット７１０に接続される。エンコーダマシン７０８はビデオとオーディオのデータを符号化し、符号化されたパケットをリレーサーバ７０２および７０４と共有するネットワークのブロードキャストアドレスに送る。リレーサーバはパケットをビックアップして、それらを、たとえば、二つの専用Ｔ−１回線を介して二つの異なるデータセンタ７１２および７１４に再送出する。これらの二つのデータセンタから、コンテントは二つ多いデータセンタ７１６、７１８、７２０、および７２２に広がる。このようにして、各データパケットの４個の写しが作成される。四つのデータセンタの各々は各パケットのコピーを一組の領域７２４ａ−ｎの各々に送る。各サーバ領域７２４は一組のホスティングサーバ７２６ａ−ｎを含む。各領域はコンセントレータ７２８を含み、コンセントレータ７２８は重複を除去し、単一の残ったストリームをその領域の中の各サーバ７２６に送る。限定を意味するものではないが、サーバ領域は、高性能でフォールトトレラントなウェブコンテント配信サービスであるアカマイ（Ａｋａｍａｉ）のＦｒｅｅＦｌｏｗ（Ｒ）のような分散コンテントホスティングシステムの一部を含んでもよい。
【００４１】
上記のように本発明は、プロセッサ内で実行可能なソフトウェアで、すなわち、コンピュータのランダムアクセスメモリに常駐するコードモジュール内の一組の命令（プログラムコード）として実現してもよい。コンピュータが必要とするまで、命令の組はもう一つのコンピュータメモリ、たとえば、ハードディスクドライブ内に、または除去可能なメモリ内に記憶してもよいし、インタネットまたは他のコンピュータネットワークを介してダウンロードしてもよい。
【００４２】
更に、上記の種々の方法はソフトウェアにより選択的に起動または再構成される汎用コンピュータで都合よく実現されるが、このような方法はハードウェア、ファームウェア、または必要な方法ステップを遂行するように構成された、より専用の装置で実行してもよいということも通常程度の当業者には了解されよう。
【００４３】
以上我々の発明を説明してきたが、新規性があり、確保したいことは請求の範囲に記載されている。
【図面の簡単な説明】
【図１】  複数のスプリッタを使用してソース信号が複数のエンドユーザすなわち視聴者に送信される公知のストリーミングアーキテクチャの概略図である。
【図２】  本発明の教示によるコンセントレータの発明的使用を示す概略図である。
【図３】  コンセントレータで使用され得る処理ルーチンの第一の型のフローチャートである。
【図４】  コンセントレータで使用され得る処理ルーチンの第二の型のフローチャートである。
【図５】  本発明で使用されるコンセントレータのブロック図である。
【図６】  本発明を実行し得るクライアント−サーバの演算環境のブロック図である。
【図７】  本発明の実現を示すブロック図である。
【図１】
0004723151.tif 000002
【図２】
0004723151.tif 000003
【図３】
0004723151.tif 000004
【図４】
0004723151.tif 000005
【図５】
0004723151.tif 000006
【図６】
0004723151.tif 000007
【図７】
0004723151.tif 000008