JP5536033B2 - 送信する方法、モバイル端末及びファイルサーバ - Google Patents

Description

本発明は、概して、モバイル受信器への映像放送に係り、より具体的に、送信信頼性を改善するための方法及びシステムに係る。

本項目は、以下で記載及び／又は請求される本発明の様々な態様に係る当該技術の様々な態様を読む者に与えることを目的とする。本議論が本発明の様々な態様のより良い理解を促す背景情報を読む者に与える助けとなると信じる。然るに、当然のことながら、これらの記述は先行技術の承認としてではなく、この観点から読まれるべきである。

サーバと複数の受信器との間のコンテンツの配信は、サーバと各受信器との間のポイント・ツー・ポイント接続、又はマルチポイント接続のいずれかをセットアップする必要がある。ポイント・ツー・ポイント接続は、各受信器へユニキャストによりコンテンツを分配することを可能にし、ロバスト配信を提供する。しかし、相当数の受信器がある場合、それは接続の限度を超えた管理を要する。それはまた、ネットワーク上のトラフィックを劇的に増大させる。マルチキャスト配信は、ネットワーク負荷がより少ないが、確認応答メカニズムがないことに起因して配信がそれほどロバストでない。マルチキャスト配信が使用される場合、例えば、再送信要求によって、受信におけるエラーを修復するための解決法が見つけられるべきである。コンテンツのマルチキャスト配信の一例として、ＩＥＴＦ ＲＦＣ ３９２６はＦＬＵＴＥ（the File Delivery over Unidirectional Transport）プロトコルを定義する。この標準規格で定義されるプロトコルは、クライアントの数に対する拡張可能性の問題と、クライアントによって支持される帯域幅に対する不均一性の問題とに応じるようにうまく適合される。

ＤＶＢ−Ｈ ＩＰデータキャスティング標準規格、＜＜ＥＴＳＩ ＴＳ １０２ ４７２ Ｖ１．１．１（２００６−０６）、Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）；ＩＰ Ｄａｔａｃａｓｔ ｏｖｅｒ ＤＶＢ−Ｈ；Ｃｏｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｐｒｏｔｏｃｏｌｓ（ＣＤＰ）＞＞（以下「ＣＤＰ標準」と称する。）は、ファイル修復メカニズムを定義する。ＣＤＰ標準で適合されるファイル修復手法は、１段階（one level）ファイル修復手法であり、中央集権的なクライアントサーバに“ファイル修復（File Repair）”モードを導入する。それは、ブロードキャスト／マルチキャスト・ネットワーク上で信頼できるファイル配信を達成するようＦＬＵＴＥプロトコルを支援するためにファイル修復メカニズムを用いる。不完全なファイルの受信が検出されると、ＦＬＵＴＥ受信器はファイル修復メカニズムを立ち上げる。それは、紛失又は破損したパケットを要求することにある。ＦＬＵＴＥ用語に従って、それらのパケットはシンボルと称される。ポイント・ツー・ポイント接続により修復ファイルサーバに要求が送られる。要求は、基本的に、修復されるべきファイルの名称と、不足シンボルのリストとを集める。

ＦＬＵＴＥプロトコルは、ファイル配信セッション内に送信されるべきファイルのファイル記述情報を含むＦＤＴ（File Delivery Table）を定義する。ＦＬＵＴＥプロトコルは、マルチキャストモードにあるコンテンツサーバから全てのクライアントへＦＤＴを送信する。これが送信エラーを前提とする場合に、ＦＤＴファイル送信の信頼性は、それ自体よく知られている前進型誤信号訂正（forward error correction）のようなメカニズムにより又はセッション中のＦＤＴの再送信により、高められ得る。故に、マルチキャストコンテンツ配信の終わりに、各クライアントは、セッションにおいて送信されるべきファイル及び受信されたファイルを正確に知る。次いで、各クライアントは、紛失したファイルをインデックスサーバに示唆することができる。

