JP2013540408A - 不均一誤り保護および一括ファイル配信サービスを提供するための汎用ファイル配信の方法 - Google Patents

Abstract

パケット交換ネットワークを通じて電子デバイスまたはシステムからデータオブジェクトを配信するための方法および装置が提供され、ソースデータを複数のソースシンボルへと編成して、汎用オブジェクトシンボル識別子(「UOSI」)と、UOSIによって特定されるパケット構造のソースデータを表す複数の符号化シンボルとを含む符号化パケットを複数生成して、複数の符号化パケットをパケット交換ネットワークへ送信することによって、ソースデータが少なくともおおよそ符号化シンボルから復元可能になるように、ソースデータはパケット中の符号化シンボルによって表される。

Description

関連出願の相互参照
本非仮出願は、2010年10月22日に出願した、「File Delivery Methods for Providing Unequal Error Protection and Bundled File Delivery Services」という表題の米国仮特許出願第61/406,091号の、米国特許法第119条(e)による優先権の利益を主張するものであり、上記仮出願の内容全体が、あらゆる目的のために参照によって本明細書に組み込まれる。

本開示は、本発明の譲受人に譲渡された以下の特許または出願に関連することがあり、以下の特許または出願の各々は、あらゆる目的のために参照によって全体が組み込まれる。

1)「Information Additive Code Generator and Decoder for Communication Systems」という表題のMichael G. Lubyに与えられた米国特許第6,307,487号(以後「Luby I」)

2)「Information Additive Group Code Generator and Decoder for Communication Systems」という表題のMichael G. Lubyに与えられた米国特許第6,320,520号(以後「Luby II」)

3)「Systems and Processes for Decoding a Chain Reaction Code Through Inactivation」という表題のM. Amin Shokrollahiに与えられた米国特許第6,856,263号(以後「Shokrollahi I」)

4)「Systematic Encoding and Decoding of Chain Reaction Codes」という表題のM. Amin Shokrollahiに与えられた米国特許第6,909,383号(以後「Shokrollahi II」)

5)「Multi-Stage Code Generator and Decoder for Communication Systems」という表題のM. Amin Shokrollahiに与えられた米国特許第7,068,729号(以後「Shokrollahi III」)

6)「File Download and Streaming System」という表題のMichael G. Luby、M. Amin Shokrollahi、およびMark Watsonに与えられた米国特許第7,418,651号(以後「Luby III」)

7)「In-Place Transformations with Applications to Encoding and Decoding Various Classes of Codes」という表題のMichael G. LubyおよびM. Amin Shokrollahiによる米国特許出願公開第2006/0280254号(以後「Luby IV」)

8)「Multiple-Field Based Code Generator and Decoder for Communications Systems」という表題のM. Amin Shokrollahiによる米国特許出願公開第2007/0195894号(以後「Shokrollahi IV」)

9)2009年10月23日に出願した「Method and Apparatus Employing FEC Codes with Permanent Inactivation of Symbols for Encoding and Decoding Processes」という表題のM. Amin Shokrollahiらによる米国特許出願第12/604,773号(以後「Shokrollahi V」)

10)2009年8月19日に出願した「Methods and Apparatus Employing FEC Codes with Permanent Inactivation of Symbols for Encoding and Decoding Processes」という表題のMichael G. Lubyによる米国仮特許出願第61/235,285号(以後「Luby V」)

11)2010年8月18日に出願した「Methods and Apparatus Employing FEC Codes with Permanent Inactivation of Symbols for Encoding and Decoding Processes」という表題のMichael G. Luby、M. Amin Shokrollahiによる米国特許出願第12/859,161号(以後「Shokrollahi VI」)

参照文献
以下の参照文献の各々は、あらゆる目的のために参照によって全体が本明細書に組み込まれる。

[Albanese96]または[PET] 「Priority Encoding Transmission」、Andres Albanese、Johannes Blomer、Jeff Edmonds、Michael Luby、およびMadhu Sudan、IEEE Transactions on Information Theory、42巻、6号(1996年11月)

[Albanese97]または[PET-Patent] 「System for Packetizing Data Encoded Corresponding to Priority Levels Where Reconstructed Data Corresponds to Fractionalized Priority Level and Received Fractionalized Packets」という表題のA. Albanese、M. Luby、J. Blomer、J. Edmondsへの米国特許第5,617,541号(1997年4月1日発行)

[ALC] Luby, M.、Watson, M.、Vicisano, L.、"Asynchronous Layered Coding (ALC) Protocol Instantiation"、IETF RFC 5775 (2010年4月)

[FEC BB] Watson, M.、Luby, M.、およびL. Vicisano、"Forward Error Correction(FEC)Building Block"、IETF RFC 5052(2007年8月)

[FLUTE] Paila, T.、Luby, M.、Lehtonen, R.、Roca, V.、Walsh, R.、"FLUTE--File Delivery over Unidirectional Transport"、IETF RFC 3926(2004年10月)

[LCT] Luby, M.、Watson, M.、Vicisano, L.、"Layered Coding Transport (LCT) Building Block"、IETF RFC 5651(2009年10月)

[Luby2010]または[RaptorQ-Spec] M. Luby、A. Shokrollahi、M. Watson、T. Stockhammer、L. Minder、"RaptorQ Forward Error Correction Scheme for Object Delivery"、draft-ietf-rmt-bb-fec-raptorq-04、Reliable Multicast Transport(2010年8月24日)

[Luby2007]または[Raptor-RFC-5053] M. Luby、A. Shokrollahi、M. Watson、T. Stockhammer、"Raptor Forward Error Correction Scheme for Object Delivery"、IETF RFC 5053(2007年9月)

[Luby2002] Luby, M.、Vicisano, L.、Gemmell, J.、Rizzo, L.、Handley, M.、およびJ. Crowcroft、"The Use of Forward Error Correction (FEC) in Reliable Multicast"、IETF RFC 3453(2002年12月)

[Matsuoka]または[LDPC-Extensions] "Low-Density Parity-Check Code Extensions Applied for Broadcast-Communication Integrated Content Delivery"、Hosei Matsuoka、Akira Yamada、およびTomoyuki Ohya、Research Laboratories、株式会社エヌ・ティ・ティ・ドコモ、神奈川県横須賀市光の丘3-6、239-8536、日本

[Roca]または[LDPC-RFC-5170] V. Roca、C. Neumann、D. Furodet、"Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes"、IETF RFC 5170(2008年6月)

本発明は、通信システムにおけるデータの符号化および復号に関し、より詳細には、通信されたデータのエラーおよび欠落の原因であるデータを効率的に符号化し復号し、複数の異なるファイル配信方法を扱う通信システムに関する。

通信チャネルを通じた送信者と受信者との間でのファイルの送信の技法は、多くの文献の主題である。好ましくは、受信者は、送信者によってチャネルを通じて送信されるデータの完璧なコピーを、あるレベルの確かさで受信することを望む。チャネルの忠実度が完全ではない場合(ほとんどすべての物理的に実現可能なシステムが該当する)、1つの問題は、送信中に失われたまたは歪められたデータをどのように扱うかということである。失われたデータ(喪失)は、破損したデータ(エラー)よりも扱いが容易であることが多い。それは、破損したデータが誤って受信されたデータであると、受信者が常に見分けることはできないからである。多くのエラー訂正符号が、喪失および/またはエラーを訂正するために開発されてきた。通常、使用される具体的な符号は、データの送信に使われるチャネルの非忠実度、および送信されるデータの性質についての何らかの情報に基づいて、選択される。たとえば、チャネルの非忠実である期間が長いと分かっている場合、そのような用途にはバーストエラー符号が最適であり得る。短く頻繁ではないエラーしか予想されない場合には、単純なパリティ符号が最善であり得る。

本明細書で使われる場合、「ソースデータ」とは、1人または複数の送信者において利用可能であり、エラーおよび/または喪失などを伴うもしくは伴わない、送信されるシーケンスからの復元による取得のために受信機が使用される、データを指す。本明細書で使われる場合、「符号化データ」とは、ソースデータを復元または取得するために搬送され使用され得るデータを指す。単純なケースでは、符号化データはソースデータのコピーであるが、受信された符号化データが(エラーおよび/または喪失によって)送信された符号化データとは異なる場合、この単純なケースでは、ソースデータについて追加のデータがなければソースデータを完全に復元可能ではないことがある。送信は、空間または時間を通じたものであってよい。より複雑なケースでは、符号化データは、ソースデータに基づいて変換を通じて生成され、1人または複数の送信機から受信機に送信される。ソースデータが符号化データの一部であると判明した場合には、符号化は「システマチック」であると言われる。システマチックな符号化の単純な例では、ソースデータについての冗長な情報が、ソースデータの終わりに添付され、符号化データを形成する。

また、本明細書で使われる場合、「入力データ」とは、FEC(前方誤り訂正)エンコーダ装置またはFECエンコーダモジュール、コンポーネント、ステップなど(「FECエンコーダ」)の入力に存在するデータを指し、「出力データ」とは、FECエンコーダの出力に存在するデータを指す。したがって、出力データは、FECデコーダの入力に存在すると見込まれ、FECデコーダは、処理した出力データに基づいて、入力データ、または入力データに相当するものを出力すると見込まれる。一部の場合には、入力データはソースデータであり、またはそれを含み、一部の場合には、出力データは符号化データであり、またはそれを含む。たとえば、FECエンコーダの入力の前に処理が行われない場合には、入力データはソースデータである。しかし、一部の場合には、ソースデータは異なる形態へと処理されて(たとえば、静的エンコーダ、逆エンコーダ、または別の処理)、ソースデータの代わりにFECエンコーダへ提示される、中間データを生成する。

一部の場合には、送信機デバイスまたは送信機プログラムコードは、2つ以上のFECエンコーダを含んでよく、すなわち、ソースデータは、一連の複数のFECエンコーダにおける符号化データへ変換される。同様に受信機において、受信された符号化データからソースデータを生成するために適用される、2つ以上のFECエンコーダが存在し得る。

データは、シンボルへと分割されるものと考えられ得る。エンコーダは、ソースシンボルまたは入力シンボルのシーケンスから、符号化シンボルまたは出力シンボルを生成する、コンピュータシステム、デバイス、電子回路などであり、デコーダは、受信または復元された符号化シンボルもしくは出力シンボルから、ソースシンボルまたは入力シンボルのシーケンスを復元する、コンピュータシステム、デバイス、電子回路などである。エンコーダおよびデコーダは、チャネルによって時間および/または空間に関して分離されており、任意の受信された符号化シンボルは、対応する送信された符号化シンボルと完全に同一ではないことがあり、送信されたのと完全に同じシーケンスで受信されないことがある。シンボルが実際にビットストリームへと分解されるかどうかに関わらず、シンボルの「サイズ」はビットで測ることができ、シンボルが2^M個のシンボルのアルファベットから選択される場合、シンボルのサイズはMビットである。本明細書の例の多くにおいて、シンボルはオクテット単位で測られ、符号は256個の可能性の領域にわたるものであってよい(各オクテット内に256個の可能な8ビットのパターンがある)が、データ測定の異なる単位が使われてよいことが理解されるべきであり、様々な方法でデータを測定することはよく知られている。一般的な文献では、「バイト」という用語は、8ビットの値を示すように「オクテット」という用語と交換可能に使われることがあるが、一部の文脈では、「バイト」はXビットの値を示し、このときXは8には等しくなくたとえばX=7である。したがって、本明細書では、全般に用語「オクテット」が使われる。別段示されない限り、本明細書の例は、シンボル当たりのビットの数に関して、特定の整数または非整数の値に限定されない。

Luby Iは、計算、メモリ、帯域幅を効率的に使用してエラー訂正に対処するための、連鎖反応符号のような符号の使用を説明する。連鎖反応エンコーダによって生成される符号化シンボルの1つの特性は、十分な符号化シンボルが受信されるとすぐに、受信機が元のファイルを復元できるということである。具体的には、元のK個のソースシンボルを高い確率で復元するために、受信機は約K+A個の符号化シンボルを必要とする。

所与の状況での「絶対的な受信オーバーヘッド」は値Aによって表され、「相対的な受信オーバーヘッド」は比A/Kとして計算され得る。絶対的な受信オーバーヘッドは、理論的な最小量のデータである情報に加えて、どれだけの余剰なデータを受信する必要があるかの基準であり、これはデコーダの信頼性に依存することがあり、ソースシンボルの数Kの関数として変化し得る。同様に、相対受信オーバーヘッドA/Kは、復元されているソースデータのサイズに対する、理論的な最小量のデータである情報に加えて受信する必要がある余剰なデータの量の基準であり、これもデコーダの信頼性に依存することがあり、ソースシンボルの数Kの関数として変化し得る。

連鎖反応符号は、パケットベースのネットワークを通じた通信には非常に有用である。しかし、連鎖反応符号は時々かなり計算集約的であり得る。ソースシンボルが、連鎖反応または別のレートレス符号を使って符号化する動的エンコーダの前に、静的エンコーダを使って符号化される場合、デコーダは、より頻繁に、またはより簡単に復号できる可能性がある。そのようなデコーダは、たとえばShokrollahi Iに示されている。そこに示されている例では、ソースシンボルは、符号化シンボルである出力シンボルを生成する動的エンコーダに対する入力シンボルである、出力シンボルを生成する静的エンコーダに対する入力シンボルであり、動的エンコーダは、入力シンボルの数に対して一定の比率ではない量の多数の出力シンボルを生成できる、レートレスエンコーダである。静的エンコーダは、2つ以上のレート一定のエンコーダを含み得る。たとえば、静的エンコーダは、ハミングエンコーダ、低密度パリティ検査(「LDPC」)エンコーダ、高密度パリティ検査(「HDPC」)エンコーダなどを含み得る。

一部のシンボルが受信されたシンボルからデコーダにおいて復元されると、そうした復元されたシンボルを使ってさらなるシンボルを復元できる可能性があり、そのさらなるシンボルが、より多くのシンボルを回復するために使われ得るという特性を、連鎖反応符号は有する。好ましくは、所望のシンボルのすべてが、受信されたシンボルの貯えを使い切る前に回復されるように、デコーダにおいて起きるシンボルの連鎖反応は続き得る。好ましいことに、連鎖反応による符号化および復号の実行の、計算的な複雑さは低い。

デコーダにおける復元処理は、どのシンボルが受信されたかを判定することと、元の入力シンボルを受信された符号化シンボルへと対応付ける行列を生成することと、その逆行列を求めて、逆行列と受信された符号化シンボルのベクトルとの行列の乗算を実行することとを伴い得る。通常のシステムでは、この総当たり式の実装形態は、過度の計算能力およびメモリ要件を費やし得る。当然、受信された符号化シンボルのある特定のセットに対しては、元の入力シンボルのすべてを復元するのが不可能であることがあり、それが可能である場合でも、結果を計算するのに非常に多くの計算能力を費やし得る。

前方誤り訂正(「FEC」)オブジェクト送信情報(「OTI」)または「FEC OTI」
FEC OTIに基づいて、受信機は受信し(または推測することができ)、受信機は、ファイル転送のソースブロックおよびサブブロック構造を決定することができる。本明細書の図1で示されるように、[Raptor-RFC-5053]および[RaptorQ-Spec]では、FECペイロードIDは(SBN, ESI)であり、[Raptor-RFC-5053]ではソースブロック番号(SBN)は16ビットであり符号化シンボルID(ESI)は16ビットであり、[RaptorQ-Spec]ではSBNは8ビットでありESIは24ビットである。このFECペイロードIDフォーマットの1つの欠点は、SBNおよびESIへ割り当てるべきFECペイロードIDのビットの数を事前に決定しなければならず、すべてのファイル配信パラメータに対して妥当になる適切な組合せを決定するのが難しいことがある、ということである。

たとえば、[Raptor-RFC-5053]を使う場合、利用可能なESIが2¹⁶=65,536個のみであることは一部の状況では制約となり得る。それは、一部の場合には、8,192個のソースシンボルを有するソースブロックが存在することがあるので、符号化シンボルの数は8以上の倍数に限られ、この場合、使われ得る可能な符号化レートは、1/8よりも小さくはならないように制限されるからである。この例では、2¹⁶=65,536個の利用可能なソースブロックは、これまで使われてきた利用可能なソースブロックよりも多い可能性があり、たとえば、各々が1,024オクテットの8,192個のソースシンボルでは、サポートされ得るファイルのサイズは524GBであり、これは多くの用途において、必要な大きさよりも2桁大きいということがあり得る。

別の例として、[RaptorQ-Spec]を使う場合、利用可能なSBNが2⁸=256個のみであることは一部の状況では制約となり得る。それは、4GBのファイルでは、各ソースブロックは8MBに制限され(最大のサブブロックサイズが256KBであり、最小のサブシンボルサイズが32オクテットであり、シンボルサイズが1,024オクテットである場合にそのようになり得る)、ソースブロックの数が256に制限され、そしてファイルサイズが2GBに制限される。この例では、利用可能な2²⁴=16,777,216個の符号化シンボルは、これまで使われてきた符号化シンボルよりも多く、たとえば8,192個のソースシンボルでは利用可能な符号化シンボルの数は2,048倍大きく、これは一部の用途では決して必要になり得ない、ということがあり得る。

