(57)【特許請求の範囲】
【請求項１】
欠落したパケットを要求する受信機での方法であって、
第１のサーバから、１つより多くの修復サーバ及び前記１つより多くの修復サーバのそれぞれにより使用される１つより多くの送信モードのリストを受信するステップと、
第２のサーバから、複数のパケットを有するファイルを受信するステップと、
必要に応じて、修復サーバ及び送信モードを選択し、前記送信モードを使用して欠落したパケットを送信するように前記修復サーバに要求するステップと
を有する方法。
【請求項２】
前記要求するステップの前に、ブロードキャスト受信品質についての受信品質を測定するステップを有する、請求項１に記載の方法。
【請求項３】
前記ファイルは、FLUTEプロトコルに従って受信される、請求項１に記載の方法。
【請求項４】
ブロードキャストネットワークからデータを受信し、双方向ネットワークで通信する通信手段と、
前記ブロードキャストネットワークから複数のパケットを有するファイルを受信すると、前記ブロードキャストネットワークでの前記パケットの正確な受信を検査するファイル受信計算手段と、
１つより多くの修復サーバ及び前記１つより多くの修復サーバのそれぞれにより使用される１つより多くの送信モードのリストから、修復サーバ及び送信モードを選択する選択手段と、
前記選択された送信モードを使用して欠落したパケットを送信するように前記修復サーバに要求するため、前記双方向ネットワークで要求を前記選択された修復サーバに送信するファイル受信報告手段と
を有する受信機。
【請求項５】
請求項１に記載の方法に従って、１つより多くの修復サーバ及び前記１つより多くの修復サーバのそれぞれにより使用される１つより多くの送信モードのリストを有する、associatedProcedureDescriptionの形式のXML構成ファイルを有するコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概してファイル修復機構に関し、特にファイル修復配信モードを要求する方法に関する。
【背景技術】
【０００２】
この部分は、当該技術の様々な側面を読者に紹介することを意図しており、以下に及び／又は特許請求の範囲に記載する本発明の様々な態様に関係し得る。この説明は、本発明の様々な態様の理解を容易にするために、読者に背景情報を提供するのに役立つと考えられる。従って、これらの記載はこの観点から読まれるべきであり、従来技術の認定として読まれるべきではないことがわかる。
【０００３】
IETF  RFC  3926は、FLUTEと呼ばれるFile  Delivery  over  Unidirectional  Transportプロトコルを規定する。この標準で規定されたプロトコルは、クライアントの数に関するスケーラビリティ及びクライアントによりサポートされる帯域幅に関する不均一性の問題にうまく対応するように適合される。DVB-H  IP  データキャスト標準の“ETSI  TS  102  472  V1.2.1  (2006-12),  Digital  Video  Broadcasting  (DVB);  IP  Datacast  over  DVB-H;  Content  Delivery  Protocols  (CDP)”（以下ではCDP標準と呼ばれる）は、ファイル修復機構を規定する。この機構は、第２の文献であるETSI  TS  102  591  1.1.1,  Digital  Video  Broadcasting  (DVB);  IP  Datacast  over  DVB-H;  Content  Delivery  Protocols  (CDP)  Implementation  Guidelinesに更に説明されている。
【０００４】
DVB-H  IPデータキャスト標準で採用されているファイル修復方式は、１レベルのファイル修復方式であり、中央集中型クライアント・サーバ“ファイル修復”モードを採用している。これは、ブロードキャスト／マルチキャストネットワークでの信頼性のあるファイル配信を実現するため、FLUTEプロトコルを支援するためにファイル修復機構を使用する。不完全なファイルの受信を検出すると、FLUTE受信機は、ファイル修復機構を起動する。これは、欠落又は破損したパケットを要求することを含む。FLUTEの用語によれば、これらのパケットはシンボルと呼ばれる。要求は、ポイント・ツー・ポイント接続を使用して修復ファイルサーバに送信される。基本的に、要求は、修復されるファイルの名前及び欠落したシンボルのリストを集約する。
【０００５】
このようなシステム内には、１つ以上の修復サービスをそれぞれ含む複数の修復サーバが共存してもよい。全ての可能な修復サービスのリストが“関連配信手順構成ファイル（associated  delivery  procedure  configuration  file）”で公開される。これは、使用可能な修復サービス毎に１つのURLを含むXMLファイルである。修復サーバが必要になった場合、クライアントは、これらのサービスのうち１つをランダムに選択し、要求されたシンボルのリストを含む修復要求をポイント・ツー・ポイントリンクでアドレス指定する。修復サービスは、要求されたシンボルの一部又は全部をポイント・ツー・ポイントリンクで送信する、或いは、要求を異なるサービスにリダイレクトする。このリダイレクトは、他の修復サーバの代わりに、欠落又は破損した受信シンボルが再びブロードキャストされるFLUTEセッションの記述を示してもよい。
【０００６】
ファイル修復手順は、ポイント・ツー・ポイントリンクを通じてクライアントにより開始され、更に、再びポイント・ツー・ポイントリンクを使用して、若しくはブロードキャストチャネルを使用して、又はこれらのリンクの組み合わせを使用して実現される。クライアントは、全ての欠落したシンボルを要求する。シンボルのリストを分析した後に、修復サーバは、配信モードを選択する。リソースの効率的な使用のため、或るシンボルはブロードキャストリンクで配信され、或るシンボルは、ポイント・ツー・ポイントリンクで送信される。
【０００７】
ポイント・ツー・ポイント及びブロードキャストリンクの使用を組み合わせたこのような修復の例は、以下の通りである。クライアントは、修復クエリをサーバに提示する。そのサーバは、ポイント・ツー・ポイントリンクで、要求されたシンボルの一部で修復要求に応答する。次に、修復クライアントは、依然として欠落したシンボルについての第２の要求を修復サーバに送信する（これは前のものと同じでもよい）。今回は、その修復サーバは、ブロードキャストセッションにリダイレクトし、残りのシンボルが回復され得る。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
同じシンボルが複数のクライアント端末により要求される場合、ブロードキャストチャネルでの配信は、少ないリソースを使用するという利点を有する。特定の状況では、これは最善の対策ではない可能性がある。例えば、端末が（ブロードキャストチャネルへのアクセスを失った後に）ポイント・ツー・ポイントネットワークのみにアクセスする場合、そのブロードキャストチャネルで配信されるコンテンツをもはや受信しない。前述の組み合わせの修復の例では、修復クエリで要求したシンボルの全てを受信できない。この理由は、修復シンボルの一部のみがポイント・ツー・ポイントネットワークで配信されており、他のものはブロードキャストネットワークで送信されるからである。例えば端末が２つの異なるポイント・ツー・ポイントリンクを介して接続される場合、特定の方法でのみ（ポイント・ツー・ポイントのみ、組み合わせモード等）又は特定のネットワークでのみコンテンツを受信できる装置のための修復方法を提供することが望まれる。
【０００９】
本発明は、受信機が所望の配信モードをサーバに指示する方法を提供することにより、従来技術での修復コンテンツの配信に関する問題のうち少なくともいくつかに対処することを試みる。
【課題を解決するための手段】
【００１０】
本発明は、欠落したシンボルを要求する受信機での方法に関し、この方法は、第１のサーバから、少なくとも１つの修復サーバ及び少なくとも１つの修復サーバのそれぞれにより使用される少なくとも１つの送信モードのリストを受信するステップと、第２のサーバから、複数のシンボルを有するファイルを受信するステップと、シンボルの正確な受信を検査するステップと、欠落したシンボルが識別された場合、修復サーバ及び送信モードを選択し、送信モードを使用して欠落したシンボルを送信するように修復サーバに要求するステップとを有する。
【００１１】
有利には、受信機は、これらの修復サーバのそれぞれが使用できる送信モードと共に、修復サーバのリストを取得する。従って、受信機は、修復サーバからのデータ受信を最適化するために、修復サーバに使用してほしい送信モードを指示する。
【００１２】
本発明の実施例によれば、送信モードは、ポイント・ツー・ポイントモード及び／又はブロードキャストモードである。
【００１３】
ブロードキャスト受信品質が低い領域に存在する場合、受信機は、ポイント・ツー・ポイント送信モードを要求してもよい。ブロードキャスト受信品質がそれほど低くない場合、受信機は、ブロードキャストモードを要求してもよく、ブロードキャスト及びポイント・ツー・ポイントを使用したハイブリッドモードを要求してもよい。
【００１４】
本発明の実施例によれば、要求された送信モードは、送信コスト及び／又はブロードキャスト受信品質に依存する。
【００１５】
送信コストは、受信機により事前に知られている。ポイント・ツー・ポイントモードの使用が高コストである場合、受信機は賢明にもそのモードを使用してもよい。
【００１６】
本発明の実施例によれば、要求するステップの前に、この方法は、ブロードキャスト受信品質についての受信品質を測定するステップを有する。
【００１７】
本発明の実施例によれば、リストは、関連手順記載（associatedProcedureDescription）のXMLファイルに含まれる。
【００１８】
本発明の実施例によれば、ファイルは、FLUTEプロトコルに従って受信される。
【００１９】
本発明の他の対象は、ブロードキャストネットワークからデータを受信し、双方向ネットワークで通信する通信手段と、ブロードキャストネットワークから複数のシンボルを有するファイルを受信すると、ブロードキャストネットワークでのシンボルの正確な受信を検査するファイル受信計算手段と、少なくとも１つの修復サーバ及び少なくとも１つの修復サーバにより使用される少なくとも１つの送信モードのリストから、修復サーバ及び送信モードを選択する選択手段と、送信モードを使用して欠落したシンボルを送信するように修復サーバに要求するため、双方向ネットワークで要求を修復サーバに送信するファイル受信報告手段とを有する受信機である。
【００２０】
本発明の実施例によれば、通信手段は、少なくとも１つの修復サーバ及び少なくとも１つの修復サーバにより使用される少なくとも１つの送信モードのリストを受信するように適合される。
【００２１】
本発明の他の対象は、プログラムがコンピュータで実行されたときに、本発明による方法のステップを実行するプログラムコード命令を有するコンピュータプログラムプロダクトである。“コンピュータプログラムプロダクト”とは、ディスク又はカセットのようなプログラムを含む記憶空間に存在するだけでなく、電気又は光信号のような信号にも存在してもよいコンピュータプログラムサポートを意味する。
【００２２】
本発明の他の対象は、関連手順記載（associatedProcedureDescription）の形式のXML構成ファイルであり、少なくとも１つの修復サーバ及び少なくとも１つの修復サーバのそれぞれにより使用される少なくとも１つの送信モードのリストを有する。
【図面の簡単な説明】
【００２３】
【図１】実施例によるシステム
【図２】実施例による移動端末
【発明を実施するための形態】
【００２４】
開示された実施例と範囲で相応する特定の態様が以下に示される。これらの態様は、単に、本発明が実現され得る特定の態様の簡単な要約を読者に提供するために提示されており、これらの態様は、本発明の範囲を限定することを意図しないことがわかる。実際に、本発明は、以下に示さない様々な態様を含み得る。
【００２５】
本発明は、限定的ではなく、添付図面を参照して以下の説明及び実行例を用いて説明され、理解される。
【００２６】
図１及び２において、示されているブロックは単に機能的エンティティであり、必ずしも物理的に別々のエンティティに対応するとは限らない。すなわち、これらは、ハードウェア又はソフトウェアの形式で開発されてもよく、１つ又は複数の集積回路に実装されてもよい。
【００２７】
例示的な実施例は、DVB-HでのIPデータキャストにおけるファイル修復の枠組みに入るが、本発明はこの特定の実施例に限定されず、受信機が様々な送信モードでコンテンツを送信するようにサーバに要求し得る他のフレームワークにも適用され得る。
【００２８】
第１の実施例によれば、様々な修復サービスが共存する。ファイル修復サービスは、専らポイント・ツー・ポイントチャネルを使用する。これは、文字列“/p2p_only”で終了するURIで識別される。他の修復サービスは、ブロードキャストチャネルを使用する。これは、終わりの文字列“/bcst_only”で識別される。他の修復サービスは、ブロードキャストチャネル又はポイント・ツー・ポイントチャネルを使用する。これは、文字列“/hybrid”で識別されるハイブリッドサービスである。更なるネットワークが修復に利用可能である場合、当然に、更なる文字列（例えば、/wimax_bcast、/wifi_p2p等）で区別されてもよい。
【００２９】
XML構造は、OMA-BCAST標準のOMA-BCAST,  OMA-TS-BCAST_Distribution-V1_0-20080807-Cに規定されており、特に、利用可能な修復サービスのURLを端末に通信するためのOMA-SUP-XSD_bcast_fd_associatedprocedure-V1_0に規定されている。XML構造はまた、DVB-CBMSにも規定されている。ファイル修復手順は、（関連するファイル配信セッションにリンク付けられた）関連ファイル配信手順（associated  file  delivery  procedure）として記載されており、関連情報は、ファイル配信セッションが開始する前に、その特定のXML構造を通じてファイル受信機に提供される。
【００３０】
例示的な構成ファイルは以下の形式を有する。
【００３１】
【表１】
0005529145.tif 000002
クライアントがブロードキャストモード又はポイント・ツー・ポイントモードのいずれかで受信する通常のカバレッジの状況では、  クライアントは、与えられた４つのURLのうち１つへの要求をランダムにアドレス指定して、修復シンボルを要求する。
【００３２】
このような要求の例は以下の通りである。端末は、HTTPプロトコルを使用して修復要求を提示する。
【００３３】
【表２】
0005529145.tif 000003
この時点で、端末は、送信モード又は送信チャネルの一部のみで修復シンボルを受信することができる特別の状況にあってもよい。端末は、これを様々な手段（低い信号受信レベル、１つのチャネルでの高い誤り率又は低いデータレート、又は法外に高いコスト）により検出してもよい。また、カバレッジの境界にあることを検出したため、このような状況を予想することも可能である。状況がポイント・ツー・ポイントリンクのみで修復シンボルの受信を可能にすることを端末が判断すると、‘ポイント・ツー・ポイントのみの修復’を示す１つの修復サービスをリストから選択する。
【００３４】
この場合、修復要求は以下の通りである。
【００３５】
【表３】
0005529145.tif 000004
第２の実施例によれば、XML方式自体が変更される。XML方式は、修復サーバにより提示される修復モードを追加する。これは、このようなXML構成ツリーを使用して記述された各修復サーバのXML属性である。属性値は、ポイント・ツー・ポイントのみ、ハイブリッド型のポイント・ツー・ポイント及びブロードキャストの修復、又はブロードキャストのみの修復である。更なる送信チャネル（例えば、Wi-Fi、Wimax）の可用性を指定するために、更なる属性が使用されてもよい。これは、有利にはXML構成モデルへの変更を最小化する。
【００３６】
初期設定の修復サーバの動作（P2P修復のみ、ハイブリッド修復又はブロードキャストのみ）は、受信機により認識されている。予想される初期設定の修復サーバの動作は、ハイブリッド修復モードであることが好ましい。
【００３７】
任意選択の情報が提供されない場合、受信機は、修復サーバが３つのモード（P2Pのみ、ハイブリッド、ブロードキャストのみ）のいずれも使用することができることを仮定する。
【００３８】
DVB-CBMSの場合に、このように変更されたXML方式を実装するXMLファイルの例は以下の通りである。
【００３９】
【表４】
0005529145.tif 000005
第２の実施例への変形は、ファイル受信機が、明示的な修復モード機能の記述をそれぞれ備えた修復サーバの１つより多くのリストの記述を取得可能にするXML方式である。１つのリストは、ポイント・ツー・ポイントのみの修復を行う修復サーバに関し、他のリストは、ハイブリッド修復（ポイント・ツー・ポイントとブロードキャストとの組み合わせ）を提供できる修復サーバ、又はブロードキャスト修復のみを行うサーバのリストに関する。
【００４０】
DVB-CBMSの場合に、このようなXML方式の例は以下の通りである。
【００４１】
【表５】
0005529145.tif 000006
第３の実施例によれば、修復モードは、HTTP拡張ヘッダに示される。HTTP拡張ヘッダは、HTTP1.1を指定するIETF  RFC  2616に規定されている。受信機は、特有のヘッダを修復要求に追加し、修復モード形式（P2Pのみ、ハイブリッド又はブロードキャストのみ）を伝達する。
【００４２】
このような拡張された修復要求が従来のHTTP1.1準拠の修復サーバに送信された場合、単に拡張ヘッダとして考えられ、サーバにより無視される。
【００４３】
OMA  BCASTの場合に、３つの選択肢（P2P_ONLY、HYBRID又はBCAST_ONLY）を提供する新たなヘッダフィールドRepairModeを使用したこのような拡張された修復クエリの例は以下の通りである。
【００４４】
【表６】
0005529145.tif 000007
第３の実施例への第１の変形例は、許可された修復モード及びチャネル（3G-P2P、Wifi-P2P及びDVB-H-BCAST）のコンマ区切りのリストとしてフィールド値を規定することである。
【００４５】
前述の例は以下の通りになる。
【００４６】
【表７】
0005529145.tif 000008
第３の実施例への第２の変形例は、修復要求の所定の修復モードを追加することである。ここでは、従来のHTTP修復クエリは、そのクエリの好ましい修復モード（P2Pのみ、ハイブリッド修復又はブロードキャストのみ）を示す潜在的な３つの値に関連するパラメータ（例えば、RepairMode）の追加により拡張される。
【００４７】
ここに、OMA  BCASTの場合に、３つの選択肢（P2P_ONLY、HYBRID又はBCAST_ONLY）を提供するその新たなパラメータRepairModeを使用したこのような拡張された修復クエリの例を示す。
【００４８】
【表８】
0005529145.tif 000009
第３の実施例への第３の変形例は、応答における特別のヘッダと共に、要求においてヘッダフィールドを使用することである。（この場合には後方互換性の理由のみで）クライアントがハイブリッド又はブロードキャストの修復を受け付ける用意があることを伝達すると、サーバは、ブロードキャスト修復のセッション情報を応答ヘッダで示してもよい。これは、ハイブリッド修復モードでのサーバとクライアントとの間での交換の数を低減する。潜在的に動的なブロードキャストセッション情報を回復するために、クライアントによる第２の要求は必要ない。
【００４９】
この変形例によれば、第３の実施例による要求への応答又は第３の実施例の第１の変形例による要求への応答は以下の通りである。
【００５０】
【表９】
0005529145.tif 000010
これは、（ポイント・ツー・ポイントリンクの）応答の本文で提供されない全ての要求されたシンボルが、指示されたブロードキャストセッションを通じて提供されることが想定されることを示す。
【００５１】
実施例によるビデオ配信システムは、図１に示されている。ビデオブロードキャストネットワーク1.6は、ETSI  TR  102  469  V1.1.1  (2006-05),  “Digital  Video  Broadcasting  (DVB);  IP  Datacast  over  DVB-H:  Architecture”（以下ではIPデータキャスト標準と呼ばれる）に準拠する。
【００５２】
システムはまた、ETSI  TS  102  472  V1.2.1  (2006-12),  “Digital  Video  Broadcasting  (DVB);  IP  Datacast  over  DVB-H:  Content  Delivery  Protocols”（以下ではCDP標準と呼ばれる）にも準拠する。
【００５３】
ファイルサーバ1.1は、CDP標準及びFLUTEプロトコルに従ってデータファイルを送信する。データファイルは、IPネットワーク1.3及びDVB-Hネットワーク1.6で移動端末1.7に配信される。IPネットワークは、マルチキャスト送信をサポートする如何なるIPネットワーク（インターネット等）でもよい。DVB-H送信ネットワークは、とりわけ、DVB-H  IPカプセル化器1.4と、DVB-H送信機1.5とを有する。当然に、実施例はDVB-Hネットワークに限定されない。デジタル加入者線の系列のような他のブロードバンド配信ネットワークにも適用可能である。
【００５４】
このシステムはまた、セルラネットワーク1.8又はホットスポットネットワーク1.9を通じた帰路チャネルを有する。移動端末は、帰路チャネルを通じてデータ（特にインタラクティブデータ）を送受信してもよい。当然に、帰路チャネルは、ポイント・ツー・ポイント双方向接続を提供する他の種類のチャネルでもよい。このシステムは、CDP標準に規定されたDVB-Hに関連する簡略化されたファイル修復インフラストラクチャである。端末は、欠落又は破損したものとして検出されたFLUTEシンボルであるパケットを回復するために、修復要求を修復サーバ1.2に提示する。修復サーバは、ダウンロードされたファイルのコピーを格納する。修復サーバは、利用可能な場合には、要求されたパケットを端末に返信する。
【００５５】
移動端末は、とりわけ、以下ではファイルサーバに規定されるパケット欠落情報を、帰路チャネルを通じて送信する。
【００５６】
移動端末1.7は、図２に示されている。実施例によれば、IPデータキャスト標準に従った端末である。移動端末は、ブロードキャストネットワーク（特にDVB-Hネットワーク）からデータを受信し、帰路チャネル（特にセルラネットワーク）でデータを送受信する通信モジュール24を有する。移動端末は、ブロードキャストチャネルから受信したデータ（とりわけ、FDT及びESG情報）を格納する格納モジュール22を有する。端末は、処理モジュール21と、モジュール間の通信を可能にする内部バス26とを有する。端末は、前述のようにファイル受信を検査するファイル受信計算モジュール25を有する。端末はまた、受信されたファイル又は受信されていないファイルをファイルサーバに報告するファイル受信報告モジュール23を有する。特に、ファイル受信報告モジュールは、前述のように要求を修復サーバに送信する。端末はまた、前述のように、サーバに要求される送信モードを選択する選択モジュール26を有する。送信モードは、修復サーバに送信される修復要求に示される。
【００５７】
発明の詳細な説明、特許請求の範囲及び図面に記載のものは、独立して提供されてもよく、如何なる適切な組み合わせで提供されてもよい。適切な場合には、特徴は、ハードウェア、ソフトウェア又は２つの組み合わせで実装されてもよい。
【００５８】
ここでの“一実施例”又は“実施例”への言及は、実施例に関して記載した特定の機能、構成又は特徴が本発明の少なくとも１つの実装に含まれ得ることを意味する。明細書の様々な場所に“一実施例では”という用語が現れることは、必ずしも全てが同じ実施例を示しているとは限らず、必ずしも他の実施例と相互排他的な別の実施例又は代替実施例であるとも限らない。
【００５９】
特許請求の範囲に現れる参照符号は、例示のみのためであり、特許請求の範囲を限定する効果を有するべきでない。
【図１】
0005529145.tif 000011
【図２】
0005529145.tif 000012