JP2010502097A - エンドユーザにトリプルプレイサービスを提供するための分散型サーバネットワーク - Google Patents

Abstract

ストリーミングされたコンテンツをユーザに配信するのに使用される分散型サーバフレームワーク。フレームワークは、中央サーバ（２０）と、局所のエッジサーバ（２１）と、アクセスサーバ（２２）のローカルグループ（３０、３１、３２）と、第１のリンク（９）と、第２のリンク（１１）と、第３のリンク（２３）と、地域サーバおよびアクセスサーバの中のファイル共有クライアント／サーバ・プロトコルとを備える。プロトコルは、ヒットリスト（６６、７１）と、スライドウィンドウとカーソルメカニズム（４５、４６）とを使って修正される。中央サーバへ投入されたデータ材料は、プロトコルを用いてそこからエッジサーバおよびアクセスサーバへ配信される。ヒットリストは、人気のある材料がアクセスサーバ上に記憶され、それほど人気のない材料がエッジサーバ上に記憶され、ほとんど要求されない材料が中央サーバに記憶されるようにする目的で、投入された材料をソートするのに使用される。アクセスサーバは、マルチプレクサ／デマルチプレクサ・デバイス（８）およびローカルループ（７）を介してユーザ（５）に接続する。従って、流行の材料や最新のニュースはユーザの近くに記憶され、それによってアクセスサーバとエッジサーバ間の第２のリンクが過負荷となるのを防ぐであろう。スライドウィンドウとカーソルメカニズムとによって、第３のリンクを用いて流行の材料や最新情報をアクセスサーバ間で上手に配信することができる。

Description

本発明は一般に、コンテンツをユーザに配信するための分散型サーバフレームワークと、コンテンツをユーザに提供する方法と、アクセスと、並びに、分散型サーバネットワークで使用されるエッジサーバとに関する。特に本発明は、ストリーミングされたＴＶおよびビデオをＩＰを利用して配信することに関する。

分散型サーバフレームワークは、トリプルプレイサービスのためのアクセス、統合、および転送ネットワークへの重畳ネットワークとして使用されるように設計される。

アルカテル（Ａｌｃａｔｅｌ）社の戦略的白書［参考文献１］は、２つの主要なネットワーク要素、すなわちブロードバンド・サービス・アグリゲータ（ＢＳＡ）とブロードバンド・サービス・ルータ（ＢＳＲ）とを利用したトリプルプレイサービスの配信アーキテクチャについて記述している。テレビ番組（ＴＶ）およびビデオ・オン・デマンド（ＶｏＤ）が、マルチキャストルーティングを用いて加入者に配信される。アルカテル社の白書は、「マルチキャストルーティングは、放送チャネルを加入者に配信するのに必要な帯域幅とファイバとを削減することによってネットワークの効率を向上させる。」と述べている。マルチキャストを行っているノードは、同報チャネルのコピーを１つ受信して、それを必要とするいずれかの下り方向のノードに対してそれを複製することができるため、必要なネットワーク資源を実質的に削減する。この効率は、加入者に近くなるほど重要性が高まる。従ってマルチキャストルーティングは、アクセスエッジノード、統合エッジノード、ビデオエッジノードの各々においてかまたはそれらのうちのいずれかにおいて行われるべきである。

アルカテル社の白書では、複数の加入者が、ＶＤＳＬ（超高速デジタル加入者回線）ノードと呼ばれるアクセスノードを介してＢＳＡに接続する。複数のアクセスノードがＢＳＡに接続する。複数のＢＳＡが１つのＢＳＲに接続し、ＢＳＲはＩＰを利用した転送ネットワークに接続する。ＢＳＡは、ＢＳＲ向けのすべてのサービスについてのトラヒックを統合してインターネットグループ管理プロトコル（ＩＧＭＰ）プロキシ・マルチキャスティングを組み込んだ、イーサネット（登録商標）中心の統合デバイスである。ＢＳＲは、動的ホスト構成プロトコル（ＤＨＣＰ）を利用したビデオサービス配信のためのエッジデバイスである。ＢＳＲは、ＩＰアドレスをホスト群に対して動的に割当て、マルチキャストルーティングを含む。

図１は、統合ネットワーク２と外部ネットワーク３の端部にブロードバンド・リモート・アクセス・サーバ（ＢＲＡＳ）１を備えた従来型のネットワークを示す。ＢＲＡＳが他の位置にあることも可能であり、例えば、外部ネットワーク内にあってもよい。ウェブサーバとも呼ばれるアプリケーションサーバ４は、ＢＲＡＳに接続しており、個々のユーザ５に配信されることになる材料を含んでいる。ユーザは、自分が視聴したい特定のデータ材料を要求し、それに応じてＢＲＡＳが、要求されたデータ材料を端から端まで、すなわちアプリケーションサーバから転送ネットワークを経由して統合ネットワーク上をアクセス領域を経由してユーザの加入者宅内機器（ＣＰＥ）まで転送する。個々のＣＰＥを、小さい四角形で示す。ＣＰＥは、ＤＳＬアクセスネットワーク７とアクセスノード８とを介して統合ネットワークに接続する。複数のＣＰＥが１つのアクセスノードに接続する。アクセスノードのグループが、第１のリンク９を介してアクセスノード−制御部の機能を備えたイーサネット（登録商標）スイッチ１０に接続する。２つのイーサネット（登録商標）リンクを示しており、その各々がアクセスノードのそれぞれのグループに接続する。イーサネット（登録商標）スイッチは、それぞれの第２のリンク１１を介してＢＲＡＳに接続する。ＢＲＡＳは典型的には複数の図示しない統合ネットワークにサービス提供する。ローカルループ内では、ＣＰＥとアクセスノード間にデジタル加入者回線（ＤＳＬ）１２が使用される。図示した例では、外部ネットワークは、転送ネットワークとも呼ばれていて典型的にはＩＰネットワークであって、各アクセスノードは、１０個の異なるＣＰＥに接続する、ＩＰを利用したデジタル加入者回線アクセスマルチプレクサ（ＩＰＤＳＬＡＭ）である。８個、１２個、あるいはその他の数のＣＰＥにサービス提供するＩＰＤＳＬＡＭも考えられる。ＩＰＤＳＬＡＭは、要求されたデータ材料を有するストリームを転送し、それを正しいＤＳＬの上に置く。ＩＰＤＳＬＡＭは、ローカルループで用いられるＡＴＭまたはイーサネット（登録商標）を利用した送信技術と、統合ネットワーク内で用いられるイーサネット（登録商標）上のＩＰの送信技術との間のインタフェースである。典型的には、ＩＰＤＳＬＡＭは、電話局またはリモートの屋外キャビネットの中に位置する。

図１の下部の双方向矢印１３は、ＣＰＥからアクセスノードまでの最初の１マイルである、統合ネットワーク内のいわゆる最初の１マイルの地理的延長部分を示す。双方向矢印１４は、アクセスノードとＢＲＡＳの間の距離である、統合ネットワーク内のいわゆる２マイル目の地理的延長部分を示す。

第１のリンクはイーサネット（登録商標）スイッチとアクセスノードの間を２マイル目に沿って延びるということを観察すべきである。第１のリンクは、アクセスノードとユーザの間の最初の１マイルに沿って延びるＤＳＬ回線と混同されてはならない。以下の明細書において、第３のリンクと第４のリンクという用語も示されるであろう。ここで用いられる用語では、第１のリンクと最初の１マイル、第２のリンクと２マイル目の間には、想像するかもしれないメンタルなつながりは存在しない。

単方向矢印１５は、ＡＤＳＬ２＋の送信モード［参考文献２］で約２４Ｍｂｐｓの最大帯域幅を有する個別ＤＳＬの各々が、２４Ｍｂｐｓの１０倍、すなわち２４０Ｍｂｐｓの帯域幅を有する１つの第１のリンク上で統合されるレベル、いわゆる第１の統合レベルを定義するアクセスノードを指す。ＢＲＡＳを指す単方向矢印１６で示す第２の統合レベルでは、各々が２４０Ｍｂｐｓの帯域幅を持つ２４個の第２のリンク上のトラヒックが統合されて、５．７６Ｇｂｐｓの帯域幅を有する１つのリンクになる［参考文献３］。

ＤＳＬ標準は、その技術がインターネットの世界に最適であり、しかもその技術に関わる導入コストが低いことから、この１０年間では最も普及している最初の１マイルのブロードバンドアクセス技術である。

ＤＳＬでは、一般電話サービス（ＰＯＴＳ）またはサービス統合デジタル網（ＩＳＤＮ）サービスを提供するのに従来用いられたツイストペアの銅線上の空きスペクトルが、デジタル変調されたデータを転送するのに用いられる。

非対称ＤＳＬ（ＡＤＳＬ）の概念によって、ユーザは上り方向でインターネットのどこかにあるサーバにデータ要求を送信し、要求されたデータを上り方向の１０倍〜２０倍の速度でインターネットから下り方向へダウンロードすることができる。ＡＤＳＬ２＋では、理論的には下り方向で最大２４Ｍｂｐｓ、上り方向で１Ｍｂｐｓが可能である。レートは回線の長さに依存するため、現実的には大半のＤＳＬで１０Ｍｂｐｓがサポートされる。ＶＤＳＬ２では、ＡＤＳＬ２＋の非対称レートの後継技術として、およそ８０／２０Ｍｂｐｓの非対称レートと、およそ５０／５０Ｍｂｐｓの対称レートが、およそ１ｋｍの長さの短距離回線上でサポートされる［参考文献４］。

従来からＡＤＳＬは、ベストエフォートのブロードバンドインターネットアクセスをユーザに提供する目的で広く使われている。サービスアクセスは、ＢＲＡＳによって完全に管理され、アプリケーションサーバに出入りするすべてのデータは、サービス方針によってユーザ・サービス・アクセスを制限するため、ＢＲＡＳを通過しなければならない。