別の望ましい特性は、不均一誤り保護(「UEP」)とも呼ばれることもある、ファイルの異なる部分の間での優先順位を付けられた符号化送信の能力を提供することである。たとえば、ファイルの最初の10%を、残りの90%よりも強力に、パケット喪失に対して保護するのが望ましいことがある。たとえば、[LDPC-Extensions]は、[LDPC-RFC-5170]がUEPをサポートするためにどのように拡張され得るかを説明する。この場合、実際のFEC符号自体が、ファイルの異なる部分に対して異なるレベルのパリティ保護を提供するように、修正される。しかし、この手法には欠点がある。たとえば、FEC符号自体の実装および検査が複雑になるので、UEPを実現するためにFEC符号自体を修正しなければならないのは望ましくない。さらに、[LDPC-Extensions]の図6で示される結果のように、ファイルの異なる部分に対して提供される、パケット喪失に対する弾力性の面でのそのような手法により得られる性能は、理想からはかけ離れている。

UEPファイル配信能力を提供する1つの方法は、[PET]および[PET-Patent]で説明されるように、優先順位およびサイズに従って、ファイルの異なる部分に対して、各パケットの異なる部分を割り当てることである。しかし、問題は、ファイルの異なる各部分がファイルの他の部分とは独立にソースブロックおよびサブブロックに分割され、たとえば、ファイルの各部分の少量のメモリの復号をサポートし、さらに同時に、ファイルの各部分のためのシンボルが各パケット内に含まれていると受信機が判定できるようにする各パケット内のFECペイロードIDを、各パケット内に提供できるように、そのようなUEPの方法をどのように組み込むかである。このことは、フォーマット(SBN, ESI)のFECペイロードIDを使って対応するのは非常に難しい。それは、ファイルの各部分について、ファイルの第1の部分に対するパケット中のシンボルの対応するSBNおよびESIは、ファイルの第2の部分に対するパケット中のシンボルのSBNおよびESIとは異なり得るからである。

HTTP修復手法
ブロードキャスト/マルチキャストファイル配信のための3GPP MBMS規格TS 26.346において、修復要求が行われる方法は、たとえば、[Raptor-RFC-5053]で規定される、すなわち、ソースブロック番号(SBN)および符号化シンボル識別子(ESI)を規定することによって規定される、FECペイロードIDを使うことである。修復要求に応答するサーバが、ブロードキャスト/マルチキャストファイル配信において使われるファイル配信構造を決定するようにそのサーバに要求する特別な方法を有する場合、すなわち、そうしたサーバが、ソースブロックおよびサブブロックの構造とともにシンボルサイズTを知っていることを必要とする、ファイルのどの部分が要求されたSBNおよびESIによって参照されるかの解釈を行うように要求される場合には、この方法は合理的である。一方、広大な地理的領域にわたって分散する数百万個のブロードキャスト/マルチキャスト受信機が存在することがあり、専用の応答サーバの配備を必要とすることは、設備投資と運用の両方の観点において、高価であるとともに煩わしい。広範に配備されているのは、たとえばウェブページ、ビデオストリーミングなどのインターネット配信をサポートする、標準的なHTTPウェブサーバおよびウェブキャッシュである。望ましいのは、標準的なHTTPウェブサーバおよびウェブキャッシュを、ブロードキャスト/マルチキャスト応答サーバとして使用するのをサポートする方法である。

ファイル配信の方法および装置の実施形態において、汎用ファイルシンボル識別子(「UFSI」)または汎用オブジェクトシンボル識別子(「UOSI」)が、パケットに含まれる符号化シンボルを特定するのに必要なパケット内の構造を特定するためにパケットと関連付けられる。そのように使われると、UFSI/UOSIは、不均一誤り保護を含めて、FECおよびファイル/オブジェクト配信の改善された処理を可能にし、配信されたデータのすべての部分が、FEC保護および一括オブジェクト配信に関して同じレベルにあるとは限らず、複数のオブジェクトを、別々に処理する場合よりも効率的に処理することができる。

以下の発明を実施するための形態は、添付の図面とともに、本発明の性質および利点のさらなる理解をもたらす。

Raptor-RFC 5053のFECペイロードIDを示す図である。 RaptorQ-SpecのFECペイロードIDを示す図である。 基本的な汎用ファイル配信(「UFD」)の方法のFECペイロードIDを示す図である。 送信機の基本的なUFDの方法を示すフローチャートである。 受信機の基本的なUFDの方法を示すフローチャートである。 ファイルのシンボルの識別情報(SBN, ESI)と、ファイルのシンボルの対応する汎用ファイルシンボル識別子(「UFSI」)への、またはそれからの対応付けとを示す例である。 送信機の汎用ファイル配信、不均一誤り保護(「UFD-UEP」)の方法を示すフローチャートである。 受信機のUFD-UEPの方法を示すフローチャートである。 各々の優先順位が異なる2つの部分を含むファイルの識別情報(SBN, ESI)の例を示す図である。 ファイルの2つの部分からの符号化シンボルの識別子(SBN, ESI)と、各パケットに含まれるUFSIとともにその部分の符号化シンボルを含むパケットとの対応付けの、図8に対応する例を示す図である。 [RaptorQ-Spec]を用いた単純なUEPファイル配信方法の性能を示す図である。 ともに[RaptorQ-Spec]を用いる、単純なUEPファイル配信方法とUFD-UEPファイル配信方法との例示的な性能の比較を示す図である。 すべて[RaptorQ-Spec]を用いる、1つのファイルのファイル配信と、複数のファイルのファイル配信と、UFD一括ファイル配信方法との例示的な性能の比較を示す図である。 ファイル配信の一部として、Raptor、RaptorQ、または他のパケットを、生成し、送信し、受信するために使われ得る、通信システムのブロック図である。 1つの受信機が、複数の、通常は独立した送信機から出力シンボルを受信する、ファイル配信が行われ得る通信システムの図である。 複数の、場合によっては独立した受信機が、複数の、通常は独立した送信機から出力シンボルを受信し、1つのみの受信機および/または1つのみの送信機が使われる場合よりも短い時間で入力ファイルを受信する、ファイル配信が行われ得る通信システムの図である。 HTTPストリーミングサーバを用いてファイル配信を実現するために使われ得る、ブロック要求ストリーミングシステムの要素を示す図である。 ブロックサービングインフラストラクチャ(「BSI」)に結合されて、ファイル配信のために使われ得る、コンテンツ取込システムによって処理されるデータを受信する、クライアントシステムの要素をさらに詳細に示す、図16のブロック要求ストリーミングシステムを示す図である。 ファイル配信のためのファイルを準備するのに使われ得る、取込システムのハードウェア/ソフトウェア実装形態を示す図である。 クライアントシステムに配信されるファイルを受信するのに使われ得る、クライアントシステムのハードウェア/ソフトウェア実装形態を示す図である。 一般のFEC OTI要素のフォーマットの例を示す図である。 方式固有のFEC OTI要素のフォーマットの例を示す図である。

本明細書の実施形態では、ファイル配信が、ファイルを送信するエンコーダ/送信機システムと、ファイルを受信する受信機/デコーダシステムとによって、実行される。エンコーダが符号化したものをデコーダが理解するように、送信の形式は調整される。以下の様々な例で示されるように、ファイル配信は、一般的なオブジェクト配信の例であり、別段示されない限り、オブジェクトはファイルとして扱われ得ること、場合によってはファイルはオブジェクトとして扱われ得ることが、これらの例から明らかであろう。

パケット配信システムにおいて、データはパケットへと編成され、パケットとして送信される。各パケットは、パケット中に何があるか、それがどのように配置されているかを受信機が判定できるようにする、要素を有する。本明細書で説明される技法を使って、前方誤り訂正(「FEC」)が使われる場合にパケットを送信するための柔軟性が提供される。

これらの技法を使って、不均一なFECの保護が、ファイルの一括配信とともに実現され得る。多くのファイルが別々のファイルとして配信される場合、パケット喪失に対する配信の弾力性は、すべてのファイルがより大きなファイルへと連結されその大きなファイルが配信において保護される場合よりも、はるかに低くなり得ることがよく知られている。しかし、より小さなファイルの組合せとしてより大きなファイルの構造をシグナリングするのが必要であり、受信機がより小さなファイルの部分集合の復元にしか関心がなくても、受信機は一般に、より大きなファイル全体を復元して、より大きなファイル内のより小さなファイルのすべてを復元する必要がある。

したがって、好ましいファイル配信システムまたは方法は、ソースブロックの数と、ファイルのためにファイル配信構造として使われるソースブロック当たりの符号化シンボルの数との、あらゆる柔軟な組合せを可能にしなければならない。ファイル配信方法が、パケット喪失に対して効率的な保護を実現し、異なる優先順位で保護されるファイルの異なる部分を有するファイルの配信をサポートし、ファイルの各部分が、ファイルの他の部分とは異なる、ソースブロック構造およびサブブロック構造を有し得ることも、当てはまらなければならない。また、一部の場合には、ファイルはオブジェクトの特定の例であると考えられるが、ファイルの転送および処理を説明するために本明細書で使われる例は、場合によってはファイルとしては呼ばれないデータオブジェクト、たとえば、データベースからのデータの大きな塊、ビデオシーケンスの一部などに対しても使われ得ることを、ここで理解されたい。

ファイル/オブジェクト配信システムまたは方法は、大きなファイル/オブジェクトの保護の効率性とともに、多くのより小さなファイル/オブジェクトの配信を実現し、より小さなファイル/オブジェクトの構造の単純なシグナリングを実現し、受信機が、より小さなファイルの/オブジェクトのすべてを復元することなく、より小さなファイル/オブジェクトの部分集合のみを独立に復元するための能力を提供できなければならない。これらの望ましい品質を有するシステムの例が、ここで説明される。

基本的な汎用ファイル配信(「UFD」)の方法およびシステム
基本的な汎用ファイルの配信(「UFD」)の方法および対応するシステムがここで説明され、UFDは、既存のファイル配信方法に対する大きな利点を含む。基本的なUFDの方法に対する、前方誤り訂正(「FEC」)ペイロードIDは、たとえば32ビットのフィールドであり得る、汎用ファイルシンボル識別子(「UFSI」)フィールドを含む。基本的なUFDの方法のための、送信機および受信機の方法が、同じくここで説明される。また、ファイルがオブジェクトと呼ばれる場合、「UFSI」は代わりに「UOSI」(汎用オブジェクトシンボル識別子)と呼ばれ得る。

送信機の基本的なUFDの方法が、図3を参照して説明される。送信機は、たとえば、[Raptor-RFC-5053]または[RaptorQ-Spec]で説明されるように(たとえば、[RaptorQ-Spec]のセクション4.3を参照)、既存の方法を使ってFECオブジェクト送信情報(「OTI」)を生成し、FEC OTIを使って、ファイルの送信に使用すべきソースブロックおよびサブブロックの構造を決定し、(SBN, ESI)のペアとファイルの符号化シンボルとの関係を決定することができる(たとえば、[RaptorQ-Spec]のセクション4.4を参照)。

たとえば、[RaptorQ-Spec]で説明されるように、生成されるFEC OTIは(F, Al, T, Z, N)であってよく、Fは送信されるファイルのサイズ、Alは、Alの倍数であるメモリの境界上でサブシンボルが揃えられるのを確実にするために使われる整列係数、Tは生成され送信において送信されるシンボルのサイズ、Zは送信のためのファイルの分割先であるソースブロックの数、Nは送信のための各ソースブロックの分割先であるサブブロックの数である。これは、図3のステップ300に示されている通りである。

たとえば、[RaptorQ-Spec]で説明されるように、送信機は、パケット内で送信されるべき符号化シンボルを形成し、ソースブロックに基づいて、かつサブブロックが使われる場合にはサブブロック構造にも基づいて、既存の方法を使ってこれらの符号化シンボルのためのSBNおよびESIを生成することができる。符号化システムが送信されるべきである度に、送信機は、図3のステップ310に示されるように、生成されるべき符号化シンボルのSBN AおよびESI Bを決定することができ、次いで送信機は、図3のステップ320に示されるように、たとえば[RaptorQ-Spec]で説明される技法のような既存の技法を使って、(SBN, ESI)=(A, B)に基づいて符号化シンボルの値を生成することができる。そして、図3のステップ330に示されるように、その符号化シンボルのUFSI Cは、C=B×Z+Aとして計算される。

送信機は、図3のステップ340に示されるように、パケットのFECペイロードIDが符号化シンボルのUFSI Cへ設定されたパケット中で、符号化シンボルを送信することができる。次いで、送信機は、図3のステップ350に示されるように、さらなる符号化シンボルが送信されるべきかどうかを判定することができ、送信されるべきである場合、送信機は、図3のステップ310への「Yes」分岐で示されるように、送信すべき追加の符号化シンボルを生成することができ、送信されるべきではない場合、送信機は、図3のステップ360への「No」分岐で示されるように、終了することができる。

送信機の基本的なUFDの方法の、多くの変形形態がある。たとえば、送信機は、パケットの少なくとも一部で2個以上の符号化シンボルを送信することができ、この場合、FECペイロードIDは、パケットに含まれる第1の符号化シンボルのUFSIに設定されてよく、パケットに含まれる追加のシンボルは、対応するUFSIの値が連続的になるように、選択され得る。たとえば、パケット中で搬送される3個の符号化シンボルがあり、第1のそのようなシンボルのUFSIが4234である場合、他の2個の符号化シンボルは、それぞれUFSIが4235および4235である符号化シンボルであり得る。他の代替形態の例として、送信機は、どれだけの符号化シンボルを生成するかを事前に決定し、符号化シンボルのいずれかを生成する前に、生成されるべきすべての符号化シンボルの(SBN, ESI)の値を決定することができる。別の例では、UFSIの値は、(SBN, ESI)の値を生成する中間ステップなしで、直接生成されてよい。

変形形態の別の例として、他の形態のFEC OTI情報を生成することができる。たとえば、基本UFSI BUが、ファイルのFEC OTIに含まれてよく、BUは次のように使われ得る。すなわち、パケットに含まれる符号化シンボルについて、FECの送信機および受信機によって使われるべきUFSIはU + BUであり、Uは、符号化シンボルを搬送するパケット中で搬送されるUFSIである。したがって、たとえば、パケットがU=1,045を搬送し、FEC OTIの中の基本UFSIがBU=2,000,000である場合、符号化シンボルのUFSIは2,001,045である。基本UFSIの使用には、いくつかの利点がある。1つの利点として、[FLUTE]、[ALC]、[LCT]、[FEC BB]において説明されるプロトコルスイートが、TOIとも呼ばれる送信オブジェクト識別子を、転送されるべきファイルまたはオブジェクトのFEC OTIと関連付ける。同じファイルの符号化シンボルが、異なる時間に、または異なるセッションで送信され、異なるTOIと関連付けられ得ることが可能である。また、異なる各TOIと関連付けられるパケットについて、UFSI=0から始まる符号化パケットを送信できるのが有利である。FEC OTIの一部として基本UFSIを規定できることで、異なる基本UFSIを、ファイルのために符号化シンボルが送信される際の各TOIと関連付けることができ、異なるTOIに対して重複する符号化シンボルが送信されない。たとえば、同じファイルの符号化シンボルは、TOI=1と関連付けられTOI=2と関連付けられるパケットで送信されてよく、TOI=1と関連付けられる基本UFSIは0に設定され、TOI=2と関連付けられる基本UFSIは1,000,000に設定される。そして、TOI=1とTOI=2の両方の符号化パケットは、UFSI0、1、2などというシーケンスを含んでよく、TOI=1でファイルのために送信される符号化シンボルが1,000,000個より少ない限り、2つのTOIと関連付けられて送信される符号化シンボルの中に、重複する送信される符号化シンボルはない。

受信機の基本的なUFDの方法が、図4を参照して説明される。受信機は、図4のステップ400で示されるように、既存の技法を使って、送信機について上で説明されたのと同じ形式の、FEC OTI (F, Al, T, Z, N)を決定することができる。たとえば、FEC OTIは、FLUTEセッションの説明に組み込まれてよく、またはFEC OTIは、URLへと符号化されてよく、またはFEC OTIは、SDPメッセージを介して取得されてよい。ステップ410において、受信機は、さらに符号化シンボルが受信されるかどうかを確かめて、別の符号化シンボルを受信するまで(この場合、受信機はステップ430に進む)、またはさらなる符号化シンボルは今後受信されないと受信機が判定するまで(この場合、受信機はステップ420に進む)、このステップに留まることができ、他の手段、たとえばファイル修復サーバへのHTTP要求を使ってファイルの復元を試み、または受信機は、後でさらなる符号化シンボルを受信するために別のセッションを待機することができ、または受信機は、ファイルを回復できないと判定することができる。

別の符号化シンボルが利用可能である場合、ステップ430において、受信機は符号化シンボルのUFSI Cを決定し、符号化シンボルの値を受信する。ステップ440において、受信機は、ソースブロックの数ZおよびUFSI Cに基づいて、A=C modulo Z、およびB=floor(C/Z)を計算し、ステップ450において、受信機は、符号化シンボルの(SBN, ESI)を(A, B)に設定し、ステップ460において、受信機は、符号化シンボルの値およびファイル復元のために使われる(A, B)を記憶する。ステップ470において、受信機は、ファイルを復元するのに十分な符号化シンボルが受信されたかどうかを判定し、受信されている場合、ステップ480のファイルの復元に進み、受信されていない場合、ステップ410のさらなる符号化シンボルの受信に進む。

