移動ＴＶのロバストなファイルキャスト
本発明は、回復制御装置及び方法に関する。回復制御装置での方法は、少なくとも１つの端末と複数の回復サーバとが少なくとも１つのファイルサーバからプッシュモードで配信される少なくとも１つのファイル配信セッションを受信するシステムにおいて、複数の回復サーバの中から回復サーバを選択する。この方法は、少なくとも１つのファイル配信セッションのパケットを回復する要求を少なくとも１つの端末から受信するステップと、少なくとも１つの端末へのパケットを回復する回復サーバを選択するステップと、選択された回復サーバのアドレスを用いて、要求を少なくとも１つの端末にリダイレクトするステップとを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概してコンテンツ配信に関し、特に効率的な回復機構を提供する方法及び装置に関する。
【背景技術】
【０００２】
この部分は、読者に様々な技術側面を紹介することを目的としており、これらの技術側面は、以下に説明する及び／又は特許請求の範囲に記載する本発明の様々な態様に関連し得る。この説明は、本発明の様々な態様の理解を容易にするために、読者に背景情報を提供する点で有用であると考えられる。従って、この記載は、この観点から読まれるべきであり、従来技術の認定として読まれるべきではない。
【０００３】
少し前から、セルラネットワークを通じて移動端末でTV番組を視聴することが可能になっている。DVB-Hで規定されているブロードキャストプロトコルは、ビジネスサービスに関する可能性及びサービス品質を拡張する。移動TVの試行及び最初の商業活動は、典型的な生のTVサービスに重点を置いている。
【０００４】
プッシュ型ファイル配信サービス（push file delivery service）が、DVB-Hのような移動ブロードキャストネットワーク及びセルラ3Gネットワークのような双方向ネットワークの上位に構築される可能性がある。ファイル型ビデオ配信サービスの１つの利点は、帯域制限及びパケット損失のようなネットワークの問題に対する相対的な柔軟性である。
【０００５】
プッシュ型ビデオオンデマンド（VOD：video on demand）サービスは、とりわけ優先度、ユーザ加入、ネットワーク状態（例えば、帯域の可用性の測定）、動的なコンテンツ分類、スケジュール履歴を含む複数の基準に基づくスマートなスケジューリング（smart scheduling）に従って、ブロードキャストマルチキャストネットワーク（例えば、DVB-H）でビデオファイルをエンドユーザ装置に送信する。ユーザの嗜好に合致するこれらのファイルは、エンドユーザ装置のローカル記憶装置に保存される。このことにより、ユーザは、再生遅延なしに、基礎となる配信機構をほとんど気にせずに、広範囲のコンテンツにアクセスすることが可能になる。DVB-Hは、標準“ETSI EN 301 192 V1.4.1 (2004-11) Digital Video Broadcasting (DVB); DVB specification for data broadcasting”及び“ETSI EN 302 304 V1.1.1 (2004-11) Digital Video Broadcasting (DVB); Transmission System for Handheld Terminals (DVB-H)”に規定されている。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
移動ブロードキャストネットワークは、片方向ネットワークであり、パケット損失は、アプリケーション前方誤り訂正（FEC：forward error correction）の使用を通じて部分的に解決可能である。しかし、FEC機構の使用は、帯域を消費し、完全に回復されたファイルを保証しない。このことは、ユーザがトンネルのようなあまりカバーされていない領域に移動したときに、端末が大部分のデータを損失する可能性がある無線移動ブロードキャストネットワークで特に当てはまる。更に、標準“ETSI TR 102 377 V1.1.1 (2005-02) Digital Video Broadcasting (DVB); DVB-H Implementation Guidelines”による現在のDVB-H受信機の実装では、複数のIPパケットを含むパケットのバーストがFECを使用して完全に回復できない場合、無視される。このように、複数の重要なIPパケットが損失する可能性がある。
【０００７】
パケット損失を回避する他の技術は、同じファイルを複数回送信することにある。これは、例えば、標準“DVB-IPDC ESG, ETSI TS 102 471 V1.2.1 (2006-09), Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic Service Guide (ESG)”に指定された電子サービスガイド（Electronic Service Guide）コンテナのような短いファイルに適することがある。しかし、ビデオファイル配信にとっては、明らかに効率の悪い機構である。
【０００８】
ファイル回復又はロバストなファイルキャスト（file casting）は、無線で送信されるビデオファイルの完全性を保証する他の方法である。これは、ユーザの視聴経験を拡張するプッシュ型VODサービスに特に適している。
【０００９】
配信後ファイル回復プロトコル（post delivery file repair protocol）は、3GPP-MBMS（Third Generation Partnership Project, Multimedia Broadcast Multicast Service group）により作成された標準“ETSI TS 102 472 V1.2.1 (2006-12), Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content Delivery Protocols”に記載されている。また、DVB-CBMS（Digital Video Broadcasting-Convergence Broadcast Multicast System group）により作成された標準“ETSI TS 126 346 V6.1.0 (2005-06), Universal Mobile Telecommunications System (UMTS); Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs (3GPP TS 26.346 version 6.1.0 Release 6)”にも記載されている。ファイル回復機構は、いわゆる関連配信（associated delivery）手順の一部であり、主な手順は、RFC 3926（File Delivery over Unidirectional Transport (FLUTE)）に指定されているFLUTEプロトコルスイートに基づくファイル配信である。ファイル回復プロトコルの目的は、ファイル配信手順に従って前に受信したファイルの一部及び／又は損失パケットを取得する方法を提供することである。
【００１０】
ファイル回復手順は、ファイルが完全に受信されたと仮定される場合に常に始まる。FLUTEでは、ファイルの終了を検出することは非常に困難である。ファイルの最後のFLUTEパケットは、ファイルの終了を伝えるために印が付けられることがある。しかし、このパケットが損失すると、受信機は、ファイル配信テーブル（FDT：File Delivery Table）に依存しなければならない。FDTは、FLUTEプロトコルの一部として帯域で送信されるファイルについての一式の情報である。このような情報は、任意選択で、ファイルのサイズを含む。それにも拘らず、RFC 3926によれば、DVB-CBMSは、FLUTEプロトコルで現在伝送されているファイルサイズを示すFDT伝送長パラメータを使用することを推奨する。ファイルが仮に受信されると、受信機は、損失したFLUTEパケットを検出し、回復サーバと接続を確立する。バックオフアルゴリズムに従って、正しい時間に１つ以上の要求を送信し、損失したパケットを取得し、完全に再構成されたファイルを保存する。
【００１１】
この機構は、DVB-CBMSにより推奨されているラプター符号（raptor code）のようなアプリケーションFECと結合され得る。受信機は、成功してFECデコード処理を実行するために必要なパケットのみを要求する。
【００１２】
しかし、FDTは受信機により受信されないことがある。更に、サイズ情報は、伝送長を含むFEC配信情報を集める必須の拡張ヘッダとして、FLUTEパケットヘッダに存在する。また、各FLUTEパケットのヘッダ拡張を配信することは必須ではない。最後に、前の情報が受信機により検出されていない場合に、ファイルを安全に閉じるために監視タイマが使用されることがある。２つのパケットの間の経過時間が一定ではないため、これは慎重に使用されなければならない。
【００１３】
本発明は、要求側装置に良く適合する回復サーバの選択を実行する回復ゲートウェイを提供することにより、従来技術のファイル回復に関する課題の少なくともいくつかを改善することを目的とする。
【課題を解決するための手段】
【００１４】
本発明は、少なくとも１つの端末と複数の回復サーバとが少なくとも１つのファイルサーバからプッシュモードで配信される少なくとも１つのファイル配信セッションを受信するシステムにおいて、複数の回復サーバの中から回復サーバを選択する回復制御装置での方法に関する。
【００１５】
このため、この方法は、少なくとも１つのファイル配信セッションのパケットを回復する要求を少なくとも１つの端末から受信するステップと、少なくとも１つの端末へのパケットを回復する回復サーバを選択するステップと、選択された回復サーバのアドレスを用いて、要求を少なくとも１つの端末にリダイレクトするステップとを有する。
【００１６】
ファイル回復機構は、何らかの受信機が一方向ブロードキャストネットワークを通じて前に受信したファイルを回復することを可能にするポイント・ツー・ポイント型プロトコルに基づく。この対策は、DVB-IPDC及び3GPP-MBMS配信後ファイル回復機構の可能性を広げ、ロバスト性及びスケーラビリティを拡張する。本発明の方法は、要求が送信された時点で最善の回復サーバを提供することにより、回復手順の効率を改善する回復手順の集中制御を提供する。これは、大規模ネットワークに展開した複数の回復サーバを有するネットワークにうまく適合する。
【００１７】
実施例によれば、この方法は、端末からの少なくとも１つのファイル配信セッションのパケットを回復する以降の要求を、選択された回復サーバにリダイレクトするステップを有する。
【００１８】
本発明はまた、少なくとも１つの端末と複数の回復サーバとが少なくとも１つのファイルサーバからプッシュモードで配信される少なくとも１つのファイル配信セッションを受信するシステムにおいて、複数の回復サーバの中から回復サーバを選択する回復制御装置での方法に関する。
【００１９】
このため、この方法は、少なくとも１つのファイル配信セッションのパケットを回復する要求を少なくとも１つの端末から受信するステップと、少なくとも１つの端末へのパケットを回復する回復サーバを選択するステップと、要求を選択された回復サーバに転送するステップとを有する。
【００２０】
実施例によれば、この方法は、端末からの少なくとも１つのファイル配信セッションのパケットを回復する以降の要求を、選択された回復サーバに転送するステップを有する。
【００２１】
実施例によれば、回復サーバは、第１の形式又は第２の形式であり、第１の形式の回復サーバは、ファイルサーバにより送信されたパケットの一部のみを正確に受信し、第２の形式の回復サーバは、ファイルサーバにより送信された全てのパケットを正確に受信する。選択するステップは、第１の形式の回復サーバを分類するステップと、続いて分類の最初から最後の回復サーバまで、回復サーバが保証できる、閾値を満たす回復確率の指示で応答を受信するまで、パケットを回復する要求を送信するステップと、回復サーバが閾値を満たす場合、回復サーバを選択するステップと、リストの最後の回復サーバが閾値を満たす確率を提供しない場合、第２の形式の回復サーバを選択するステップとを有する。
【００２２】
実施例によれば、回復コントローラは、最も負荷の低いものから最も負荷の高いものに回復サーバを分類する。
【００２３】
実施例によれば、回復コントローラは、要求側装置に最も近い第２の形式の回復サーバを選択する。
【００２４】
実施例によれば、ファイル配信セッションは、片方向トランスポートセッションでのファイル配信である。
【００２５】
実施例によれば、選択するステップは、マルチキャスト回復を使用することについて決定するステップと、第２の形式の回復サーバを選択するステップとを有する。
【００２６】
本発明はまた、回復制御装置に関し、１つより多くの回復サーバと少なくとも１つの端末とが少なくとも１つのファイルサーバからプッシュモードで配信される少なくとも１つのファイル配信セッションを受信するシステムにおいて、１つより多くの回復サーバ及び少なくとも１つの端末と通信する通信手段と、少なくとも１つの端末から回復要求を受信したときに、少なくとも１つの端末へのパケットを回復する回復サーバを１つより多くの回復サーバの中から選択する選択手段と、パケットを回復するために端末から受信した要求を回復サーバにリダイレクトする又は要求を回復サーバに転送するリダイレクト手段とを有する。
【図面の簡単な説明】
【００２７】
【図１】単一サーバを有するシステムのブロック図
【図２】実施例によるマルチサーバ・アーキテクチャのブロック図
【図３】実施例による回復コントローラのブロック図
【図４】実施例による選択方法のフローチャート
【発明を実施するための形態】
【００２８】
開示された実施例の範囲に相当する特定の態様が以下に示される。これらの態様は、本発明が取り得る特定の形式の簡単な要約を読者に提供するためにのみ提示されており、これらの態様は、本発明の範囲を限定することを意図しないことがわかる。実際に、本発明は、以下に示さないことがある様々な態様を含み得る。
【００２９】
本発明は、添付図面を参照して、非限定的ではない以下の実施例及び実行例を用いて示され、良く理解できる。
【００３０】
図３では、提示されたブロックは、単なる機能エンティティであり、必ずしも物理的に別個のエンティティに対応するとは限らない。すなわち、これらは、ハードウェア又はソフトウェアの形式で開発されてもよく、１つ又は複数の集積回路に実装されてもよい。
【００３１】
例示的な実施例は、DVB-Hアーキテクチャでのビデオブロードキャストのフレームワーク内に入るが、本発明は、この特定の環境に限定されず、サーバが複数のサーバから選択される他のフレームワークにも適用され得る。
【００３２】
単一サーバを有するシステムが図１に示されている。これは、標準“ETSI TS 102 472 V1.2.1 (2006-12)-Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content Delivery Protocols”に準拠する。コンテンツは、IPネットワーク（1）及びDVB-Hネットワーク（3）でDVB-H端末（T1、T2、T3）にブロードキャストされる（4）。端末は、GPRS標準に準拠した3Gネットワーク（2）を通じて、紛失したファイル（5）を回復サーバ（R1）に要求する。回復サーバ（R1）は、ファイルサーバ（F1）に対してトランスペアレントである。回復サーバは、送出されるUDPトラヒックを受信し、信頼性があることを仮定する。回復サーバは、ファイルサーバのホスト内に存在してもよい。回復サーバは、マルチチャネルでもよい。すなわち、FLUTEセッションに関連する複数のALCチャネルを受信してもよい。ALCはRFC 3450（Asynchronous Layered Coding (ALC) Protocol Instantiation）に規定されている。
【００３３】
FLUTEセッションは、ファイル配信セッションに対応する。これは、ファイルサーバのソースIPアドレスと、トランスポートセッション識別子（TSI：Transport Session Identifier）とにより識別される。TSIは、各FLUTEパケットに示される。回復サーバは、一意のセッションを受信することに専用のものでもよく、マルチセッションでもよい。すなわち、並列に複数のセッションを受信してもよい。
【００３４】
回復を要求するときに、端末は、回復されるファイルのユニフォームリソース識別子（URI：Uniform Resource Identifier）を使用する。しかし、このURIは、受信機に知られていないことがあり、URI及び対応するFLUTEトランスポート識別子の間の関連付けを伝達するFDTが損失する可能性がある。実施例によれば、回復されるファイルは、進行中のセッションのトランスポートオブジェクト識別子（TOI：Transport Object Identifier）を使用して、ファイルのブロードキャストに続くファイル回復期間中に一意に識別されてもよい。TOIは、FLUTEパケットヘッダに埋め込まれたFLUTEプロトコルスイート識別子である。この識別子は、（異なるURIにリンクされたトランスポートオブジェクト識別子として）FLUTEセッションの存続期間中に異なる時間に再利用されてもよい。同時に、この識別子は、送信者（すなわち、ファイルサーバ）のソースアドレスIPとトランスポートセッション識別子（TSI：Transport Session Identifier）とのおかげで識別されたFLUTEセッション内で、FDTインスタンスを通じて有効なURIに一意に関連付けられる。
【００３５】
FDTは、ファイルのURIを含み、配信されるファイルにリンクした重要な情報を伝達する。これは、受信機により、それに従ってファイルを格納、分類又は処理するために使用される。FDTが部分的に受信された場合、端末が受信ファイルで関連するFDT情報を見つけることができないことが生じ得る。前述のようにFLUTE識別子を使用してファイルを回復し、プライベートなネーミング方式（private naming scheme）に従ってそれを格納し得るが、更に便利なネーミング処理で紛失したFDT情報を取得することが有用である。実施例によれば、回復要求は、端末がTSI/TOIの対で識別されたファイルにリンクされた少なくとも部分的なFDT又はFDTを要求できるように拡張されている。当然に、最適化された要求は、ファイルを識別するためのTSI/TOIと、回復されるFLUTEパケットのリストと、関連する部分的なFDTを同時に取得する指示とを集める。
【００３６】
現在のDVB-CBMSファイル回復プロトコルは、回復を要求するクライアントが回復される各FLUTEパケットに対応するFECペイロードIDを送信する。これは、ソースブロック番号（SBN：Source block Number）と符号化シンボルID（ESI：Encoding Symbol ID）とで構成される。回復サーバは、その応答で、いわゆるFECペイロードIDをそれぞれ前に付けられた、一式の要求されたペイロードチャンクを返信する。このことは、クライアントに対して、非FLUTEパケットとして入来する回復パケットを処理させる。或いは、クライアントに対して、FLUTEパケットを再構成させる。これは容易なタスクではない。実施例によれば、回復サーバは、クライアントの要求時に、ペイロード部分のみではなく、完全なFLUTEパケットを返信してもよい。このことは、回復されたFLUTEパケットがDVB-Hインタフェースから入来するものとして受信処理に再挿入され得るため、クライアント側の実装を簡単にする。
【００３７】
マルチサーバ・アーキテクチャが図２に示されている。これは、単一サーバシステムにスケーラビリティを提供することを目的とする。これは、FLUTEマルチキャスト配信プロトコルに従ってファイルをブロードキャスト又はマルチキャストするファイルサーバ（F1）を有する。
【００３８】
これは、高信頼性接続手段を通じてファイルサーバにリンクされた少なくとも１つの高信頼性サーバ（RR）を有する。高信頼性接続手段は、非常に低い誤り率又は0に等しい誤り率を提供する手段である。高信頼性回復サーバは、マルチキャストトラヒックを受信し、同時に、その内部ファイルデータベースを構築する。高信頼性回復サーバは、誤りなしに全てのトラヒックを取得する。高信頼性回復サーバ及びファイルサーバは、異なるエンティティに表されている。当然に、これらは、同じ物理エンティティ内に存在してもよい。
【００３９】
このアーキテクチャはまた、以下で回復サーバと呼ばれる一式の低信頼性回復サーバ（R1、R2、R3、R4、R5、R6）を有する。これらは、ファイルサーバによりブロードキャストされるファイルを取得する。これらは、損失及び誤りを有してファイルを受信するという意味で信頼性がない。従って、これらは、他のクライアント端末としてファイル回復プロトコルを使用して自分のファイルを回復する必要がない。
【００４０】
コンテンツは、IPネットワーク（1）及びDVB-Hネットワーク（3）でDVB-H端末（T1、T2、T3）にブロードキャストされる。端末は、GPRS標準に準拠した3Gネットワーク（2）を通じて、紛失したファイルを回復コントローラ（RC）に要求する。
【００４１】
マルチサーバ・アーキテクチャは、回復制御ゲートウェイ（RC）を有する。回復制御ゲートウェイ（RC）は、基本的には、システムのHTTPサーバのフロントエンドである。これは、クライアント端末から入来する回復要求を受信して分析する。これは、回復サーバのインフラストラクチャに従って回復方針を決定する。前述の単一サーバシステムでは、回復制御ゲートウェイ及び高信頼性回復サーバは、一緒に統合されてもよい。マルチサーバ・アーキテクチャでは、回復制御ゲートウェイは、回復サーバの１つに含まれてもよい。代替として、回復制御ゲートウェイは、クライアント端末と同じ場所にあってもよい。一般的に、回復コントローラは、定期的にサーバにポーリングし、どれがアクティブでありどれが非アクティブであるかを検査し、各サーバのCPU負荷を検査する。
【００４２】
実施例によれば、２つのトポロジがサポートされる。
【００４３】
集中型インフラストラクチャとも呼ばれるサーバファーム（server farm）・インフラストラクチャ（11）は、LANを通じて共に接続された一式の回復サーバを有する。サーバファームは回復制御ゲートウェイにより制御され、場合によってはクライアントと直接に相互接続されてもよい。回復制御ゲートウェイは、DNS型負荷バランシングを実行するウェブファーム・コントローラにより使用されるものと同様の負荷基準に従って、回復サーバを選択する。
【００４４】
分散型インフラストラクチャ（10）は、最も効率的な応答時間を提供するために大規模な範囲に沿って分散された一式の回復サーバである。
【００４５】
回復コントローラとも呼ばれる回復制御ゲートウェイは、システムインフラストラクチャのヘッドエンドである。要求提示用のアドレスは、端末により周知の唯一の情報である。端末がファイルを回復する必要があるときに、回復要求を回復コントローラに送信する。回復コントローラは、前述の２つのトポロジ（サーバファーム及び分散型ネットワーク）を扱うことができる。
【００４６】
分散型ネットワークの場合、回復コントローラは、要求を、端末に最も近い回復サーバに転送する。転送は、回復コントローラが回復応答としてHTTPリダイレクトコマンドをクライアントに返信するHTTPリダイレクトに基づく。HTTPリダイレクトは、HTTP1.0についてのRFC1945及びHTTP1.1についてのRFC2616に規定されている。HTTPリダイレクトを受信すると、クライアントは、HTTPリダイレクトに示された回復サーバに、新しいHTTP要求を自動的に発行する。この回復サーバは、回復プロトコルに従って要求に応答する。
【００４７】
サーバファームの場合、回復コントローラは、ファームのあまり負荷のない回復サーバに要求を転送する。要求は、回復サーバに直接転送される。選択された回復サーバは、回復プロトコルに従って要求に務めることができる。要求及び応答は、常に回復コントローラを通過する。
【００４８】
実施例によれば、回復コントローラは、あまり負荷がないため又は要求を送信する端末に近いためだけでなく、特定の要求に関連する特定の回復確率を保証できるサーバを選択してもよい。回復確率は、回復コントローラの設定パラメータである。一式の回復サーバの中から、最も信頼性のあるものと考えられるサーバが依然として存在する。他のサーバは、パケット損失のため、ファイルサーバから出力された完全なトラヒックを部分的に取得している可能性がある。
【００４９】
サーバの選択は、図４に示すように、以下の通り実行される。端末は、回復コントローラとTCPセッションを設定する。これは、回復コントローラにHTTP回復要求を送信するS1。ステップS2、S3において、回復コントローラは、要求を変更する。これは、回復がその回復サーバで可能であるか否かを検査するために要求が使用されることを示すために、要求の名前を変更する。その要求は、回復には使用されない。次に、（分散型ネットワークの場合）要求を最も近い回復サーバに転送する。或いは、（サーバファームの場合）最も負荷のないサーバに転送する。換言すると、回復コントローラは、回復サーバのリストを構築し、ネットワーク形式に応じた基準に従ってリストの回復サーバを分類する。サーバファームでは、ランク付けはサーバ負荷に基づく。
【００５０】
要求を受信すると、回復サーバは、要求を分析し、保証できる回復レベルを示す応答を回復コントローラに返信するS4。この回復レベルは、以下のような複数のパラメータに基づいて推定され得る。
−回復サーバが回復できるファイルの割合（関連するローカルデータベースで利用可能なデータに対応する）
−受信した要求に対応する回復確率
回復コントローラは、これらのパラメータを使用し、閾値に基づいてその選択を維持するか否かを決定する。
【００５１】
回復サーバの応答が回復コントローラを満足させない場合、回復コントローラは、他の回復サーバを試しS6、より良い回復率を提供するか否かを検査する。
【００５２】
その選択処理がうまく回復サーバを提供しない場合、回復コントローラは、場合によっては負荷基準を使用して、高信頼性回復サーバの１つを選択するS7。
【００５３】
換言すると、端末は、回復されるファイルの特定の数のパケットを要求する。要求を受信すると、回復コントローラは、要求を回復コントローラに送信し、サーバがパケットを提供できるか否かを認識する。要求を受信すると、サーバは、利用可能なパケット数を検査する。確率は、要求されたパケットの数のうち利用可能なパケットの数である。回復コントローラは、閾値を設定する。確率が閾値より小さい場合、回復コントローラは、他のサーバに要求を送信する。確率が閾値より大きい場合、サーバは選択される。閾値は40%の値に設定されることが好ましい。
【００５４】
HTTP回復要求長は制限される。これは256バイトの値に制限されてもよい。端末が大量のデータを要求すると、単一の要求では十分ではなく、端末は同じセッションで複数の下位要求を連続して送信する。その場合、回復コントローラは、一連の下位要求のうち最初の要求に基づいて、サーバの選択を実行する。回復サーバは、各下位要求に対して応答を送信する。
【００５５】
回復サーバが選択されると、回復コントローラの動作は、インフラストラクチャに依存する。サーバファームの場合、２つの可能性が存在する。
【００５６】
第１の可能性では、サーバファームは、クライアントのネットワークに直接接続されていない。回復コントローラは、検査目的ではなく、処理目的のために、選択された回復サーバに要求を転送する。回復サーバは、要求を処理し、回復コントローラにその応答を返信し、回復コントローラは、それを端末などに転送する。
【００５７】
第２の可能性では、サーバファームは、クライアントのネットワークに直接接続されている。回復要求を受信すると、回復コントローラは、HTTPリダイレクトコマンドをクライアントに返信する。そのコマンドは、選択された回復サーバのアドレスを集める。HTTPリダイレクトを受信すると、クライアントは、HTTPリダイレクトに示されたアドレスで、HTTP要求を回復サーバに自動的に送信する。回復サーバは、回復パケット等をクライアントに返信する。
【００５８】
分散型インフラストラクチャの場合、第２の可能性のみが当てはまる。
【００５９】
分散型インフラストラクチャは、サーバファーム・インフラストラクチャと結合されてもよい。結合されたインフラストラクチャは、一式の分散型“スタンドアローン”及び“ファーム”サーバを有する。コントローラは、サーバ（又はサーバファーム）の位置とそれぞれ個々の回復サーバの負荷レベルとに基づいて、より複雑な発見的手法を使用する。
【００６０】
実施例によれば、回復ゲートウェイはまた、ユニキャスト・マルチキャストモジュールを有する。このモジュールは、ユニキャスト配信モードからマルチキャスト配信に回復モードを切り替えるように適合される。前述のように、ゲートウェイは、端末を回復サーバにリダイレクトする、或いは、要求を回復サーバに転送する。これはユニキャストモードである。
【００６１】
ETSI TS 126 346に準拠した方法では、ゲートウェイは、端末をブロードキャスト／マルチキャスト配信にリダイレクトしてもよい。マルチキャストに切り替えるときに、ゲートウェイは、そのマルチキャスト配信を通じてブロードキャストされる回復データを提供する高信頼性回復サーバを選択することが好ましい。
【００６２】
回復制御ゲートウェイRCが図３に示されている。これは、インターネットに接続する通信手段102を有する。当然に、回復コントローラは、回復サーバ及び端末に接続可能な他の形式のネットワークに接続してもよい。通信手段により、ゲートウェイは、端末及び回復サーバと通信することが可能になる。
【００６３】
これは、端末からの要求を回復サーバのアドレスにリダイレクトするリダイレクト手段104を有する。実施例によれば、リダイレクト手段は、前述のHTTPリダイレクトに準拠する。
【００６４】
これは、前述のように回復サーバを選択する選択手段103を有する。
【００６５】
これは、前述のようにユニキャストモードとマルチキャストモードとの間の切り替えを実行するユニキャスト・マルチキャストモジュール105を有する。
【００６６】
これは、メモリの形式の、アーキテクチャの回復サーバのリストを格納する格納モジュール101を有する。
【００６７】
これは、プロセッサの形式の処理モジュール106を有する。
【００６８】
回復制御ゲートウェイは、コンピュータ装置と同じ場所にあってもよい。当然に、回復制御ゲートウェイはまた、前述の機能モジュールを有する如何なるスタンドアローン型装置でもよい。
【００６９】
詳細な説明、特許請求の範囲及び図面に示された言及は、独立して又は如何なる適切な組み合わせで提供されてもよい。必要に応じて、機能は、ハードウェア、ソフトウェア又はこれら２つの組み合わせで実装されてもよい。
【００７０】
ここでの“一実施例”又は“実施例”への言及は、実施例に関して説明した特定の機能、構造又は特徴が本発明の少なくとも１つの実装に含まれ得ることを意味する。明細書の様々な場所に“一実施例で”という用語が現れることは、必ずしも同じ実施例を示すとは限らず、必ずしも他の実施例と相互排他的な別の又は代替の実施例であるとは限らない。
【００７１】
特許請求の範囲に現れる参照符号は、例示のみであり、特許請求の範囲に限定的な影響を与えるべきではない。
【技術分野】
【０００１】
本発明は、概してコンテンツ配信に関し、特に効率的な回復機構を提供する方法及び装置に関する。
【背景技術】
【０００２】
この部分は、読者に様々な技術側面を紹介することを目的としており、これらの技術側面は、以下に説明する及び／又は特許請求の範囲に記載する本発明の様々な態様に関連し得る。この説明は、本発明の様々な態様の理解を容易にするために、読者に背景情報を提供する点で有用であると考えられる。従って、この記載は、この観点から読まれるべきであり、従来技術の認定として読まれるべきではない。
【０００３】
少し前から、セルラネットワークを通じて移動端末でTV番組を視聴することが可能になっている。DVB-Hで規定されているブロードキャストプロトコルは、ビジネスサービスに関する可能性及びサービス品質を拡張する。移動TVの試行及び最初の商業活動は、典型的な生のTVサービスに重点を置いている。
【０００４】
プッシュ型ファイル配信サービス（push file delivery service）が、DVB-Hのような移動ブロードキャストネットワーク及びセルラ3Gネットワークのような双方向ネットワークの上位に構築される可能性がある。ファイル型ビデオ配信サービスの１つの利点は、帯域制限及びパケット損失のようなネットワークの問題に対する相対的な柔軟性である。
【０００５】
プッシュ型ビデオオンデマンド（VOD：video on demand）サービスは、とりわけ優先度、ユーザ加入、ネットワーク状態（例えば、帯域の可用性の測定）、動的なコンテンツ分類、スケジュール履歴を含む複数の基準に基づくスマートなスケジューリング（smart scheduling）に従って、ブロードキャストマルチキャストネットワーク（例えば、DVB-H）でビデオファイルをエンドユーザ装置に送信する。ユーザの嗜好に合致するこれらのファイルは、エンドユーザ装置のローカル記憶装置に保存される。このことにより、ユーザは、再生遅延なしに、基礎となる配信機構をほとんど気にせずに、広範囲のコンテンツにアクセスすることが可能になる。DVB-Hは、標準“ETSI EN 301 192 V1.4.1 (2004-11) Digital Video Broadcasting (DVB); DVB specification for data broadcasting”及び“ETSI EN 302 304 V1.1.1 (2004-11) Digital Video Broadcasting (DVB); Transmission System for Handheld Terminals (DVB-H)”に規定されている。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
移動ブロードキャストネットワークは、片方向ネットワークであり、パケット損失は、アプリケーション前方誤り訂正（FEC：forward error correction）の使用を通じて部分的に解決可能である。しかし、FEC機構の使用は、帯域を消費し、完全に回復されたファイルを保証しない。このことは、ユーザがトンネルのようなあまりカバーされていない領域に移動したときに、端末が大部分のデータを損失する可能性がある無線移動ブロードキャストネットワークで特に当てはまる。更に、標準“ETSI TR 102 377 V1.1.1 (2005-02) Digital Video Broadcasting (DVB); DVB-H Implementation Guidelines”による現在のDVB-H受信機の実装では、複数のIPパケットを含むパケットのバーストがFECを使用して完全に回復できない場合、無視される。このように、複数の重要なIPパケットが損失する可能性がある。
【０００７】
パケット損失を回避する他の技術は、同じファイルを複数回送信することにある。これは、例えば、標準“DVB-IPDC ESG, ETSI TS 102 471 V1.2.1 (2006-09), Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic Service Guide (ESG)”に指定された電子サービスガイド（Electronic Service Guide）コンテナのような短いファイルに適することがある。しかし、ビデオファイル配信にとっては、明らかに効率の悪い機構である。
【０００８】
ファイル回復又はロバストなファイルキャスト（file casting）は、無線で送信されるビデオファイルの完全性を保証する他の方法である。これは、ユーザの視聴経験を拡張するプッシュ型VODサービスに特に適している。
【０００９】
配信後ファイル回復プロトコル（post delivery file repair protocol）は、3GPP-MBMS（Third Generation Partnership Project, Multimedia Broadcast Multicast Service group）により作成された標準“ETSI TS 102 472 V1.2.1 (2006-12), Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content Delivery Protocols”に記載されている。また、DVB-CBMS（Digital Video Broadcasting-Convergence Broadcast Multicast System group）により作成された標準“ETSI TS 126 346 V6.1.0 (2005-06), Universal Mobile Telecommunications System (UMTS); Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs (3GPP TS 26.346 version 6.1.0 Release 6)”にも記載されている。ファイル回復機構は、いわゆる関連配信（associated delivery）手順の一部であり、主な手順は、RFC 3926（File Delivery over Unidirectional Transport (FLUTE)）に指定されているFLUTEプロトコルスイートに基づくファイル配信である。ファイル回復プロトコルの目的は、ファイル配信手順に従って前に受信したファイルの一部及び／又は損失パケットを取得する方法を提供することである。
【００１０】
ファイル回復手順は、ファイルが完全に受信されたと仮定される場合に常に始まる。FLUTEでは、ファイルの終了を検出することは非常に困難である。ファイルの最後のFLUTEパケットは、ファイルの終了を伝えるために印が付けられることがある。しかし、このパケットが損失すると、受信機は、ファイル配信テーブル（FDT：File Delivery Table）に依存しなければならない。FDTは、FLUTEプロトコルの一部として帯域で送信されるファイルについての一式の情報である。このような情報は、任意選択で、ファイルのサイズを含む。それにも拘らず、RFC 3926によれば、DVB-CBMSは、FLUTEプロトコルで現在伝送されているファイルサイズを示すFDT伝送長パラメータを使用することを推奨する。ファイルが仮に受信されると、受信機は、損失したFLUTEパケットを検出し、回復サーバと接続を確立する。バックオフアルゴリズムに従って、正しい時間に１つ以上の要求を送信し、損失したパケットを取得し、完全に再構成されたファイルを保存する。
【００１１】
この機構は、DVB-CBMSにより推奨されているラプター符号（raptor code）のようなアプリケーションFECと結合され得る。受信機は、成功してFECデコード処理を実行するために必要なパケットのみを要求する。
【００１２】
しかし、FDTは受信機により受信されないことがある。更に、サイズ情報は、伝送長を含むFEC配信情報を集める必須の拡張ヘッダとして、FLUTEパケットヘッダに存在する。また、各FLUTEパケットのヘッダ拡張を配信することは必須ではない。最後に、前の情報が受信機により検出されていない場合に、ファイルを安全に閉じるために監視タイマが使用されることがある。２つのパケットの間の経過時間が一定ではないため、これは慎重に使用されなければならない。
【００１３】
本発明は、要求側装置に良く適合する回復サーバの選択を実行する回復ゲートウェイを提供することにより、従来技術のファイル回復に関する課題の少なくともいくつかを改善することを目的とする。
【課題を解決するための手段】
【００１４】
本発明は、少なくとも１つの端末と複数の回復サーバとが少なくとも１つのファイルサーバからプッシュモードで配信される少なくとも１つのファイル配信セッションを受信するシステムにおいて、複数の回復サーバの中から回復サーバを選択する回復制御装置での方法に関する。
【００１５】
このため、この方法は、少なくとも１つのファイル配信セッションのパケットを回復する要求を少なくとも１つの端末から受信するステップと、少なくとも１つの端末へのパケットを回復する回復サーバを選択するステップと、選択された回復サーバのアドレスを用いて、要求を少なくとも１つの端末にリダイレクトするステップとを有する。
【００１６】
ファイル回復機構は、何らかの受信機が一方向ブロードキャストネットワークを通じて前に受信したファイルを回復することを可能にするポイント・ツー・ポイント型プロトコルに基づく。この対策は、DVB-IPDC及び3GPP-MBMS配信後ファイル回復機構の可能性を広げ、ロバスト性及びスケーラビリティを拡張する。本発明の方法は、要求が送信された時点で最善の回復サーバを提供することにより、回復手順の効率を改善する回復手順の集中制御を提供する。これは、大規模ネットワークに展開した複数の回復サーバを有するネットワークにうまく適合する。
【００１７】
実施例によれば、この方法は、端末からの少なくとも１つのファイル配信セッションのパケットを回復する以降の要求を、選択された回復サーバにリダイレクトするステップを有する。
【００１８】
本発明はまた、少なくとも１つの端末と複数の回復サーバとが少なくとも１つのファイルサーバからプッシュモードで配信される少なくとも１つのファイル配信セッションを受信するシステムにおいて、複数の回復サーバの中から回復サーバを選択する回復制御装置での方法に関する。
【００１９】
このため、この方法は、少なくとも１つのファイル配信セッションのパケットを回復する要求を少なくとも１つの端末から受信するステップと、少なくとも１つの端末へのパケットを回復する回復サーバを選択するステップと、要求を選択された回復サーバに転送するステップとを有する。
【００２０】
実施例によれば、この方法は、端末からの少なくとも１つのファイル配信セッションのパケットを回復する以降の要求を、選択された回復サーバに転送するステップを有する。
【００２１】
実施例によれば、回復サーバは、第１の形式又は第２の形式であり、第１の形式の回復サーバは、ファイルサーバにより送信されたパケットの一部のみを正確に受信し、第２の形式の回復サーバは、ファイルサーバにより送信された全てのパケットを正確に受信する。選択するステップは、第１の形式の回復サーバを分類するステップと、続いて分類の最初から最後の回復サーバまで、回復サーバが保証できる、閾値を満たす回復確率の指示で応答を受信するまで、パケットを回復する要求を送信するステップと、回復サーバが閾値を満たす場合、回復サーバを選択するステップと、リストの最後の回復サーバが閾値を満たす確率を提供しない場合、第２の形式の回復サーバを選択するステップとを有する。
【００２２】
実施例によれば、回復コントローラは、最も負荷の低いものから最も負荷の高いものに回復サーバを分類する。
【００２３】
実施例によれば、回復コントローラは、要求側装置に最も近い第２の形式の回復サーバを選択する。
【００２４】
実施例によれば、ファイル配信セッションは、片方向トランスポートセッションでのファイル配信である。
【００２５】
実施例によれば、選択するステップは、マルチキャスト回復を使用することについて決定するステップと、第２の形式の回復サーバを選択するステップとを有する。
【００２６】
本発明はまた、回復制御装置に関し、１つより多くの回復サーバと少なくとも１つの端末とが少なくとも１つのファイルサーバからプッシュモードで配信される少なくとも１つのファイル配信セッションを受信するシステムにおいて、１つより多くの回復サーバ及び少なくとも１つの端末と通信する通信手段と、少なくとも１つの端末から回復要求を受信したときに、少なくとも１つの端末へのパケットを回復する回復サーバを１つより多くの回復サーバの中から選択する選択手段と、パケットを回復するために端末から受信した要求を回復サーバにリダイレクトする又は要求を回復サーバに転送するリダイレクト手段とを有する。
【図面の簡単な説明】
【００２７】
【図１】単一サーバを有するシステムのブロック図
【図２】実施例によるマルチサーバ・アーキテクチャのブロック図
【図３】実施例による回復コントローラのブロック図
【図４】実施例による選択方法のフローチャート
【発明を実施するための形態】
【００２８】
開示された実施例の範囲に相当する特定の態様が以下に示される。これらの態様は、本発明が取り得る特定の形式の簡単な要約を読者に提供するためにのみ提示されており、これらの態様は、本発明の範囲を限定することを意図しないことがわかる。実際に、本発明は、以下に示さないことがある様々な態様を含み得る。
【００２９】
本発明は、添付図面を参照して、非限定的ではない以下の実施例及び実行例を用いて示され、良く理解できる。
【００３０】
図３では、提示されたブロックは、単なる機能エンティティであり、必ずしも物理的に別個のエンティティに対応するとは限らない。すなわち、これらは、ハードウェア又はソフトウェアの形式で開発されてもよく、１つ又は複数の集積回路に実装されてもよい。
【００３１】
例示的な実施例は、DVB-Hアーキテクチャでのビデオブロードキャストのフレームワーク内に入るが、本発明は、この特定の環境に限定されず、サーバが複数のサーバから選択される他のフレームワークにも適用され得る。
【００３２】
単一サーバを有するシステムが図１に示されている。これは、標準“ETSI TS 102 472 V1.2.1 (2006-12)-Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content Delivery Protocols”に準拠する。コンテンツは、IPネットワーク（1）及びDVB-Hネットワーク（3）でDVB-H端末（T1、T2、T3）にブロードキャストされる（4）。端末は、GPRS標準に準拠した3Gネットワーク（2）を通じて、紛失したファイル（5）を回復サーバ（R1）に要求する。回復サーバ（R1）は、ファイルサーバ（F1）に対してトランスペアレントである。回復サーバは、送出されるUDPトラヒックを受信し、信頼性があることを仮定する。回復サーバは、ファイルサーバのホスト内に存在してもよい。回復サーバは、マルチチャネルでもよい。すなわち、FLUTEセッションに関連する複数のALCチャネルを受信してもよい。ALCはRFC 3450（Asynchronous Layered Coding (ALC) Protocol Instantiation）に規定されている。
【００３３】
FLUTEセッションは、ファイル配信セッションに対応する。これは、ファイルサーバのソースIPアドレスと、トランスポートセッション識別子（TSI：Transport Session Identifier）とにより識別される。TSIは、各FLUTEパケットに示される。回復サーバは、一意のセッションを受信することに専用のものでもよく、マルチセッションでもよい。すなわち、並列に複数のセッションを受信してもよい。
【００３４】
回復を要求するときに、端末は、回復されるファイルのユニフォームリソース識別子（URI：Uniform Resource Identifier）を使用する。しかし、このURIは、受信機に知られていないことがあり、URI及び対応するFLUTEトランスポート識別子の間の関連付けを伝達するFDTが損失する可能性がある。実施例によれば、回復されるファイルは、進行中のセッションのトランスポートオブジェクト識別子（TOI：Transport Object Identifier）を使用して、ファイルのブロードキャストに続くファイル回復期間中に一意に識別されてもよい。TOIは、FLUTEパケットヘッダに埋め込まれたFLUTEプロトコルスイート識別子である。この識別子は、（異なるURIにリンクされたトランスポートオブジェクト識別子として）FLUTEセッションの存続期間中に異なる時間に再利用されてもよい。同時に、この識別子は、送信者（すなわち、ファイルサーバ）のソースアドレスIPとトランスポートセッション識別子（TSI：Transport Session Identifier）とのおかげで識別されたFLUTEセッション内で、FDTインスタンスを通じて有効なURIに一意に関連付けられる。
【００３５】
FDTは、ファイルのURIを含み、配信されるファイルにリンクした重要な情報を伝達する。これは、受信機により、それに従ってファイルを格納、分類又は処理するために使用される。FDTが部分的に受信された場合、端末が受信ファイルで関連するFDT情報を見つけることができないことが生じ得る。前述のようにFLUTE識別子を使用してファイルを回復し、プライベートなネーミング方式（private naming scheme）に従ってそれを格納し得るが、更に便利なネーミング処理で紛失したFDT情報を取得することが有用である。実施例によれば、回復要求は、端末がTSI/TOIの対で識別されたファイルにリンクされた少なくとも部分的なFDT又はFDTを要求できるように拡張されている。当然に、最適化された要求は、ファイルを識別するためのTSI/TOIと、回復されるFLUTEパケットのリストと、関連する部分的なFDTを同時に取得する指示とを集める。
【００３６】
現在のDVB-CBMSファイル回復プロトコルは、回復を要求するクライアントが回復される各FLUTEパケットに対応するFECペイロードIDを送信する。これは、ソースブロック番号（SBN：Source block Number）と符号化シンボルID（ESI：Encoding Symbol ID）とで構成される。回復サーバは、その応答で、いわゆるFECペイロードIDをそれぞれ前に付けられた、一式の要求されたペイロードチャンクを返信する。このことは、クライアントに対して、非FLUTEパケットとして入来する回復パケットを処理させる。或いは、クライアントに対して、FLUTEパケットを再構成させる。これは容易なタスクではない。実施例によれば、回復サーバは、クライアントの要求時に、ペイロード部分のみではなく、完全なFLUTEパケットを返信してもよい。このことは、回復されたFLUTEパケットがDVB-Hインタフェースから入来するものとして受信処理に再挿入され得るため、クライアント側の実装を簡単にする。
【００３７】
マルチサーバ・アーキテクチャが図２に示されている。これは、単一サーバシステムにスケーラビリティを提供することを目的とする。これは、FLUTEマルチキャスト配信プロトコルに従ってファイルをブロードキャスト又はマルチキャストするファイルサーバ（F1）を有する。
【００３８】
これは、高信頼性接続手段を通じてファイルサーバにリンクされた少なくとも１つの高信頼性サーバ（RR）を有する。高信頼性接続手段は、非常に低い誤り率又は0に等しい誤り率を提供する手段である。高信頼性回復サーバは、マルチキャストトラヒックを受信し、同時に、その内部ファイルデータベースを構築する。高信頼性回復サーバは、誤りなしに全てのトラヒックを取得する。高信頼性回復サーバ及びファイルサーバは、異なるエンティティに表されている。当然に、これらは、同じ物理エンティティ内に存在してもよい。
【００３９】
このアーキテクチャはまた、以下で回復サーバと呼ばれる一式の低信頼性回復サーバ（R1、R2、R3、R4、R5、R6）を有する。これらは、ファイルサーバによりブロードキャストされるファイルを取得する。これらは、損失及び誤りを有してファイルを受信するという意味で信頼性がない。従って、これらは、他のクライアント端末としてファイル回復プロトコルを使用して自分のファイルを回復する必要がない。
【００４０】
コンテンツは、IPネットワーク（1）及びDVB-Hネットワーク（3）でDVB-H端末（T1、T2、T3）にブロードキャストされる。端末は、GPRS標準に準拠した3Gネットワーク（2）を通じて、紛失したファイルを回復コントローラ（RC）に要求する。
【００４１】
マルチサーバ・アーキテクチャは、回復制御ゲートウェイ（RC）を有する。回復制御ゲートウェイ（RC）は、基本的には、システムのHTTPサーバのフロントエンドである。これは、クライアント端末から入来する回復要求を受信して分析する。これは、回復サーバのインフラストラクチャに従って回復方針を決定する。前述の単一サーバシステムでは、回復制御ゲートウェイ及び高信頼性回復サーバは、一緒に統合されてもよい。マルチサーバ・アーキテクチャでは、回復制御ゲートウェイは、回復サーバの１つに含まれてもよい。代替として、回復制御ゲートウェイは、クライアント端末と同じ場所にあってもよい。一般的に、回復コントローラは、定期的にサーバにポーリングし、どれがアクティブでありどれが非アクティブであるかを検査し、各サーバのCPU負荷を検査する。
【００４２】
実施例によれば、２つのトポロジがサポートされる。
【００４３】
集中型インフラストラクチャとも呼ばれるサーバファーム（server farm）・インフラストラクチャ（11）は、LANを通じて共に接続された一式の回復サーバを有する。サーバファームは回復制御ゲートウェイにより制御され、場合によってはクライアントと直接に相互接続されてもよい。回復制御ゲートウェイは、DNS型負荷バランシングを実行するウェブファーム・コントローラにより使用されるものと同様の負荷基準に従って、回復サーバを選択する。
【００４４】
分散型インフラストラクチャ（10）は、最も効率的な応答時間を提供するために大規模な範囲に沿って分散された一式の回復サーバである。
【００４５】
回復コントローラとも呼ばれる回復制御ゲートウェイは、システムインフラストラクチャのヘッドエンドである。要求提示用のアドレスは、端末により周知の唯一の情報である。端末がファイルを回復する必要があるときに、回復要求を回復コントローラに送信する。回復コントローラは、前述の２つのトポロジ（サーバファーム及び分散型ネットワーク）を扱うことができる。
【００４６】
分散型ネットワークの場合、回復コントローラは、要求を、端末に最も近い回復サーバに転送する。転送は、回復コントローラが回復応答としてHTTPリダイレクトコマンドをクライアントに返信するHTTPリダイレクトに基づく。HTTPリダイレクトは、HTTP1.0についてのRFC1945及びHTTP1.1についてのRFC2616に規定されている。HTTPリダイレクトを受信すると、クライアントは、HTTPリダイレクトに示された回復サーバに、新しいHTTP要求を自動的に発行する。この回復サーバは、回復プロトコルに従って要求に応答する。
【００４７】
サーバファームの場合、回復コントローラは、ファームのあまり負荷のない回復サーバに要求を転送する。要求は、回復サーバに直接転送される。選択された回復サーバは、回復プロトコルに従って要求に務めることができる。要求及び応答は、常に回復コントローラを通過する。
【００４８】
実施例によれば、回復コントローラは、あまり負荷がないため又は要求を送信する端末に近いためだけでなく、特定の要求に関連する特定の回復確率を保証できるサーバを選択してもよい。回復確率は、回復コントローラの設定パラメータである。一式の回復サーバの中から、最も信頼性のあるものと考えられるサーバが依然として存在する。他のサーバは、パケット損失のため、ファイルサーバから出力された完全なトラヒックを部分的に取得している可能性がある。
【００４９】
サーバの選択は、図４に示すように、以下の通り実行される。端末は、回復コントローラとTCPセッションを設定する。これは、回復コントローラにHTTP回復要求を送信するS1。ステップS2、S3において、回復コントローラは、要求を変更する。これは、回復がその回復サーバで可能であるか否かを検査するために要求が使用されることを示すために、要求の名前を変更する。その要求は、回復には使用されない。次に、（分散型ネットワークの場合）要求を最も近い回復サーバに転送する。或いは、（サーバファームの場合）最も負荷のないサーバに転送する。換言すると、回復コントローラは、回復サーバのリストを構築し、ネットワーク形式に応じた基準に従ってリストの回復サーバを分類する。サーバファームでは、ランク付けはサーバ負荷に基づく。
【００５０】
要求を受信すると、回復サーバは、要求を分析し、保証できる回復レベルを示す応答を回復コントローラに返信するS4。この回復レベルは、以下のような複数のパラメータに基づいて推定され得る。
−回復サーバが回復できるファイルの割合（関連するローカルデータベースで利用可能なデータに対応する）
−受信した要求に対応する回復確率
回復コントローラは、これらのパラメータを使用し、閾値に基づいてその選択を維持するか否かを決定する。
【００５１】
回復サーバの応答が回復コントローラを満足させない場合、回復コントローラは、他の回復サーバを試しS6、より良い回復率を提供するか否かを検査する。
【００５２】
その選択処理がうまく回復サーバを提供しない場合、回復コントローラは、場合によっては負荷基準を使用して、高信頼性回復サーバの１つを選択するS7。
【００５３】
換言すると、端末は、回復されるファイルの特定の数のパケットを要求する。要求を受信すると、回復コントローラは、要求を回復コントローラに送信し、サーバがパケットを提供できるか否かを認識する。要求を受信すると、サーバは、利用可能なパケット数を検査する。確率は、要求されたパケットの数のうち利用可能なパケットの数である。回復コントローラは、閾値を設定する。確率が閾値より小さい場合、回復コントローラは、他のサーバに要求を送信する。確率が閾値より大きい場合、サーバは選択される。閾値は40%の値に設定されることが好ましい。
【００５４】
HTTP回復要求長は制限される。これは256バイトの値に制限されてもよい。端末が大量のデータを要求すると、単一の要求では十分ではなく、端末は同じセッションで複数の下位要求を連続して送信する。その場合、回復コントローラは、一連の下位要求のうち最初の要求に基づいて、サーバの選択を実行する。回復サーバは、各下位要求に対して応答を送信する。
【００５５】
回復サーバが選択されると、回復コントローラの動作は、インフラストラクチャに依存する。サーバファームの場合、２つの可能性が存在する。
【００５６】
第１の可能性では、サーバファームは、クライアントのネットワークに直接接続されていない。回復コントローラは、検査目的ではなく、処理目的のために、選択された回復サーバに要求を転送する。回復サーバは、要求を処理し、回復コントローラにその応答を返信し、回復コントローラは、それを端末などに転送する。
【００５７】
第２の可能性では、サーバファームは、クライアントのネットワークに直接接続されている。回復要求を受信すると、回復コントローラは、HTTPリダイレクトコマンドをクライアントに返信する。そのコマンドは、選択された回復サーバのアドレスを集める。HTTPリダイレクトを受信すると、クライアントは、HTTPリダイレクトに示されたアドレスで、HTTP要求を回復サーバに自動的に送信する。回復サーバは、回復パケット等をクライアントに返信する。
【００５８】
分散型インフラストラクチャの場合、第２の可能性のみが当てはまる。
【００５９】
分散型インフラストラクチャは、サーバファーム・インフラストラクチャと結合されてもよい。結合されたインフラストラクチャは、一式の分散型“スタンドアローン”及び“ファーム”サーバを有する。コントローラは、サーバ（又はサーバファーム）の位置とそれぞれ個々の回復サーバの負荷レベルとに基づいて、より複雑な発見的手法を使用する。
【００６０】
実施例によれば、回復ゲートウェイはまた、ユニキャスト・マルチキャストモジュールを有する。このモジュールは、ユニキャスト配信モードからマルチキャスト配信に回復モードを切り替えるように適合される。前述のように、ゲートウェイは、端末を回復サーバにリダイレクトする、或いは、要求を回復サーバに転送する。これはユニキャストモードである。
【００６１】
ETSI TS 126 346に準拠した方法では、ゲートウェイは、端末をブロードキャスト／マルチキャスト配信にリダイレクトしてもよい。マルチキャストに切り替えるときに、ゲートウェイは、そのマルチキャスト配信を通じてブロードキャストされる回復データを提供する高信頼性回復サーバを選択することが好ましい。
【００６２】
回復制御ゲートウェイRCが図３に示されている。これは、インターネットに接続する通信手段102を有する。当然に、回復コントローラは、回復サーバ及び端末に接続可能な他の形式のネットワークに接続してもよい。通信手段により、ゲートウェイは、端末及び回復サーバと通信することが可能になる。
【００６３】
これは、端末からの要求を回復サーバのアドレスにリダイレクトするリダイレクト手段104を有する。実施例によれば、リダイレクト手段は、前述のHTTPリダイレクトに準拠する。
【００６４】
これは、前述のように回復サーバを選択する選択手段103を有する。
【００６５】
これは、前述のようにユニキャストモードとマルチキャストモードとの間の切り替えを実行するユニキャスト・マルチキャストモジュール105を有する。
【００６６】
これは、メモリの形式の、アーキテクチャの回復サーバのリストを格納する格納モジュール101を有する。
【００６７】
これは、プロセッサの形式の処理モジュール106を有する。
【００６８】
回復制御ゲートウェイは、コンピュータ装置と同じ場所にあってもよい。当然に、回復制御ゲートウェイはまた、前述の機能モジュールを有する如何なるスタンドアローン型装置でもよい。
【００６９】
詳細な説明、特許請求の範囲及び図面に示された言及は、独立して又は如何なる適切な組み合わせで提供されてもよい。必要に応じて、機能は、ハードウェア、ソフトウェア又はこれら２つの組み合わせで実装されてもよい。
【００７０】
ここでの“一実施例”又は“実施例”への言及は、実施例に関して説明した特定の機能、構造又は特徴が本発明の少なくとも１つの実装に含まれ得ることを意味する。明細書の様々な場所に“一実施例で”という用語が現れることは、必ずしも同じ実施例を示すとは限らず、必ずしも他の実施例と相互排他的な別の又は代替の実施例であるとは限らない。
【００７１】
特許請求の範囲に現れる参照符号は、例示のみであり、特許請求の範囲に限定的な影響を与えるべきではない。
【特許請求の範囲】
【請求項１】
少なくとも１つの端末と複数の回復サーバとが少なくとも１つのファイルサーバからプッシュモードで配信される少なくとも１つのファイル配信セッションを受信するシステムにおいて、複数の回復サーバの中から回復サーバを選択する回復制御装置での方法であって、
前記少なくとも１つのファイル配信セッションのパケットを回復する要求を前記少なくとも１つの端末から受信するステップと、
前記少なくとも１つの端末への前記パケットを回復する回復サーバを選択するステップと、
前記選択された回復サーバのアドレスを用いて、前記要求を前記少なくとも１つの端末にリダイレクトするステップと
を有する方法。
【請求項２】
前記端末からの前記少なくとも１つのファイル配信セッションのパケットを回復する以降の要求を、前記選択された回復サーバにリダイレクトするステップを有することを特徴とする請求項１に記載の方法。
【請求項３】
少なくとも１つの端末と複数の回復サーバとが少なくとも１つのファイルサーバからプッシュモードで配信される少なくとも１つのファイル配信セッションを受信するシステムにおいて、複数の回復サーバの中から回復サーバを選択する回復制御装置での方法であって、
前記少なくとも１つのファイル配信セッションのパケットを回復する要求を前記少なくとも１つの端末から受信するステップと、
前記少なくとも１つの端末への前記パケットを回復する回復サーバを選択するステップと、
前記要求を前記選択された回復サーバに転送するステップと
を有する方法。
【請求項４】
前記端末からの前記少なくとも１つのファイル配信セッションのパケットを回復する以降の要求を、前記選択された回復サーバに転送するステップを有することを特徴とする請求項３に記載の方法。
【請求項５】
前記回復サーバは、第１の形式又は第２の形式であり、第１の形式の回復サーバは、前記ファイルサーバにより送信されたパケットの一部のみを正確に受信し、第２の形式の回復サーバは、前記ファイルサーバにより送信された全てのパケットを正確に受信し、
前記選択するステップは、
前記第１の形式の前記回復サーバを分類するステップと、
続いて前記分類の最初から最後の回復サーバまで、前記回復サーバが保証できる、閾値を満たす回復確率の指示で応答を受信するまで、パケットを回復する要求を送信するステップと、
回復サーバが閾値を満たす場合、当該回復サーバを選択するステップと、
リストの最後の回復サーバが前記閾値を満たす確率を提供しない場合、第２の形式の回復サーバを選択するステップと
を有することを特徴とする請求項１ないし４のうちいずれか１項に記載の方法。
【請求項６】
前記回復制御装置は、最も負荷の低いものから最も負荷の高いものに前記回復サーバを分類することを特徴とする請求項１ないし５のうちいずれか１項に記載の方法。
【請求項７】
前記回復制御装置は、要求側装置に最も近い前記第２の形式の前記回復サーバを選択することを特徴とする請求項５又は６に記載の方法。
【請求項８】
前記ファイル配信セッションは、片方向トランスポートセッションでのファイル配信であることを特徴とする請求項１ないし７のうちいずれか１項に記載の方法。
【請求項９】
前記選択するステップは、
マルチキャスト回復を使用することについて決定するステップと、
前記第２の形式の回復サーバを選択するステップと
を有することを特徴とする請求項３に記載の方法。
【請求項１０】
１つより多くの回復サーバと少なくとも１つの端末とが少なくとも１つのファイルサーバからプッシュモードで配信される少なくとも１つのファイル配信セッションを受信するシステムにおいて、１つより多くの回復サーバ及び少なくとも１つの端末と通信する通信手段と、
前記少なくとも１つの端末から回復要求を受信したときに、前記少なくとも１つの端末への前記パケットを回復する回復サーバを前記１つより多くの回復サーバの中から選択する選択手段と、
パケットを回復するために端末から受信した要求を前記回復サーバにリダイレクトする又は前記要求を前記回復サーバに転送するリダイレクト手段と
を有する回復制御装置。
【請求項１】
少なくとも１つの端末と複数の回復サーバとが少なくとも１つのファイルサーバからプッシュモードで配信される少なくとも１つのファイル配信セッションを受信するシステムにおいて、複数の回復サーバの中から回復サーバを選択する回復制御装置での方法であって、
前記少なくとも１つのファイル配信セッションのパケットを回復する要求を前記少なくとも１つの端末から受信するステップと、
前記少なくとも１つの端末への前記パケットを回復する回復サーバを選択するステップと、
前記選択された回復サーバのアドレスを用いて、前記要求を前記少なくとも１つの端末にリダイレクトするステップと
を有する方法。
【請求項２】
前記端末からの前記少なくとも１つのファイル配信セッションのパケットを回復する以降の要求を、前記選択された回復サーバにリダイレクトするステップを有することを特徴とする請求項１に記載の方法。
【請求項３】
少なくとも１つの端末と複数の回復サーバとが少なくとも１つのファイルサーバからプッシュモードで配信される少なくとも１つのファイル配信セッションを受信するシステムにおいて、複数の回復サーバの中から回復サーバを選択する回復制御装置での方法であって、
前記少なくとも１つのファイル配信セッションのパケットを回復する要求を前記少なくとも１つの端末から受信するステップと、
前記少なくとも１つの端末への前記パケットを回復する回復サーバを選択するステップと、
前記要求を前記選択された回復サーバに転送するステップと
を有する方法。
【請求項４】
前記端末からの前記少なくとも１つのファイル配信セッションのパケットを回復する以降の要求を、前記選択された回復サーバに転送するステップを有することを特徴とする請求項３に記載の方法。
【請求項５】
前記回復サーバは、第１の形式又は第２の形式であり、第１の形式の回復サーバは、前記ファイルサーバにより送信されたパケットの一部のみを正確に受信し、第２の形式の回復サーバは、前記ファイルサーバにより送信された全てのパケットを正確に受信し、
前記選択するステップは、
前記第１の形式の前記回復サーバを分類するステップと、
続いて前記分類の最初から最後の回復サーバまで、前記回復サーバが保証できる、閾値を満たす回復確率の指示で応答を受信するまで、パケットを回復する要求を送信するステップと、
回復サーバが閾値を満たす場合、当該回復サーバを選択するステップと、
リストの最後の回復サーバが前記閾値を満たす確率を提供しない場合、第２の形式の回復サーバを選択するステップと
を有することを特徴とする請求項１ないし４のうちいずれか１項に記載の方法。
【請求項６】
前記回復制御装置は、最も負荷の低いものから最も負荷の高いものに前記回復サーバを分類することを特徴とする請求項１ないし５のうちいずれか１項に記載の方法。
【請求項７】
前記回復制御装置は、要求側装置に最も近い前記第２の形式の前記回復サーバを選択することを特徴とする請求項５又は６に記載の方法。
【請求項８】
前記ファイル配信セッションは、片方向トランスポートセッションでのファイル配信であることを特徴とする請求項１ないし７のうちいずれか１項に記載の方法。
【請求項９】
前記選択するステップは、
マルチキャスト回復を使用することについて決定するステップと、
前記第２の形式の回復サーバを選択するステップと
を有することを特徴とする請求項３に記載の方法。
【請求項１０】
１つより多くの回復サーバと少なくとも１つの端末とが少なくとも１つのファイルサーバからプッシュモードで配信される少なくとも１つのファイル配信セッションを受信するシステムにおいて、１つより多くの回復サーバ及び少なくとも１つの端末と通信する通信手段と、
前記少なくとも１つの端末から回復要求を受信したときに、前記少なくとも１つの端末への前記パケットを回復する回復サーバを前記１つより多くの回復サーバの中から選択する選択手段と、
パケットを回復するために端末から受信した要求を前記回復サーバにリダイレクトする又は前記要求を前記回復サーバに転送するリダイレクト手段と
を有する回復制御装置。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２０１０−５２４２８５（Ｐ２０１０−５２４２８５Ａ）
【公表日】平成２２年７月１５日（２０１０．７．１５）
【国際特許分類】
【出願番号】特願２０１０−５００２２８（Ｐ２０１０−５００２２８）
【出願日】平成２０年３月１９日（２００８．３．１９）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０５３３２９
【国際公開番号】ＷＯ２００８／１１９６７３
【国際公開日】平成２０年１０月９日（２００８．１０．９）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
【公表日】平成２２年７月１５日（２０１０．７．１５）
【国際特許分類】
【出願日】平成２０年３月１９日（２００８．３．１９）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０５３３２９
【国際公開番号】ＷＯ２００８／１１９６７３
【国際公開日】平成２０年１０月９日（２００８．１０．９）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
[ Back to top ]