最近になってヨーロッパの通信事業者各社が、トリプルプレイサービスを提供するために、すなわち、ビデオ、音声および従来のインターネットサービスを単一のＤＳＬで提供して加入者１人当りの平均売上（ＡＲＰＵ）を維持しあるいは増加させるために、自社のＤＳＬネットワークをアップグレードし始めた。従ってビデオサービス（同報ＩＰＴＶ、ビデオ・オン・デマンド）は、可能性と収入の点で最強の新規事業である。残念ながら、ビデオ関連サービスは、ＤＳＬネットワークに最高のサービス品質（ＱｏＳ）制約を課し、既存のネットワーク技術を実現可能性の境界線に追いやるサービスである。

ユーザによって要求されるビデオコンテンツがユーザ固有のものになればなるほど、より多くのトラヒックがＢＲＡＳから統合ネットワーク部分を通ってアクセスネットワークへとユーザに向って流れる必要がある。そのような状況では、ネットワーク内で帯域幅を加算する自分の個別のユニキャストトラヒックフローを各ユーザが要求するため、マルチキャストプロトコルをそれ以上使用することができない。転送、統合、およびアクセスネットワークの部分に過負荷状況が発生するという事実が原因で、図１に示すような従来のアクセススキームは、ユーザの必要性に完全に応じたビデオコンテンツを各ユーザに提供するには十分ではないことが分かる。

図１に示すネットワーク構造のようなネットワーク構造におけるＩＰＴＶマルチキャストは、図２に示す原則に従って機能する。ビデオサービスプロバイダは、ＢＲＡＳの後に位置するビデオ・ヘッド・エンドによってネットワークに供給される、異なるビデオチャネルＣＨ１およびＣＨ２を提供する。インターネットグループ管理プロトコル（ＩＧＭＰ）を介して、ユーザはＩＧＭＰグループ参加メッセージをＩＰＤＳＬＡＭへ送信することによってチャネルに加入する。ＩＰＤＳＬＡＭに接続している少なくとも１人のユーザがチャネルに参加する場合、ＩＰＴＶトラヒックはそのＩＰＤＬＳＡＭへストリーミング配信される。Ａとラベル付けされた一番上のグループでは、ユーザ１および４がチャネルＣＨ１を要求し、Ｂとラベル付けされた真ん中のグループでは、ユーザ１、３および４がＣＨ１を要求し、ユーザ６、８および１０がＣＨ２を見ることを要求した。Ｃとラベル付けされた一番下のグループでは、ユーザ６および８がＣＨ２を要求した。第１のビデオサービスプロバイダ（テレビ会社）によって提供されるＣＨ１は、ＢＲＡＳへ配信される。場合によっては別のサービスプロバイダ（テレビ会社）から配信されるＣＨ２も、ＢＲＡＳへ配信される。ＢＲＡＳから、ＣＨ１のコピー１部とＣＨ２のコピー１部が、第２のリンク上でイーサネット（登録商標）スイッチへストリーミング配信される。イーサネット（登録商標）スイッチでは、ＣＨ１がコピーされ、第１のリンクの一部上でグループＡおよびＢのＩＰＤＳＬＡＭへストリーミング配信される。グループＡのＩＰＳＬＡＭでは、ＣＨ１がコピーされてユーザ１および４へ配信され、グループＢのＩＰＤＳＬＡＭでは、ＣＨ１がコピーされてユーザ１、３および４へ配信される。イーサネット（登録商標）スイッチでは、ＣＨ２がコピーされ、他の第１のリンク上でグループＢおよびＣのＩＰＤＳＬＡＭへストリーミング配信される。グループＢのＩＰＤＳＬＡＭでは、ＣＨ２がコピーされてユーザ６、８および１０へ配信される。グループＣのＩＰＤＳＬＡＭでは、ＣＨ２がコピーされてユーザ６および８へストリーミング配信される。グループＡでは誰もＣＨ２を要求しなかったため、イーサネット（登録商標）スイッチはＣＨ２をグループＡのＩＰＤＳＬＡＭへストリーミング配信しない。同様に、ＣＨ１は、グループ内のどのユーザもそれを要求しなかったため、グループＣのＩＰＤＳＬＡＭへストリーミング配信されない。

このマルチキャスト状況では、あるチャネルにあるユーザがすでに加入している場合、そのチャネルに参加する別のユーザは、統合または転送ネットワーク内で帯域幅需要を増加させることはない。例えばグループＢのユーザ７がＣＨ１またはＣＨ２を見たいと望む場合、グループＢのＢＰＤＳＬＡＭは、対応する要求をユーザ７から受信し、それに応じてＣＨ１またはＣＨ２をもう１部コピーしてそれをユーザ７へストリーミング配信するであろう。

上記の例で、第２のリンク上の帯域幅要件は、チャネルＣＨのそれの２倍である。一般に、第２のリンク上の帯域幅要件は、それが転送するチャネルの数に比例するであろう。同様に、１つの第１のリンク上の帯域幅要件は、そのリンクが転送するチャネルの数に比例する。すでにストリーミング配信されているチャネルを見ることを望むユーザがさらにもう１人あったとしても、それが第２のリンク上の帯域幅需要を増加させることはないであろう。もう１人のユーザが、チャネルがすでにそれに対してストリーミング配信されているグループに属する場合、第１のリンク上の帯域幅需要は、増加しないであろう。もう１人のユーザが、望むチャネルがまだそれに対してストリーミング配信されていないグループに属する場合、そのユーザが属するグループに対する（第１の）リンク上の帯域幅需要は、チャネルＣＨが必要とする量だけ増加するであろう。

上記のマルチキャスト状況では、ユーザのためのコンテンツの柔軟性が非常に限定的であることは明らかである。ユーザは、ライブＴＶチャネルの集合から選択できるだけであって、ストリーミング配信されたコンテンツの概略を描く手段を有しない。特に、本当のビデオ・オン・デマンドはサポートされない。本当のビデオ・オン・デマンド（ＶｏＤ）とは、ユーザが映画を自分の都合のよいときに何時でも見始めることができることを意味する。マルチキャスト状況では、ユーザは映画が活動状態になるまで待つ必要がある。映画はマルチキャストされる場合に活動状態になるが、それは典型的には、１日のうちで何らかの所定の時間に起こるかまたは十分な数のユーザが同じ映画を要求した場合に起こる。また、本当のＶｏＤとは、ユーザが、例えば映画を前に進めたり、後に戻したり、早送り再生や高速巻き戻し再生をする目的で、映画の再生中で映画を開始、停止、一時停止することのような、映画の中のビデオ録画も制御できることも意味する。ビデオ録画はマルチキャスティングでは不可能である。また、本当のＶｏＤとは、ユーザが、例えば字幕や他言語の音声トラック等の特別の情報をビデオに追加できることも意味する。

ユーザによって要求されるビデオコンテンツがユーザ固有のものになればなるほど、より多くのトラヒックがＢＲＡＳから統合ネットワーク部分を通ってアクセスネットワーク上でユーザに向って流れる必要がある。そのような状況では、ネットワーク内で帯域幅を合算するその個別のユニキャストトラヒックフローを各ユーザが要求するため、マルチキャストプロトコルをそれ以上使用することができない。

また、既存ネットワーク内のマルチキャスティングの場合には、各統合レベル上のミスマッチが原因でサービス品質（ＱｏＳ）の問題が持ち上がるであろう。第１の統合レベル上で、各々が実際には約１０Ｍｂｐｓのオーダで帯域幅を提供している１対のＤＳＬ回線１２が、約１００〜２００Ｍｂｐｓを提供できる第１のリンク９上で統合される。典型的には、１００Ｍｂｐｓのレートを有する１つの第１のリンク上には、各々が１５Ｍｂｐｓのレートを有するＤＳＬが１０個統合される。１０個のＤＳＬによって利用可能な帯域幅資源全体（すなわち１５０Ｍｂｐｓ）を完全に使用するには、第１のリンクは過負荷状態になって１５０Ｍｂｐｓを搬送する必要があるだろう。同様の問題が、約１〜５Ｇｂｐｓのオーダで帯域幅を提供する第２のリンク１１上で複数の第１のリンク９が統合される、第２の統合レベルにも存在する。複数の第１のリンクで利用可能な帯域幅を完全に使用できるようにするには、第２のリンクは、過負荷状態になる必要がある。入口帯域幅は、出口帯域幅とは異なることから、ミスマッチが発生して品質が劣化する。これは、各統合レベルで発生する。従って、帯域幅に関する品質の問題は、各統合レベルで発生し、それが送信に関する品質の問題になる。これらの問題は関連している。多くのリンクが統合される弱いリンク上で帯域幅が十分でない場合には、その弱いリンクが過負荷状態になる必要があることから、適正な送信品質が得られない。一定の送信品質を維持し、かつ、弱いリンクを過負荷にしないことを望むならば、多くの統合リンクの利用可能な帯域幅資源は、完全には利用されない。

既存のマルチキャスト技術の場合のもう１つの問題は、チャネル切り替えに関する。ユーザが第１のプログラムから第２のプログラムへ切り替えることを望み、かつ、第２のプログラムはユーザにサービス提供しているＩＰＤＳＬＡＭでは利用できないと仮定する。その場合、そしてＩＧＭＰプロトコルに従って、対応するチャネル切り替え命令が、ＩＰＤＳＬＡＭからイーサネット（登録商標）スイッチを介して、マルチキャスティングを制御するＢＲＡＳまで伝搬する。ＢＲＡＳは、必要なステップをとり、ユーザのＩＰＤＳＬＡＭへ信号を送信するであろう。ＩＰＤＳＬＡＭはシグナリングに反応し、最終的にチャネルが切り替えられるであろう。チャネル切り替え命令とユーザが第２のチャネルを見る時刻との間に経過する時間は、かなりかかり、数百ミリ秒のオーダであり、ユーザはマルチキャストシステムを遅くてのろのろしていると感じる。

柔軟なコンテンツを各ユーザに提供するという問題に対して考えうる解決策は、ユニキャストルーティングを用いてコンテンツを配信することであろう。プログラムのユニキャストとは、ＢＲＡＳが、個人に合わせた、すなわち個別の、ストリームを各ユーザに提供することを意味する。そのような場合、第１および第２のリンク上の帯域幅需要は、そのリンクに接続するユーザの数に比例する。典型的には１つのチャネルは、約５Ｍｂｐｓのオーダの帯域幅要件を有するため、これは、１０万人のユーザが、第１および第２のリンクが５００Ｇｂｐｓのビットレートを必要とするであろうということを意味する。今日、２マイル目の回線への手ごろな経済投資でこれを実現するのは不可能である。