ＣＤＰ標準で定められるメカニズムは、受信器が少なくともファイルのパケットを受信することを必要とする。パケットが受信される場合、受信器は、即座に且つ正確には、ファイルが受信されなかったことを検出することができない。
米国特許出願公開第２００５／１８２８４２号明細書（Ｗａｌｓｈ Ｒｏｄ等）（２００５年８月１８日）は、正確に受信されなかったデータブロックの識別に基づく、ファイル配信システムにおける再送信方法を扱う。

本発明は、信頼性を改善するメカニズムを提供することによって、先行技術における複数の受信器への送信に関連する懸念事項の少なくとも一部を解消しようとするものである。

本発明は、ファイルサーバにおいて１よりも多いファイルを１よりも多い受信器へ送信する方法であって、前記ファイルをコンテナに統合するステップと、前記コンテナを１よりも多いパケットに分け、該１よりも多いパケットを前記１よりも多い受信器に送信するステップであって、前記コンテナの少なくとも１つのパケットの受信は、受信器が前記コンテナの欠損パケットの再送信を要求することを可能にするステップとを有する方法に係る。このために、当該方法は、前記１よりも多い受信器ごとに前記コンテナの連続する欠損パケットの数の表示を受け取るステップと、前記受信器での前記連続する欠損パケットの数の関数において前記コンテナのサイズを適合させるステップとを有する。

このようにして、本発明は、サーバが受信器の受信能力に対して統合サイズを適合させることを可能にする。受信器での受信環境は可変である。それはサーバに報告され、サーバは、送信を改善するよう反応する。本発明のシステムは、送信パラメータをネットワーク環境に適合させることを可能にする。パケット損失バースト性は、パケット損失の期間のほとんどが比較的短いことを特徴とする。ファイル統合技術は、小さなファイルが度々の短い損失期間では完全には失われないことを確かにする。その場合に修復は可能でない。

実施形態に従って、前記コンテナのサイズは、デフォルト値を上回る又は下回る連続する欠損パケットの数を報告する受信器の数に基づく。

実施形態に従って、前記受信器の数がデフォルト値を上回る場合、前記コンテナのサイズは増大し、前記受信器の数が前記デフォルト値を下回る場合、前記コンテナのサイズは低減する。

実施形態に従って、前記コンテナのサイズは、前記１よりも多い受信器の受信バッファサイズに依存する。

実施形態に従って、前記パケットは、ＦＬＵＴＥ（the File Delivery over Unidirectional Transport）プロトコルにより送信される。

実施形態に従って、前記表示を受け取るステップは、前記受信器から受け取られる修復リクエストに係る情報を修復サーバで得るステップを有する。

実施形態に従って、前記表示を受け取るステップは、前記連続する欠損パケットの数に係る報告を前記受信器から受け取るステップを有する。

実施形態に従って、前記コンテナのサイズは、最初にデフォルト値に設定され、前記コンテナのサイズの値は、前記デフォルト値以上でしかあり得ない。

また、本発明は、サーバと通信し、該サーバからファイルを受信する通信手段と、前記ファイルの受信を確認するファイル受信演算手段と、前記ファイルの受信有無を前記サーバに報告するファイル受信報告手段とを有するＤＶＢ−Ｈモバイル端末に係る。

また、本発明は、あるサイズを有するコンテナに統合される１よりも多いファイルを１よりも多い受信器へ送信する通信手段と、少なくとも１つの受信器での連続する欠損パケットの数に前記コンテナのサイズを適合させる統合損失値演算手段と、前記コンテナを構築し、該コンテナを１よりも多いパケットに分け、該パケットを前記少なくとも１つの受信器へ送信するファイル統合手段とを有するファイルサーバに係る。