受信機の基本的なUFDの方法の、多くの変形形態がある。たとえば、受信機は、パケットの少なくとも一部で2個以上の符号化シンボルを受信することができ、この場合、FECペイロードIDは、パケットに含まれる最初の符号化シンボルのUFSIに設定されてよく、パケット中の追加のシンボルは、連続的な対応するUFSIの値を有し得る。たとえば、パケット中で搬送される3個の符号化シンボルがあり、第1のそのようなシンボルのUFSIが4234である場合、他の2個の符号化シンボルは、それぞれUFSIが4235および4235である符号化シンボルであってよく、パケット中で搬送されるUFSIは、第1の符号化シンボルのUFSI=4234であり得る。他の代替形態の例として、受信機は、復元を試みる前に、どれだけの符号化シンボルを受信すべきかを事前に決定することができる。別の例として、受信機は、ファイルの復元に十分な符号化シンボルが受信されたかどうかを判定するのに使われるFEC符号に特有の、何らかの処理を行うことができる。別の例として、UFSIの値は、復元処理において、(SBN, ESI)の値を生成する中間ステップなしで、直接使用されてよい。別の例として、ファイルの復元は、符号化シンボルの受信と同時に行われてよい。別の例として、他の形態のFEC OTI情報を使用することができる。

基本的なUFDの方法を、ソースブロックおよびサブブロックの構造を決定するための[RaptorQ-Spec]で説明された技法と組み合わせることで、多くの利点がもたらされる。たとえば、ファイルを送信するための、SBNとESIの組合せによって特定される、従来の方法ではソースシンボルと呼ばれていたものは、基本的なUFDの方法を使うと、UFSIによって特定されるファイルシンボルとして見なされ得る。Fを、オクテット単位での送信されるべきファイルのサイズ、Tを、ファイルを送信するときにFEC符号化/復号のために使われるべきシンボルサイズとすると、KT=ceil(F/T)は、ファイル中のシンボルの総数であり、ceil(x)は、x以上の最小の整数である。

ソースブロック構造およびサブブロック構造はたとえば、[RaptorQ-Spec]で説明されるように決定され、上で説明された基本的なUFDの方法を使って、シンボルの識別情報を(SBN, ESI)形式からUFSI形式へと変換し、ファイルシンボルのUFSIの範囲は0, 1, 2, ..., KTであり、ファイルから生成される任意の修復シンボルは、範囲KT+1、KT+2などの中にUFSIを有する。この特性は、シンボルが元のファイルの一部であるかどうか、またはファイルから生成された修復シンボルであるかどうかを、シンボルのUFSIをKTの値と単に比較することによって判定するのを可能にする。このことはたとえば、どのシンボルが元のファイルの一部であるか(およびファイル内でのシンボルの位置)、ならびにどのシンボルを修復シンボルとして無視できるかを、パケット中で搬送されるUFSIの値とファイルのKTの値とに基づいて、FEC復号をサポートしない受信機が判定できるようにするのに、有用であり得る。

図5はある例を示し、この場合、ファイルサイズがF=28,669オクテット、シンボルサイズがT=1,024オクテットであり、したがってKT=ceil(F/T)=28である。図5では、ファイルのシンボルの(SBN, ESI)標示が上側に示され、各行はソースブロックに対応し、各列は同じESI値を有するシンボルに対応する。シンボルの対応するUFSI標示が、下側に示されている。この場合、UFSI=27であるシンボル、すなわちUFSI標示に関して28番目のシンボルは、FECの符号化および復号のために、最後の(KT×T)-F=3オクテットを0によってパディングされているが、このシンボルの最後のパディングされた3オクテットは、送信する必要はない。この例では、UFSI 28以上の任意の符号化シンボルは修復シンボルであり、UFSI 28である符号化シンボルは、SBN=3のソースブロックから生成され、UFSI 29である符号化シンボルは、SBN=4のソースブロックから生成され、UFSI 30である符号化シンボルは、SBN=0のソースブロックから生成され、以下同様である。当業者が認識するように、この特性には多くの他の利点がある。

基本的なUFDの方法の別の利点は、符号化シンボルが、UFSIによって定義される順序で、すなわちUFSIの順序0, 1, 2, 3, 4, ...で送信される場合、Z個のソースブロックの符号化シンボルは、交互の順序で送信され、すなわち、Z個のソースブロックの各々のうちのESI 0であるZ個の符号化シンボルが最初に送信され、続いて、Z個のソースブロックの各々のうちのESI 1であるZ個の符号化シンボルが送信される、などである。大半の送信に対しては、この単純な送信順序で十分であり、それが好ましい。しかし、ソースブロックの数Zと同期し得る何らかの周期性がパケット喪失にある場合、より良い可能性のある送信順序は、UFSIが連続したZ個の符号化シンボルの各セットを、送信する前にランダムに順序を変えるというものであり、すなわち、UFSI 0, ..., Z-1である最初のZ個の符号化シンボルが、ランダムに変えられた順序で送信され、次いで、UFSI Z, ..., 2×Z-1である次のZ個の符号化シンボルが、ランダムに変えられた順序で送信される、などである。この説明の全体で、別段示されない限り、「ランダム」は擬似ランダムを含み得ることを理解されたい。

基本的なUFDの方法を使うことで、従来の既知の方法に対する多くのさらなる利点がもたらされる。たとえば、所定のサイズのSBNおよびESIフィールドを含むFECペイロードIDを使う場合、可能なソースブロックの所定の数と、ソースブロックあたりの可能な符号化シンボルの所定の数は別々である。たとえば、32ビットのFECペイロードIDを生じる8ビットのSBNおよび24ビットのESIは、可能なソースブロックの数を256に制限し、ソースブロック当たりの可能な符号化シンボルの数を16,777,216に制限する。UFSIフィールドを含むFECペイロードIDは、そうではなく、ファイルのソースブロック構造とは無関係に、ファイルの可能な符号化シンボルの総数のみを制限する。たとえば、32ビットのFECペイロードIDを生じる32ビットのUFSIを使うと、ファイルのために生成され得る符号化シンボルの総数は4,294,967,296であり、これは、ファイルが何個のソースブロックへと分割されるかに無関係であり、サブブロックが使われる場合には、ファイルのサブブロック構造にも無関係である。したがって、シンボルのサイズが1,024オクテットである場合、この例では、ファイルサイズは最大で4GBであってよく、符号化シンボルの数はファイルサイズの1,024倍であってよく、これは、ファイルが1つのソースブロックへと分割されるか、16,384個のソースブロックへと分割されるか、または4,194,304個のソースブロックへと分割されるかには無関係である。別の例として、ファイルサイズは2TBであってよく、符号化シンボルの数は、ファイルサイズの2倍であってよい。すべての場合において、サブブロック構造が使われる場合、ファイルのために生成され得る符号化シンボルの数は、ファイルのサブブロック構造とは無関係である。

不均一誤り保護ファイル配信サービスのための汎用ファイル配信方法
ほとんどの従来のファイル配信方法は、不均一誤り保護(「UEP」)ファイル配信をサポートしない。ファイルの異なる部分を符号化するのに使われる実際のFEC符号を変えることによってUEPをサポートする、たとえば、ISDB-Tmm(地上モバイルマルチメディア)規格で現在規定されており[LDPC-Extensions]で説明される方法を用いる、いくつかの従来の方法がある。UEPを使うときに実際のFEC符号を変更しなければならないという欠点とは別に、さらなる欠点は、これらの方法によって実現される保護が理想からかけ離れているということである。

ある例として、結果が[LDPC-Extensions]の図6に示される例を考える。その例では、パケット中で送信されるべき1,000KBのサイズのファイルに2つの部分があり、各パケットは1KBのシンボルを含む。ファイルの第1の部分はサイズが30KBであり、100個のパリティパケットまたは修復パケットによって保護され、ファイルの第2の部分は970KBであり、全体で1,000個のソースパケットおよび1,000個のパリティパケットがそのファイルのために送信される。実現される保護は、2つの問題によって理想からはかけ離れている。1つの問題は、[LDPC-RFC-5170]に基づく、用いられるFEC符号が、ソースブロックを復元するために大きな受信オーバーヘッドを必要とすることが多いということであり、すなわち、ファイルを復元するために、ファイル中のソースパケットよりも多くのパケットを、受信する必要がある。第2の問題は、この方法は基本的に、ファイルの第2の部分を送信して保護するのに使われるパケットとは別個のセットを使って、ファイルの第1の部分を送信して保護するということである。第2の問題について、ファイルの第1の部分のために送信される、130個のパケットのうちの30個のパケットを受信する際の変動は、大きいものであり得る。それは、ファイルの第1の部分が、そのような少数のパケットを通じて送信されるからである。

[LDPC-Extensions]で説明されたUEPファイル配信方法は、本明細書では「単純UEP」ファイル配信方法と呼ばれる拡張によって、改善することができる。単純UEPファイル配信方法は、ファイル配信のための既存の技法を使い、優先順位に基づいてファイルの各部分に対して異なる保護の量を使って、ファイルの複数の部分を別個のファイル配信として配信し、配信された複数のファイルが同じファイルの複数の部分であると受信機が知るように、ファイルの複数の部分の間の論理的な接続がシグナリングされ得る。たとえば、単純UEPファイル配信方法は、上の例の[RaptorQ-Spec]を使い、ファイルの第1の30KB部分を、その第1の部分から生成されたサイズが1,024オクテットの符号化シンボルを各々含む全体で130個のパケットを送信することによって、配信することができ、ファイルの第2の970KB部分は、その第2の部分から生成されたサイズが1,024オクテットの符号化シンボルを各々含む全体で1870個のパケットを送信することによって、別個のファイルとして配信され得る。したがって、ファイルの2つの部分に対して、全体で2,000個のパケットが別個のファイルとして送信される。単純UEPファイル配信方法は、[LDPC-Extensions]で説明された方法に対する改善である。それは、FEC符号自体が修正されず、本明細書の図10に示されるように、パケット喪失状態の異なるファイルの2つの部分の配信の性能が、[LDPC-Extensions]の図6に示されたものよりも優れているからである。

この違いの1つの可能性のある原因は、[RaptorQ-Spec]で規定されたFEC符号が、[LDPC-RFC-5170]で規定されたFEC符号よりも、優れた復元特性を有しているからである。しかし、単純UEPファイル配信方法は依然として、上で説明された第2の問題を抱える。

[PET]および[PET-Patent]は、UEPファイル配信サービスを提供するための、改善の可能性がある方法を提供し、各パケットは、優先順位に基づいて、ファイルの各部分からの規定された量の符号化データを含む。[PET]の簡単な組み込みは、ファイルの各部分に対して適切なサイズの符号化シンボルを各パケットに含めて、ファイルの各部分に対する(SBN, ESI)ペアを含む別個のFECペイロードIDを含めることであろう。しかし、この方法は、いくつかの理由によって不利である。

たとえば、各部分に対する所定のサイズのSBNおよびESIフィールドを含むFECペイロードIDを使う場合、ファイルの各部分に対する、可能なソースブロックの所定の数と、ソースブロックあたりの可能な符号化シンボルの所定の数とは、別々である。たとえば、d個の部分の各々に対する、8ビットのSBNおよび24ビットのESIは、1つの部分当たりの可能なソースブロックの数を256に制限し、ソースブロック当たりの可能な符号化シンボルの数を16,777,216に制限する、(32×d)ビットのFECペイロードIDをもたらす。さらに、FECペイロードIDのサイズは、d個の部分の各々に対して32ビットであり、これは、各パケットのすべての部分に対するFECペイロードIDが全体で32×dビットになることを意味し、各パケット中のFECペイロードIDヘッダだけに対して、たとえばd=10であればこれは320ビットであり、または等価的に40オクテットである。

ファイル配信のための基本的なUFDの方法は、以下で詳細に説明されるような、従来の不均一誤り保護(UEP)ファイル配信方法に対して大きな利点をもたらすUEPファイル配信サービスを実現するように、拡張され得る。本明細書では、これらの拡張された方法は、「UFD-UEP」ファイル配信方法と呼ばれる。これらのUFD-UEPファイル配信方法は、[PET]および[PET-Patent]で説明される方法の一部を使うことができる。

例示的なUFD-UEPファイル配信方法が、ここでより詳細に説明される。そのような方法では、送信機は、サイズがFであるファイルを、サイズがF₀, F₁, ..., F_d-1であるd > 1個の部分に分割するので、Fは、F_iのiにわたる合計に等しい。送信機は、パケットサイズTを、サイズがT₀, T₁, ..., T_d-1であるd個の部分に分割するので、Tは、T_iのiにわたる合計に等しい。Tのこの分割は、F₀, F₁, ..., F_d-1と、対応するファイルの部分の優先順位とに基づく。比F_i/T_iは、1つのソースブロックとしてのファイルの部分iを保護するために理想的なFEC符号が使われると仮定して、ファイルの部分iを復元するためにどれだけのパケットを受信する必要があるかを判定するので、比F_i/T_iが小さいほど、ファイルの部分iの優先順位は高い。実際には、たとえば、FEC符号は完璧ではなく何らかの受信オーバーヘッドを示すので、または、ファイルのその部分が複数のソースブロックに分割され、一部のソースブロックの符号化シンボルが他のソースブロックの符号化シンボルよりも高い比率で失われるので、または、F_i/T_iが整数ではないので、F_i/T_iよりもわずかに多くのパケットが、ファイルの部分iを復元するために必要であり得る。UEPの例として、F=1MB、T=1,024オクテット、d=2、F₀=32KB、F₁=F-F₀=992KB、かつT₀=64オクテット、T₁=T-T₀=960オクテットであるとする。この例では、F₀/T₀=512なので、理想的には512パケットの受信によって、ファイルの部分0の復元が可能であり、F₁/T₁ = 1,058.13なので、理想的には1,059パケットの受信によって、ファイルの部分1の復元が可能である。したがって、この例では、ファイルの部分0は、ファイルの部分1の復元に必要なパケットのおよそ半分のパケットから、復元され得る。

この例では、UEPが使われない場合、すなわち、d=1であり、したがってF₀=F = 1MBであり、T₀=T = 1,024オクテットである場合、F₀/T₀=1,024個のパケットがファイルの復元に必要である。したがって、前の段落で説明されたUEPの例では、ファイルの部分0の優先順位がより高いので、ファイルの部分1の復元には、UEPが使われない場合よりもわずかに多くのパケットが必要である。この基本的なトレードオフの分析的な研究を、[PET]において見出すことができる。

F₀, F₁, ..., F_d-1と、異なるファイルの部分の優先順位とに基づいて、Tの部分T₀, T₁, ..., T_d-1を生成するための、送信機のUFD-UEPの方法に対する様々な方式がある。F_i/T_i≒F/T となるようにT_iが選ばれる場合、ファイルの部分iの優先順位は平均的であると見なされ、部分iの優先順位は、F_i/T_i < F/TであるかF_i/T_i > F/Tであるかに応じて、それぞれ、比較的高いかまたは低い。

FEC OTIの生成のための送信者のUFD-UEPの方法が、図6を参照してここで説明される。d, F₀, F₁, ..., F_d-1, T₀, T₁, ..., T_d-1, Al, WSの値を与えると、ファイルのd個の部分の各々に適用されるFEC OTIは、既存の方法を使って、たとえば、[RaptorQ-Spec]のセクション4.3で説明される方法を使って、通常通りに独立に計算することができる。すなわち、各々のi=0, ..., d-1に対して、送信機は、ファイルの部分iに対するFEC OTIを生成することができ、このFEC OTIは、たとえば、[RaptorQ-Spec]のセクション4.3で説明された方法を使い、F_iをファイルサイズとして、T_iを部分iのための情報を各パケットで搬送するために使われるべきシンボルサイズとして扱って、ファイルの部分iがどのようにソースブロックおよびサブブロックへと分割されるべきかを決定する。こうして、送信機は、ファイルの他の部分とは独立に、ファイルの部分iに対するFEC OTIを生成する。この処理は、本明細書の図6のステップ600に示されている。

送信機はまた、ソースブロックおよびサブブロックへのファイルの部分iの分割、および、ファイルの部分iの符号化シンボルの(SBN, ESI)と、既存の方法、たとえば、[RaptorQ-Spec]のセクション4.4およびセクション5で説明される方法を使って、符号化シンボルがどのようにファイルの部分iから生成されるかということとの対応付けを、生成することができる。これらのUFD-UEPの方法は、ファイルの他の部分とは独立に、ファイルの部分iに適用されるので、ファイルの異なる部分は、異なるソースブロックおよびサブブロック構造を有してよく、特に、この方法はファイルの各部分に対して独立に適用されるので、ファイルの異なる部分の間で、ソースブロック当たりのソースシンボルの数およびソースブロックの数が異なっていてよい。