図３は、帯域幅要件対ユーザ数を３つの異なる場合、すなわち曲線１７、１８および１９についてそれぞれ示す図である。あるチャネルが、５Ｍｂｐｓの帯域幅要件を有すると仮定する。曲線１７は、マルチキャスティングの最悪の場合を表す。曲線１７の急坂部分は、チャネル数が増加するにつれて帯域幅需要が増加する様子を示す。曲線のこの部分の間は、最悪の場合、別の視聴者がそれぞれ新たなチャネルを要求すると想定されている。例えば、４０人の異なるユーザが４０種類の異なるチャネルを要求した場合、曲線１７上の帯域幅は、２００Ｍｂｐｓに達する。次いで、別のユーザが新たにグループに参加し、これらの新たな別のユーザが、４０個のチャネルのいずれかを視聴することを望む。帯域幅需要は、曲線１７の水平部分で表わされるように、別の新たなユーザの数に関わらず増加しないであろう。

曲線１８は、曲線１７と同様であり、経験のある場合の４０個の異なるチャネルのマルチキャストに関連する。曲線１８の急坂部分は、チャネル数が増加するにつれて帯域幅需要が増加する様子を示す。曲線のこの部分の間は、最悪の場合と同様、１０人の異なるユーザがそれぞれ、新たな映画を要求すると想定されている。その後、曲線１８のゆるやかな坂の部分で表されるように、別のユーザがグループに参加し、その別のユーザの一部は、すでに活動状態となっている映画を要求し、一部は新たな映画を要求し、時間と共に全部で４０個の異なるチャネルが要求されるまでそれらが行われる。

曲線１９は、個別のプログラムがユニキャスト技術を用いてユーザへ送信される場合に必要とされる帯域幅を表す。各ユーザは、この場合、自分自身のデータのストリームを提供され、そのようなストリームはそれぞれ、ＢＲＡＳによって個別化される。従って本当のＶｏＤが提供される。この場合、帯域幅需要はユーザの数に比例する。データ材料の個々のストリームは、約５Ｍｂｐｓおよびユーザのオーダで帯域幅需要を有する。個々のストリームを何百万人ものユーザに配信するのにユニキャストが用いられる場合、ＩＰネットワーク内および２マイル目のネットワーク内に重い過負荷の問題が生じるであろうことは明らかである。

転送、統合、およびアクセスネットワークの部分に過負荷状況が発生するという事実が原因で、図２に示すような従来のアクセススキームは、ユーザの必要性に完全に応じたビデオコンテンツを各ユーザに提供するには十分ではないことが分かる。

本発明の目的は、上述した不利な点を回避し、独立請求項に従って分散サーバフレームワークおよびサーバを向上させることである。

以下に列挙して番号を振った利点が、本発明を使って達成される。詳細記述の中で、それらを各々の番号を用いて言及するであろう。これによって、言葉の反復が回避されるであろう。

［利点１］本発明によって達成される利点は、人気のあるデータ材料がユーザに近いアクセスサーバ内に記憶され、それによってデータ材料がストリームされる必要のあるリンクの数を削減することである。データ材料のプロバイダとユーザの間のギャップが削減され、人気のあるデータ材料は、最初の１マイル上でストリーミング配信されるだけでよい。そのようにして、ネットワークの過負荷（ネットワークの輻輳）が予防され、すべてのリンクが最適に利用できる。

［利点２］分散サーバフレームワークのサーバ間にデータ材料の断片を配信するためにファイル共有技術を利用することによって、分散サーバの各々の中で利用可能な記憶容量が相互に結合される。データ材料の１つの断片が１つのサーバ上に記憶され、別の断片が別のサーバ上に記憶される。分散サーバフレームワークの１つ１つのサーバがいずれも記憶のために用いられるため、全体的な記憶要件を削減することも可能である。また、ファイル共有プロトコルは、記憶されることになるデータ材料の断片をサーバ間に等しく配信し、それによって記憶のバランシングを図る。

［利点３］データ材料の異なる断片を異なるサーバ上に記憶させることによって、異なる断片を異なるサーバから取ってきて、それらを正しい順序で結合させ、データ材料全体のコピーをユーザに対してストリーミング配信することができる。サーバは、データ材料全体のコピーを記憶する必要はなく、データ材料の断片を記憶するだけで十分である。ユーザは、サーバ同士の結合された記憶容量である、異なるサーバ上に記憶されたデータ材料のすべてを、自分の思いどおりにすることができるであろう。

［利点４］中央サーバに投入されるデータ材料は、正しい順序の断片として細かく切断され、各断片は記録されてメッセージ認証コードが添付されるであろう。サーバフレームワーク内に投入されるデータ材料の断片はいずれも、記録され、認証を受ける。従って、不要なデータ材料を敵対ユーザがアップロードすることは不可能である。

［利点５］データ材料は、分散サーバフレームワーク内の中央サーバへ一度投入されるだけでよい。コピーを投入する必要はなく、従って、分散サーバフレームワークの記憶容量を減らすことができる。

［利点６］トラッカによってサポートされるファイル共有プロトコルが、断片が帯域幅に関して常に最適な状態で交換されるように管理する。従ってフレームワーク内のすべてのリンクは最適なかたちで利用され、負荷バランシングが達成される。

［利点７］さらに、結合された記憶容量は、データ材料の重複コピーを記憶するのを回避することによって、データ材料のスマート記憶として用いられる。これによっても、アクセスネットワークの最初の１マイルの中の帯域幅が節約できる。

［利点８］本発明の分散サーバフレームワークは、容易に拡張できる。ユーザ数が増加した場合、既存のサーバフレームワークに対応する数のアクセスサーバおよびエッジサーバを追加するだけで十分であろう。

［利点９］本発明の分散サーバフレームワークは、本当のＶｏＤと個別のユーザストリームとを提供する。

［利点１０］ＩＰＴＶのチャネル間の切り替えは迅速であり、少ない待ち時間で行われる。

［利点１１］本発明の分散サーバフレームワークによって、チャネルを視聴しながら同時にチャネルの個人的なビデオ録画（ＰＶＲ：Private Video Recording）ができる。

［利点１２］分散サーバフレームワークは、例えばビデオ、音楽、データなど、原則としてすべての種類のデータ形式を分散して交換するのに使用することができる。

［利点１３］本発明の分散サーバフレームワークは、例えば従来型のツイスト銅線および無線など、いかなるタイプのアクセスメディアと共に使用することもできる。

トリプルプレイサービスをユーザに提供するための従来型ネットワークを示す図である。 図１に示すネットワークの中のＩＰＴＶのマルチキャストルーティングを示す図である。 帯域幅要件とユーザ数との関係をマルチキャストルーティングとユニキャストルーティングとを用いてそれぞれ示す図である。 本発明による分散サーバフレームワークのサーバトポロジを示す図である。 トリプルプレイサービスをユーザに提供するため既存のネットワーク上に実施された、本発明の分散サーバフレームワークを示す図である。 本発明による分散サーバフレームワークの一部を示す図であり、図７に関連すべきである。 サーバがファイル共有プログラムを使用する場合に、本発明による分散サーバフレームワーク内でコンテンツがどのようにして広められるかを示すフローチャートである。 スライドウィンドウ・メカニズムを示す図である。 本発明による分散サーバフレームワークの一部であり、多様な時刻に行われるユーザの要求を示す図である。 図９に示すユーザに適用される、スライドウィンドウの原理を示すタイミング図である。 本発明による中央サーバ（ＣＳ）のブロック図である。 本発明によるエッジサーバ（ＥＳ）のブロック図である。 本発明によるアクセスサーバ（ＡＳ）のブロック図である。

図４は、本発明の分散サーバフレームワークのトポロジを示す。これは、中央サーバ（ＣＳ）２０と、複数のエッジサーバ（ＥＳ）２１と、複数のアクセスサーバ（ＡＳ）２２と、第１のリンク９と、第２のリンク１１と、第３のリンク２３と、第４のリンク２４と、第５のリンク２５と、そしてファイル共有クライアント／サーバプロトコル２６とを含む。第３のリンクと第４のリンクとは、必ずしも専用物理リンクではない。アクセスサーバはＡＳグループ３０、３１、３２を形成する。各ＡＳは、第５のリンク２５上でＩＰＤＳＬＡＭ８に接続する。ユーザのグループＡ、Ｂ、Ｃなどは、それらのそれぞれのＤＳＬ回線１２上で関連のＩＰＤＳＬＡＭに接続する。

各ＡＳグループ３０〜３２は、それぞれのアクセス領域３３、３４、３５に属する。アクセス領域は、典型的には、主要都市ネットワークの一部であり、例えばストックホルムやベルリンのような首都の北部、南部、西部、東部である。各ＡＳグループでは、各ＡＳは、それぞれの第１のリンク上でそれぞれのＥＳに接続する。各アクセス領域には、１つのＥＳがある。ＥＳは、アクセス領域と転送ネットワーク３の間のエッジ部分に所在する。ＣＳは、転送ネットワークに接続し、例えばサービスプロバイダの接続点（ＰｏＰ）に所在する。

領域内のＡＳ同士は、第３のリンク２３によって相互接続され、他方、ＥＳ同士は第４のリンク２４を介して領域間で接続する。

ＡＳ、ＥＳ、ＣＳはそれぞれ、四角形で象徴的に示すファイル共有クライアント／サーバプロトコル２６を有する。分りやすくするため、アクセスサーバ内のファイル共有クライアント／サーバプロトコルは、絵を不明確にする恐れがあるため各ＡＳでは示しておらず、その代わり、ファイル共有クライアント／サーバプロトコルは、ＡＳグループ３０〜３２の各々の中に示す。