開示される実施形態と適用範囲内で相応の特定の態様が以下に挙げられている。当然のことながら、これらの態様は、単に、本発明がとりうる特定の形態の概要を読む者に与えるために提示されているにすぎず、これらの態様は、本発明の適用範囲を限定することを目的としない。実際には、本発明は、以下で挙げられていない様々な態様を包含しうる。

実施形態に従う映像配信のためのシステムを表す。 実施形態に従うモバイル端末を表す。 実施形態に従うファイルサーバを表す。 パケット損失バースト性の測定報告を表す。 実施形態に従うファイル統合を表す。

本発明は、添付の図面を参照して、全く限定することなく、下記の実施形態及び実施例により表され、より良く理解されるであろう。

図１乃至３で、表されているブロックは単なる機能エンティティであり、必ずしも物理的に分離したエンティティに対応するわけではない。すなわち、それらは、ハードウェア若しくはソフトウェアの形で開発されてよく、又は１若しくは複数の集積回路に実装されてよい。

例となる実施形態は、ＤＶＢ−Ｈ伝送のフレームワーク内にあるが、本発明は、この特定の実施形態に限定されず、サーバが送信信頼性を改善すべく複数の受信器へ統合された様式でデータを送信するところの他のフレームワーク内で適用されてよい。

実施形態に従う映像配信システムは、図１に表されている。ビデオブロードキャストネットワーク１．６は、ＥＴＳＩ ＴＳ １０２ ４７２ Ｖ１．１．１（２００６−０５）、“Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）；ＩＰ Ｄａｔａｃａｓｔ ｏｖｅｒ ＤＶＢ−Ｈ：Ａｒｃｈｉｔｅｃｔｕｒｅ”（以下「ＩＰデータキャスト標準」と称される。）に従う。

システムはまた、ＥＴＳＩ ＴＳ １０２ ４７２ Ｖ１．２．１（２００６−１２）、“Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）；ＩＰ Ｄａｔａｃａｓｔ ｏｖｅｒ ＤＶＢ−Ｈ：Ｃｏｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｐｒｏｔｏｃｏｌｓ”（以下「ＣＤＰ標準」と称される。）に従う。

ファイルサーバ１．１は、ＣＤＰ標準及びＦＬＵＴＥプロトコルに従ってデータファイルを送信する。データファイルは、ＩＰネットワーク１．３及びＤＶＢ−Ｈブロードキャストネットワーク１．６を介してモバイル端末１．７に送られる。ＩＰネットワークは、例えばインターネット等の、如何なるＩＰネットワーク支援マルチキャスト伝送であってもよい。ＤＶＢ−Ｈ送信ネットワークは、とりわけ、ＤＶＢ−Ｈ ＩＰエンカプスレータ（Encapsulator）１．４及びＤＶＢ−Ｈ送信器１．５を有する。当然、実施形態はＤＶＢ−Ｈネットワークに限定されない。それは、例えばデジタル加入者線（subscriber line）ファミリ等の、その他のブロードキャスト配信ネットワークに適用可能である。

システムは、更に、セルラーネットワーク１．８を通るリターンチャネルを有する。モバイル端末は、リターンチャネルを介してデータ（特に、インタラクティブデータ）を送受信することができる。当然、リターンチャネルは、ポイント・ツー・ポイント双方向接続を提供するその他タイプのチャネルであってよい。システムは、ＣＤＰ標準で定義されるようにＤＶＢ−Ｈに関連する簡単化されたファイル修復インフラストラクチャである。端末は、紛失又は破損していることを検出されたパケット（これらはＦＬＵＴＥシンボルである。）を回復するために、修復サーバ１．２へ修復要求を提示する。修復サーバは、ダウンロードされたファイルのコピーを記憶する。修復サーバは、入手可能である場合に、要求されたパケットを端末に送り返す。

モバイル端末は、とりわけ、以下で定義されるパケット損失情報をリターンチャネルを介してファイルサーバへ送信する。