整列係数Alは、好ましくはファイルの部分のすべてに対して同一であり、特に、各部分iに対して、T_iの値がAlの倍数であることが好ましい。さらに、たとえば、[RaptorQ-Spec]のセクション4.5で説明される方法が、FEC OTIを導出するために使われる場合、ファイルの部分の各々のソースブロックおよびサブブロック構造を導出するときに、同じ値のAlおよびWSが使われることが好ましい。Alに同じ値を使うことで、Alの倍数個のオクテット上に整列されたメモリに対して、受信機において復号が行えることが確実になり、WSに同じ値を使うことで、受信機において復号される必要のあるランダムアクセスメモリ(RAM)中の最大のブロックサイズが、ファイルのすべての部分に対して同一になることが確実になる。たとえば、ファイルの優先順位の高い部分を復元するのにより少量のメモリを使用するのが望ましい場合には、FEC OTIを導出するのに、ファイルの異なる部分に対して異なる値のWSを使うのが好ましい、いくつかの適用例がある。

異なる部分に対して異なる整列係数を使うのが有利である、適用例が存在し得る。たとえば、優先順位の高い部分は、4オクテットで整列されたメモリを有するローエンド受信機と、8オクテットで整列されたメモリを有するハイエンド受信機の両方によって復号されてよく、優先順位の低い部分は、ハイエンド受信機のみによって復号されてよい。この例では、ローエンド受信機がこれらの部分を効率的に復号できるように、優先順位の高い部分に対してはAl=4を使うのが有利であり得るが、優先順位の低い部分に対してはAl=8を使うのが有利であり得る。それは、ハイエンド受信機は、Al=4よりもAl=8で、優先順位の低い部分をより効率的に復号できるからである。

送信機のUFD-UEPの方法によって生成された、ファイルの部分iに固有の対応するFEC OTIは、F_i、T_i、Z_i、N_iを含み、Z_iは、ファイルの部分iの分割先のソースブロックの数であり、N_iは、ファイルの部分iの各ソースブロックの分割先のサブブロックの数である。したがって、ファイルのために送信機のUFD-UEPの方法が生成する全体のFEC OTIは、(d, Al, F₀, T₀, Z₀, N₀, F₁, T₁, Z₁, N₁, ..., F_d-1, T_d-1, Z_d-1, N_d-1)を含み得る。たとえば、dが一定であり、したがってFEC OTIで明示的に列挙される必要がない場合、または、ソースブロック構造と、使われる場合にはサブブロック構造とを示すために、他の方法が使われる場合には、FEC OTIの他のバージョンも利用可能である。

送信機は、UFD-UEPの方法を使って、パケット中で送信されるべきファイルの各部分のための1つの符号化シンボルを組み立て、パケットのFECペイロードIDは、UFSI値Cを含む。パケットが送信されるべきである場合、送信機は、図6のステップ610で示されるように、パケットのFECペイロードIDとして使われるべき、UFSI値Cを決定する。使われるべきUFSI値は、たとえば連続的であってよく、たとえばUFSI値0, 1, 2, 3, ...,などであってよい。図6のステップ620に示されるように、所与のUFSI値Cに対して、ファイルの部分iのためのパケット中の、パケットのi番目の部分に配置されるべきサイズT_iの符号化シンボルは、A_i=C modulo Z_i、およびB_i=floor(C/Z_i)として計算される、SBN A_iおよびESI B_iを有する。図6のステップ630、640、および650に示されるように、i=0, ..., d-1に対して、これらのd個の符号化シンボルが、パケットのd個の部分の各々について生成され、次いで、合計のサイズがTである、UFSI Cとこれらのd個の符号化シンボルとが一緒にパケット中で送信される。図6のステップ660で行われる判定で示されるように、送信機のUFD-UEPの方法は、符号化パケットの生成と送信を続ける。

受信機のUFD-UEPの方法が、図7を参照して説明される。図7のステップ700で示されるように、受信機は、既存の技法を使って、送信機について上で説明されたものと同じ形式で、FEC OTI (d, Al, F₀, T₀, Z₀, N₀, F₁, T₁, Z₁, N₁, ..., F_d-1, T_d-1, Z_d-1, N_d-1)を決定することができる。たとえば、FEC OTIは、FLUTEセッションの説明に組み込まれてよく、またはFEC OTIは、URLへと符号化されてよく、またはFEC OTIは、SDPメッセージを介して取得されてよい。ステップ710において、受信機は、さらなるパケットが受信されるかどうかを確認し、受信機が別のパケットを受信するまで(この場合、受信機はステップ730へ進む)、または、さらなるパケットが受信される予定はないと受信機が判定するまで(この場合、受信機はステップ720へ進む)、このステップに留まってよく、そして、ファイルの十分な部分が復元されたと判定して停止し、または、他の手段を使って、たとえば、ファイル修復サーバへのHTTP要求を使って、ファイルのさらなる部分を復元しようと試み、または受信機は、後でさらなるパケットを受信するための別のセッションを待機することができる。

別のパケットが利用可能である場合、ステップ730において、受信機は、受信されたパケットのUFSI Cを求め、各i=0, ..., d-1に対して、各i=0, ..., d-1のパケットからサイズT_iの符号化シンボルを抽出する。ステップ740において、各i=0, ..., d-1に対して、受信機は、ソースブロックの数Z_iおよびUFSI Cに基づいて、A_i=C modulo Z_i、およびB_i=floor(C/Z_i)を計算し、ステップ750において、受信機は、部分iの符号化シンボルの(SBN, ESI)を(A_i, B_i)に設定し、ステップ760において、受信機は、部分iの符号化シンボルの値と、ファイルの部分iを復元するために使われるべき(A_i, B_i)とを記憶する。ステップ770において、受信機は、各i=0, ..., d-1に対して、ファイルの部分iを復元するのに十分な符号化シンボルが受信されたかどうかを判定し、受信されている場合、ステップ780におけるファイルの部分iの復元に進み、受信されていない場合、ステップ710におけるさらなるパケットの受信に進む。

受信機のUFD-UEPの方法の、多くの変形形態がある。たとえば、送信機は、パケットの少なくとも一部で、ファイルの各部分のための2個以上の符号化シンボルを送信できるので、受信機はこれを受信することができ、この場合、FECペイロードIDは、パケットに含まれる各部分に対する第1の符号化シンボルに対応するUFSIに設定されてよく、パケット中の各部分に対する追加のシンボルは、連続的な対応するUFSI値を有し得る。たとえば、パケット中で搬送される、ファイルの各部分のための3個の符号化シンボルがあり、各部分のための第1のシンボルがUFSI=4234に対応する場合、各部分のための他の2個の符号化シンボルは、UFSI=4235および4235にそれぞれ対応してよく、パケット中で搬送されるUFSIは、UFSI=4234であり得る。

他の代替形態の例として、受信機は、復元を試みる前にどれだけの符号化シンボルを受信すべきかを事前に決定することができ、または、セッション中のパケット喪失の統計情報を計算し、これに基づいて、ファイルのどの部分の回復を試みるべきかを決定することができる。別の例として、受信機は、ファイルの各部分の復元に十分な符号化シンボルが受信されたかどうかを判定するのに使われるFEC符号に特有の、何らかの処理を行うことができる。別の例として、UFSIの値は、ファイルの各部分の復元処理において、(SBN, ESI)の値を生成する中間ステップなしで、直接使用されてよい。別の例として、ファイルの部分の復元は、符号化シンボルの受信と同時に行われてよい。

別の例として、他の形態のFEC OTI情報を使用することができる。たとえば、基本UFSI BU_Iが、他の部分とは独立に部分iのFEC OTIにおいて規定されてよく、BU_Iは次のように使われ得る。すなわち、パケットに含まれる部分iの符号化シンボルのために、FECの送信機および受信機によって使われるべきUFSIはU+BU_Iであり、Uは、符号化シンボルを搬送するパケット中で搬送されるUFSIである。したがって、たとえば、パケットがU=1,045を搬送し、部分iのFEC OTIの中の基本UFSIがBU_i=2,000,000である場合、符号化シンボルのUFSIは2,001,045である。

基本UFSIの使用には、いくつかの利点がある。たとえば、(後で述べられる理由により)異なる部分については修復シンボルのみが送信されるべきである場合、BU_i=KT_iに設定するのが有利である可能性があり、KT_iは部分iのファイルシンボルの数である。この場合、送信されるパケットシーケンスにおけるUFSIのシーケンスは、0、1、2、3などであってよいが、それでも、各部分については、その部分から生成された修復シンボルのみがパケット中で送信される。

この段落は、基本UFSIの使用の別の例示的な利点を説明する。[FLUTE]、[ALC]、[LCT]、[FEC BB]において説明されるプロトコルスイートは、TOIとも呼ばれる送信オブジェクト識別子を、転送されるべきファイルまたはオブジェクトのFEC OTIと関連付ける。同じ部分の符号化シンボルが、異なる時間に、または異なるセッションで送信され、異なるTOIと関連付けられ得ることが可能である。また、異なる各TOIと関連付けられるパケットについて、UFSI=0から始まる符号化パケットを送信できるのが有利である。各部分について独立に、FEC OTIの一部として基本UFSIを規定できることで、各部分の異なる基本UFSIを、ファイルのために符号化シンボルが送信される際の各TOIと関連付けることができ、異なるTOIに対して重複する符号化シンボルが送信されない。たとえば、同じ部分の符号化シンボルは、TOI=1と関連付けられTOI=2と関連付けられるパケットで送信されてよく、TOI=1と関連付けられる部分の基本UFSIは0に設定され、TOI=2と関連付けられる同じ部分の基本UFSIは1,000,000に設定される。そして、TOI=1とTOI=2の両方の符号化パケットは、UFSI 0、1、2などのシーケンスを含んでよく、TOI =1でその部分のために送信される符号化シンボルが1,000,000個より少ない限り、2つのTOIと関連付けられて送信される符号化シンボルの中に、その部分のための送信される重複する符号化シンボルはない。各部分に対して異なる基本UFSIを規定する代わりに、部分のすべてによって使われるべき基本UFSIをFEC OTIの中に有することも、有利であり得る。それは、これによって、FEC OTIを搬送するのに必要なオクテット数を低減でき、それと同時に、FEC OTIにおいて各部分に対して別個の基本UFSIを規定することの利点の多くを共有できるからであり、この方法とともに使われるFEC符号が、たとえばLuby Iで説明されるような情報追加型のFEC符号である場合には、すべての部分のためのUFSIの有効な範囲は非常に広くなり得るので、特に上記のことが当てはまる。

UFD-UEPの方法を、ソースブロックおよびサブブロックの構造を決定するための[RaptorQ-Spec]で説明された技法と組み合わせることで、多くの利点がもたらされる。具体的には、基本的なUFDの方法の利点のすべては、UFD-UEPの方法でも有効である。たとえば、ファイルのUEP部分の1つを送信するための、SBNとESIの組合せによって特定される、従来の方法ではソースシンボルと呼ばれていたものは、UFD-UEPの方法を使うと、UFSIによって特定されるその部分のためのファイルシンボルとして見なされ得る。KT_i=ceil(F_i/T_i)は、ファイルの部分iにおけるファイルシンボルの総数であることに留意されたい。ソースブロック構造およびサブブロック構造がたとえば、[RaptorQ-Spec]で説明されるようにファイルの各部分について決定され、上で説明されたUFD-UEPの方法を使って、ファイルの部分のためのシンボルの識別情報を(SBN, ESI)形式からUFSI形式へと変換する場合、ファイルシンボルのUFSIの範囲は0, 1, 2, ..., KT_iであり、ファイルから生成される任意の修復シンボルは、範囲KT_i+1、KT_i+2などの中にUFSIを有する。この特性は、シンボルがファイルの元の部分iの一部であるかどうか、またはファイルの部分iから生成された修復シンボルであるかどうかを、シンボルのUFSIをKT_iの値と単に比較することによって判定するのを可能にする。このことはたとえば、パケットのどの部分が元のファイルの一部を含むか(およびファイル内でのその部分の位置)、ならびにパケットのどの部分が、無視され得る修復シンボルを含むかを、パケット中で搬送されるUFSIの値とファイルの各部分iに対するT_iおよびKT_iの値とに基づいて、FEC復号をサポートしない受信機が判定できるようにするのに、有用であり得る。

図8はある例を示し、この場合ではファイルは2つの部分を含む。第1の部分は5個のソースブロックに分割され、これらのソースブロックの最初の3個は各々6個のソースシンボルを有し、残りの2個のソースブロックは各々5個のソースシンボルを有し、これらのシンボルの各々のサイズは、たとえば48オクテットなので、第1の部分のサイズは28×48=1,344オクテットである。第2の部分は4個のソースブロックに分割され、これらのソースブロックの最初の3個は各々4個のソースシンボルを有し、残りの1個のソースブロックは各々3個のソースシンボルを有し、これらのシンボルの各々のサイズは、たとえば256オクテットなので、第2の部分のサイズは256×48=3,840オクテットである。

図9は、図8に示されるファイル構造のための、可能なパケット化を示す。この例では、各パケットは、UFSI C、図6を参照して上で説明されたような、Cに基づく、図8で示されるファイル構造の第1の部分から生成されるサイズが48オクテットの第1の符号化シンボル、および、図6を参照して前に説明されたような、Cに基づく、図8で示されるファイル構造の第2の部分から生成されるサイズが256オクテットの第2の符号化シンボルを含む。パケットの保護されていない部分は、ファイルの対応する部分のソースシンボルを搬送し、保護されている部分は、ファイルの対応する部分から生成された修復シンボルを搬送する。この例では、ファイルの第1の部分を復元するのに必要なパケットの最小の数は28であり、一方ファイルの第2の部分を復元するのに必要なパケットの最小の数は15である。

図9は、UFSIが0, ..., 27である28個のパケットを示し、したがって、これらのパケットで搬送されるファイルの第1の部分の符号化シンボルのすべてが、ソースシンボルである。少なくとも28のUFSI値を有するように生成される任意の追加のパケットは、ファイルの第1の部分の修復シンボルを搬送する。

UFD-UEPの方法の別の利点は、符号化シンボルが、UFSIによって定義される順序で、すなわちUFSIの順序0, 1, 2, 3, 4, ...で送信される場合、ファイルの部分iのZ_i個のソースブロックの符号化シンボルは、交互の順序で送信され、すなわち、Z_i個のソースブロックの各々のうちのESI 0であるZ_i個の符号化シンボルが最初に送信され、続いて、Z_i個のソースブロックの各々のうちのESI 1であるZ_i個の符号化シンボルが送信される、などである。この特性は、各部分が独立のソースブロック構造を有する場合であっても、ファイルのすべての部分に対して当てはまる。大半の送信に対しては、この単純な送信順序で十分であり、それが好ましい。しかし、ソースブロックの数Z_iと同期し得る何らかの周期性がパケット喪失にある場合、より良い可能性のある送信順序は、Z個のUFSIが連続した符号化シンボルの各セットを、送信する前にランダムに順序を変えるというものであり、ここでZはすべてのi=0, ..., d-1に対するZ_iの最大値である。すなわち、UFSI 0, ..., Z-1である最初のZ個の符号化シンボルが、ランダムに変えられた順序で送信され、次いで、UFSI Z, ..., 2×Z-1である次のZ個の符号化シンボルが、ランダムに変えられた順序で送信される、などである。別の可能な送信順序は、送信されるべき符号化シンボルのすべてを、送信する前にランダムに順序を変えるというものである。

UFD-UEPの方法を使うことで、従来の方法、または従来の方法の単純な拡張に対して、多くのさらなる利点がもたらされる。たとえば、UFSIフィールドを含むFECペイロードIDフィールドを使ったUFD-UEPの方法では、ファイルの各部分のための可能な符号化シンボルの総数は、UFSIフィールドのサイズのみによって制限され、ファイルの各部分のソースブロック構造とは独立である。さらに、ファイルの各部分の完全に異なるソースブロック構造から生成されるシンボルの同時の識別を可能にする、汎用的で簡潔なFECペイロードIDが、UFSIフィールドの使用によって実現される。たとえば、32ビットのFECペイロードIDを生じる32ビットのUFSIを使う場合、ファイルのために生成され得る符号化シンボルの総数は4,294,967,296であり、これは、ファイルの各部分について、ファイルが何個のソースブロックへと分割されるかに無関係であり、サブブロックが使われる場合には、ファイルのサブブロック構造にも無関係である。したがって、ファイルの第1の部分のシンボルのサイズが256オクテットであり、ファイルの第2の部分のシンボルのサイズが1,024オクテットである場合、この例では、ファイルの第1の部分のサイズは1GBであり、ファイルの第2の部分のサイズは4GBであり、符号化シンボルの数は、ファイルの各部分のソースシンボルの数の1,024倍であってよく、これは、ファイルの各部分が1つのソースブロックに分割されるか、16,384個のソースブロックに分割されるか、または4,194,304個のソースブロックに分割されるかに無関係である。

UFD-UEPのファイル配信方法が単純なUEPファイル配信方法に対して実現する改善の例が、図11に示される。この例では、1MBのファイルが、32KBの第1の部分と992KBの第2の部分とに分割される。両方の方法において、[RaptorQ-Spec]で規定されるFEC符号が使われ、符号化シンボルを搬送するための各パケット内のサイズは1,024オクテットであり、全体で2,048個のパケットが送信される。

