JP5485134B2 - 移動ｔｖのロバストなファイルキャスト - Google Patents

移動ｔｖのロバストなファイルキャスト Download PDF

Info

Publication number
JP5485134B2
JP5485134B2 JP2010500228A JP2010500228A JP5485134B2 JP 5485134 B2 JP5485134 B2 JP 5485134B2 JP 2010500228 A JP2010500228 A JP 2010500228A JP 2010500228 A JP2010500228 A JP 2010500228A JP 5485134 B2 JP5485134 B2 JP 5485134B2
Authority
JP
Japan
Prior art keywords
recovery
server
file
request
packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2010500228A
Other languages
English (en)
Other versions
JP2010524285A (ja
JP2010524285A5 (ja
Inventor
ビショー，ギヨーム
アローム，ヴァンサン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thomson Licensing SAS
Original Assignee
Thomson Licensing SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thomson Licensing SAS filed Critical Thomson Licensing SAS
Publication of JP2010524285A publication Critical patent/JP2010524285A/ja
Publication of JP2010524285A5 publication Critical patent/JP2010524285A5/ja
Application granted granted Critical
Publication of JP5485134B2 publication Critical patent/JP5485134B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64315—DVB-H
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2383—Channel coding or modulation of digital bit-stream, e.g. QPSK modulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4382—Demodulation or channel decoding, e.g. QPSK demodulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6375—Control signals issued by the client directed to the server or network components for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092—Error control systems characterised by the topology of the transmission link

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本発明は、概してコンテンツ配信に関し、特に効率的な回復機構を提供する方法及び装置に関する。
この部分は、読者に様々な技術側面を紹介することを目的としており、これらの技術側面は、以下に説明する及び／又は特許請求の範囲に記載する本発明の様々な態様に関連し得る。この説明は、本発明の様々な態様の理解を容易にするために、読者に背景情報を提供する点で有用であると考えられる。従って、この記載は、この観点から読まれるべきであり、従来技術の認定として読まれるべきではない。
少し前から、セルラネットワークを通じて移動端末で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バイトの値に制限されてもよい。端末が大量のデータを要求すると、単一の要求では十分ではなく、端末は同じセッションで複数の下位要求を連続して送信する。その場合、回復コントローラは、一連の下位要求のうち最初の要求に基づいて、サーバの選択を実行する。回復サーバは、各下位要求に対して応答を送信する。
回復サーバが選択されると（S5、S7）、回復コントローラの動作は、インフラストラクチャに依存する。サーバファームの場合、２つの可能性が存在する。
第１の可能性では、サーバファームは、クライアントのネットワークに直接接続されていない。回復コントローラは、検査目的ではなく、処理目的のために、選択された回復サーバに要求を転送する。回復サーバは、要求を処理し、回復コントローラにその応答を返信し、回復コントローラは、それを端末などに転送する。
第２の可能性では、サーバファームは、クライアントのネットワークに直接接続されている。回復要求を受信すると、回復コントローラは、HTTPリダイレクトコマンドをクライアントに返信する。そのコマンドは、選択された回復サーバのアドレスを集める。HTTPリダイレクトを受信すると、クライアントは、HTTPリダイレクトに示されたアドレスで、HTTP要求を回復サーバに自動的に送信する。回復サーバは、回復パケット等をクライアントに返信する。
分散型インフラストラクチャの場合、第２の可能性のみが当てはまる。
分散型インフラストラクチャは、サーバファーム・インフラストラクチャと結合されてもよい。結合されたインフラストラクチャは、一式の分散型“スタンドアローン”及び“ファーム”サーバを有する。コントローラは、サーバ（又はサーバファーム）の位置とそれぞれ個々の回復サーバの負荷レベルとに基づいて、より複雑な発見的手法を使用する。
実施例によれば、回復ゲートウェイはまた、ユニキャスト・マルチキャストモジュールを有する。このモジュールは、ユニキャスト配信モードからマルチキャスト配信に回復モードを切り替えるように適合される。前述のように、ゲートウェイは、端末を回復サーバにリダイレクトする、或いは、要求を回復サーバに転送する。これはユニキャストモードである。
ETSI TS 126 346に準拠した方法では、ゲートウェイは、端末をブロードキャスト／マルチキャスト配信にリダイレクトしてもよい。マルチキャストに切り替えるときに、ゲートウェイは、そのマルチキャスト配信を通じてブロードキャストされる回復データを提供する高信頼性回復サーバを選択することが好ましい。
回復制御ゲートウェイRCが図３に示されている。これは、インターネットに接続する通信手段102を有する。当然に、回復コントローラは、回復サーバ及び端末に接続可能な他の形式のネットワークに接続してもよい。通信手段により、ゲートウェイは、端末及び回復サーバと通信することが可能になる。
これは、端末からの要求を回復サーバのアドレスにリダイレクトするリダイレクト手段104を有する。実施例によれば、リダイレクト手段は、前述のHTTPリダイレクトに準拠する。
これは、前述のように回復サーバを選択する選択手段103を有する。
これは、前述のようにユニキャストモードとマルチキャストモードとの間の切り替えを実行するユニキャスト・マルチキャストモジュール105を有する。
これは、メモリの形式の、アーキテクチャの回復サーバのリストを格納する格納モジュール101を有する。
これは、プロセッサの形式の処理モジュール106を有する。
回復制御ゲートウェイは、コンピュータ装置と同じ場所にあってもよい。当然に、回復制御ゲートウェイはまた、前述の機能モジュールを有する如何なるスタンドアローン型装置でもよい。
詳細な説明、特許請求の範囲及び図面に示された言及は、独立して又は如何なる適切な組み合わせで提供されてもよい。必要に応じて、機能は、ハードウェア、ソフトウェア又はこれら２つの組み合わせで実装されてもよい。
ここでの“一実施例”又は“実施例”への言及は、実施例に関して説明した特定の機能、構造又は特徴が本発明の少なくとも１つの実装に含まれ得ることを意味する。明細書の様々な場所に“一実施例で”という用語が現れることは、必ずしも同じ実施例を示すとは限らず、必ずしも他の実施例と相互排他的な別の又は代替の実施例であるとは限らない。
特許請求の範囲に現れる参照符号は、例示のみであり、特許請求の範囲に限定的な影響を与えるべきではない。

Claims (2)

  1. 少なくとも１つの端末と複数の回復サーバとが少なくとも１つのファイルサーバからプッシュモードで配信される１つのファイル配信セッション中に少なくとも１つのパケットを受信するシステムにおいて、複数の回復サーバの中から回復サーバを選択する回復制御装置での方法であって、
    前記回復制御装置において、
    前記少なくとも１つのファイル配信セッションのパケットを回復する要求を前記少なくとも１つの端末から受信するステップと、
    回復サーバが前記パケットを回復できるか否かを識別するために、所定の基準に従って前記複数の回復サーバに要求を連続して送信するステップと、
    回復サーバが前記パケットを回復できる場合、前記パケットを回復できる前記回復サーバのアドレスを前記少なくとも１つの端末に示すステップ又は前記要求を前記パケットを回復できる前記回復サーバに転送するステップと
    を有する方法。
  2. １つより多くの回復サーバと少なくとも１つの端末とが少なくとも１つのファイルサーバからプッシュモードで配信される１つのファイル配信セッション中に少なくとも１つのパケットを受信するシステムにおいて、１つより多くの回復サーバ及び少なくとも１つの端末と通信する通信手段と、
    前記少なくとも１つの端末から回復要求を受信したときに、回復サーバが前記パケットを回復できるか否かを識別するために、前記複数の回復サーバに要求を連続して送信し、前記回復サーバを選択する選択手段と、
    前記パケットを回復できる前記回復サーバのアドレスを前記少なくとも１つの端末に示す又は前記要求を前記パケットを回復できる前記回復サーバに転送するリダイレクト手段と
    を有する回復制御装置。
JP2010500228A 2007-03-30 2008-03-19 移動ｔｖのロバストなファイルキャスト Active JP5485134B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP07300911 2007-03-30
EP07300911.0 2007-03-30
PCT/EP2008/053329 WO2008119673A1 (en) 2007-03-30 2008-03-19 Robust file casting for mobile tv

Publications (3)

Publication Number Publication Date
JP2010524285A JP2010524285A (ja) 2010-07-15
JP2010524285A5 JP2010524285A5 (ja) 2011-05-19
JP5485134B2 true JP5485134B2 (ja) 2014-05-07

Family

ID=39672759

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010500228A Active JP5485134B2 (ja) 2007-03-30 2008-03-19 移動ｔｖのロバストなファイルキャスト

Country Status (6)

Country Link
US (1) US8341479B2 (ja)
EP (1) EP2143274A1 (ja)
JP (1) JP5485134B2 (ja)
KR (1) KR101495369B1 (ja)
CN (2) CN103152650B (ja)
WO (1) WO2008119673A1 (ja)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8849183B2 (en) 2007-10-05 2014-09-30 Qualcomm Incorporated Location and time based filtering of broadcast information
TWI486040B (zh) 2008-10-10 2015-05-21 Thomson Licensing 在接收器要求失落符號之方法及其接收器
US9280778B2 (en) 2008-12-15 2016-03-08 Qualcomm Incorporated Location logging and location and time based filtering
JP4960392B2 (ja) * 2009-01-07 2012-06-27 株式会社東芝 通信装置、通信方法、及び通信プログラム
US8489948B2 (en) * 2010-04-02 2013-07-16 Nokia Corporation Methods and apparatuses for facilitating error correction
US9485108B2 (en) 2011-03-14 2016-11-01 Qualcomm Incorporated System and apparatus for using multichannel file delivery over unidirectional transport (“FLUTE”) protocol for delivering different classes of files in a broadcast network
US9026671B2 (en) * 2011-04-05 2015-05-05 Qualcomm Incorporated IP broadcast streaming services distribution using file delivery methods
US9451401B2 (en) 2011-05-27 2016-09-20 Qualcomm Incorporated Application transport level location filtering of internet protocol multicast content delivery
US9826502B2 (en) 2011-07-25 2017-11-21 Qualcomm Incorporated Managing handoff triggering between unicast and multicast services
CN103118288B (zh) * 2011-11-16 2017-02-22 康佳集团股份有限公司 一种网络电视安全管理系统及方法
US9213605B2 (en) * 2012-01-23 2015-12-15 Intel Corporation IP multimedia subsystem and method for MBMS file repair using HTTP servers
EP3119022B1 (en) * 2012-07-09 2018-06-13 Telefonaktiebolaget LM Ericsson (publ) Method and arrangement for distributing information during broadcast delivery
US20150286521A1 (en) * 2012-10-15 2015-10-08 Hongxia Long A UE, a BM-SC, a Status Management Server, a Load Balancing Server and a File Repair Server and Respective Methods therein are Provided for File Repair Procedure
CN105556898B (zh) * 2013-08-07 2019-03-29 起元科技有限公司 管理数据馈送
US9699230B2 (en) * 2014-12-10 2017-07-04 At&T Mobility Ii Llc Network bandwidth conservation
WO2016101213A1 (zh) * 2014-12-25 2016-06-30 华为技术有限公司 一种文件修复的方法、相关装置及系统
US10705907B1 (en) * 2016-03-24 2020-07-07 EMC IP Holding Company LLC Data protection in a heterogeneous random access storage array
US9857990B1 (en) 2016-03-24 2018-01-02 EMC IP Holding Company LLC Fast startup for modular storage systems
CN106453593B (zh) * 2016-10-26 2020-09-04 腾讯科技（深圳）有限公司 一种消息推送方法及装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6782490B2 (en) * 1999-03-17 2004-08-24 At&T Corp. Network-based service for the repair of IP multicast sessions
US6577599B1 (en) * 1999-06-30 2003-06-10 Sun Microsystems, Inc. Small-scale reliable multicasting
US6567929B1 (en) * 1999-07-13 2003-05-20 At&T Corp. Network-based service for recipient-initiated automatic repair of IP multicast sessions
US7035258B2 (en) * 2001-12-27 2006-04-25 Microsoft Corporation Method and system for dynamically adjusting transmit and receive parameters for handling negative acknowledgments in reliable multicast
JP3933557B2 (ja) * 2002-10-18 2007-06-20 シャープ株式会社 無線通信システム、装置及び方法
JP3896068B2 (ja) * 2002-10-22 2007-03-22 エヌ・ティ・ティ・コミュニケーションズ株式会社 サーバ・クライアント間通信システムおよび制御サーバ
US8296436B2 (en) 2004-03-22 2012-10-23 Nokia Corporation Conveying parameters for broadcast/multicast sessions via a communication protocol
US7590922B2 (en) * 2004-07-30 2009-09-15 Nokia Corporation Point-to-point repair request mechanism for point-to-multipoint transmission systems
US7376150B2 (en) * 2004-07-30 2008-05-20 Nokia Corporation Point-to-point repair response mechanism for point-to-multipoint transmission systems
US7631085B2 (en) * 2004-08-30 2009-12-08 Nokia Corporation Point-to-point delivery verification report mechanism for point-to-multipoint transmission systems
US8266473B2 (en) * 2005-03-10 2012-09-11 Telecom Italia S.P.A. Disaster recovery architecture
US20060262806A1 (en) * 2005-05-19 2006-11-23 Imed Bouazizi System and method for data delivery

Also Published As

Publication number Publication date
JP2010524285A (ja) 2010-07-15
KR101495369B1 (ko) 2015-02-24
CN101647282A (zh) 2010-02-10
WO2008119673A1 (en) 2008-10-09
CN103152650B (zh) 2016-12-28
KR20090122981A (ko) 2009-12-01
US8341479B2 (en) 2012-12-25
CN103152650A (zh) 2013-06-12
EP2143274A1 (en) 2010-01-13
US20100050032A1 (en) 2010-02-25

Similar Documents

Publication Publication Date Title
JP5485134B2 (ja) 移動ｔｖのロバストなファイルキャスト
US10321199B2 (en) Streaming with optional broadcast delivery of data segments
KR100809654B1 (ko) 통신 프로토콜을 통한 브로드캐스트/멀티캐스트 세션의파라미터들 전송
EP2103083B1 (en) System and method for combining pull and push modes
KR100753026B1 (ko) 무선 네트워크에서의 방송 핸드오버
US8656241B2 (en) Cell dependent multi-group hybrid automatic repeat request method for multicast in wireless networks
CN107948762B (zh) 直播视频的传输方法、装置和系统
US8976787B2 (en) Protocol booster for SCTP in multicast networks
EP2445162A1 (en) Method For Adaptive Streaming
KR20140051493A (ko) 복합 멀티미디어 데이터를 전송하기 위한 데이터 패킷을 송수신하는 방법 및 장치
KR20080108514A (ko) 데이터 수신 방법, 복구 방법 및 대응 단말기
JP5536033B2 (ja) 送信する方法、モバイル端末及びファイルサーバ
EP1921824A1 (en) System and method for sending content from a server to a terminal
KR101699351B1 (ko) 파일 정정 배포 모드를 요청하는 방법

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110318

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110330

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20121130

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121218

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20130315

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20130325

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130617

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140204

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140219

R150 Certificate of patent or registration of utility model

Ref document number: 5485134

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250