好適実施形態において、ＡＳとＥＳとＣＳとを備えたサーバフレームワークは、既存のデータネットワークへの重畳ネットワークを形成し、その場合、サーバ同士はデータネットワークの既存のリンクを用いて相互接続される。第１および第２のリンク９および１１は、それぞれ既存のネットワークの一部であって、アクセスサーバおよびエッジサーバは、この場合、それ自体が知られているかたちでデータネットワークに接続することが望ましい。実装によっては、ＥＳ同士がＣＳおよび第２のリンクを介して相互接続されてもよく、その場合、第４のリンクは物理リンクではない。グループのＡＳ同士が、同様に、第１のリンク９上でＥＳを介して相互接続されてもよく、その場合、第３のリンク２３は物理リンクではない。上記の利点［利点８］は、重畳の概念を使って達成される。

図４に示す実施形態では、ＡＳは１つのＩＰＳＳＬＡＭに接続する。代替的実施形態では、ＡＳは、図５に示すように２つのＩＰＤＳＳＬＡＭに接続する。

図５は、既存のネットワークを示し、そこにアクセスサーバとエッジサーバと中央サーバとが重畳ネットワークとして接続している。既存のネットワークが、３つのアクセス領域３３〜３５を備えていて、そのそれぞれが３３に示す構造に似た構造を有しており、かつ、それぞれが複数のＩＰＤＳＬＡＭ８と、イーサネット（登録商標）スイッチ１０と、領域サーバ２７とを備える様子を示す。ユーザは、ローカルループ７の中でＤＳＬ１２上でＩＰＤＳＬＡＭに接続する。ＩＰＤＳＬＡＭは、第１のリンク９によって２つのイーサネット（登録商標）スイッチ１０に接続する。２つのイーサネット（登録商標）スイッチは、リンク３８によって共通イーサネット（登録商標）スイッチ３７に接続する。共通イーサネット（登録商標）スイッチ３７は、リンク４０によってエッジノード３９に接続する。各アクセス領域は、それぞれのリンク４０によってこのようにエッジノードに接続する。

既存のアクセス領域の一例として、エリクソンによって提供されるＥＤＡシステムがある。ＥＤＡシステムは、そのようなシステムの顧客に利用可能であるＡＤＳＬ／ＶＤＬＳ２を利用したフレキシブルアクセスシステムである［参考文献３］。

３つのアクセス領域が一緒になって地域領域４１を形成する。エッジノードは、地域領域と転送ネットワーク３の間の端部に所在する。地域領域はさらに、そこからアクセスネットワークが操作される、オペレーションセンタ４２を備える。

典型的には、複数の地域領域が存在し、その各々が、地域領域と転送ネットワークの間に所在するエッジノード３９を有する。多くの地域領域は一緒になって、全国的なアクセスネットワークを形成する。

図５に示す各アクセス領域では、アクセスサーバＡＳがイーサネット（登録商標）スイッチ１０に接続し、エッジサーバＥＳがエッジノード３９に接続し、そして中央サーバＣＳが転送ネットワーク３に接続し、それによって本発明による分散サーバフレームワークを形成する。

図５の一番下の部分では、最初の１マイルの延長部分を、双方向矢印１３で示し、２マイル目の延長部分を、双方向矢印１４で示す。

サーバフレームワークは、ピアツーピア（Ｐ２Ｐ）のデータ共有ネットワークのように機能する。関与するプロトコルは、ファイル共有プロトコルの修正バージョンである。ファイル共有プロトコルの例として、Ｂｉｔｔｏｒｒｅｎｔ（ビットトレント）、Ｇｎｕｔｅｌｌａ（グヌーテラ）などがある。

ビットトレントプロトコル
ビットトレントプロトコルの一般的な説明は、［参考文献５］で入手可能である。ビットトレントは、人気のあるファイルを効果的にダウンロードするためのファイル共有プロトコルであって、ある種のＰ２Ｐネットワーキングのかたちでダウンロード支援ソフト同士を相互に支援させる。効果的なダウンロードは、ユーザがダウンロードした全データ量の断片が、この断片を受信していない他のユーザにもさらに配信されるという事実に起因する。

ビットトレントは、ユーザ同士が小さな断片を相互にアップロードすることによって、ファイルをできるだけ速くできるだけ多くのユーザに転送するというタスクに焦点を合わせる。同じファイルに関心を持つユーザのグループをｓｗａｒｍ（スワーム：群れ）と呼ぶ。

例えば封切り間近な映画の予告編のような、人気のあるファイルについての共通の問題は、それらが公開された直後に多くの人々がファイルを欲しがることである。これがユーザのマシンやネットワーク接続を過負荷状態にするであろうし、それらがダウンロードされるまで皆がいたずらに長く待たなければならない。ビットトレントを使うと、皆へのダウンロードがより迅速になり、スワームが拡大し、従って上記の利点［利点３、利点６］が達成される。ビットトレントプロトコルは、ファイルを小さな部分または断片に分解する。不足している部分をピア同士が相互にダウンロードし、すでに所有している部分を、それらを要求するピアへアップロードする。

ダウンロードするのは容易である。ファイルのダウンロードを望む各人が、最初に「トレントファイル」をダウンロードし、次いでビットトレント・クライアント・ソフトウェアを開く。トレントファイルは、クライアントに「ｔｒａｃｋｅｒ（トラッカ）」のアドレスを教える。トラッカは、どのユーザがファイルをダウンロードしているのか、および、ファイルとその部分がどこに存在するのかのログを維持する。クライアントは、それがまだ有していない最も希なブロックを要求してそれを取り込む。次いで、そのブロックをアップロードする相手先を探し始める。このようにして、ユーザマシン間でファイルが共有される。

「ｔｏｒｒｅｎｔ（トレント）」は、１つの「トレントファイル」かまたはそれによって記述されるすべてのファイルを意味する。

「トレントファイル」は、名前、大きさ、チェックサムを含めて、それがダウンロード可能にするすべてのファイルについてのメタデータを含む。「トラッカ」のアドレスも含む。

「ｔｒａｃｋｅｒ（トラッカ）」は、どのシードおよびピアがスワームの中にいるのかを追跡するサーバである。クライアントは、情報をトラッカに定期的に報告する。「ピア」は、不足している断片を見つけるべき場所をトラッカに尋ねる。

「ｐｅｅｒ（ピア）」は、ユーザの接続先でありデータの転送先である、インターネット上のコンピュータ上で実行されるビットトレントクライアントの１つの例である。一般にピアは、完全なファイルを持つのではなく、その一部のみを持つ。

「ｓｅｅｄ（シード）」は、「トレント」の完全なコピーを有するピアである。「シード」が多ければ多いほど、ファイルが完成する可能性が高い。「シード」は、材料を他の「ピア」へアップロードしている。

「ｌｅｅｃｈ（リーチ）」は一般に、非常に共有割合が低い「ピア」であり、「リーチ」がアップロードする材料よりダウンロードする材料の方がかなり多い。

「ｓｕｐｅｒｓｅｅｄｅｒ（スーパーシーダ）」は、初めてアップロードされる材料をシードする。「スーパーシーダ」は通常、ダウンローダが完成し始める前に、少なめのビットをアップロードする。それによって重複部分のアップロードが厳しく制限される。

ビットトレントを使えば、すべてのユーザは新たな材料をネットワークに投入して、それをシードし始めることができる。違法の材料が投入されることすら、ありうる。

スーパーシーダが断片を失うと、他の誰も１００％正しいファイルをダウンロードできない。

本発明による修正されたファイル共有プロトコル
本発明の好適実施形態では、ビットトレントプロトコルの修正バージョンが用いられる。修正されたビットトレントプロトコルによれば、ユーザマシン、典型的にはＰＣおよびセットトップボックスは、ファイル共有には含まれず、すなわち、それらはそのプロトコルを持たない。アクセスサーバとエッジサーバと中央サーバとだけが参加する。アクセスサーバがビットトレントプロキシとして動作する。

本発明の分散サーバフレームワークで使用されるファイルプロトコルは、ビットトレントプロトコルから受け継いだものである。さらに上記の修正に加えて、ビットトレントプロトコルは、ＩＰＴＶネットワーク内のストリーミングビデオ要件に適合するように若干修正されている［利点３］。従来型のインターネット・ビットトレント・ネットワークと本書で考察中の分散ビデオサーバ・フレームワークとの間では、複数の相違点が指摘されうる。

・従来型のトレントネットワークでは、ファイルの多様な断片が多様なソースから同時にダウンロードされ、それらの断片のダウンロード順序は、すべての断片がネットワーク内で入手可能である場合、大きな影響を与えない（通常は、希な断片の優先度が高い）。ＩＰＴＶネットワークでは、映画は時間的には直線的に視聴され、従って、映画の断片は、それらが必要なときに利用可能となる必要があり、断片がユーザに提示される順序は重要である。従って、優先度付与アルゴリズムが、コンテンツによって与えられる。視聴されることになる断片の提供が、最高の優先度を有する。後で必要となる断片の優先度は低い。優先度付与アルゴリズムを実装するため、以下に記述するスライドウィンドウおよびカーソルメカニズムが用いられる。スライドウィンドウおよびカーソルメカニズムは、ファイル共有プロトコルの新規の修正である［利点３］。

・従来型のトレントネットワークでは、さまざまなクライアントが、さまざまなアップロード／ダウンロード帯域幅を有する。協力的なファイル共有を実現するため、これらの帯域幅の相違を考慮に入れなければならない。さらに、代償サービスとしてのアップロードをせずにダウンロードすることである、いわゆるリーチングおよびスタッビングを禁止するため、セキュリティ手段を提供しなければならない。本発明による分散サーバフレームワークなら、環境が友好的であって全てのサーバが信頼できるため、そのようなセキュリティ手段はまったく必要ない。統合レベルのすべてのクライアントプログラムは、帯域幅の構成および連携が同等であり、取引は友好的で協力的な環境で行われる。本発明による分散サーバフレームワークは、不正を行おうとする敵意のあるユーザのいない管理されたネットワークである［利点４］。

本発明による修正されたファイル共有プロトコルの場合、データ材料をサーバフレームワーク内に投入することを許可されるのは１つのノードだけであり、それは、中央ノードである［利点４］。

本発明による修正されたファイル共有プロトコルの場合、ビットトレントプロトコルと関係する必要があるため、ピアは完全なファイルをダウンロードする必要がなく、ファイルのうちの複数の断片だけをダウンロードすればよい。これは、ダウンロードされた材料が、下記のカーソルおよびスライドウィンドウ・メカニズムに従ってユーザへストリーミング配信されるからである［利点２、利点６］。