図11に示される単純UEPファイル配信方法の例では、ファイルの第1の部分およびファイルの第2の部分は、独立に処理および配信され、第1の部分と第2の部分の両方の場合において、サイズが1,024オクテットのちょうど1つの符号化シンボルが各パケット中で搬送される。ファイルの第1の部分のソースは32個のパケットで搬送され、符号化シンボルを含む全体で128個のパケットが送信される。ファイルの第2の部分のソースは992個のパケットで搬送され、符号化シンボルを含む全体で1920個のパケットが送信される。

図11に示されるUFD-UEPファイル配信方法の例では、ファイルの第1の部分およびファイルの第2の部分は、組み合わされて処理および配信される。すなわち、送信される各パケットは、2つの部分の各々について符号化シンボルを含み、第1の部分については符号化シンボルのサイズは64オクテットであり、第2の部分については符号化シンボルのサイズは960オクテットである。ファイルの第1の部分のソースは512個のパケットで搬送され、すべての2,048個のパケットが第1の部分の符号化シンボルを含む。ファイルの第2の部分のソースは1,059個のパケットで搬送され(ソースの最後のパケット中の符号化シンボル、992オクテットのフルシンボルサイズまで0でパディングされた第2の部分の符号化シンボル)、すべての2,048個のパケットが第2の部分の符号化シンボルを含む。

図11で見られるように、単純UEPファイル配信方法とUFD-UEPファイル配信方法の復元性能は、ファイルの第2の部分については、パケット喪失率の関数として実質的に同一である。すなわち、両方の場合において、ファイルの第2の部分は、最大で48%に達するパケット喪失率まで、かなり安定して復元される。一方、ファイルの第1の部分に対しては、UFD-UEPファイル配信方法の復元性能は、単純UEPファイル配信方法の復元性能を大きく上回る。単純UEPファイル配信方法は、パケット喪失率が65%未満である場合に、ファイルの第1の部分を安定して復元できるが、UFD-UEPファイル配信方法は、パケット喪失率が75%に達しても、ファイルの第1の部分を安定して復元できる。

一括ファイル配信サービスのための汎用ファイル配信方法およびシステム
大半の従来のファイル配信方法は、一括ファイル配信、すなわち、単一の一括ファイルとしての複数のファイルの配信をサポートしない。いくつかのファイルを配信する単純な方法は、各ファイルを独立に配信することである。しかし、この単純な方法にはいくつかの欠点がある。たとえば、ファイルが小さい場合に、実現される保護が理想から離れたものになる。それは、各ファイルの符号化シンボルを含むパケットの数が少ない場合に、パケット喪失の統計値に大きな変動が存在し得るからである。

図12は、この問題を例示する。図12では、32KBのファイル配信の信頼性が、配信中のネットワークにおけるパケット喪失の百分率の関数として示されている。このファイル配信の例では、シンボルはサイズが1,024であり、ファイルの32個のソースシンボルが、[RaptorQ-Spec]で規定されるFEC符号を使って64個の符号化シンボルへと符号化され、各符号化シンボルは別個のパケットで送信される。図12で見られるように、上記の変動によって、ファイルの信頼性のある配信を実現できる喪失率は、50%よりもはるかに低い。

さらに、多くの小さなファイルが独立に符号化されて送信される場合、すべてのファイルが信頼性をもって受信されるパケット喪失率は、さらに低い。図12は、各々が32KBのサイズである、32個のファイルの配信についてのこの現象を示し、各ファイルの符号化および送信は、前の段落で説明されたパラメータと同じパラメータを使って、他のファイルとは独立に実行される。理解され得るように、すべての32個のファイルの配信は、パケット喪失が、50%よりもはるかに低い25%前後よりも低い場合にのみ、信頼性をもって実現できる。

UFD-UEPファイル配信方法は、以下のように拡張されて、UFD一括ファイル配信方法を提供することができる。UFD一括ファイル配信方法は、UFD-UEPファイル配信方法と同じ方法を使うことができるが、同じファイルのd個の部分の配信をシグナリングする代わりに、各部分が別々のファイルであり、d個のファイルが一括して配信されていることをシグナリングする。送信機が、それぞれサイズがF₀, F₁, ..., F_d-1であるd個のファイルの一括配信を行うのを望んでいるとする。送信機のUFD一括方法は、パケットサイズTを、サイズがT₀, T₁, ..., T_d-1であるd個の部分に分割するので、Tは、T_iのiにわたる合計に等しい。Tのこの分割は、F₀, F₁, ..., F_d-1と、対応するファイルの優先順位とに基づく。

比F_i/T_iは、1つのソースブロックとしてのファイルの部分iを保護するために理想的なFEC符号が使われると仮定して、ファイルiを復元するためにどれだけのパケットを受信する必要があるかを判定するので、比F_i/T_iが小さいほど、ファイルの部分iの優先順位は高い。実際には、たとえば、FEC符号は完璧ではなく何らかの受信オーバーヘッドを示すので、または、ファイルのその部分が複数のソースブロックに分割され、一部のソースブロックの符号化シンボルが他のソースブロックの符号化シンボルよりも高い比率で失われるので、または、F_i/T_iが整数ではないので、F_i/T_iよりもわずかに多くのパケットが、ファイルの部分iを復元するために必要であり得る。配信されるすべてのファイルの優先順位が同一であることが望ましい場合、F_i/T_i≒F/TとなるようにT_iが設定される。UFD一括ファイル配信方法の多くの詳細情報は、送信機と受信機の両方について、UFD-UEPファイル配信方法とほとんど同一なので省略する。

UFD一括ファイル配信方法は、一括ファイル配信とUEPファイル配信の両方を同時に実現するように拡張することができ、すなわち、束の中の各ファイルの優先順位は異なるように設定され得る。さらに、UFD一括ファイル配信方法は、複数のファイルの優先順位付けられた配信と、ファイルの部分の優先順位付けられた配信との、両方の配信を、適切なシグナリングによってサポートすることができる。たとえば、UFD一括ファイル配信方法を使って、3個のオブジェクトが符号化され送信されることになる場合、最初の2個のオブジェクトは、異なる優先順位を有する同じファイルの異なる部分であってよく、3番目のオブジェクトは、さらに異なる優先順位を有する異なるファイルであってよい。受信機は、多くの要因に基づいて、一括ファイルおよび/またはファイルの部分のいずれの復元に受信機が関心があるかを決定し、他のファイルまたはファイルの部分とは独立に、そうしたファイルまたはファイルの部分のみを復元することができる。当業者が認識するように、本開示を読むと、UFD一括ファイル配信方法の多くの可能な代替的なバージョンがある。

UFD一括ファイル配信の単純な例として、各ファイルのサイズが32KBの、32個のファイルの束が配信されるべきであり、各ファイルの優先順位が同じであるとする。T=1,024オクテットであるとする。この場合、各i=0, ..., 31について、T_iの値は32オクテットである。各パケットは、32個のファイルの各々のための32オクテットの符号化シンボルと、パケット中で32個の符号化シンボルを特定するUFSIとを含む。この例では、32個のサイズが等しいファイルの各々からのソースシンボルを含む、1,024個のパケットがあり、これらのパケットは、0から1,023の範囲のUFSIを有するパケットである。この例では、1,024個の追加の修復シンボルが、各ファイルについて生成され、1,024から2,047の範囲のUFSIを有する追加の1,024個のパケット中で送信されるものとする。

図12は、パケット喪失の関数として、このUFD一括ファイル配信の例の復元特性を示す。この例では、50%に達するパケット喪失率において、32個のファイルすべてを、UFD一括ファイル配信方法を使って信頼性をもって復元することができ、これは、各ファイルを別々に符号化して送信した場合に32個のファイルすべての信頼性のある配信が可能になる約25%のパケット喪失率に対して、かなり改善されている。

ユニキャスト修復要求のネイティブなHTTPサポートのための方法
ファイルまたはファイルの部分は、受信機によるファイルまたはファイルの部分へのアクセス権を記憶および提供するために標準的なHTTPウェブキャッシュサーバによって使われ得る関連するURLを有する、「HTTPファイル」へと編成されてよく、またはHTTPファイルとして利用可能にされてよい。HTTPファイルとして利用可能にされる、その元の順序のファイルまたはファイルの部分は、本明細書では「元順序HTTPファイル」と呼ばれる。一般に、ユニキャスト修復要求のネイティブなHTTPサポートのための方法は、SBNおよびESIに基づいて、HTTPファイルのソースブロックのシンボルおよびサブシンボルの修復要求を、HTTPファイル内の標準的なHTTPオクテット範囲要求(規定されたバイト範囲を有するHTTP部分獲得要求と呼ばれることが多い)へと変換することができる。これによって、標準的なHTTPウェブキャッシュサーバが、これらの修復要求をサービスできるようになり、HTTPファイルがソースブロックおよびソースブロック内のソースシンボルへとどのように分割されるかを理解する、専用のHTTPウェブキャッシュサーバを大量に配備する必要がなくなる。

そのような状況では、システマチックなFEC符号が使用中である場合、セッションの一部、たとえばブロードキャスト/マルチキャストセッションにおいて、修復シンボルのみを送信するのが有利であることが多い。それは、受信機が、ユニキャスト修復要求においてソースシンボルのみを要求できるようになるからである。このことには、HTTPファイル、または、以下でさらに詳細に説明されるようなHTTPファイルの単純な順序変更の変換しか、標準的なHTTPウェブキャッシュサーバであってよいユニキャスト修復サーバに提供しなくてもよいという利点があり、HTTPファイルの定義およびHTTPファイルの配信の管理が、FEC符号化と独立なのでより簡単になる。別の利点は、セッションにおいてソースシンボルが送信されない場合、ソースシンボルのすべてが「欠けている」ので、受信機がユニキャスト修復要求においてソースシンボルの任意のシーケンスを要求できるということであり、このことは、ソースシンボルの連続的なシーケンスに対する修復要求を可能にするので好ましいことがある。たとえば、完全な復元特性を有するFEC符号が使われ、ある部分のソースブロックが1,000個のソースシンボルを含み、700個の修復シンボルがソースブロックのために受信される(修復シンボルの一部は送信中に失われ得るので、受信された修復シンボルのESIのパターンは決して連続的ではないことがあるとしても)ものとする。次いで、受信機は、ユニキャスト修復要求において、ソースブロックの最初の300個の連続するソースシンボルを要求し、これらのソースシンボルを700個の修復シンボルと組み合わせてソースブロックを復元することができる。ソースシンボルがHTTPファイル中で連続的である場合、単一のHTTPオクテット範囲要求を使って、300個の連続するソースシンボルのすべてを要求して受信することができる。受信機は、プレフィックス要求(すなわち、最初のバイトから始まるファイルのバイトのセット数の要求)を必ずしも行う必要はないが、一部の場合には、それを行うのがよりシンプルである。

この要求は、特定の数のバイトまたはシンボルに対するものである。一部の場合には、受信機は、受信された修復シンボルの数と、受信されることになるファイルまたはオブジェクトの中に含まれると予想されるソースシンボルの数とに基づいて、要求すべきソースシンボルの数を決定する。他の場合には、受信機は、スケジューリング動作を実行してもよく、このとき受信機は、すでに受信した修復シンボルのみを使ってどのように復号するかを決定するので、必要なソースシンボルのより具体的な数を知ることができる。たとえば、修復シンボルの一部が他の修復シンボルの冗長部分であることがあり、この場合、より多くのソースシンボルが必要であり得る。他の場合には、必要なソースシンボルはより少数であると判明することがある。

受信機は、FEC OTIに基づいて、特定の(SBN, ESI)ペアに対応する元順序HTTPファイルのソースシンボルに対する要求を、HTTPオクテット範囲要求へと変換することができる。たとえば、ファイルのFEC OTIが(F, Al, T, Z, N)であり、要求されることになるソースシンボルのSBNがAであり、ソースシンボルのESIがBであるものとし、簡単にするために、N=1、すなわち、ソースブロックがこの例ではファイル構造のサブブロックへとさらに分割はされないものとする。次いで、受信機は、[RaptorQ-Spec]のセクション4.4で説明された方法をたとえば適用して、(KL, KS, ZL, ZS)を決定することができ、ここで最初のZL個のソースブロックはKL個のソースシンボルを有し、残りのZS個のソースブロックはKS個のソースシンボルを有する。次いで、A、B、およびシンボルサイズTに基づいて、受信機は、ファイル内のソースシンボルの開始オクテットインデックスが式1に示される通りであると決定することができ、ファイル内のソースシンボルの終了オクテットインデックスは、EI=SI+ Tである。そして、受信機は、ソースシンボルに対して標準的なHTTPオクテット範囲要求を使うことができる。
SI=T×(KL×min{A, ZL}+KS×max{A-ZL, 0}+B) (式1)

当業者が認識するように、これらの方法に対する多くの拡張および改善がある。たとえば、サブブロックが使われない場合には、複数の連続するソースシンボルが元順序HTTPファイルから要求されれば、単一のHTTPオクテット範囲要求が行われ得る。別の例として、HTTPウェブキャッシュサーバは、元順序HTTPファイルに加えて、またはその代わりに、修復シンボルを含むファイルを有してよく、または、元順序HTTPファイルはすでに、修復シンボルを含むように拡張されていてよく、受信機は、本明細書で説明された方法と同様の方法を使って、修復シンボルに対するHTTPオクテット範囲要求を行うことができる。改善の別の例として、これらの方法は、当業者が認識するような方法と同様の方法を使って、サブブロックが使われる場合を扱うように拡張され得る。たとえば、受信機は、[RaptorQ-Spec]のセクション4.4で説明された方法を使って(TL, TS, NL, NS)を決定することができ、このときソースブロックの最初のNL個のサブブロックのサイズはTL×Alであり、ソースブロックの残りのNS個のサブブロックのサイズはTS×Alである。そして、A、B、およびシンボルサイズTに基づいて、受信機は、ソースシンボルに対応するファイル内のN個のサブシンボルの開始オクテットインデックスおよび終了オクテットインデックスを決定し、標準的なHTTPオクテット範囲要求を使ってこれらのオクテットに対する要求を行うことができる。

別の例として、受信機は、FEC OTIに基づいて、特定のUFSIに対応するファイルまたはファイルの部分のソースシンボル対する要求を、HTTPオクテット範囲要求へと変換することができる。

以下の方法は、受信機による標準的なHTTPバイト範囲要求を使ってHTTPファイルのシンボルを復元する際の効率を大幅に改善することができ、それと同時に、標準的なHTTPウェブキャッシュサーバを使って、要求されたオクテット範囲要求を受信機に配信する。

説明されるようなHTTPオクテット範囲要求をサポートするための単純な方法は、元順序HTTPファイルを使うことである。この方法には、HTTPウェブキャッシュサーバのための元順序HTTPファイルを生成するのに、元のファイルまたはファイルの部分の変換が必要ないという利点があるが、各ソースブロックに対して連続的なソースシンボルのみが要求される場合であっても、ソースシンボルを要求するために多くの異なるHTTPオクテット範囲要求が必要になり得るという、欠点がある。これには、少なくとも2つの理由がある。すなわち、(1)複数のソースブロックと、各ソースブロックにおいて欠けているソースシンボルが存在することがあり、その場合、各ソースブロックに対して別々のオクテット範囲要求が必要になり得る。(2)ソースブロック当たり複数のサブブロックが存在することがあり、ソースシンボルのためのサブシンボルが元順序HTTPファイルに置いて連続的ではないことがあるので、1つのソースブロックから単一のソースシンボルを要求するのにも、ソースシンボルを含む複数のサブシンボルに対する、複数のHTTPオクテット範囲要求が必要になり得る。

上で説明されたHTTPオクテット範囲要求をサポートするための有利な方法はまず、元のファイルまたはファイルの部分のFEC OTIに基づいて、本明細書では「UFSI順序HTTPファイル」と呼ばれる新しい形式へと、ファイルまたはファイルの一部を再編成する。この方法は、複数のソースブロックがある場合、および/またはソースブロック当たり複数のサブブロックがある場合に有用である。UFSI順序HTTPファイルの中のデータの順序は、UFSI 0のファイルシンボル、UFSI 1のファイルシンボル、UFSI 2のファイルシンボル、などの順序であり、すなわち、UFSI順序HTTPファイルの中のデータの順序は、FEC OTIによって決定されるような、連続的なUFSIの昇順に従って並べられたファイルシンボルへと編成される。URLは、UFSI順序HTTPファイルと関連付けられてよく、URLは、HTTPウェブキャッシュシステムへと与えられ得る。次いで受信機は、HTTPオクテット範囲要求を使って、必要に応じてUFSI順序HTTPファイルの部分を要求することができる。UFSI順序HTTPファイルの1つの利点は、受信機がソースブロックの各々からほぼ同じ数の修復シンボルを受信した場合に、元のファイルまたはファイルの部分を復元するのに十分なソースシンボルを取得するのに必要とされる、HTTPオクテット範囲要求の数を最小限にできるということであり、たとえば、各ソースブロックに対して全く同じ数の修復シンボルが受信される場合には、1つのHTTPオクテット範囲要求で十分であり得る。たとえば、元のファイルまたはファイルの部分のZ個のソースブロックの各々から、サイズTの最初のL個のソースシンボルを受信するには、UFSI順序HTTPファイルの最初のL×T×Z個の連続的なオクテットに対する要求で十分である。K-L個の修復シンボルが、Z個のソースシンボルの各々の1つまたは複数のセッションにおいて受信される場合、かつ、FEC符号が理想的な復元特性を有する場合、HTTPファイルをFEC復号するには、HTTPオクテット範囲要求から受信されるL×T×Z個のオクテットで十分であり、この例では、Z個のソースブロックの各々の中にあるソースシンボルの数はKであると仮定される。