モバイル端末１．７は、図２に表されている。実施形態に従って、それは、ＩＰデータキャスト標準に従う端末である。モバイル端末１．７は、ブロードキャストネットワーク（特に、ＤＶＢ−Ｈネットワーク）からデータを受信し、且つ、リターンチャネル（特に、セルラーネットワーク）上でデータを送受信する通信モジュール２４を有する。モバイル端末１．７は、ブロードキャストチャネルから受信したデータ（とりわけ、ＦＤＴ及びＥＳＧ情報）を記憶する記憶モジュール２２を有する。モバイル端末１．７は、処理モジュール２１と、モジュール間の通信を可能にする内部バス２６とを有する。モバイル端末１．７は、実施形態に従ってファイル受信を確認するファイル受信演算モジュール２５を有する。モバイル端末１．７は、更に、受信された又は受信されなかったファイルをファイルサーバに報告するファイル受信報告モジュール２３を有する。

ファイルサーバ１．１は、図３に表されている。それはＣＤＰ標準に従う。ファイルサーバ１．１は、リターンチャネルを介してモバイル端末と通信し、且つ、配信チャネルを介してコンテンツを送信する通信モジュール３４を有する。ファイルサーバ１．１は、モバイル端末から受信した統合値及びパケット損失値を記憶する記憶モジュール３２を有する。ファイルサーバ１．１は、処理モジュール３１と、モジュール間の通信を可能にする内部バス３６とを有する。ファイルサーバ１．１は、モバイル端末の夫々から受信したコンテナ（container）の連続する欠損パケットに基づいて統合値（aggregation value）を計算する統合損失値演算モジュール３３を有する。統合値ついては、以下で更に記載する。サーバは、統合されたファイルを構築し、そのファイルをモバイル端末へ送信するファイル統合モジュール３５を有する。

パケット長Ｘに係る連続するパケット損失の個々の数はＩＮＣＰＬ−Ｘと称される。ＩＮＣＰＬ−Ｘはサーバで計算される。ＭＳＡＦ−Ｘは、統合されたファイルの最小サイズを表し、以下で更に記載される。ＭＳＡＦ−Ｘの値は、ＩＮＣＰＬ−Ｘの値に基づいて調整される。

特定の出現閾値（Ｔ）及び典型的なパケット長Ｘに対応する連続したパケット損失の数は、ＮＣＰＬ−Ｔ−Ｘである。それは一定値である。例えば、１４００バイトのブロードキャスト送信されるパケットに関して、ＮＣＰＬ−８０−１４００は、関連するブロードキャストシステム及び受信器についてのＮＣＰＬ値を示し、そのため、受信器から観測される連続したパケット損失期間の８０％は“ＮＣＰＬ−８０−１４００”以下の連続したパケット損失を有する。図４に従って、損失期間の約８０％は１６２以下のパケットを有する。すなわち、ＮＣＰＬ−８０−１４００の値は１６２の値を有する。言い換えると、ＮＣＰＬ−８０−１４００が１６２に設定される場合、受信器の８０％は１つのパケットを少なくとも受信する。ここで、１４００は最小長さであり、これは、ＮＣＰＬ−８０−１４００の値が１４００以上の長さを有するパケットに適用されることを意味する。

より一般的に、ＮＣＰＬ−Ｔ−Ｘの設定の計算は、フィールド測定によって確認されるモデル、又はそのブロードキャストシステムを用いてモバイル端末によって行われる定期的な測定に基づく動的評価、のいずれかに基づく。

受信報告情報は、受信器によってサーバに提供される。それは、受信器の夫々１つによって提供される。それは、受信器の一部のみによって提供されてもよい。受信器は、所謂トランスペアレントモード又は非トランスペアレントモードで当該情報を送信するために双方向リンクを用いる。

非トランスペアレントモードで、モバイル端末は、双方向チャネルを用いて受信報告情報を送信する。受信報告情報は周期的に送信される。それは、最近のファイル受信に関する測定報告に対応する。