本発明による修正されたファイル共有プロトコルの場合、エッジサーバおよびアクセスサーバは、ユーザが要求する断片をそれらが有するならば、常に断片をシードし／アップロードしている。

もう１つの修正は、ファイル共有プロトコルの中でのヒットリストの使用である。大雑把に言うと、ヒットリストは、ファイルの個々の断片がアクセスサーバ上およびエッジサーバ内のデータベースにそれぞれ記憶される時間を制御するために用いられる。各サーバ上の各断片は、それ自身のヒットリストを有する。ある断片が要求されるたびに、その断片のヒットリストが１つずつ増加する［利点２、利点６］。

人気のある材料はアクセスサーバ上に記憶される。構成可能な最初の時間帯の間に、ＡＳ上に記憶された断片を誰も要求しなかった場合、その断片はＡＳから削除される。このようにして、ＡＳは人気のある材料だけを記憶するであろう。従って、断片が要求されるたびに、所定の時間帯は延長されてもよい。例えば、第１の時間帯は、時間のエリアまたは曜日のエリアに存在する［利点１］。

それほど人気のない材料は、エッジサーバに記憶される。第１の時間帯より長い、構成可能な第２の時間帯の間に、ＥＳ上に記憶された断片を誰も要求しなかった場合、その断片はＥＳから削除される。このようにして、ＥＳは、それほど要求されない材料、すなわち、それほど人気のない材料を、記憶する。断片が要求される度に、所定の時間帯が延長されてもよい。例えば、所定の第２の時間帯が、週のオーダとなる［利点１］。

めったに要求されない、従って人気のない材料は、中央サーバ上に記憶される。ＣＳ上に記憶された断片に関しては、ヒットリストは必要ない。

新規のビデオコンテンツ、例えば映画が、ＣＳに投入され、そしてそこから、ユーザからの要求があった時点でＥＳおよびＡＳに配信される。そのような要求は、ＤＳＬ上でアップリンクでＲＴＳＰプロトコルを用いてＣＳへ送信される［利点６］。従ってＣＳは、映画を含むファイルを、順序付けられたアドレス可能な数の断片に、例えば１メガバイトの断片に分割する。ダウンロードが始まると、ＣＳは、他のサーバが映画の断片を有しないため、スーパーシーダとして動作する。スーパーシーディングモードでは、ＣＳは、多様なプロトコルのクライアントへ向けた複数のダウンロードを可能にする。関与するＥＳおよびＡＳは、ダウンロードされた断片を記憶して、それらを使って取引を開始することができる。ＣＳは、ＣＳへ投入された各映画の各断片について、サーバフレームワーク内のどのサーバに断片が現在記憶されているかを示すリストを維持する。この拡散の段階では、データ断片は、ＥＳとＡＳの間に公平なかたちで相互に交換される［利点６］。ＣＳ内のトラッカが、映画のどの断片が分散サーバネットワーク内のどこに記憶されるかについての情報を保持するリスト（トラッキング・リスト）をデータベース内に維持する。従って、ユーザが新たな断片を要求する場合、トラッカが、これらの断片を最も効率よく取得する場所についての情報を提供する。ＥＳトラッカは、それに接続するアクセスサーバ上に記憶されたすべての断片のＩＤとアドレスとを知っている［利点２、利点１２］。

各ＡＳおよびＥＳについてのダウンロード／アップロードの帯域幅は対称的であり、すなわち、各サーバは、必要な断片を入手したり断片を提供したりすることに関しては、公平なやりとりをしている。ビットトレントの場合のように、ファイル共有サーバ間で報復ゲームが行われて、大域的なパレート効率が得られる［利点２］。

サーバが入手した各断片は、データベース内に記憶され、構成可能な有効期限までそこに保持される。ある断片についての新規ダウンロード要求（ヒット）があれば、それはファイルが人気があって使用率が高いことを示すことから、有効期限を延長することができる。各サーバの記憶スペースは限られているため、ヒットリストは、メモリ内に保持する断片の優先度（寿命優先度）を定義する。ＥＳとＡＳとは帯域幅および記憶に対する制約が異なるため、サーバ上に保持されるデータ量とデータの種類とが異なる［利点１、利点２］。

この方針を使うと、拡散段階は、絶対に新しい材料がＣＳによってスーパーシードされるかまたは、非常に古くてめったに要請されない材料がＣＳからダウンロードされるかのいずれかの状態に至るであろう。次いでＥＳは、利用可能なメモリが多めであって有効期限が長めであるという事実に起因して、多少古めの材料を保持する。ＡＳは、頻繁に要求される最新のデータ材料の断片だけを保持する［利点１］。

この動作は、ビデオ関連材料の典型的なダウンロード統計に対応している。新規コンテンツが入手可能となる場合、若干の時間遅延の後で人気が出て、そして需要が大いに高まる。その後、要求数が急激に減少し、帯域幅需要も激減する。

ＣＳは、サーバ階層の中の最高位のサーバであり、その中で用いられるトラッカは、スーパートラッカと呼ばれる。またＣＳは、新規材料が最初に投入されるサーバである。ＣＳに投入された材料は、ＣＳ上に記憶される。それは常にユーザが利用可能であり、原則として決して削除されない。従ってＣＳは、接続しているサーバによってダウンロードされうる完全なファイルを記憶する。ファイルをダウンロードしてファイルの断片を記憶する、ネットワーク内の各サーバは、いわゆるファイルのスワームに追加され、そしてトラッカは、ファイルの断片が見つかる可能性がある場所を尋ねられてもよい（トラッキング機能）。サーバ上のプロトコルクライアントは、完全なファイルがロードされるまで、ファイルの断片を相互に交換する。完全ファイルを有するクライアントは、ファイルがメモリから削除されない限りシーダとして機能する。

従って中央サーバは、すべてのソースコンテンツ材料を最大限含む、トラッキング機能付きのスーパーシーダとして動作する［利点１２］。エッジサーバおよびアクセスサーバは、断片だけを記憶するリーチャ／シーダのように動作する。ＤＳＬに接続するユーザは、純粋なリーチャとして動作し、いかなるデータ材料もアップロードしない。新規データがネットワーク内で配信され、需要が多い場合には、完全なコンテンツが直接エッジサーバにコピーされてもよく、そうすればエッジサーバがスーパーシードを行い、それによって拡散モードの開始時点でのＣＳ上の満載状態を軽減させることになる。またエッジサーバが、ＣＳのシード負荷を軽減するためにスーパーシーダとして動作してもよい。文書の断片がエッジサーバまたはアクセスサーバ上で完全に捕捉された場合、このサーバは、コンテンツが手動でサーバから削除されるかまたはヒットリストによって寿命として削除されるまで、所定の時間帯はシーダとして動作（他者が必要とする何らかの材料をそれらが保持する場合には常にアップロードする）する。そのようなやり方で、１つのファイルの異なる断片が、可能な限り近くにあるサーバからダウンロードされるであろう。従って、中央サーバから２番目のリンク上のロードは、軽減される。この構造は、図２の記述に関連して概説した諸問題を解決する。

アクセスサーバおよびエッジサーバは、ネットワーク内に分散されるかたちで構成されているため、トラヒック負荷を共有する第１のリンクおよび第２のリンクがたくさんあり、従って、第１の統合レベルおよび第２の統合レベル上の帯域幅が増加し、それによってミスマッチを減らし、配信されるデータ材料のＱｏＳを高めるであろう。言い換えれば、ユーザがデータ材料を入手できるリンクが増加する［利点１］。

ここで図６を参照するが、図６は、修正されたファイル共有プロトコルによる各種コンテンツ配信状況を示すのに用いられる構成を示す。図７を図６と比較しやすくすることを目的として、この図では、短い引用符号を用いる。１つの中央サーバＣＳ１が、２つのエッジサーバＥＳ１およびＥＳ２に接続する。ＥＳ１には、２つのアクセスサーバＡＳ１，１およびＡＳ１，２が接続し、他方、ＥＳ２には、１つのＡＳ２，１だけが接続する。ＡＳ１，１には、２人のユーザ１，１，１および１，１，２が接続する。ＡＳ１，２には１人のユーザ１，２，１が接続する。ＡＳ２，１には、ユーザ２，１，１が接続する。コンテンツは、文書の断片であってもよいし、その意味で文書全体であってもよい。

ここで、７つの異なるコンテンツ配信の事例を示す図７を参照しよう。

事例１：
ユーザ１，１，１が、ＣＳでしか入手できないコンテンツを要求する。ＥＳ１の中のトラッカが、要求について責任を持っており、自分のトラッカリストの中にレコードを有していないため、要求をＣＳへ転送する。ＣＳ内のトラッカリストは、要求されたコンテンツについては空であり、従ってコンテンツはＣＳ自身によってＡＳ１，１を介してユーザへストリーミング配信される。ＥＳ１が、送信をインターセプトし、ＡＳ１，１へ中継されるコンテンツを記憶する。ＣＳおよびＥＳは、自分のトラッキングリストを更新する。

事例２ａ：
ユーザ１，１，２が、ユーザ１，１，１と同じコンテンツを要求し、そしてＥＳ１が、有用なウィンドウ（ユーザ１，１，１のためのもの）をＡＳ１，１が提供できることを示す。そこで次にＡＳ１，１は、要求されたコンテンツを直接ユーザ１，１，２へストリーミング配信する。スライドウィンドウとカーソルメカニズムに関しては、図８〜１０と、対応する以下の文章とを参照されたい。

事例２ｂ：
ユーザ１，１，２が、コンテンツを要求するが、カーソルが遠すぎるため、ユーザ１，１，１のウィンドウを使用することができない。ＥＣ１が、（トラッカリスト内でチェックされた）コピーをまだ有していることから、それがユーザへストリーミング配信されてヒットリストが更新される。

事例３ａ：
ＡＳ１，２上のユーザ１，２，１が、同じコンテンツを要求する。ＥＳ１が、そのＡＳ１，１または１，２上で適切なウィンドウを見つけた場合、コンテンツを直接サーバから使用することができる。両方のサーバがウィンドウを有する場合、近い方のサーバ、すなわちＡＳ１，２が使用される。ＥＳ１上のトラッカおよびヒットリストが更新される。