上で説明されたHTTPオクテット範囲要求をサポートするための別の有利な方法はまず、元のファイルまたはファイルの部分のFEC OTIに基づいて、本明細書では「SS順序HTTPファイル」と呼ばれる異なる新しい形式へと、ファイルまたはファイルの一部を再編成する。この方法は、ソースブロック当たり複数のサブブロックがある場合に有用である。なぜなら、この場合、各ソースシンボルは、元のファイルまたはファイルの部分の連続的な部分ではないことがあり、すなわち、ソースシンボルのサブシンボルが、元のファイルの順序ではソースブロック全体に分散し得るからである。SS順序HTTPファイルの中のデータの順序は、最初のソースブロックのすべてのソースシンボル、続いて2番目のソースブロックのすべてのソースシンボル、続いて3番目のソースブロックのすべてのソースシンボル、などという順序であり、すなわち、SS順序HTTPファイルの中のデータの順序は、FEC OTIによって決定されるように、ソースブロック内の連続的なESIの昇順に従って並べられたソースシンボルへと編成され、連続的なSBNの昇順の順序でのソースブロックの連結である。URLは、SS順序HTTPファイルと関連付けられてよく、URLは、HTTPウェブキャッシュシステムへと与えられ得る。次いで受信機は、HTTPオクテット範囲要求を使って、必要に応じてSS順序HTTPファイルの部分を要求することができる。受信機が、ソースブロックの各々から異なる数の修復シンボルを受信する場合には、SS順序HTTPファイルは特に有利である。たとえば、各々1,000個のソースシンボルを有する2つのソースブロックがあり、受信機が、1つまたは複数のセッションから、第1のソースブロックのために900個の修復シンボルを受信し、第2のソースブロックのために100個の修復シンボルを受信する場合、受信機は、SS順序HTTPファイルの最初のT×100オクテットに対する1つの要求を行い、第1のソースブロックのための100個のソースシンボルを受信することができ、受信機は、SS順序HTTPファイルのオクテットT×1,000+1からT×1900に対する別の要求を行い、第2のソースブロックのための900個のソースシンボルを受信することができ、この例では、Tは両方のソースブロックのオクテット単位でのシンボルサイズである。

上で説明された方法の両方の組合せも使われてよく、すなわち、UFSI順序HTTPファイルとSS順序HTTPファイルの両方が、異なるURLを通じて受信機に対して利用可能にされてよく、受信機は、2つの異なる形式のHTTPファイルに対して、HTTPオクテット要求の組合せを使ってよい。たとえば、各々1,000個のソースシンボルを有する10個のソースブロックがある場合、かつ、1つまたは複数のセッションにおいて、最初の8個のソースブロックの各々のために800個の修復シンボルが受信され、9番目のソースブロックのために820個の修復シンボルが受信され、10番目のソースブロックのために500個の修復シンボルが受信される場合、受信機は、UFSI順序HTTPファイルに対するHTTPオクテット範囲要求を行い、10個のソースブロックの各々のために200個のソースシンボルを受信でき、SS順序HTTPファイルに対する追加のHTTPオクテット範囲要求を行い、10番目のソースブロックのための追加の300個のソースシンボルを受信できる。この例では、受信機は、9番目のソースブロックのために不必要な20個のソースシンボルを受信し得るが(FEC符号が理想的な復元特性を有すると仮定して)、一部の場合には、より少数のHTTPオクテット範囲要求を使って、いくつかのソースブロックのために必要最小限よりも多くのオクテットを要求することは、はるかに多数の異なるHTTPオクテット範囲要求が必要になり得る、各ソースブロックのためにちょうど必要な数のソースシンボルを要求することよりも、効率的であり得る。

当業者が認識するように、これらの方法に対する多くの変形形態がある。たとえば、HTTPファイル、UFSI順序HTTPファイル、およびSS順序HTTPファイルが、要求に対して利用可能にされ得る。別の例として、SS順序HTTPファイルは、分割されて多数のHTTPファイルとして利用可能にされてよく、そのようなHTTPファイルの1つが、各ソースブロックのためのものである。変形形態の他の例として、HTTPに基づくもの以外の方法およびプロトコル、たとえば、RTP/UDP、またはUDPの上層に構築されたプロプライエタリプロトコルに基づく方法が用いられてよい。

ハードウェアシステムおよび例
上で説明された方法およびシステムは、ハードウェア、ソフトウェア、および/または、プログラムコードもしくは他の命令を格納する適切に体系化されたコンピュータ可読媒体として、実装され得る。上記の教示を使い得るシステムのいくつかの例が、本明細書で与えられる。

図13は、パケットを送信するのに使われ得るような多段階の符号化を使う、本明細書で説明されたようなファイル配信システムの一部としての、通信システム1300のブロック図である。当然、他の符号および/またはハードウェアが、代わりに使われてよい。

通信システム1300において、入力ファイル1301、または入力ストリーム1305が、入力シンボル生成器1310に与えられる。入力シンボル生成器1310は、入力ファイルまたは入力ストリームから、1つまたは複数の入力シンボル(IS(0),IS(1),IS(2), ...)のシーケンスを生成し、各入力シンボルは、値および位置を有する(括弧中の整数として図13では示される)。上で説明されたように、入力シンボルの可能な値、すなわちそのアルファベットは、通常は2^M個のシンボルのアルファベットなので、各入力シンボルは、入力ファイルのMビットを符号化する。Mの値は一般に、通信システム1300を使って決定されるが、汎用システムは、Mが使用ごとに変化し得るように、入力シンボル生成器1310に対するシンボルサイズ入力を含み得る。入力シンボル生成器1310の出力は、エンコーダ1315に与えられる。

静的鍵生成器1330は、静的鍵S₀, S₁, ...のストリームを生成する。生成される静的鍵の数は一般に限られており、エンコーダ1315の具体的な実施形態に依存する。静的鍵の生成は、後でより詳細に説明される。動的鍵生成器1320は、エンコーダ1315によって生成されることになる各出力シンボルのための、動的鍵を生成する。各動的鍵は、同じ入力ファイルに対する動的鍵の大部分が一意になるように生成される。たとえば、Luby Iは、使用され得る鍵生成器の実施形態を説明する。動的鍵生成器1320および静的鍵生成器1330の出力は、エンコーダ1315に与えられる。

動的鍵生成器1320によって与えられる各鍵Iから、エンコーダ1315は、入力シンボル生成器によって与えられる入力シンボルから、値B(I)を有する出力シンボルを生成する。エンコーダ1315の動作は、以下でより詳細に説明される。各出力シンボルの値は、各出力シンボルの鍵に基づいて、入力シンボルの1つまたは複数と、場合によっては入力シンボルから計算された1つまたは複数の冗長シンボルとの何らかの関数によって生成される。特定の出力シンボルを生じさせる入力シンボルおよび冗長シンボルの収集は、本明細書では、出力シンボルの「関連するシンボル」または単に出力シンボルの「関連物」と呼ばれる。関数(「値関数」)および関連物の選択は、以下でより詳細に説明される処理に従って行われる。常時ではないが通常、Mは、入力シンボルと出力シンボルに対して同一であり、すなわち、入力シンボルと出力シンボルの両方が、同じ数のビットを符号化する。

いくつかの実施形態では、関連物を選択するために、入力シンボルの数Kがエンコーダ1315によって使われる。Kが事前に知られていない場合、たとえば入力がストリーミングファイルである場合、Kは単に推定値であってよい。値Kはまた、入力シンボルおよびエンコーダ1315によって生成される任意の中間シンボルのための記憶領域を割り当てるために、エンコーダ1315によって使われ得る。

エンコーダ1315は、出力シンボルを送信モジュール1340に与える。送信モジュール1340はまた、動的鍵生成器1320から、そのような出力シンボルの各々の鍵を与えられる。送信モジュール1340は出力シンボルを送信し、使われる変調方法に応じて、送信モジュール1340はまた、送信される出力シンボルの鍵についての何らかのデータを、チャネル1345を通じて受信モジュール1350に送信し得る。チャネル1345は消失通信路であると想定されるが、これは通信システム1300の適切な動作の要件ではない。

送信モジュール1340が、出力シンボルおよびその鍵についての任意の必要なデータをチャネル1345へ送信するようになされ、受信モジュール1350が、シンボルおよび場合によってはその鍵についての何らかのデータをチャネル1345から受信するようになされる限り、モジュール1340、1345、および1350は、任意の適切なハードウェアコンポーネント、ソフトウェアコンポーネント、物理媒体、またはこれらの任意の組合せであってよい。Kの値は、関連物を決定するために使われる場合、チャネル1345を通じて送信されてよく、または、エンコーダ1315とデコーダ1355との合意によって前もって設定されてもよい。図13(および本明細書の他の箇所)に示される他の要素も、モジュール、ステップ、処理などとして説明されるかどうかに関わらず、ハードウェア、ソフトウェア、および/または電気的な可読媒体に記憶されたプログラムコードを用いて、実装され得る。

上で説明されたように、チャネル1345は、リアルタイムのチャネル、たとえば、テレビジョン送信機からテレビジョン受信機への、インターネットもしくはブロードキャストリンクを通じた経路、または、ある点から別の点への電話接続であってよく、またはチャネル1345は、CD-ROM、ディスクドライブ、ウェブサイトなどのような、記憶チャネルであってよい。チャネル1345は、リアルタイムチャネルと記憶チャネルの組合せ、たとえば、ある人物がパーソナルコンピュータからインターネットサービスプロバイダ(ISP)へと電話線を通じて入力ファイルを送信するときに形成されるチャネルであってもよく、入力ファイルはWebサーバに記憶され、その後インターネットを通じて受信者に送信される。

チャネル1345は消失通信路であると想定されるので、通信システム1300は、受信モジュール1350から出た出力シンボルと、送信モジュール1340へと入る出力シンボルとの間に、1対1の対応を想定しない。実際には、チャネル1345がパケットネットワークを含む場合、通信システム1300は、任意の2つ以上のパケットの相対的な順序が、チャネル1345を通じた送信において保存されると、想定できないこともある。したがって、出力シンボルの鍵は、上で説明された鍵方式の1つまたは複数を使って決定され、出力シンボルが受信モジュール1350から出る際の順序によって決まるとは限らない。

受信モジュール1350は、出力シンボルをデコーダ1355に与え、これらの出力シンボルの鍵について受信モジュール1350が受信する任意のデータは、動的鍵生成器1360に与えられる。動的鍵生成器1360は、受信された出力シンボルのために動的鍵を再生成し、これらの動的鍵をデコーダ1355に与える。静的鍵生成器1363は、静的鍵S₀, S₁, ...を生成し、デコーダ1355に与える。静的鍵生成器は、符号化処理と復号処理の両方において使われる、乱数生成器1335へのアクセス権を有する。このアクセス権は、乱数がそのようなデバイスで生成される場合には、同じ物理デバイスへのアクセス権の形態であってよく、または、理想的な挙動を実現するための乱数の生成のための同じアルゴリズムに対するアクセス権の形態であってよい。デコーダ1355は、動的鍵生成器1360および静的鍵生成器1363によって与えられる鍵を対応する出力シンボルとともに使い、入力シンボル(やはりIS(0),IS(1),IS(2), ...)を復元する。デコーダ1355は、復元された入力シンボルを入力ファイル再組立器1365に与え、入力ファイル再組立器1365は、入力ファイル1301または入力ストリーム1305のコピー1370を生成する。

ファイル配信は、複数の受信機および/または複数の送信機によって行われ得る。これらの考え方は、図14〜図15に示されている。

図14は、1つの受信機2402が、3つの送信機2404(「A」、「B」、および「C」と個別に示されている)から3つのチャネル2406を通じて、データを受信する構成を示す。この構成を使って、受信機が利用可能な帯域幅を3倍にすることができ、または、任意の1つの送信機から全体のファイルを取得するのに十分広い帯域幅が利用可能ではない送信機を扱うことができる。示されるように、各送信機2404は、値のストリームS()を送信する。各々のS()の値は、出力シンボルB(I)および鍵Iを表し、これらの使用は上で説明されている。たとえば、値S(A, n_A)は、送信機2402(A)において生成される出力シンボルのシーケンスにおける、「n_A」番目の出力シンボルおよび「n_A」番目の鍵である。送信機の作業が重複しないように、1つの送信機からの鍵のシーケンスは、好ましくは、他の送信機からの鍵のシーケンスとは別物である。このことは、シーケンスS()が送信機の関数であるという事実によって、図14において示されている。

送信機2402は、作業が重複しないように、同期または協調されなくてもよいことに留意されたい。実際には、協調することなく、各送信機は、そのシーケンス中で異なる位置にある可能性が高い(すなわち、n_A≠n_B≠n_C)。

図15では、1つの入力ファイル2502のコピーが、複数の送信機2504(このうちの2つが図で示されている)に与えられる。送信機2504は、入力ファイル2502のコンテンツから生成された出力シンボルを、チャネル2506を通じて受信機2508へと独立に送信する。示されている2つの送信機の各送信機は、受信機のデコーダが入力ファイル全体を復元できるまでに、(K+A)/2個の出力シンボルしか送信する必要がなくてよい。

2つの受信機および2つの送信機を使うと、受信機ユニット2510によって受信される情報の総量は、1つのチャネル2506を通じて入手可能な情報の4倍であり得る。情報の量は、たとえば、送信機が同じデータを両方の受信機にブロードキャストする場合には、単一のチャネル情報の4倍よりも少なくなり得る。その場合、データがいずれかのチャネルで失われると、受信機ユニット2510における情報の量は、少なくとも2倍であり、それより多くなることが多い。送信機が1つの信号しかブロードキャストしない場合でも、受信機が異なる時間において送信の範囲にあれば、各送信機を聴取する受信機が2つ以上あることが有利であることに留意されたい。図15では、受信機ユニット2510は、図1に示される、受信機150、デコーダ155、鍵生成器160、および入力ファイル再組立器165の機能と同様の機能を実行する。

いくつかの実施形態では、入力ファイル2502は、コンピューティングデバイスが一方の送信機に対する1つの出力および他方の送信機に対する別の出力を提供できるように、2つのエンコーダを有する1つのコンピューティングデバイスにおいて符号化される。これらの例の他の変形形態は、本開示を検討することで明らかであろう。

本明細書で説明される符号化の装置および方法は、他の通信状況においても使われてよく、インターネットのような通信ネットワークには限定されないことを理解されたい。たとえば、コンパクトディスク技術も、消失符号およびエラー訂正符号を使って、傷のついたディスクの問題に対処し、ディスク上に情報を記憶する際に、連鎖反応符号を使用することで利益を受ける。別の例として、衛星システムは、送信のための出力要件を犠牲にするために消失符号を使って、出力を下げることによってより多くのエラーを意図的に許容することがあり、この用途においては連鎖反応符号化が有用である。また、消失符号は、情報の記憶の信頼性のための、RAID(redundant arrays of independent disks)システムの開発に使われてきた。したがって、本発明は、喪失またはエラーが多い可能性のあるデータについての問題に対処するために符号が使われる、上の例のような他の用途で有用であることがわかり得る。

いくつかの好ましい実施形態では、上で説明された通信処理を実行するための命令(またはソフトウェア)のセットが、喪失が多い可能性のある通信媒体を通じて通信する、2つ以上の多目的コンピューティングマシンへ与えられる。マシンの数は、1つの送信機および1つの受信機から、任意の数の送信および/または受信するマシンにまで、わたり得る。マシンを接続する通信媒体は、有線媒体、光学媒体、ワイヤレス媒体などであってよい。上述の通信システムには多くの使用法があり、それらはこの説明から明らかであろう。

HTTPストリーミングサーバを用いたブロック要求ストリーミングシステムが、上で説明されたようにファイルを配信し得る。以下では、そのようなシステムの例示的な実装形態が説明される。HTTPストリーミングでは、ソースは、標準的なウェブサーバおよびコンテンツ配信ネットワーク(CDN)であってよく、標準的なHTTPを使用してよい。

クライアント側では、クライアントによってシームレスに一緒につなぎ合わされた個々のセグメントに対して、HTTPを使って要求が行われ得る。HTTPストリーミングの利点には、標準的な既存のインフラを使用することがある。

図16は、ファイルを配信し得るブロック要求ストリーミングシステムの簡略図を示す。図16では、取込システム103を含むブロックサービングインフラストラクチャ(「BSI」)101を含むブロックストリーミングシステム100が示されており、取込システム103は、コンテンツ102を取り込み、取込システム103とHTTPストリーミングサーバ104の両方へアクセス可能なコンテンツ記憶装置110へとそのコンテンツを記憶することによって、HTTPストリーミングサーバ104によるサービスのためにそのコンテンツを準備してパッケージングするためのものである。示されるように、システム100は、HTTPキャッシュ106も含み得る。動作において、HTTPストリーミングクライアントのようなクライアント108は、要求112をHTTPストリーミングサーバ104へ送信し、HTTPストリーミングサーバ104またはHTTPキャッシュ106から応答114を受信する。各場合において、図16に示される要素は、少なくとも一部は、プロセッサまたは他の電子回路で実行されるプログラムコードを含むソフトウェアで実装されてよい。