１つの非トランスペアレントモードは、ブロードキャスティングで、媒体を介して配信又はダウンロードをされるファイル及びそれらのスケジューリングされた配信時間のリストが、他の同様のタイプのリストの電子サービスガイド（ＥＳＧ）のおかげで、通常は前もって知られている、との事実に基づく。受信器は、自身がファイルを受信したか否かを検出する。次いで、受信器は、ファイルの受信に係る確認応答又は非確認応答情報をファイルサーバへ送信する。端末は、ファイル配信ステータスを報告するために、ＥＴＳＩ ＴＳ１０２４７２のチャプタ７．４．３で定義される受信報告プロシージャを用いる。かかる標準規格は、報告タイプ（reportType）パラメータによるファイル受信報告を定義する。実施形態に従って、その標準規格とは異なる報告タイプパラメータが、ファイルが受信されなかったことを報告するために定義される。報告タイプ値は“ｒｎａｃｋ”に設定される。当然、端末は、ＯＭＡ−ＢＣＡＳＴで定義される受信報告プロシージャを使用してもよい。ファイルサーバがモバイル端末から報告を受信する場合、ファイルサーバは、観測期間中に各端末ごとにＩＮＣＰＬ−Ｘの値を計算する。次いで、ファイルサーバは、ブロードキャスト送信される次の統合ファイルのサイズを駆動するために、全ファイル配信システムについてＭＳＡＦ−Ｘを計算する。

サーバでこのような報告を得る他の非トランスペアレントモードは、実時間（Real-Time）トランスポートプロトコル（ＲＴＰ）を用いることができる。それは、専用の送信に係る媒体を監視することに基づく。例えば、端末ｎに関する長さＹｎの連続するＲＴＰパケットの受信成功は、その端末ｎについてＩＮＣＰＬ−Ｘを計算することを可能にする。関連するＲＴＣＰ受信器は、パケット損失に係る収集情報を報告し、次いで、ファイルサーバが、システム内の報告する受信器ごとにＩＮＣＰＬ−Ｘのオーバビューを得ることを可能にする。

トランスペアレントモードで、モバイル端末は、ファイル修復要求を修復サーバに提示する。修復サーバは、モバイル端末の夫々１つについて、その端末から受信した修復要求に基づいて、ＩＮＣＰＬ−Ｘ値を計算する。修復サーバは、ＦＬＵＴＥパケット送信の元の順序を知っていると期待される場合は、修復要求からＩＮＣＰＬ−Ｘを計算する。修復サーバは、サーバに利用可能な値の組を作る。ファイルサーバは、周期的に、その値の組を取り出してよい。次いで、ファイルサーバは、ＭＳＡＦ−Ｘの新しい値を決定することができる。

代替案で、修復サーバは、更に、比（ratio）Ｒｒｅｆを計算する。次いで、修復サーバは、それ自体よく知られている何らかのＩＰ通知メカニズムにより、Ｒｒｅｆをファイルサーバに示す。

実施形態に従って、開始時に、ＮＣＰＬ−Ｔ−Ｘの値はサーバに与えられる。その値は、グラフィックユーザインターフェースを介してオペレータにより手動で設定される。当然、それは、設定ファイルにより、又は何らかの局所的な若しくは遠隔の設定手段を介して、サーバに示されてよい。

そのＮＣＰＬ−Ｔ−Ｘの値は、受信器へブロードキャスト送信される統合されたファイルを構築するための初期最小サイズを計算するために使用される。

サーバでは調節可能な期間が定義される。期間は、ブロードキャスト及び２又は３のファイルの修復期間に対応する値を有する。また、調整可能な値は、サーバにおいてオペレータによって設定されてもよい。調整可能な期間の後、統合されたファイルの最小サイズは、端末によって報告される情報により動的に調整される。