事例３ｂ：
ユーザ１，２，１が、そのＥＳ１を介してコンテンツを要求するが、どのＡＳも適切なウィンドウを持っていない。コンテンツがＥＳ１上に記憶されている場合、コンテンツはＥＳ１から引き出され、ヒットリストは更新される。そうでない場合、不足している断片を見つけるのをトラッカリストが支援する。

事例４ａ：
ユーザ２，１，１が、すでにＥＳ２上に位置するコンテンツを要求している。コンテンツは直接ＡＳ２，１へ転送される。

事例４ｂ：
ユーザ２，１，１が、ＥＳ２上には見つからないコンテンツを直接要求する。ＥＳ２内のトラッカリストは、要求されたコンテンツのコピーがＥＳ１上にあることを示し、そこからコンテンツがＥＳ２へ転送されて記憶される。ＥＳ２上のトラッカリストが更新されて、コンテンツがヒットリストに追加される。

図８は、スライドウィンドウおよびカーソルメカニズムを示す。ＣＳは、コンテンツファイルを断片の順序正しいシーケンスに分割して、各断片に連続番号を振っている。ファイル共有プロトコルは、断片がさまざまなサーバ上に記憶されるように、断片をサーバフレームワーク全体に拡散させている。映画は直線的に視聴されるが、すなわち、視聴者に提示される断片は正しい順序で現れなければならない。例えばリアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）のようなストリーミングプロトコルは、断片を順序正しいシーケンスでユーザにストリーミング配信しなければならない。これを実現するためにスライドウィンドウおよびカーソルメカニズムが用いられる。ユーザのＡＳには、断片用のバッファがあり、このバッファに断片がロードされるべきである。図８では、再構築されてＡＳからユーザへストリーミング配信されることになるファイルを４３で示す。その断片は、断片１、断片２などのように記されている。最初に、プログラムソフトウェアのかたちで実施されるメカニズムは、スライドウィンドウ４４を備えており、このウィンドウは、矢印４５で示すように、時間と共に直線的に移動すると考えることができる。カーソル４６が、スライドウィンドウに関連付けられる。このカーソルは、上記の優先順位アルゴリズムの一部であって、ユーザにストリーム配信されている断片、すなわちユーザが現在視聴中の断片を指し示す。バッファ４７は、スライドウィンドウ４４の範囲内にある断片を記憶する。この場合、カーソルは断片３を指示する。カーソルが断片３を指し示す場合、メカニズムは、ストリーミング配信されることになる次の断片である断片４を見つけるべき場所をＣＳに尋ねる。ＣＳは、その断片が記憶されているサーバにアドレスを教えることによって応答し、メカニズムが、示されたサーバにある断片４をフェッチする。最後に、断片４が、バッファ内に記憶される。次に、スライドウィンドウが右へ移動して、カーソルが、「高」と優先度を付けられた断片である断片４を指し示す。次に断片４が、ユーザにストリーム配信され、断片３が終わる。ここでメカニズムが、断片５を見つけるべき場所をＣＳに尋ねる。ＣＳが応答し、断片５がフェッチされてバッファ内に記憶される。スライドウィンドウ４４が、カーソル４６と共に再び移動する。スライドウィンドウ４４の範囲内のすべての断片が、バッファ内に維持される［利点１、利点１０］。バッファのサイズは、直近の未来にユーザにストリーミング配信されることになりそうな断片を記憶するのに十分な大きさがあるべきである。例えば、ある断片をユーザにストリーム配信するのに約５秒かかるとすると、ユーザ側でコンテンツをなめらかに中断されないように再生するためには、次の５分間バッファは、断片を記憶することができる必要がある。そのような場合、スライドウィンドウおよびバッファのサイズは、図８に示す３つだけでなく６０個の断片を収容しなければならない。スライドウィンドウのメカニズムおよびバッファは、ＡＳ内に位置し、ソフトウェア、ハードウェア、またはそれらを組み合わせたかたちで実施される。スライドウィンドウのサイズとバッファのサイズは構成可能である。

第１のユーザが、図８のファイル４３によって表される映画を見ていると仮定しよう。第１のユーザと同じＡＳ上の第２のユーザが同じ映画を見たいと考えた場合、第２のユーザが第１のユーザのスライドウィンドウの範囲内にいるならば、スライドウィンドウのメカニズムは、ＡＳ内に映画のコピーを作成する。次いでそのコピーが第２のユーザへストリーミング配信される。特に映画またはＩＰＴＶ番組が非常に人気があって多数のユーザから要請される場合、これによって最初の１マイルのネットワーク上の負荷が軽減されるであろう。加えて、時間のシフトが非常に容易に行える。これを説明するには、図９および１０を参照されたい［利点９、利点１０］。

図９は、ユーザ１およびユーザ２がＩＰＤＳＬＡＭ２７．１を介してＡＳ２２．１に接続し、ユーザ３がＩＰＤＳＬＡＭ２７．２を介してＡＳ２２．２に接続している場合のアクセス領域３３での構成を示す。アクセスサーバＡＳ２２．１およびＡＳ２２．２は、ＥＳ２１に接続する。図１０は、図９に関連するタイミング図である。実際の時間はｘ軸に沿っており、再生時間（映画が再生される時間）はｙ軸に沿っている。スライドウィンドウのサイズは、従ってストリーミングバッファのサイズでもあるが、矢印４４で表し、ユーザ１に関連する。サーバフレームワーク内のすべてのＡＳは、インターネット・グループ・マネジメント・プロトコル（ＩＧＭＰ）スヌーピングを用いるが、これはＡＳが、同じＡＳに接続している他のユーザが送信した要求を覗いていることを意味する［利点７、利点８］。

ＥＳトラッカは、それに接続しているアクセスサーバ上に記憶されているすべての断片のＩＤとアドレスとを知っているため、ＥＳは、カーソル周辺の断片をフェッチするための適切なスライドウィンドウを見つけるべき場所を知っている［利点１０］。

ユーザ１は、矢印５０で表される、特定の映画についての要求を送信して、時刻ｔ１に映画を視聴し始める。ＡＳ２２．１は、ＡＳ２２．１の映画の断片をフェッチして、映画をユーザ１にストリーミング配信する。ユーザ１にとって、再生時間は実際の時間と同じである。ユーザ２が、時刻ｔ２に同じ映画についての矢印５１で表される要求を送信して、同じ映画を視聴し始める。ｔ２はスライドウィンドウ４４の範囲内にあるため、ユーザ１にストリーミング配信された映画の断片は、ＡＳ２２．１にコピーされ、ユーザ２にストリーミング配信される。これは、ユーザ２に関連する点線５３のうちの５２の部分である。ユーザ２が、ユーザ２の点線５３の水平部分に相当する時間の間、自分の映画を一時停止して、その場合、再生時間は停止して実際の時間は増え続けるのだが、そしてユーザ２が、スライドウィンドウの範囲内の時刻に再生を開始する場合には、ユーザ１の映画の断片はまだストリーミングバッファ４７で利用可能であり、ユーザ２にストリーミング配信されるであろう。従って、ユーザ２は、ＡＳ２２．２から映画をフェッチする。

ＡＳ２２．１上の別のユーザがユーザ１とは別の映画を視聴している場合、前記他の映画に関連するスライドウィンドウの範囲内でチャネル切り替え要求が行われるならば、ユーザ１は、この映画への即時アクセスができるであろう。

引き続き図１０を参照すると、ユーザ３が時刻ｔ３にユーザ１と同じ映画を要求するが、この要求は矢印５４で表される。時刻ｔ３はユーザ１のスライドウィンドウの外側であるため、ユーザ３は、エッジサーバ２１から映画をフェッチする必要がある。ユーザ３の映画時間の実際の時間の線を点線５５で示す。

図１１は、中央サーバのブロック図である。中央サーバは、コンテンツ投入部５６と、データ格納部５７と、ファイル共有クライアント／サーバ・プロトコル２６と、ストリーム生成手段５８と、スーパートラッカ５９と、そして、列挙したユニット間の相互作用を制御する制御部６０とを備える。スーパートラッカは、データ格納部の中の利用可能なすべてのファイルのリストを、クライアント固有位置データおよび分解情報と共に保有する。特にリストは、ファイルの断片を有するすべてのクライアントのアドレスと、断片の番号と、そして、クライアントの実際のアップロードレートおよびダウンロードレートとを保持する。クライアント（ＥＳおよびＡＳ）は、不足している断片をダウンロードすべき場所をスーパートラッカに尋ねる。断片を要求するクライアントは、サーバ階層の中でデータを上り方向または下り方向にストリーミング配信する場所を、ストリーミングレートに基づいてスーパートラッカから知る。この概念を使って、スーパートラッカは、ダウンロードする「最高の」ピアを見つけるのを支援する。最高のピアとは、負荷が最小となるようなピアであろう。これは、識別されたコンテンツの識別された断片を別のクライアントが要求する場合に、スーパートラッカが、その断片を見つけるべき場所を知っており、それを持ってくるべき場所をクライアントにアドバイスできることを意味する。スーパートラッカは、過負荷状態であるかまたは高負荷状態であるサーバから断片を取得するようにはアドバイスせず、代わりに、それほど負荷が重くない別のサーバから要求された断片を取得するようにアドバイスするであろう。スーパートラッカは、使用されているすべてのレートの知識を有し、従ってサーバフレームワーク内で用いられているリンク上の負荷についての知識も有する［利点１、利点６、利点７］。

例えば、リストのエントリＶ１Ｆ１とは、ビデオ映画第１号の断片第１のことをいい、Ｖ２Ｆ１は、ビデオ映画第２号の断片第２のことをいい、以下同様である。図示した事例のＥＳ１およびＡＳ２２．１では、このエントリＶ１Ｆ１に、エントリのコピーを含むクライアントのアドレスが列挙される。ダウンロードレートは、リスト内のＲ１、Ｒ２等で示される。コンテンツ投入部は、図５に示すオペレーションセンタ４２の中に位置する管理システムの、表示しない管理インタフェースの一部である。管理システムからは、中央サーバ内に記憶された要らないデータ材料を手動で削除することが可能である［利点１］。