図17で示されるように、メディアブロックは、たとえば、HTTPサーバ、コンテンツ配信ネットワークデバイス、HTTPプロキシ、FTPプロキシもしくはサーバ、または何らかの他のメディアサーバもしくはシステムであってよい、ブロックサービングインフラストラクチャ101(1)内に記憶されてよい。ブロックサービングインフラストラクチャ101(1)は、たとえば、インターネットのようなインターネットプロトコル(「IP」)ネットワークであってよい、ネットワーク122に接続される。ブロック要求ストリーミングシステムクライアントは、6個の機能的コンポーネント、すなわち、上で説明されたメタデータを与えられ、メタデータによって示される複数の利用可能なブロックの中から要求されるべきブロックまたは部分ブロックを選択する機能を実行する、ブロック選択器123、ブロック選択器123から要求命令を受信し、規定されたブロック、ブロックの部分、または複数のブロックに対する要求を、ネットワーク122を通じてブロックサービングインフラストラクチャ101(1)へ送信し、返答としてそのブロックを含むデータを受信するのに必要な動作を実行する、ブロック要求器124、さらには、ブロックバッファ125、バッファモニタ126、メディアデコーダ127、およびメディアの利用を容易にする1つまたは複数のメディアトランスデューサ128を、有するものとして示されている。

ブロック要求器124によって受信されるブロックデータは、一時的な記憶のために、メディアデータを記憶するブロックバッファ125へと渡される。あるいは、受信されたブロックデータは、図16に示されるように、ブロックバッファ125へと直接記憶されてもよい。メディアデコーダ127は、ブロックバッファ125によってメディアデータを与えられ、メディアトランスデューサ128へ適切な入力を与えるために必要な変換を、このデータに対して実行し、メディアトランスデューサ128は、メディアをユーザの利用または他の利用に適切な形態にする。メディアトランスデューサの例には、携帯電話、コンピュータシステムまたはテレビにおいて見出されるような、視覚ディスプレイデバイスが含まれ、スピーカまたはヘッドフォンのような音声表現デバイスも含まれ得る。

バッファモニタ126は、ブロックバッファ125のコンテンツに関する情報を受信し、この情報および場合によっては他の情報に基づいて、本明細書で説明されるような、要求すべきブロックの選択を決定するのに使われるブロック選択器123へ、入力を与える。

ブロック要求ストリーミングシステム(BRSS)は、1つまたは複数のコンテンツサーバ(たとえば、HTTPサーバ、FTPサーバなど)へ要求を行う、1つまたは複数のクライアントを含む。取込システムは、1つまたは複数の取込プロセッサを含み、取込プロセッサは、コンテンツを(リアルタイムでまたはそれ以外で)受信し、BRSSによる使用のためにコンテンツを処理し、コンテンツサーバへアクセス可能な記憶装置に、場合によっては取込プロセッサによって生成されたメタデータとともに、コンテンツを記憶する。

BRSSは、コンテンツサーバと協調するコンテンツキャッシュも含み得る。コンテンツサーバおよびコンテンツキャッシュは、URLを含むHTTP要求の形態でファイルまたはセグメントに対する要求を受信する、従来のHTTPサーバおよびHTTPキャッシュであってよく、URLによって示されるファイルまたはセグメントのすべてよりも少数のものを要求するために、オクテット範囲も含み得る。クライアントは、HTTPサーバの要求を行い、そうした要求への応答を処理する、従来のHTTPクライアントを含んでよく、ここでHTTPクライアントは、要求を作成し、その要求をHTTPクライアントへ渡し、HTTPクライアントから応答を取得し、クライアントデバイスによる再生のために表示プレーヤーへとその応答を与えるためにその応答を処理する(たとえば、記憶する、変換するなど)、新規のクライアントシステムによって動作させられる。通常、クライアントシステムは、どのメディアが必要になるかを事前には知らず(必要性はユーザの入力に応じたものであり得るので、ユーザの入力が変化するので、など)、そのため、受信されるとすぐに、または受信の後まもなく、メディアが「消費される」という点で、これは「ストリーミング」システムと呼ばれる。その結果、応答の遅延および帯域幅の制約は、表示に遅延を引き起こすことがあり、たとえば、ユーザが表示を見ている箇所にストリームが追いつくと、表示に一時停止が生じる。

良好な品質であると知覚される表示を提供するために、クライアント側、取込側、またはこれら両方のいずれかにおいて、いくつかの細部がBRSSに実装され得る。一部の場合には、実装される細部は、ネットワークにおけるクライアントとサーバとのインターフェースを考慮して、またはそれに対応するようになされる。いくつかの実施形態では、クライアントシステムと取込システムの両方が改善を認識し、他の実施形態では、片側のみが改善を認識する。そのような場合、片側が改善を認識していなくても、システム全体が改善から利益を得て、他の場合には、双方が改善を認識する場合にのみ利益が生じるが、片側が改善を認識しなくても、システムは破綻することなく動作し続ける。

図18に示されるように、様々な実施形態に従って、取込システムは、ハードウェアコンポーネントとソフトウェアコンポーネントの組合せとして実装され得る。取込システムは、本明細書で論じられた方法の任意の1つまたは複数をシステムに実行させるように実行され得る、命令のセットを含み得る。システムは、コンピュータの形態である固有の機械として実現され得る。システムは、サーバコンピュータ、パーソナルコンピュータ(PC)、または、そのシステムによってとられるべき動作を規定する命令のセット(順次的な命令または他の命令)を実行できる、任意のシステムであってよい。さらに、単一のシステムのみが示されているが、「システム」という用語は、本明細書で論じられた方法の任意の1つまたは複数を実行するための命令のセット(または複数のセット)を、個々にまたは一緒に実行する、システムの任意の集合も含むと、解釈されるべきである。

取込システムは、取込プロセッサ302(たとえば、中央演算処理装置(CPU))、実行中のプログラムコードを記憶できるメモリ304、およびディスク記憶装置306を含んでよく、これらのすべてが、バス300を介して互いに通信する。システムはさらに、ビデオディスプレイユニット308(たとえば液晶ディスプレイ(LCD)または陰極線管(CRT))を含み得る。システムはまた、英数字入力デバイス310(たとえばキーボード)、および、コンテンツのソースを受信しコンテンツの貯えを配信するための、ネットワークインターフェースデバイス312を含み得る。

ディスク記憶ユニット306は、本明細書で説明される方法または機能の任意の1つまたは複数を具現化する、命令(たとえばソフトウェア)の1つまたは複数のセットが記憶され得る、機械可読媒体を含み得る。命令はまた、システムによるその実行の間、完全にまたは少なくとも部分的に、メモリ304内、かつ/または取込プロセッサ302内に存在してよく、メモリ304および取込プロセッサ302も、機械可読媒体を構成する。

図19に示されるように、様々な実施形態に従って、クライアントシステムは、ハードウェアコンポーネントとソフトウェアコンポーネントの組合せとして実装され得る。クライアントシステムは、本明細書で論じられた方法の任意の1つまたは複数をシステムに実行させるように実行され得る、命令のセットを含み得る。システムは、コンピュータの形態である固有の機械として実現され得る。システムは、サーバコンピュータ、パーソナルコンピュータ(PC)、または、そのシステムによってとられるべき動作を規定する命令のセット(順次的な命令または他の命令)を実行できる、任意のシステムであってよい。さらに、単一のシステムのみが示されているが、「システム」という用語は、本明細書で論じられた方法の任意の1つまたは複数を実行するための命令のセット(または複数のセット)を、個々にまたは一緒に実行する、システムの任意の集合も含むと、解釈されるべきである。

クライアントシステムは、クライアントプロセッサ402(たとえば、中央演算処理装置(CPU))、実行中のプログラムコードを記憶できるメモリ404、およびディスク記憶装置406を含んでよく、これらのすべてが、バス400を介して互いに通信する。システムはさらに、ビデオディスプレイユニット408(たとえば液晶ディスプレイ(LCD)または陰極線管(CRT))を含み得る。システムはまた、英数字入力デバイス410(たとえばキーボード)、および、要求を送信し応答を受信するための、ネットワークインターフェースデバイス412を含み得る。

ディスク記憶ユニット406は、本明細書で説明される方法または機能の任意の1つまたは複数を具現化する、命令(たとえばソフトウェア)の1つまたは複数のセットが記憶され得る、機械可読媒体を含み得る。命令はまた、システムによるその実行の間、完全にまたは少なくとも部分的に、メモリ404内、かつ/またはクライアントプロセッサ402内に存在してよく、メモリ404およびクライアントプロセッサ402も、機械可読媒体を構成する。

具体的な実施形態の例
このセクションでは、[RaptorQ-Spec]で規定されるRaptorQ FEC方式を使った、汎用的なオブジェクト配信のための完全に規定されたFEC方式の、特定の実施形態が説明される。UOSI FECペイロードIDが、簡素で改善されたオブジェクト配信能力を提供するために、[RaptorQ-Spec]におけるRaptorQ FEC方式(本明細書では「UOD-RaptorQ FEC方式」と呼ばれる)とともに使われ得る。具体的には、より柔軟で簡単なサポートが、基本的なオブジェクト配信のために提供され、不均一誤り保護(UEP)オブジェクト配信、一括オブジェクト配信、およびUEPオブジェクト配信と一括オブジェクト配信の組合せに対するサポートも提供される。適切なハードウェアおよび/またはソフトウェアを使って、通信デバイス間で「UOD-RaptorQ FEC方式」を実装できることを理解されたい。

FECペイロードIDの形式は、図2に示されるように4オクテットフィールドであり、この特定の実装形態では、32ビットの符号なしの整数である汎用ファイルシンボル識別子(UFSI)は、やはり32ビットの符号なしの整数である汎用オブジェクトシンボル識別子(UOSI)によって一般化される。UOSIは、そのペイロードIDを搬送するパケット内に含まれる符号化シンボルを特定するために、FEC OTIとともに使われる、負ではない整数である。

単一のオブジェクト、または複数のオブジェクト、または優先順位の異なる複数の部分に分割される単一のオブジェクト、またはこれらの任意の組合せの配信について、FEC OTIは以下のように説明される。配信される各オブジェクトについて、FEC OTIは、RaptorQ FEC方式で規定されるものと同じであってよいことに留意されたい。配信は、dを何らかの正の整数としてd個のオブジェクトを含み得る。各オブジェクトは、同じファイルの異なる部分、または異なるファイル、またはこれらの組合せを含み得る。オブジェクトiのサイズF_iと、オブジェクトiのために使われるべき符号化シンボルのサイズT_iとの関係を使って、送信の際のオブジェクトiの優先順位を決定することができる。

図20は、一般のFEC OTIフィールドの例を示す。そのフィールドで用いられる、配信されるオブジェクトの数のための8ビットの符号なしの整数dがあり、示される例はd=2の場合である。デフォルトの値は、d=1であり得る。他のサブフィールドは、d個のオブジェクトの各々に対する(すなわち、i=1, ..., dに対する)、オブジェクトiに固有である一般のFEC OTI要素を含み、一般のFEC OTI要素は、2¹⁶未満の正の整数でありオブジェクトiのためのシンボルのサイズをオクテット単位で示す、シンボルサイズT_iに対する16ビットの符号なしの整数と、最大で2⁴⁰の負ではない整数でありオブジェクトiの転送長をオクテット単位で示す、オブジェクトiの転送長F_iに対する40ビットの符号なしの整数とを含む。適切なパディングが行われる。

一般のFEC OTIフィールドとは対照的に、図21に示されるような、方式固有のFEC OTI要素が存在し得る。その例で示されるように、方式固有のFEC OTI要素は、シンボル整列パラメータ(Al)(8ビットの符号なしの整数)を含み、各オブジェクトに対する方式固有のFEC OTI要素は、オブジェクトiのためのソースブロックの数Z_i(12ビットの符号なしの整数)と、オブジェクトiのためのサブブロックの数N_iとを含む。符号化された方式固有のオブジェクト送信情報は、(1+3×d)オクテットのフィールドである。図21の例は、d=2の場合である。そして、符号化されたFEC OTIは、符号化された一般のFEC OTIと符号化された方式固有のFEC OTI要素との連結を含む、(2+10×d)オクテットのフィールドであってよい。

符号化されたFEC OTIを用いたコンテンツ配信には、UOD-RaptorQ FEC方式と、オブジェクト配信のためにUOD-RaptorQ FEC方式を使用するコンテンツ配信プロトコル(「CDP」)とを使った、デバイス間、コンピュータ間、システムのプログラム間での情報交換が伴い得る。CDPは、d、Alをエンコーダおよびデコーダに与えなければならず、各オブジェクトについてF_i、T_i (Alの倍数)、Z_iおよびN_iを与えなければならない。エンコーダは、オブジェクトi自体を与えられる。UOD-RaptorQエンコーダ方式を用いるエンコーダは、送信されるべき各パケットについて、パケットのUOSIおよびd個のオブジェクトのための符号化シンボルを、CDPに供給する。CDPは、この情報を受信機に伝える。

パラメータ選択の例が、ここで説明される。

一例では、[RaptorQ-Spec]のセクション4.3で説明される例示的なパラメータの導出が、d個のオブジェクトの各々に対して独立に使用され適用され得る。ある例では、Al=4オクテット、SS=8(各サブシンボルは少なくともSS×Al=32オクテットであることを示唆する)であり、オブジェクトiのT_iは好ましくは少なくともSS×Alオクテットであり、T_iはAlの倍数であり、各符号化パケットのペイロードサイズは好ましくは少なくともTのサイズであり、TはT_iのi=1, ..., dにわたる和である。

ソースブロックの構築では、[RaptorQ-Spec]のセクション4.4.1の手順が、d個のオブジェクトの各々に対して独立に適用され得る。

符号化パケットの構築では、各符号化パケットは、d個のオブジェクトに対するUOSIおよび符号化シンボルを含む。[RaptorQ-Spec]のRaptorQ FEC方式によって使われるFECペイロードIDの(SBN, ESI)フォーマットと、UOD-RaptorQ FEC方式によって使われるUOSIフォーマットとの互換性のために、UOSIフォーマットは特定のフォーマットであり得る。たとえば、各オブジェクトについて、UOSIの値Cから、オブジェクトiの対応する(SBN, ESI)の値(A, B)への対応付けは、B=floor(C/Z_i)およびA=C-B×Z_iであり得る。同様に、各オブジェクトについて、オブジェクトiの(SBN, ESI)の値(A, B)から、対応するUOSIの値Cへの対応付けは、C=A+B×Z_iである。

各オブジェクトi=1,..., dについて、0からKT_i-1のUOSI値が、ソースブロック中のオブジェクトiのソースシンボルを交互の順序で特定し、KT_i=ceil(F_i/T_i)である。KT_i 以降のUOSI値は、RaptorQエンコーダを使って、オブジェクトiのソースシンボルから生成された修復シンボルを特定する。

符号化パケットは、ソースシンボル、修復シンボル、またはソースシンボルと修復シンボルの組合せを含み得る。パケットは、オブジェクトiの同じソースブロックからの、任意の数のシンボルを含み得る。オブジェクトiのソースパケット中の最後のソースシンボルは、FEC符号化のために追加されたパディングオクテットを含み、これらのオクテットはパケット中に含まれるべきなので、シンボル全体のみが各パケットに含まれる。

各符号化パケットで搬送される汎用オブジェクトシンボル識別子Cは、そのパケットで搬送される各オブジェクトのための第1の符号化シンボルのUOSIである。各オブジェクトのためのパケット中の後続の符号化シンボルは、連続的な順序でC+1からC+G-1まで番号を付けられたUOSIを有し、ここでGは、パケット中の各オブジェクトのための符号化シンボルの数である。

好ましい実装形態では、各符号化パケットにおいて、d個のオブジェクトの各々に対して1つの符号化シンボルがある。好ましい実装形態では、符号化パケットは、以下の手順に従って生成され送信される。各UOSI値C=0, 1, 2, 3, ...について、エンコーダは、以下のように符号化パケットを生成して送信し、符号化パケットのFECペイロードIDの値はUOSI値Cに設定され、i=1, ..., dである各オブジェクトiに対して、エンコーダは、UOSI値Cに対応する(SBN, ESI)値(A_i, B_i)を決定し、RaptorQ FEC方式[RaptorQ-Spec]の手順に従って、オブジェクトiからの(SBN, ESI)値(A_i, B_i)に対応するサイズT_iの符号化シンボルE_iを生成し、符号化シンボルE_iを符号化パケットのペイロードに追加し、符号化パケットを送信する。受信機は、符号化パケットの総数を必ずしも知らなくてもよいことに留意されたい。