サーバで計算されるＭＳＡＦ−Ｘの値は、常に、各受信器バッファの容量を考慮する。受信器バッファサイズは、オペレータによって設定されて全ての受信器及びサーバに送られる設定パラメータである。当然、それは、受信器からの最大バッファサイズ能力の受信に応じて、サーバで動的に設定されてよい。

サーバは、オペレータによって、デフォルトのＮＣＰＬ−Ｔ−Ｘ値の組を示される。この値の組は、サーバが統合パケットを送信し始めることを可能にする。この値の組は、キャンペーン測定（campaign measurement）に由来する。測定の一例は、実際のＤＶＢ−Ｈサービスエリアで行われてよく、パケット損失の基本特性がこのようなネットワークについて決定されることを可能にする。測定は、ヘッドエンド送信装置にＩＰ／ＲＴＰパケット生成器を結合することによって、且つ、携帯型受信器によりサービスエリア内の固定点及び移動点で受信パケットを記録することによって、行われる。送信される夫々のパケットが個々に番号付けされる場合に、受信器ログの解析は、パケット損失率及びバースト特性が決定されることを可能にする。図４は、パケット長が１４００バイトである場合に係るパケット損失バースト性の測定の例示である。それは、連続したパケット損失が比較的少ない場合にパケット損失期間が高い確率で発生することを示す。損失期間の約８０％は１６２以下のパケットを有する。このようにして、８０％の出現閾値は１６２のＮＣＰＬ−８０−１４００の値を与える。それは、ＮＣＰＬ−Ｔ−Ｘの値の推定をもたらす。

各受信器について計算されるＩＮＣＰＬ−Ｔ−Ｘは、次いでＭＳＡＦ−Ｘの値を決定することを可能にする。その値は増大又は減少する。ＭＳＡＦ−Ｘは、統合されたファイルの最小サイズを表す。それは、統合される長さＸのパケットの数に対応する。

開始時に、ＭＳＡＦ−Ｘの値はＮＣＰＬ−Ｔ−Ｘの値を用いて生成される。ＭＳＡＦ−Ｘの値はＮＣＰＬ−Ｔ−Ｘの値よりも大きい。それは、ＭＳＡＦ−Ｘ＝ＮＣＰＬ−Ｔ−Ｘ＋Ｎに設定される。Ｎは５に設定される。Ｎの値が大きいと、クライアントが統合されたファイルの中の少なくとも１つのパケットを受信する機会は増える。しかし、それは、クライアントでのバッファサイズが大きいことを要する。次いで、Ｎは１より大きいが、オペレータが設定した閾値よりも小さい値に設定されるべきであり、受信器バッファサイズ要求に依存する。

選択されると、値は調整可能な期間の間保持されて使用される。上述されるように、調整可能な期間は、サイズＭＳＡＦ−Ｘの２又は３の統合ファイルのブロードキャストの持続期間及び関連する修復期間に設定される。それは、トランスペアレント又は非トランスペアレントな方法を通じて受信器から受信報告を取得する時間を配信システムに与える。

次いで、サーバは、受信器のリファレンス比（Ｒ）を計算する。そのために、報告されるＩＮＣＰＬ−ＸはＮＣＰＬ−Ｔ−Ｘよりも大きい。比Ｒｒｅｆは次のステップでのリファレンスに使用される。

値Ｒｒｅｆが取得されると、システムは以下のように周期的にＭＳＡＦ−Ｘを適合させる。各期間に、Ｒは受信器からの最後の受信報告により計算される。

・第１の場合に、ＲはＲｒｅｆよりも低い。それは、過去の期間に、選択されたＮＣＰＬ−Ｔ−Ｘよりも高いＩＮＣＰＬ−Ｘを報告した受信器がより少なかったことを意味する。次いで、ＭＳＡＦ−Ｘの値は低減する。当然、それはＮＣＰＬ−Ｔ−Ｘ＋Ｎを下回る値をとらない。