図１２は、制御部６１と、タイムアウト手段６２と、データ格納部５７と、ファイル共有クライアント／サーバ・プロトコル２６と、ストリーム生成手段５９と、トラッカ６５と、ヒットリスト６６とを備えたエッジサーバのブロック図である。制御部は、それに接続するユニット間の相互動作を制御している。ＥＳは、受信したすべての断片を記憶する。ＥＳに記憶されたすべての断片が、これらの断片が他のピアによってどのくらいの頻度で何時要求されたかについての情報と共に、ヒットリストに記憶される。ヒットリストは、断片が記憶された状態を維持するための優先度を生じさせるために用いられる。また、どの断片がめったに使用されずに期限切れになった（寿命が尽きた）断片であって記憶から削除されることになるのかについても、ヒットリストによって分る。

特に、映画第１号に関するヒットリストの映画の断片第１に関するエントリＶ１Ｆ１では、コラムＸＸＸＸは、断片に関するヒット数を含む。各断片について、断片に関するヒットの連続カウントがある。カウントは、ヒットがある度に１ずつ進む。ヒットリストには、０と１とを含むコラムがある。コラムの１（１）は、関連する断片が利用可能であることを示し、ゼロ（０）は、関連する断片がもはや必要ではなく、データストアから削除されてもよいことを示す。

断片は、ヒット数が一定の閾値Ｔ１を超える限り、エッジサーバ上に記憶される。閾値は構成可能である。例えば、Ｔ１が１０，０００回に構成される。構成可能な時間帯、例えば５日間の間に連続カウントがＴ１を超えると、Ｖ１Ｆ１およびＶ１Ｆ２で示したように、断片に１（１）という印が付けられる。構成可能な時間帯について断片の連続カウントがＴ１未満である場合には、その断片は時間切れ（タイムアウト）となり、消去されてもよい。利用不可能な断片は、Ｖ１Ｆ３で示したように、ゼロ（０）という印が付けられる。

ヒットリストの機能の実装は他にも多数考えられる。例えば、１回ヒットすれば、ゼロに設定されたカウンタを１だけ増やし、そして、所定の時間、例えば１分間の後、カウントを１だけ減らす。この場合、カウンタがゼロより上か下かを見れば十分であるため、閾値は必要ない。ヒットがカウンタを増やし、時間がカウンタを減らすのである。

データ格納部６３が一杯で、かつ新規の断片を記憶する必要がある場合には、ここでもやはりヒットリストが、どれを保持してどれを消去するかという情報を提供する。利用可能な断片はすべて共有される。完全なファイルはシードされる。

ブロック図では、記憶されたデータファイル毎に１つのヒットリストがある。１つの共通ヒットリストを用いることも可能である。

図１３は、制御部６７と、タイムアウト手段６２と、スライド・ウィンドウ・バッファ４７と、ファイル共有クライアント／サーバ・プロトコル２６と、ストリーム生成手段５９と、ヒットリスト７１と複製手段７２とを備えたアクセスサーバのブロック図である。制御部は、それに接続するユニット間の相互動作を制御している。ＡＳは、受信したすべての断片を記憶する。ＡＳに記憶されたすべての断片が、これらの断片が他のピアによってどのくらいの頻度で何時要求されたかについての情報と共に、ヒットリストに記憶される。ヒットリストは、断片が記憶されるための優先度を生じさせるために用いられる。また、どの断片が、めったに使用されずに寿命が尽きた断片であって記憶から削除されることになるのかについても、ヒットリストによって分る。

特に、映画第１号に関するヒットリストの映画の断片第１に関するエントリＶ１Ｆ１では、ＸＸＸＸと記されたコラムは、断片に関するヒット数を含む。各断片について、断片に関するヒットの連続カウントがある。カウントは、ヒットがある度に１ずつ進む。ヒットリストには、０と１とを含むコラムがある。コラムの１（１）は、関連する断片が利用可能であることを示し、ゼロ（０）は、関連する断片がもはや利用できず、データストアから削除されてもよいことを示す。

断片は、ヒット数が一定の閾値Ｔ２を超える限り、アクセスサーバ上に記憶される。閾値は構成可能である。例えば、Ｔ２が１００，０００回に構成される。構成可能な時間帯、例えば２日間の間に連続カウントがＴ２を超えると、Ｖ１Ｆ１およびＶ１Ｆ２で示したように、断片に１（１）という印が付けられる。構成可能な時間帯について断片の連続カウントがＴ１未満である場合には、その断片は時間切れとなり、消去されてもよい。利用不可能な断片には、Ｖ１Ｆ３で示したようにゼロ（０）という印が付けられる。

データ格納部６３が一杯で、かつ新規の断片を記憶する必要がある場合には、ここでもやはりヒットリストが、どれを保持してどれを消去するかという情報を提供する。利用可能な断片はすべて共有される。

ブロック図では、記憶されたデータファイル毎に１つのヒットリストがある。１つの共通ヒットリストを用いることも可能である。

アクセスサーバは第１の統合ポイント１５に設置されており、従って記憶容量および処理容量が非常に限られている。１つのＡＳを使用するユーザ数は限られている。

スライド・ウィンドウ・バッファは、スライドウィンドウの原則に従ってファイルの断片を保持するが、これについては図８を参照されたい。従ってＡＳは、どちらかというと、完全なファイルよりもカーソル４６周辺の断片を保持する。図８を参照すると、ウィンドウ４４は、どれくらいの履歴がスライド・ウィンドウ・バッファ４７内に記憶されるかを定義する。

従って、流行の映画や最新ニュースなどの人気のある材料はすべて、ユーザに近いアクセスサーバに記憶されるであろう［利点１、利点１０］。ある断片が不足しているＡＳは、不足している断片を見つけるべき場所をそのエッジサーバに要求してもよい。またスヌーピングも、不足している断片を求める別のアクセスサーバの要求を覗き込むことによってそのサーバにもその断片が不足していることをアクセスサーバが知りうる手段である。スヌーピングをしているＡＳが、自身のスライドウィンドウの中において断片が不足していることを検知した場合には、不足している断片を直接コピーして、それを必要としているＡＳに対してそれを第３のリンク２３上で送信してもよい。このようにして、第２のリンク１１上の負荷がかなり減少し、第１のリンク９上の負荷も減少するであろう。万一、人気のある材料への需要が、例えば第１のリンク９が過負荷状態になる程度まで増す場合には、ＡＳ内の複製手段７２が、需要の非常に多い断片のコピーを作成して、それらを他のアクセスサーバへ送信してもよい。そうすることで、第１のリンクを含むネットワーク内での伝送経路の長さが減少し、それによってより多くの帯域幅が解放される。

個人的ビデオ録画（ＰＶＲ）では、映画の断片がレコーダに順序正しく記憶される必要がない。断片はいかなる順序で記憶されてもよく、それでも、録画やレンダリングに用いられるプロトコルのおかげで順序正しく再生されることができる。また本発明があれば、番組（ＩＰＴＶチャネルまたはビデオチャネルまたは両方）の視聴と別番組のＰＶＲとを同時に提供することも可能であろう。例えば、ＡＳにあるファイル共有クライアントが、視聴されることになる番組、すなわちユーザにストリーム配信されることになる番組についての１つの要求と、録画されることになる番組についての別の要求という、２つの要求をエッジサーバへ送信し、後者の要求は、断片が入手可能であってクライアントがフェッチできるようなサーバのアドレスを結果として提供する。クライアントが断片を受信する度に、断片がユーザへのＤＳＬ上で多重化されて、シーケンスの順序に関係なくＰＶＲレコーダへ送信される［利点１１］。

ファイル共有クライアント／サーバ・プロトコル２６は、ファイル共有プロトコルを実施して、対応するＥＳへ伝送する。

加入者固有の管理情報に基づいて、情報ストリームがＡＳによって内部的に生成され、格納部内に置かれてユーザへストリーミング配信される。これを用いて、割当数量と、レートと、サービス義務と回線ステータスとを加入者に知らせることができる。

図４および図９に示すように、ＡＳは、ユーザを示す小さなアイコンを備え、ＥＳは、情報を含んでいるフォルダを示す小さなアイコンを有し、ＣＳは、多量の情報を含んでいるデータベースを示す小さなアイコンを有する。ＡＳ内のユーザのアイコンは、ＡＳがユーザのためのプロキシとして機能することを象徴し、フォルダのアイコンは、ＡＳが入手可能な適量のデータ材料をＥＳが含んでいることを象徴し、ＣＳ内のデータベースのアイコンは、ＥＳが入手可能な多量のデータ材料をＣＳが保持することを象徴している。

本発明について、デジタル加入者回線、ＩＰＤＳＬＡＭ、スイッチなどを備えた有線システムに関連して記述してきたが、本発明はこれに限定されない。本発明は、無線システムにも等しく実装されてもよく、その場合、加入者宅内機器は携帯電話と入れ替えられ、デジタル加入者回線は無線チャネルと入れ替えられ、ＩＰＤＳＬＡＭは基地局ＢＳと入れ替えられ、イーサネット（登録商標）スイッチはＳＧＳＮ（在圏ＧＰＲＳサポートノード）と入れ替えられ、ＢＲＡＳはＧＧＳＮ（ゲートウェイＧＰＲＳサポートノード）と入れ替えられる［利点１３］。

エッジサーバは、図示するように転送ネットワーク３と統合ネットワークの間の端部に設置される必要はなく、転送ネットワークに直接接続されて、そこからＥＳが統合ネットワークに達することができてもよい。

参考文献
［参考文献１］http://www.alcatel.se/gsearch/search.jhtml;jsessionid=JZGU31I1QEKBKCTFR0HHJHAKMWHI0TNS?_requestid=387550で入手可能である”Optimizing the Broadband Aggregation Network for Triple Play Services”、２００６年５月２３日、（コメント：これらの参考文献を本書の最後に自己の章で追加する）
［参考文献２］”ITU-T G992.5, Asymmetric Digital Subscriber Line (ADSL) transceiver - Extended bandwidth ADSL2 (ADSL2plus)”、２００３年５月、および、”Amendment 1”、２００５年７月
［参考文献３］Ericsson DSL Access 2.2 (EDA 2.2 System Overview, 1/1511-HSC 901 35/3 Uen C 2005-12-02)、２００５年１２月、エリクソン
［参考文献４］ITU-T G993.2, Very high speed digital subscriber line 2、２００６年４月
［参考文献５］http://en.wikipedia.org/wiki/Bittorrent（２００６年４月１９日）、または、http://bittorrent.com（同日）（参考文献移動）
［参考文献６］Real Time Streaming Protocol, RFC 2326、１９９８年４月、H. Schulzrinne, R. Lanphier