これは、1つの特定の例である。本開示を読んだ後で、当業者はさらなる実施形態を想起し得る。他の実施形態では、有利には、上で開示された発明の組合せまたは副組合せが作られ得る。コンポーネントの例示的な構成は例示のために示されており、組合せ、追加、再構成などが、本発明の代替的な実施形態で考慮されることを理解されたい。したがって、本発明は、例示的な実施形態に関して説明されてきたが、当業者は、多くの修正が可能であることを認識するだろう。

たとえば、本明細書で説明された処理は、ハードウェアコンポーネント、ソフトウェアコンポーネント、および/またはこれらの任意の組合せを使って実装され得る。したがって、本明細書および図面は、限定ではなく例示であると見なされるべきである。しかし、特許請求の範囲において述べられる本発明のより広範な趣旨および範囲から逸脱することなく、様々な修正および変更を行うことができ、本発明は、以下の特許請求の範囲内にあるすべての修正および等価物を包含することが意図されることが、明らかであろう。

101 ブロックサービングインフラストラクチャ
102 コンテンツ
103 取込システム
104 HTTPストリーミングサーバ
106 HTTPキャッシュ
108 クライアント
110 コンテンツ記憶装置
122 ネットワーク
123 ブロック選択器
124 ブロック要求器
125 ブロックバッファ
126 ブロックモニタ
127 メディアデコーダ
128 メディアトランスデューサ
300 バス
302 取込プロセッサ
304 メモリ
306 ディスク記憶装置
308 ビデオディスプレイ
310 英数字入力デバイス
312 ネットワークインターフェース
400 バス
402 クライアントプロセッサ
404 メモリ
406 ディスク記憶装置
408 ビデオディスプレイ
410 英数字入力デバイス
412 ネットワークインターフェース

Claims (24)

1. パケット交換ネットワークを通じて、電子デバイスまたはシステムから、1つまたは複数のデータオブジェクトを配信する方法であって、前記1つまたは複数のデータオブジェクトのソースデータが、前記ソースデータがパケット中の符号化シンボルから少なくともおおよそ復元可能であるように、前記符号化シンボルによって表される、方法において、
   a)配信されるべき前記1つまたは複数のデータオブジェクトの各データオブジェクトについて、オクテット単位での前記データオブジェクトのサイズF、前記データオブジェクトを表すのに使われる各シンボルを表すために使われるオクテットの数T、および、前記データオブジェクトの配信のための分割先のソースブロックの数Zを含む、オブジェクト送信情報(「OTI」)を特定するステップと、
   b)前記1つまたは複数のデータオブジェクトのための複数のパケットの各パケットに対して、汎用オブジェクトシンボル識別子(「UOSI」)を生成するステップであって、所与のパケットに対する前記UOSIが、可能なUOSI値のセットから選択され、前記セットが、前記所与のパケットにおいて表される各データオブジェクトのための前記OTIの値とは独立である、ステップと、
   c)前記1つまたは複数のデータオブジェクトを表す前記ソースデータを含む、複数のソースシンボルから複数の符号化シンボルを生成するステップであって、前記ソースシンボルの各々が前記ソースデータ中の位置を有し、所与のデータオブジェクトのための所与のパケットの符号化シンボルを生成するステップが、
   1)使用すべきFEC符号化処理を決定するステップと、
   2)前記所与のパケットの前記UOSIおよび前記所与のデータオブジェクトの前記OTIから、ソースブロック番号(「SBN」)および符号化シンボル識別子(「ESI」)を決定するステップと、
   3)前記符号化シンボルについて、(a)前記FEC符号化処理、(b)前記符号化シンボルの前記SBNから決定された前記Z個のソースブロックのうちの1つのソースブロックからの1つまたは複数のソースシンボル、および(c)前記符号化シンボルの前記ESIに少なくとも基づいて、サイズTの符号化シンボル値を生成するステップと
   を含む、ステップと、
   d)ステップa)で扱われた前記データオブジェクトの各々の前記OTIを表すものを含むOTIフィールドを生成するステップであって、前記OTIフィールドが、前記OTIフィールドによって表されるデータオブジェクトの数であるdも含む、ステップと、
   e)前記1つまたは複数のデータオブジェクトのための前記複数のパケットを生成するステップであって、前記複数のパケットの各パケットが、前記パケットの前記UOSIと、前記データオブジェクトの前記OTIおよび前記パケットの前記UOSIを使って前記データオブジェクトから生成された、前記パケット中で表される各データオブジェクトの1つまたは複数の符号化シンボルとを含む、ステップと、
   f)前記パケット交換ネットワークによって使用可能な形態で、前記OTIフィールドおよび前記複数のパケットを出力するステップと
   を含む、方法。
2. 各データオブジェクトの前記OTIが、前記データオブジェクトの各ソースオブジェクトの送信のための分割先であるサブブロックの数Nも含む、請求項1に記載の方法。
3. SBNをUOSI modulo Zに等しく設定するステップと、
   ESIを、UOSIをZで除算したもの以下の最大の整数に等しく設定するステップと
   をさらに含む、請求項1に記載の方法。
4. パケット交換ネットワークを通じて、電子デバイスまたはシステムから、1つまたは複数のデータオブジェクトを配信する方法であって、前記1つまたは複数のデータオブジェクトのソースデータが、前記ソースデータがパケット中の符号化シンボルから少なくともおおよそ復元可能であるように、前記符号化シンボルによって表される、方法において、
   a)配信されるべき前記1つまたは複数のデータオブジェクトの各データオブジェクトについて、オブジェクト送信情報(「OTI」)を特定するステップであって、前記1つまたは複数のデータオブジェクトが2個以上のデータオブジェクトを含む場合、1つの配信の中の2個のデータオブジェクトのOTIが異なり得る、ステップと、
   b)前記1つまたは複数のデータオブジェクトのための複数のパケットの各パケットに対して、汎用オブジェクトシンボル識別子(「UOSI」)を生成するステップであって、所与のパケットに対する前記UOSIが、可能なUOSI値のセットから選択され、前記セットが、前記所与のパケットにおいて表される各データオブジェクトのための前記OTIの値とは独立である、ステップと、
   c)前記1つまたは複数のデータオブジェクトを表す前記ソースデータを含む、複数のソースシンボルから複数の符号化シンボルを生成するステップであって、前記ソースシンボルの各々が前記ソースデータ中の位置を有し、所与のデータオブジェクトのための所与のパケットの符号化シンボルを生成するステップが、(a)前記所与のパケットの前記UOSI、(b)前記所与のデータオブジェクトの前記OTI、および(c)1つまたは複数のソースシンボル値から前記符号化シンボルの値を決定するステップを含む、ステップと、
   d)配信されるべき前記1つまたは複数のデータオブジェクトのための前記複数のパケットを生成するステップであって、前記複数のパケットの各パケットが、前記パケットの前記UOSIと、前記データオブジェクトの前記OTIおよび前記パケットの前記UOSIを使って前記データオブジェクトから生成された、前記パケット中で表される各データオブジェクトの1つまたは複数の符号化シンボルとを含む、ステップと、
   e)前記パケット交換ネットワークによって使用可能な形態で、少なくとも前記複数のパケットを出力するステップと
   を含む、方法。
5. シンボルが、データオブジェクトのソースシンボルに相当するか、それとも、1つまたは複数のソースシンボルの復元のためのFEC復号処理で使用可能なFEC修復シンボルに相当するかを、受信機が判定できるように、シンボルを標識するステップをさらに含み、前記受信機が、前記シンボルを含む前記パケットの前記UOSIを、データオブジェクト中のシンボルの数を表す値と比較することによって、前記判定を実行する、請求項4に記載の方法。
6. 前記UOSIが負ではない整数であり、各データオブジェクトの前記OTIが、前記データオブジェクトのオクテット単位のサイズ、前記データオブジェクト表すために使われる各シンボルを表すのに使われるオクテットの数、前記データオブジェクトの配信のための分割先であるソースブロックの数、ソースブロックの分割先のサブブロックの数、および、好ましいメモリの整列に対応する整列係数を含む、請求項4に記載の方法。
7. 前記所与のデータオブジェクトの前記OTIが基本UOSI値を含み、
   (a)前記所与のパケットの前記UOSI、(b)前記所与のデータオブジェクトの前記OTI、および(c)1つまたは複数のソースシンボル値から、前記符号化シンボルの値を決定するステップが、前記符号化シンボルの値を決定する前に、前記基本UOSI値によって、前記所与のパケットの前記UOSIを調整して、それによって前記UOSIのオフセット値を可能にするステップを含む、請求項4に記載の方法。
8. 前記符号化シンボルの値を決定するステップが、前方誤り訂正(「FEC」)を使うステップを含み、異なるレベルのFEC保護が、異なるデータオブジェクトに対して可能にされ、FEC保護のレベルが、異なる各データオブジェクトの前記OTIから決定される、請求項4に記載の方法。
9. 前記1つまたは複数のデータオブジェクトが、単一のデータオブジェクトを含み、OTIの単一のセットが、前記1つまたは複数のデータオブジェクトの各符号化シンボルを生成するために使われる、請求項4に記載の方法。
10. 前記1つまたは複数のデータオブジェクトが、複数のデータオブジェクトを含み、OTIフィールドが、データオブジェクトごとに1つの複数のOTIサブフィールドと、前記複数のデータオブジェクト中のデータオブジェクトの数を示すカウントサブフィールドとを含み、前記OTIサブフィールドのすべてが同一とは限らず、あるOTIサブフィールドが、少なくとも1つの他のOTIサブフィールドとは独立に生成される、請求項4に記載の方法。
11. 各OTIサブフィールドが、そのデータオブジェクトに対して、前記データオブジェクトのサイズ、前記データオブジェクトの転送のための分割先であるソースブロックの数、ソースブロック当たりの使われるサブブロックの数、使われるシンボルサイズ、および整列係数を含み、少なくとも2つのデータオブジェクトに対するソースブロックの前記数が異なる、請求項10に記載の方法。
12. 前記1つまたは複数のデータオブジェクトが、少なくとも第1のデータオブジェクトおよび第2のデータオブジェクトを含み、前記配信が、少なくとも2つの別々のパケットシーケンスへと編成され、前記第1のデータオブジェクトの符号化シンボルが、第1のパケットシーケンスのパケットと、第2のパケットシーケンスのパケットとに現れ、前記第2のデータオブジェクトの符号化シンボルが、前記第1のパケットシーケンスのパケットには現れるが、前記第2のパケットシーケンスのパケットには現れない、請求項4に記載の方法。
13. 前記1つまたは複数のデータオブジェクトの各々が、データをファイルとして記憶するコンピュータ可読媒体に記憶された異なるファイルを含む、請求項4に記載の方法。
14. 前記1つまたは複数のデータオブジェクトの少なくとも1つが、データをファイルとして記憶するコンピュータ可読媒体に記憶された異なるファイルの一部を含む、請求項4に記載の方法。
15. 電子デバイスまたはシステムを用いて、パケット交換ネットワークを通じて受信される1つまたは複数のデータオブジェクトを受信して復号する方法であって、十分な符号化シンボルが受信される場合には、受信される符号化シンボルが、前記1つまたは複数のデータオブジェクトを表すソースシンボルへと復号される、方法において、
    a)配信される前記1つまたは複数のデータオブジェクトの各データオブジェクトについて、オブジェクト送信情報(「OTI」)を特定するステップであって、前記1つまたは複数のデータオブジェクトが2個以上のデータオブジェクトを含む場合、1つの配信の中の2個のデータオブジェクトのOTIが異なり得る、ステップと、
    b)復号において使われるべき各符号化シンボルについて、前記符号化シンボルによって自身のソースシンボルが符号化されるデータオブジェクト、符号化シンボルの値、および、前記符号化シンボルを含むパケットの汎用オブジェクトシンボル識別子(「UOSI」)を決定するステップと、
    c)復号において使われるべき各符号化シンボルについて、復号のために使われる復号パラメータを決定するステップであって、前記符号化シンボルおよび前記対応するデータオブジェクトのOTIを含む前記パケットの前記UOSIを使って、前記復号パラメータを決定する、ステップと、
    d)符号化シンボルおよびステップc)で決定された復号パラメータを使って、前記符号化シンボルを、データオブジェクトを表す復元されたソースシンボルへと復号するステップと、
    e)前記復元されたソースシンボルを、コンピュータ可読の形態で出力するステップと
    を含む、方法。
16. 前記受信された符号化シンボルとともに前記OTIを受信するステップをさらに含む、請求項15に記載の方法。
17. 前記復号パラメータが、ソースブロック番号および符号化シンボル識別子を含み、前記方法が、
    UOSI modulo (使用されるソースブロックの数)と等しく、前記ソースブロックの数を設定するステップと、
    使用されるソースブロックの前記数によってUOSIを除算したもの以下の最大の整数と等しく、前記符号化シンボル識別子を設定するステップと
    をさらに含む、請求項15に記載の方法。
18. 前記符号化シンボルが、ソースシンボルに相当するか、それとも、1つまたは複数のソースシンボルの復元のためのFEC復号処理で使用可能な前方誤り訂正(FEC)修復シンボルに相当するかを、複数の前記符号化シンボルの各々について判定するステップをさらに含み、受信機が、前記符号化シンボルを含む前記パケットの前記UOSIを、データオブジェクト中のシンボルの数を表す値と比較することによって、前記判定を実行する、請求項15に記載の方法。
19. 前記UOSIが負ではない整数であり、複数のデータオブジェクトの各々の前記OTIが、各データオブジェクトのオクテット単位のサイズ、各データオブジェクト表すために使われる各シンボルを表すのに使われるオクテットの数、各データオブジェクトの配信のための分割先であるソースブロックの数、ソースブロックの分割先のサブブロックの数、および、好ましいメモリの整列に対応する整列係数を含み、OTIの値が少なくとも2つのデータオブジェクトで異なり、異なるレベルの前方誤り訂正(「FEC」)が、少なくとも2つのデータオブジェクトに対して使われる、請求項15に記載の方法。
20. 電子デバイスまたはシステムを用いて、パケット交換ネットワークを通じて受信される1つまたは複数のデータオブジェクトを受信して復号する方法であって、十分な符号化シンボルが受信される場合には、受信される符号化シンボルが、前記1つまたは複数のデータオブジェクトを表すソースシンボルへと復号される、方法において、
    a)各データオブジェクトのための符号化シンボルを含む、1つまたは複数のパケットを受信するステップと、
    b)ある数の追加のシンボルが所望のデータオブジェクトの復元に必要であると、判定するステップと、
    c)複数の符号化シンボルファイル順序から、ある符号化シンボルファイル順序を選択して、前記数の追加のシンボルを要求するのに必要なバイト範囲の指定が、別の符号化シンボルファイル順序が選択された場合に必要なバイト範囲の指定よりも狭くなるようにするステップと、
    d)前記所望のデータオブジェクトの復元に必要な、少なくとも前記数の追加のシンボルを受信するために行うべき、1つまたは複数のバイト要求を決定するステップであって、前記選択された符号化シンボルファイル順序に基づく、ステップと、
    e)前記選択された符号化シンボルファイル順序をサービスするように構成されたハイパーテキスト転送プロトコル(「HTTP」)サーバへ、前記1つまたは複数のバイト要求を送信するステップと
    を含む、方法。
21. 符号化シンボルファイル順序を選択するステップが、前記受信された1つまたは複数のパケットの転送の種類に基づいて、前記符号化シンボルファイル順序を選択するステップを含む、請求項20に記載の方法。
22. パケット交換ネットワークを通じて、電子デバイスまたはシステムから、1つまたは複数のデータオブジェクトを配信する方法であって、前記1つまたは複数のデータオブジェクトのソースデータが、前記ソースデータがパケット中の符号化シンボルから少なくともおおよそ復元可能であるように、前記符号化シンボルによって表され、
    a)ファイル要求およびバイト範囲要求に応答し、ファイルおよびバイト範囲をサービスする、ハイパーテキスト転送プロトコル(「HTTP」)サーバを構成するステップと、
    b)使用される前方誤り訂正(「FEC」)に基づいて要求パターンを決定するステップと、
    c)前記バイト範囲要求に応答するために使われる元順序HTTPファイルの順序を変えるステップと、
    d)前記順序を変えられたHTTPファイルへのアクセス権を、前記HTTPサーバに与えるステップと
    を含み、使用される前記FECに基づく予想される要求が、前記HTTPサーバが前記元順序HTTPファイルへのアクセス権を有するが前記順序を変えられたHTTPファイルへのアクセス権を有さない場合に要求されるバイト範囲の指定よりも狭い、バイト範囲の指定を要求するように、前記順序の変更が行われる、方法。
23. 前記使われるFECが、データオブジェクトのソースブロックを複数のサブブロックへと分割し、前記ソースブロックがソースシンボルを含み、
    前記順序を変えられたHTTPファイルが、連続的なソースブロックの順序であり、ソースブロック内で、ソースシンボルの順序である、請求項22に記載の方法。
24. 前記使われるFECが、複数のソースブロックを交互の順序で使い、データオブジェクトのソースブロックを複数のサブブロックへと分割し、前記ソースブロックがソースシンボルを含み、
    前記順序を変えられたHTTPファイルが、ソースブロックの交互の順序であり、ソースブロック内で、ソースシンボルの順序である、請求項22に記載の方法。

Images