・第２の場合に、ＲはＲｒｅｆよりも高い。それは、過去の期間に、選択されたＮＣＰＬ−Ｔ−Ｘよりも高いＩＮＣＰＬ−Ｘを報告した受信器がより多かったことを意味する。次いで、ＭＳＡＦ−Ｘの値は増大する。当然、それは、受信器のメモリ制約に対する最大ファイルサイズ値を上回る値をとらない。

・ＲがＲｒｅｆと同じ値を有する場合、ＭＳＡＦ−Ｘの値は不変なままである。

ＭＳＡＦ−Ｘの計算は、また、他のメカニズムに基づいてよい。それは、更に、１つの受信器のみから又は受信器のサブセットから受信した受信報告に基づいてもよい。次いで、それは、サーバが、全ての受信器からのフィードバックを有することなく統合サイズを駆動することを可能にする。それは、報告する受信器がサーバにとって信頼できると考えられるものである点において、報告メカニズムを最適化する。

実施形態に従うファイルグルーピングメカニズムはＧＺＩＰ、すなわち、ＧＮＵ ＺＩＰフリー圧縮ソフトウェアである。ＧＺＩＰフォーマットにより、ファイルは圧縮される。サーバは、結果として得られる圧縮ファイルのサイズを考慮する。Ｎ個のファイルを１つに統合した後、ＧＺＩＰを用いて、ファイル統合モジュールは、得られたファイルを、自動的に割り当てられる名称を用いて、局所記憶部に記憶する。端末は、送信されたオブジェクトが統合されたファイルオブジェクトであることを検出するためにＧＺＩＰフォーマットを使用し、このようにして、ファイル分割機能をトリガする。名称の接頭辞（prefix）は“GroupedFile_”であってよく、接尾辞（suffix）は、夫々の新しい統合ファイルオブジェクトごとに増分される整数値であってよい。

ファイル統合モジュールは、局所ルールに基づいてファイルをグループ化してよい。ファイルがＦＤＴファイルによってしか知らされない場合、サーバは、ファイルをバッファリングし、ファイルカテゴリに基づいてそれらを統合してよい。例えば、同じウェブページに対応するファイルは、一緒にグループ化されてよい。ファイルがＥＳＧにより知らされる場合、サーバは、ファイルトランスポートがＥＳＧに従う場合にのみ、そのようなバッファリング及び統合を行ってよい。ファイルのブロードキャスト時間は、ＥＳＧで示される時間に従う。

より一般的に、あらゆる私的な又は従来のファイルトランスポートフォーマットが可能である。ファイルフォーマットに付随する要件は以下の通りである：
・ 複数のコンポーネントを搬送する可能性、
・ 各コンポーネントの名称をエンコードする可能性、及び
・ 各コンポーネントに付随する他の情報をエンコードする可能性。

構築される場合に、統合されたファイルは、受信器への送信のために、ＦＬＵＴＥスタックへ送られる。ファイル統合の一例は図５に表されている。ファイルサーバは、長さＬに達するためにファイルをコンテナ４０に統合する。なお、Ｌ＝Ｘ×ＭＳＡＦ−Ｘであり、Ｘはパケット長を表す。サーバは、ファイル１、ファイル２及びファイル３をコンテナに統合する。次いで、コンテナは長さＸの３つのパケット、すなわち、パケット１、パケット２及びパケット３に分割される。このとき、ＭＳＡＦ−Ｘの値は３である。

上記の調整可能なメカニズムは、当然、セルが小さいほど正確である。モバイルブロードキャスト又はマルチキャスト・ネットワークを考えると、夫々が少なくとも１つの送信ポイントのエリアに仕える複数のファイルサーバ及び関連する修復サーバのインフラストラクチャを有することが好ましい。その場合に、ＮＣＰＬ−Ｔ−Ｘ及びＭＳＡＦ−Ｘは、ファイル配信システム全体のより一層の効率を各ファイルサーバが提供することによってカバーされる各エリアごとに推定され提供されてよい。サービスプラットフォームは、全てのファイルサーバにおいてファイルを送信させる。各ファイルサーバは、統合されたファイルについてそれ自体の最小サイズを維持するファイル統合モジュールを集める。