Claims (20)

1. ストリーミング技術を使用してエンドユーザにトリプルプレイサービスを提供するための分散サーバ・フレームワークであって、
   １つの中央サーバ（２０）と、複数の局所のエッジサーバ（２１）と、複数のアクセスサーバ（２２）の複数のローカルグループと、を含み、１つのグループの前記アクセスサーバは各々の第１リンク（９）を介してエッジサーバに接続され、前記エッジサーバは各々の第２リンク（１１）を介して前記中央サーバに接続され、１つのグループの前記アクセスサーバは第３リンク（２３）を介して相互接続され、
   前記中央サーバは、大量のデータ材料を格納するためのデータ格納部（５７）を有し、
   前記エッジサーバ（２１）は、前記データ材料の断片を一時的に格納するためのデータ格納部（６３）を有し、
   前記アクセスサーバは、前記データ材料の断片を一時的に格納するためのデータ格納部（４７）を有し、
   前記アクセスサーバは、有限数のエンドユーザ（５）の装置（６）が接続されたマルチプレクサ／デマルチプレクサ（８）に接続され、
   前記中央サーバ、エッジサーバ、アクセスサーバの各々は、
   （ａ）エンドユーザから要求されたデータ材料（４３）のファイル断片（断片１〜断片６）の、前記中央サーバから前記エッジサーバおよび前記アクセスサーバへの拡散、
   および、
   （ｂ）格納されたデータ材料のエンドユーザから要求された頻度に従った、各々の所定時間に対する、拡散されたファイル断片のエッジサーバおよびアクセスサーバの各々での格納、
   のための、ＩＰベースのファイル共有プロトコルを用いる、前記第１リンク、第２リンク、第３リンクを介した通信のためのクライアント／サーバ・ファイル共有ソフトウェア（２６）を有する
   ことを特徴とする分散サーバ・フレームワーク。
2. 前記中央サーバは、前記エッジサーバおよびアクセスサーバに拡散したファイル断片の識別子を含むトラックリストを保持するスーパートラッカ（５９）として動作し、前記エッジサーバは、各々の、前記アクセスサーバに拡散されたファイル断片の識別子を含むトラックリストと、識別された断片が要求された回数を含むヒットリスト（６６）と、を保持するトラッカ（６５）として動作することを特徴とする請求項１に記載の分散サーバ・フレームワーク。
3. エンドユーザから頻繁に要求される人気の高いファイル断片は、
   （ａ）第１の失効時間を割り当てられ、
   （ｂ）ファイル断片の拡散のための前記第１リンク（９）の使用を回避するために、一時的にアクセスサーバ（２１）に格納され、
   （ｃ）ファイル断片の失効時間が満了し、かつ、当該ファイル断片に対する要求を受信していない場合に、前記アクセスサーバから削除され、
   （ｄ）ファイル断片が要求されるたびに、当該ファイル断片の失効時間が延長され、
   かつ、
   前記人気が高いファイル断片ほどは人気がないファイル断片でありエンドユーザからそれほど要求されないファイル断片は、
   （ａ）前記第１の失効時間より長い第２の失効時間を割り当てられ、
   （ｂ）ファイル断片の拡散のための前記第２リンク（１１）の使用を回避するために、一時的にエッジサーバ（２１）に格納され、
   （ｃ）ファイル断片の失効時間が満了し、かつ、当該ファイル断片に対する要求を受信していない場合に、前記エッジサーバから削除され、
   （ｄ）ファイル断片が要求されるたびに、当該ファイル断片の失効時間が延長され、
   かつ、
   ユーザから要求されることがほとんどない人気のないデータ材料は、永続的に前記中央サーバに存在する
   ことを特徴とする請求項２に記載の分散サーバ・フレームワーク。
4. 前記アクセスサーバはファイル共有プロトコルのクライアント（２６）を含み、該ファイル共有プロトコルは前記アクセスサーバにおいてスライドウィンドウおよびカーソルメカニズムに従ってファイル断片を格納するのに適している
   ことを特徴とする請求項１または３に記載の分散サーバ・フレームワーク。
5. アクセスサーバ（２２）はスライドウィンドウおよびカーソルメカニズムを含み、該メカニズムは、リアルタイムに移動するウィンドウ（４４）と、最高のフェッチ優先度を有しアクセスサーバによりフェッチされユーザにストリームされることになる断片を指示するカーソル（４６）とを含む
   ことを特徴とする請求項４に記載の分散サーバ・フレームワーク。
6. 個々のエンドユーザは識別されたデータ材料の個別化された要求をアクセスサーバと通信し、前記アクセスサーバは、前記要求への応答として、要求されたデータ材料を含むエッジサーバおよびアクセスサーバから当該要求されたデータ材料を取り出すのに、および、指定されたエッジサーバおよびアクセスサーバが前記第１リンク（９）および第３リンク（２３）の各々を介して前記要求されたファイル断片をフェッチし前記要求を行ったエンドユーザにストリームするのに、適していることを特徴とする請求項５に記載の分散サーバ・フレームワーク。
7. アクセスサーバは、他のアクセスサーバの各々のスライドウィンドウ内に前記要求されたファイル断片が提供されている場合、当該他のアクセスサーバ上の前記ファイル断片を取り出すのに適しており、取り出す場合には、前記要求されたファイル断片は前記第３リンク（２３）を介してフェッチされることを特徴とする請求項６に記載の分散サーバ・フレームワーク。
8. 前記データ材料の識別された断片が不足している第１のアクセスサーバは、任意の他のアクセスサーバにおけるスライドウィンドウ内に前記不足した断片が有るか否かを見るために、他のアクセスサーバからの要求をスヌープし、有る場合には、当該アクセスサーバから前記不足した断片をフェッチするために当該断片の転送のための第３リンクを使用することを特徴とする請求項７に記載の分散サーバ・フレームワーク。
9. スライドウィンドウおよびカーソルメカニズムと組み合わせたファイル断片の前記アクセスサーバおよびエッジサーバへの格納は、個別化された真のビデオ・オン・デマンドを提供することを特徴とする請求項８に記載の分散サーバ・フレームワーク。
10. アクセスサーバは、複数のマルチプレクサ／デマルチプレクサへ接続されていることを特徴とする請求項９に記載の分散サーバ・フレームワーク。
11. 前記マルチプレクサ／デマルチプレクサは、エンドユーザに、データ、ビデオ、音声のサービスを提供するためのデータＶＬＡＮ、ビデオＶＬＡＮ、音声ＶＬＡＮに接続されていることを特徴とする請求項１０に記載の分散サーバ・フレームワーク。
12. 前記アクセスネットワークは、移動無線ネットワークであることを特徴とする請求項１１に記載の分散サーバ・フレームワーク。
13. 前記アクセスネットワークはイーサネット（登録商標）ベースのネットワークであり、前記マルチプレクサ／デマルチプレクサはＩＰベースのデジタル加入者線アクセスマルチプレクサ（ＩＰ−ＤＳＬＡＭ）であることを特徴とする請求項４に記載の分散サーバ・フレームワーク。
14. 前記ファイル共有ソフトウェアは、エンドユーザ装置を前記ファイル共有プロトコルに含まないように、かつ、スライドウィンドウおよびカーソルメカニズムを含むように、修正されたビットトレントプロトコルであることを特徴とする請求項４に記載の分散サーバ・フレームワーク。
15. データ材料の個別化されたストリームをユーザ装置に配信するためのアクセスサーバであって、前記ユーザ装置はマルチプレクサ／デマルチプレクサを介してアクセスサーバに接続するのに適しており、前記アクセスサーバはファイル共有クライアント／サーバ・プロトコル（２６）とストリーム生成手段（７０）とデータ格納手段（４７）とを含み、
    データ材料の識別された断片が前記ファイル共有クライアント／サーバ・プロトコルにより要求された回数を計数するヒットリスト（７１）と、第１の所定時間の間にヒットが無かった識別された断片を削除するためのタイムアウト手段（６２）と、
    を含むことを特徴とするアクセスサーバ。
16. 前記ファイル共有クライアント／サーバ・プロトコルは、要求されたデータ材料の断片を連続した順序でフェッチしユーザにストリームするのに使用される、スライドウィンドウおよびカーソルメカニズムにより修正されていることを特徴とする請求項１５に記載のアクセスサーバ。
17. 前記第１の所定時間は数時間または数日のオーダであり、前記アクセスサーバは、人気が高くユーザによる要求が多いデータ材料を格納することを特徴とする請求項１５に記載のアクセスサーバ。
18. 前記アクセスサーバにおいて断片を複製するための複製手段（７２）を含むことを特徴とする請求項１５に記載のアクセスサーバ。
19. ＩＰベースの転送ネットワーク（３）とアクセスネットワークとの間の端に位置するエッジサーバであって、該エッジサーバは前記アクセスネットワーク内のアクセスサーバにデータを配信するのに適しており、該エッジサーバはファイル共有クライアント／サーバ・プロトコル（２６）とストリーム生成手段（６４）とデータ格納手段（６３）とを含み、
    データ材料の識別された断片のエントリと各エントリに関連付けられた前記識別された断片が格納されているアクセスサーバのアドレスとのリストを含むトラッカ（６５）と、データ材料の識別された断片が前記ファイル共有クライアント／サーバ・プロトコルにより要求された回数を計数するヒットリスト（６６）と、第２の所定時間の間にヒットが無かった識別された断片を削除するためのタイムアウト手段（６２）と、
    を含むことを特徴とするエッジサーバ。
20. 前記第２の所定時間は約５日のオーダであり、前記エッジサーバは人気がより低くユーザによる要求がより少ないデータ材料を格納することを特徴とする請求項１９に記載のエッジサーバ。

Images