上記のメカニズムは、ＤＶＢ−Ｈの適用範囲にある。当然、それは、サーバが統合された様式で複数のサーバへコンテンツをブロードキャスト送信し、受信器がリターンチャネルによりサーバと通信を行うあらゆるシステムに適用される。このようなシステムの一例は、ＵＤＰパケットの統合であってよい。このとき、ＵＤＰパケットは、受信器が欠損パケットを検出することを可能にするよう、ラベルを付されている。

明細書、特許請求の範囲及び図面で開示される参照は、個別に又は何らかの適切な組み合わせで提供されてよい。特徴は、必要に応じて、ハードウェア、ソフトウェア又はこれらの組み合わせで実施されてよい。

「一実施形態」又は「実施形態」との本願での言及は、その実施形態に関連して記載される特定の特徴、構成又は特性が本発明の少なくとも１つの実施に含まれうることを意味する。明細書中の様々な箇所に現れる「実施形態で」とのフレーズは、全てが必ずしも同じ実施形態を参照しているわけではなく、必ずしも相互に他の実施形態を除く別個の又は代替の実施形態であるわけでない。

特許請求の範囲に記載される参照符号は、単なる一例として記載されており、特許請求の範囲の技術的範囲を限定する効果を有さない。

Claims (5)

1. ファイルサーバにおいて１よりも多いファイルを１よりも多い受信器へ送信する方法であって、
   前記ファイルを、あるサイズを有するコンテナに統合するステップと、
   前記コンテナを１よりも多いパケットに分け、該１よりも多いパケットを前記１よりも多い受信器に送信するステップであって、前記コンテナの少なくとも１つのパケットの受信は、受信器が前記コンテナの欠損パケットの再送信を要求することを可能にするステップと、
   前記１よりも多い受信器ごとに前記コンテナの連続する欠損パケットの数の表示を受け取るステップと、
   前記受信器での前記連続する欠損パケットの数の関数において前記コンテナのサイズを適合させるステップと
   を有する方法。
2. 前記コンテナのサイズは、更に、連続する欠損パケットの数を報告する受信器の数に基づく、請求項１に記載の方法。
3. 連続する欠損パケットの数を報告する受信器の数がデフォルト値を上回る場合、前記コンテナのサイズは増やされ、連続する欠損パケットの数を報告する前記受信器の数が前記デフォルト値を下回る場合、前記コンテナのサイズは減らされる、請求項２に記載の方法。
4. サーバからブロードキャストされる少なくとも第１又は第２のコンテナを形成するパケットを受信する、前記サーバと通信する通信手段であって、前記コンテナの各々は１よりも多いファイルの集合体である、通信手段と、
   前記パケットの受信を確認するファイル受信演算手段と、
   前記第１のコンテナの連続して欠損したパケットの数を前記サーバに報告するファイル受信報告手段であって、前記第２のコンテナのサイズは前記第１のコンテナの連続して欠損したパケットの数に応じた大きさである、ファイル受信報告手段と
   を有するモバイル端末。
5. あるサイズを有するコンテナに統合される１よりも多いファイルを１よりも多い受信器へ送信する通信手段と、
   前記コンテナを構築し、該コンテナを１よりも多いパケットに分け、該パケットを前記１よりも多い受信器へ送信するファイル統合手段と、
   １よりも多い受信器ごとに前記コンテナの連続する欠損パケットの数の表示を受信し、前記１よりも多い受信器での前記連続する欠損パケットの数に前記コンテナのサイズを適合させる統合損失値演算手段と
   を有するファイルサーバ。

Images