JP2015222954A - 放送チャネル上の高速チャネルザッピングおよび高品質ストリーム保護 - Google Patents

Abstract

【課題】短いチャネルザッピング時間を可能とし、高品質配信を提供するためのＦＥＣコードを利用するチャネル上でストリーミングデータを送信および受信するための方法を提供する。【解決手段】多数の物理層ブロック内でソースブロック送信のシグナリングは、ストリーミングとオブジェクト配信アプリケーションとの両方へ実行され、最小の付加オーバヘッドを使用して、いくつかの場合オーバヘッドを使用せずに、ソースブロックの順位付けされたデータの表示および送信を示し、それらが生成されるソースブロックとシンボルがどのように関連するか示し、物理層ブロック内でインターリーブされたソースブロックを示す。必要とされる受信器電力源およびチャネルリソースの必要な量の最小化または改善するとともに、１以上のチャネル上でストリームを送りおよび体系付けることが、配信されたストリームの品質の向上のために実行され得る。【選択図】図５

Description

[0001] 本特許出願は２００８年５月７日出願の「放送チャネル上の高品質ＦＥＣストリーム保護および高速チャネルザッピング（Fast Channel Zapping and High Quality FEC Streaming Protection over a Broadcast Channel）」と題する仮出願番号第６１／０５１，３２５号に対する優先権を主張する。

[0002] 本発明は、一般に、ストリーミング（streaming）とオブジェクト配信（object delivery）に関し、特に、送出されたストリームの質を保護するためのＦＥＣを用いる、信頼性の低いチャネル上のストリーミングとオブジェクト配信に関する。

[0003] チャネル上で、一般的にオーディオおよび／又はビデオデータであり、遠隔測定データのような他のタイプのデータでもある、ストリーミングデータ送信を考慮するためのプラクティスが普及している。１つの主要な関心事は、配信されたストリームの質の保証が高いこと、例えば、全てまたは殆どのオリジナルストリームデータが１つの受信器又は一連の受信器へ配信される、あるいは、受信器又は一連の受信器での再生のビデオ品質が高いことである。例えば、ストリーミングデータが送出されるチャネルは、完全に信頼性のあるものでなく、例えば、送信でデータの部分が失われ又は破損するかもしれない。したがって、しばしば高品質配信（high quality delivery）を達成するために他の手段は配信劣化（delivery degradation）を克服するために取られることを必要とし、そのような手段はオリジナルデータストリームへのＦＥＣのアプリケーション、例えば、リンクにおいて又はパケット破損に対する保護のための物理層において、パケット損失に対して保護するためのアプリケーション層又はトランスポート層を含んでもよい。他の手段は、例えばリンク層再送プロトコル又はアプリケーション層再送プロトコルのような、損失又は破損データを再送するための再送ストラテジーを使用することを含む。

[0004] そのようなシステムを設計するときのもう１つの主要な関心事は、例えばエンドユーザがビデオストリームの視聴の開始を最初に要求したときからビデオストリームの表示の開始に要する期間、又は、ユーザ要求により始動される新たなビデオストリームの表示開始および現在のビデオストリームの表示停止に要する期間である。この期間はしばしばチャネルザッピング時間（channel zapping time）と呼ばれる。一般的に、チャネルザッピング時間が短いほどエンドユーザ経験（end user experience）が良くなり、したがってより有益な総合的サービスである。例えば、チャネルザッピング時間をできるだけ短く、例えば１秒未満とすることがしばしば要求される。

[0005] ストリームがバックチャネル（backchannel）のない高い信頼性のあるチャネル上で配信（delivery）されるとき、あるいは、ストリームがそれほど信頼性のないチャネル上で配信されるときおよび損失データの再送を要求するために使用可能なバックチャネルがあるとき、そのようなチャネルザッピング時間および高品質ストリーム配信を達成することがしばしば可能であるが、ストリームがそれほど信頼性のないチャネル上で配信されるときおよびバックチャネルが信頼性の向上のために使用されず、代わりにＦＥＣの使用が適切かもしれないときには、そのようなチャネルザッピング時間を達成することが困難である。また、代わりに、ＦＥＣの使用は適切かもしれない。

[0006] 最近、伝送の間にストリーミングメディアの保護のためにＦＥＣコードを使用することを考慮するためのプラクティスが普及している。それらの例が３ＧＰＰ、３ＧＰＰ２およびＤＶＢのようなグループにより規格化された無線ネットワークやインターネットを含むパケットネットワーク上に送られたとき、ソースストリームは、それが生成され又は利用可能となるようにパケットに格納され、したがってパケットはそれが生成され又は利用可能とされた順にソースストリームを受信器へ搬送する。シナリオのこれらのタイプへのＦＥＣコードの典型的なアプリケーションでは、ＦＥＣコードはソースストリームを含むオリジナルソースパケットへ付加的なリペアパケット（repair packet）を加えるために利用され、これらリペアパケットはソースパケット損失が生じた場合に受信リペアパケットが損失ソースパケットに含まれたデータの修復のために用いられることができるという特性を有している。他の例において、部分的なパケット損失が生じる可能性がある、つまり、受信器は、そのパケットの他の部分を受け取る間にパケットの部分を損失し、したがって、全体的にあるいは部分的に受け取られた例において、全体的にあるいは部分的に失われたソースパケットを回復するためにリペアパケットを使用することができる。まだ他の例で、例えば、ビットの値の反転のような他のタイプのコラプション（corruption）が送られたデータに生じる場合があり、このように、リペアパケットは、そのようなコラプションを修正し、そして、できるだけ正確なソースパケットの回復を提供するために使用されてもよい。他の例において、ソースストリームは個別のパケットの中で必ずしも送られないが、その代り、例えば連続的なビット・ストリームとして送られてもよい。

[0007] ソースストリームの保護を提供するために使用することができるＦＥＣコードの多くの例がある。リード・ソロモンコード（Reed-Solomon codes）は、通信システムにおける誤りおよび消去修正のための良く知られたコードである。例えばパケットデータネットワーク上の消去修正については、リード・ソロモンコード（Reed-Solomon codes）の良く知られた効率的なインプリメンテーションは、Ｌ．リゾー（Rizzo）「信頼性のあるコンピュータ通信プロトコルのための有効な消去コード（Effective Erasure Codes for Reliable Computer Communication Protocols）」、コンピュータ通信レビュー（Computer Communication Review）、27(2):24-36 (１９９７年４月)（以下「リゾー」という）、および、J.Bloemer、M.Kalfane、R.Karp、M.Karpinski、M.Luby、D.Zuckerman、「An XOR-Based Erasure-Resilient Coding Scheme」、テクニカルレポート（Technical Report） TR-95-48、国際計算機科学協会、バークレー、カリフォルニア、（１９９５年）（以下、「ＸＯＲ-リード−ソロモン」という）に記述されるようなコーシーまたはバンデルモンドの行列を使用することである。ＦＥＣコードの他の例は、ＬＤＰＣコード、米国特許６，３０７，４８７号（以下、「Luby I」という）および米国公開特許出願２００３／００５８９５８号（以下、「Shokrollahi I」という）に記述されたような、連鎖反応コードおよびマルチステージ連鎖反応コード、を含み、それぞれ、すべての目的のためにここに組込まれる。

[0008] リード・ソロモンコードの変形のためのＦＥＣ復号プロセスの例は、「リゾー」および、「ＸＯＲ−リード−ソロモン」に記載されている。これらの例において、復号は一旦十分なソースに適用され、修復データパケットが受信される。復号プロセスは、計算上集中的であってもよく、また、利用可能なＣＰＵリソースに依存してもよく、これがブロック中のメディアによって測定された時間長に比べて、完了するために相当な時間を要してもよい。

[0009] 多くのアプリケーションでは、パケットは、ＦＥＣプロセスが適用されるシンボルへさらにサブ分割される。１つのシンボルは、どんなサイズとすることも可能であるが、しばしば１つのシンボルのサイズはパケットのサイズと高々等しい。以下に、我々は、復号ブロックを備えるシンボルを「ソースシンボル（source symbols）」と称し、ＦＥＣプロセス中に生成されたシンボルを「符号化シンボル（encoding symbols）」と称する。いくつかのＦＥＣコード、特にリード・ソロモンコードについては、ソースブロック毎の符号化シンボルの数が増大するにつれて、符号化および復号化時間は非現実的に増大する。したがって、実際上、多くの場合ソースブロックにつき生成可能な符号化シンボルの総数には例えば２５５の上限が存在する。シンボルがしばしば異なるパケットペイロード内に配置されるためこれは時には実用的な上限であって、例えばパケットペイロードが多くとも１０２４バイトである場合、符号化ソースブロックが多くとも２５５ＫＢ（キロバイト）であって、そして、各シンボルが別個のパケットに送られた場合これは当然ながらソースブロック自身のサイズ上の上限でもある。

[0010] より大きな時間に渡って送られるデータのブロックにＦＥＣコーディングを適用することは、より小さい時間に渡って送られるデータのブロックへＦＥＣコーディングよりも、一般的に同じ帯域幅のオーバヘッドのためのより好ましい保護をストリームに提供するので、送られたストリームが大きな期間に渡って拡散する間にＦＥＣ符号化および復号化をデータのブロックに適用することはしばしば望ましい。これは、多くのチャネルが損失および／または破損に関連する時間に従うからであって、例えば、データは、破損中に失われる可能性が高く、あるいは、それらが他の短い期間に渡るよりもチャネル特性がより悪くなる短い時間である可能性が高い。

[0011] 大きな時間に渡って拡散して送られたデータのブロックに適用されたＦＥＣ符号化を使用する課題は、これがチャネルザッピング時間に不利な影響を与える可能性があることである。例えば、受信器において、符号化されたデータのブロックは完全に回復され、そして、全体のブロックに対して十分なデータが受信された後に展開されことが可能であるかもしれない。したがって、ＦＥＣ符号化されたデータのブロックが大きな時間に渡って送られると、チャネルザッピング時間は容認され得ないほど高くなるかもしれない。

[0012] 大きな時間に渡ってＦＥＣ符号化されたデータのブロックを同時に送信する間に短いチャネルザッピング時間の目的を構築するための１つの方法は、ＦＥＣ符号化されたデータの中で最も重要なデータが最後に送られ最も重要でないデータが最初に送られるようにデータを順序付けることである。例えば、すべての目的のためにここに組込まれる、「前方向誤り訂正（ＦＥＣ：Forward Error Correcting）コーディングとストリーミング」と題された米国特許出願１１／４２３，３９１号（以下に「ＦＥＣストリーミング」と称する）は、例えば、ソースデータの前にＦＥＣ修復データをソースブロックへ送り、その結果、受信器がソースブロックの中程おけるストリームに結合されていたとしても、受信器がソースブロックに関するソースデータの一部を受信して例えば再生のためのメディアプレイヤーへそれを送信することを開始することを可能にし、結果としてチャネルザッピング時間を最小化するための方法を説明している。

[0013] 別の関心事は、送信される実際のデータを識別するために利用されるヘッダーデータにより利用されるチャネルリソース量を最小化することである。一般に、ヘッダーデータは、一般的に、データを配信するために利用可能な容量に否定的な影響を与えるオーバヘッドである。例えば、４バイトのヘッダーデータが１００バイトの実際のデータのそれぞれを識別するために使用される場合、ヘッダーオーバヘッドは大きな４％である。特に、ストリーミングとオブジェクト配信アプリケーション（object delivery applications）との両方にとって、しかし、より一般的には任意のデータ配信アプリケーションについてヘッダーオーバヘッドをできるだけ最小化することが望ましい。

[0014] 短いチャネルザッピング時間が要求されるときに信頼性を向上するためにバックチャネル（back channels）が使用されないときに、高品質ストリームがそれほど信頼性のないチャネル上で配信されることを可能にする方法、プロセスおよび装置である。与えられた信頼性のレベルを達成するための物理リソースの最小化は、例えばヘッダーオーバヘッドおよびＦＥＣオーバヘッドのために、同様に最高に重要なことである。

[0015] 実施形態は、短いチャネルザッピング時間を可能とし高品質配信を提供するためのＦＥＣコードを利用するチャネル上でのストリーミングデータの送信および受信するための新規性のある方法およびプロセスを示す。ストリーミングおよびオブジェクト配信のためにそのようなシステムにおいて必要とされるヘッダーオーバヘッドを最小化する、新規なシグナリング方法が説明される。ストリームの保護および送信するための新規な処理も説明される。

[0016] 添付の図面と共に後述される詳細な説明は、本発明の効果および性質についてのよりよい理解を提供する。

図１は、本発明の１実施例による通信システムのブロック図である。 図２は、既知のシステムへの受信器の待ち時間（receiver latency）のコンポーネントを例示する図である。 図３は、ＦＥＣリペアシンボル（FEC repair symbols）が対応するソースシンボルが生成される前に送信される場合に受信器の待ち時間のコンポーネントを例示する図である。 図４は、実施例がサブブロックへデータに優先順位を付け、優先的に送られる順序にサブブロックを位置づけ（map）得る方法を示すブロック図である。 図５は、実施例が各物理層ブロックへ不可欠なサブブロックの位置づけに基づく物理層ブロックへサブクロックを位置づけ得る方法を示すブロック図である。 図６は、実施例が等しい量のサブブロック・データが各物理層ブロックへ位置づけられ、サブブロックが物理層ブロックに渡って時々分割される物理層ブロックへサブクロックを位置付け得る方法を示すブロック図である。

詳細な説明

[0023] ここに記載された実施形態は、ストリーミングとオブジェクト配信アプリケーションとの両方のための、複数の物理層ブロック内でソースブロックの送信をシグナリングするための新規性のある方法を提供する。これらのシグナリング方法は、物理層ブロック内でインターリーブされたソースブロックをシグナルするために最小の付加オーバヘッドを使用し、いくつかの場合にオーバヘッドを使用しない方法、シンボルがそれらが生成されたソースブロックに対してどのように関係するかのシグナリング、および、ソースブロックに対して優先順位付けされたデータの表示およびシグナルされた送信、を含む。必要とされる受信器の電力資源およびチャネルリソースの必要な量を最小化する、または改善するとともに、配信されるストリームの品質を改善する、ストリームを体系化し１以上のチャネル上で送信のための付加的な方法が記述される。

[0024] 以下、ここに記載されたプロセスおよび方法が連続的なビット・ストリームネットワークとして転送ネットワークの他のタイプにどのように適用されうるか当業者が容易に理解することができるという認識とともに、ここの記載を単純にするために、データを搬送するネットワークはパケットに基づくと仮定される。以下、ここに記載されたプロセスおよび方法がビット・フリップとしてデータ送信破損の他のタイプへどのように適用されうるか当業者が容易に理解することができるという認識とともに、ここの記載を単純にするために、ＦＥＣコードは損失パケット又はパケット内の損失部分的データに対する保護を提供すると仮定される。

[0025] 図１は、連鎖反応コーディングを利用する通信システム１００のブロック図である。通信システム１００において、入力ファイル１０１、又は入力ストリーム１０５は、入力シンボル生成器１１０へ供給される。入力シンボル生成器１１０は、値および位置（括弧内の整数として図１に表示された）を持つ入力シンボルと共に、入力ファイル又はストリームから１以上の入力シンボル（ＩＳ（０）、ＩＳ（１）、ＩＳ（２）．．．）のシーケンスを生成する。入力シンボルの可能な値、即ちそのアルファベットは、主として２Ｍシンボルのアルファベットであって、その結果、各入力シンボルはＭビットの入力ファイルをコード化する。Ｍの値は、一般的に通信システム１００の利用により決定される。しかし、用途から用途へＭを可変にするために、汎用システムは入力シンボル生成器１１０へ入力されるシンボルサイズを含んでもよい。入力シンボル生成器１１０の出力は、符号器１１５へ供給される。

[0026] 鍵生成器１２０は、符号器１１５によって生成されるべき各出力シンボルのための鍵を生成する。それらがこの又は他の鍵生成器によって生成されたかどうかに関わらず、各鍵は、Luby I又はShokrollahi Iに記載された方法、又は、ストリームにおいて同じ入力ファイル又はデータのブロックのために生成された鍵の大きな比が固有であることを保障する任意の類似の方法の１つに従って生成される。例えば、鍵生成器１２０は、各鍵を生成するためのランダムナンバ生成器１３５の出力、ユニークなストリーム識別子１３０、および／又は、カウンタ１２５の出力の組み合わせを使用しても良い。鍵生成器１２０の出力は符号器１１５へ供給される。他の例、例えばいくつかのストリーミングアプリケーションにおいて、鍵の組は、ストリーム内のデータの各ブロックについて再利用および固定されてもよい。

[0027] 符号器１１５は、入力シンボル生成器から供給された入力シンボルから値Ｂ（Ｉ）を生成するとともに、鍵生成器１２０から供給された各鍵Ｉからシンボルを生成する。各出力シンボルの値は、その鍵と、ここにおいて出力シンボルの「関連した入力シンボル」あるいは単にその「関連要素」と称される１以上の入力シンボルのいくつかの機能とに基づいて生成される。典型的には、常にではなく、Ｍは入力シンボルと出力シンボルとに対して同じである、つまり、それらは両方ともビットと同じ数に対して符号化する。

[0028] いくつかの実施例では、入力シンボルの番号Ｋは入力シンボルの番号Ｋは関連要素を選ぶために符号器によって使用される。もし、入力がストリームであってＫがストリーム内の各ブロック間で可変である場合のように、Ｋが予め知られていない場合、Ｋは単に推定値であってもよい。値Ｋは、入力シンボルへストレージを割り付けるために符号器１１５によっても使用されても良い。

[0029] 符号器１１５は、送信モジュール１４０へ出力シンボルを供給する。送信モジュール１４０は、鍵生成器１２０からそのような出力シンボルのそれぞれの鍵を供給される。チャネル１４５を通過して受信モジュール１５０へ、送信モジュール１４０は出力シンボルを送信し、使用されるキーイング方法に依存して、送信モジュール１４０は送信された出力シンボルの鍵についてのいくつかのデータも送信する。チャネル１４５は消去（erasure）チャネルであると仮定されるが、それは通信システム１００の適切なオペレーションのための要求ではない。送信モジュール１４０がチャネル１４５のためのそれらの鍵についての任意の必要なデータおよび出力シンボルの送信に適合し、受信モジュール１５０がチャネル１４５からそれらの鍵についての潜在的ないくつかのデータおよびシンボルの受信に適合する限り、モジュール１４０、１４５および１５０は、任意の適切なハードウエア、ソフトウエア、物理メディア、あるいは、それらの組み合わせでもよい。Ｋの値は、関連要素を決定するために使用される場合、チャネル１４５を通過して送られてもよく、あるいは、復号器１５５と符号器１１５と一致により、予め設定されてもよい。

[0030] チャネル１４５は、あるポイントから別のポイントへの電話コネクションやテレビジョン送信器からテレビ受像機への放送リンクあるいはインターネットを介するパスのようなリアルタイムチャネルであっても良く、また、チャネル１４５はＣＤ−ＲＯＭ、ディスクドライブ、ウェブサイト等のようなストレージチャネルであっても良い。パーソナルコンピュータからインターネットサービスプロバイダ（ＩＳＰ）へ電話回線を通して１つの入力ファイルを送信したとき、その入力ファイルがウェブサーバーに保存され、その後インターネットを通して受信者へ送信されるチャネルのように、チャネル１４５は、リアルタイムチャネルとストレージチャネルとの組み合わせあってもよい。

[0031] チャネル１４５がパケットネットワークを含む場合、通信システム１００は、チャネル１４５を通じた送信において任意の２以上のパケットの相対的な順序（relative order）が維持されることは想定することができない。したがって、出力シンボルの鍵は１以上の上述のキーイングスキーム（keying scheme）を用いて決定され、出力シンボルが受信モジュール１５０を出た順序で必ずしも決定されない。

[0032] 受信モジュール１５０は、復号器１５５へ出力シンボルを供給し、受信モジュール１５０が受信するこれらの出力シンボルの鍵に関する任意のデータは鍵再生成器１６０へ供給される。鍵際生成器１６０は、受信された出力シンボルのための鍵を再生成し、これらの鍵を復号器１５５へ供給する。復号器１５５は、入力シンボル(再び IS(0), IS(1), IS(2), ...)を回復するために、鍵再生成器により供給されたその鍵を対応する出力シンボルとともに使用する。復号器１５５は、回復された入力シンボルを、入力ファイル１０１のコピー１７０又は入力ストリーム１０５のコピー１７５を生成する入力シンボル再組立器１６５へ供給する。

[0033] メディアストリーミングアプリケーションにおいて使用される場合、ソースメディアストリームを形成するソースパケットはソースブロックと呼ばれるグループに時々集められる。例えば、ソースブロックは時間の固定長を測定するソースパケットのグループでありえ、例えばリード・ソロモン消去コードは、ソースブロックのオリジナルソースパケットと合わせて受信器へ送られたリペアパケットを生成するためにこれらのソースブロックへ独立に適用され得る。

[0034] 送信器（sender）では、ソースストリームは、ソースパケットが到着したときにソースブロックへ連続的に分割され、そして、リペアパケットは各ソースブロックに対して生成されて送られる。特に、ライブあるいはインタラクティブストリームアプリケーションについて、ＦＥＣコードの使用により追加される末端間遅延を最小化することはより好ましく、したがって、ＦＥＣソリューションのデザイン全体が、送られる前の送信器においてソースパケットができる限り遅延が少ないような場合、ソースブロックに対する全てのソースおよびリペアパケットができるだけ総遅延が少なく送られることが好ましい。ＦＥＣ符号化ストリームのレートができるだけ円滑であることも好ましく、すなわち、これはＦＥＣ符号化ストリーム帯域幅用法をより予測可能にし、ネットワークおよび他の競合し得るストリーム上のインパクトを最小化するため、ＦＥＣ符号化ストリームレートにおける変動ができるだけ小さい、あるいは、オリジナルソースストリームにおいてすでに存在する変動がすくなくとも拡張することがないことが好ましい。パケットにおいて、ソースブロックへ送られたデータが、パケットがソースブロックへ送られた期間に渡ってできるだけ一様に広がることが好ましく、これはバースト損失（burst losses）に対する最良の保護を供給するからである。

[0035] 受信器（receiver）では、パケットが失われ、（例えばＣＲＣチェックを使用して、検知され廃棄され得る）エラーとともに受信された場合、十分なリペアパケットが受信されたと仮定して、リペアパケットは１以上の損失ソースパケットの回復のために使用されてもよい。

[0036] いくつかのアプリケーションにおいて、パケットはＦＥＣプロセスが適用されるシンボルにさらに細分される。いくつかのＦＥＣコード、とくにリード・ソロモン符号について、符号化および復号化時間はソースブロック毎の符号化シンボルの数が増大すると非実用的に増大し、ソースブロック毎に生成され得る符号化シンボルの総数における上限がある。シンボルは、アプリケーション層で使用される異なるパケットペイロード内に一般的に位置しているため、これが実質的な上限をソースブロックの符号化上の最大長に拘束し、これがもちろんソースブロック自身のサイズ上の上限をも拘束する。

[0037] 多くのアプリケーションのために、保護は長い期間に渡って提供されることである場合、あるいは、メディアストリームレートが高い場合、１パケット当たり１つのシンボルを搬送することによりサポートされ得るよりも大きなソースブロックサイズに渡って保護を提供することは有利かもしれない。これらの場合では、より短いソースブロックを使用し、異なるソースブロックからソースパケットをインターリーブ（interleave）することは、個々のソースブロックからのソースパケットが大きな期間にわたって広げられる解決策を提供する。別の関連方法は、パケットに適合しないより大きなシンボルから大きなソースブロックを形成し、連続するパケット内に入れられるサブシンボルにシンボルを分割することである。この方法を使用すると、シンボルに対する損失パターンあるいは潜在的な異なるサブシンボル損失を有することの犠牲（expense）において、より大きいソースブロックが維持され得る。しかしながら、チャネルが強く関連する損失あるいはバースティー（bursty）を示す多くの場合において、シンボルを備えるサブシンボルの破損あるいは損失は高度に関連し、したがって、この方法を使用するときのＦＥＣ保護の低下はほとんどない。
・用語（Terminology）
・ＦＥＣコード
[0038] この記述では、我々は、符号化されるデータ（ソースデータ）は同じ長さであって、（シングルビットまでの）任意の長さでありえる「シンボル（symbol）」へ分割される。各パケット内に包含されあるいは明白に搬送されたすべてのシンボルの数とともに、シンボルはパケット内のデータネットワーク上で搬送されることが可能である。ある場合には、ソースパケットはシンボル長の倍数（multiple）でないことがあり得、その場合にはパケット内の最後のシンボルは切り捨てられてもよい。この場合、ＦＥＣコーディングのために、この最後のシンボルは黙示的に固定されたビット、例えばゼロ値ビットのパターンから引き延ばされたと推定され、これらのビットはパケット内に搬送されなくても受信器は最大限のシンボルの外にこの最後の切り捨てられたシンボルを満たすことができる。他の実施例では、ビットの固定されたパターンはパケット内に置かれることができ、それによって、パケットの長さと等しい長さへシンボルを有効に詰め込むことができる。シンボルのサイズはしばしばビットで測定することが可能であり、シンボルがＭビットのサイズを有している場合にはシンボルは２Ｍシンボルのアルファベットから選択される。非２進法数字も熟考されるが、それらがより一般的に使用されるため２進数のビットが好まれる。

[0039] ここでストリーミングのために我々が考慮するＦＥＣコードは、典型的に系統的（）なＦＥＣコードであり、すなわち、ソースブロックのソースシンボルはソースブロックの符号化の一部に含まれ、したがってソースシンボルは送信される。その後、系統的なＦＥＣコードはソースシンボルのソースブロックから若干のリペアシンボルを生成し、そして、ソースおよびリペアシンボルの組み合わせはソースブロックへ送られたシンボルの符号化である。ＦＥＣコードは、必要な分のリペアシンボルを効率的に生成する機能を有している。そのようなコードは「情報添加コード（information additive code）」および「起源コード（fountain code）」と称され、これらのコードの例は「連鎖反応コード（chain reaction code）」および「多段連鎖反応コード（multi-stage chain reaction code）」を含む。

[0040] リード・ソロモンコードのような他のＦＥＣコードは、限定された数のソースシンボルから限定された数のリペアシンボルだけを生成することが実質的に可能である。これらのタイプのコードについて、ソースブロックはなお比較的大きく、ソースブロックは、ソースブロックのソースシンボルの数が最大でソースシンボルの実用的な数の上限となり、ソースブロックから生成されるリペアシンボルの望まれる数は最大でリペアシンボルの実用的な数の上限となるように、十分な大きさのシンボルに分割される。これらのシンボルが物理層パケットの送信のための適切なサイズよりも大きい場合には、シンボルはそのようなパケットにおいて個々に搬送され得るサブシンボルへさらに分割されてもよい。後の説明を単純化するために、シンボルは分割不可能なユニットとして典型的に説明され、しかし多くの場合においてシンボルは複数のサブシンボルで構成されてもよく、ここで、説明においてシンボルはサブシンボルへ分割されてもよく、結果として生じる方法およびプロセスはシンボルを用いた説明とまったく同様であるだろう。

[0041] パケット内でシンボルを搬送するための多くの他の方法があり、下記の説明はこの例を単純化するために使用するが、それは限定することおよび包括することを意味するものではない。以下の説明の文脈では、「パケット」という用語はデータの単一ユニットとして送られるものを文字通り意味することを拘束される意味ではない。代わりに、それは、データの単一ユニットとして送られても送られなくてもよい部分的なシンボルと、シンボルの論理的なグルーピングの定義との広い概念を含むことを意味する。

[0042] シンボル、例えば他の方法において破損されたあるいは送信中にそれらの値が変わったシンボルの損失以外のデータの破損の形態があり、以下に説明される方法が等しく適用される。したがって、下記の説明はシンボルの損失についてしばしば説明し、その方法は他のタイプの破損、および、ＦＥＣ誤り訂正コードやＦＥＣチェックサムコードやＦＥＣ検証コードのようなＦＥＣ消去コード以外の他のタイプのＦＥＣコードに等しくよく適用する。
・ストリーミング
[0043] ソースストリームのＦＥＣ保護を提供する目的のために、ソースストリームは１以上の論理ストリームの組み合わせ、例えば、オーディオＲＴＰストリームとビデオＲＴＰストリームとの組み合わせ、ＭＩＫＥＹストリームとＲＴＰストリームとの組み合わせ、２以上のビデオストリームの組み合わせ、および、コントロールＲＴＣＰトラヒックよＲＴＰストリームとの組み合わせであってもよい。送信器にソースストリームが到着したときに、例えばソースビットストリーム、ソースシンボルストリーム、あるいは、ソースパケットストリームであるフォーマットでは、送信器はソースブロック内にストリームを一時記憶し、ソースブロックからリペアストリームを生成してもよい。送信器は、例えばパケットネットワーク上に送られるパケット内で、リペアストリームおよびソースストリームを送り、予定（schedules）する。ＦＥＣ符号化ストリームはソースおよびリペアストリームの結合である。受信器は、例えば損失あるいはビット反転（bit-flips）により破損されたかもしれないＦＥＣ符号化ストリームを受信する。受信器は、ソースストリームの全てのオリジナルソースブロックあるいは一部を再構築することを試み、受信器において例えばメディアプレイヤーにオリジナルストリームのこれらの再構築された一部を利用可能にさせる。

[0044] ストリーミングアプリケーションについて、ソースストリームを保護するためにＦＥＣコードを使う方法の設計への入力であるいくつかの鍵パラメータ（key parameters）と、最適化するために典型的に重要であるいくつかの鍵メトリクス（key metrics）とがある。

[0045] 設計において２つ鍵入力パラメータは、保護期間（protection period）と保護量（protection amount）である。ソースブロックのための送信器の保護期間（sender protection period）は、ソースブロックから生成されたシンボルが送られるときの期間である。ソースブロックのための保護量は、ソースブロックにおけるソースブロックの数のパーセンテージあるいは比として表現される、ソースブロックへ送られるＦＥＣリペアシンボルの数である。例えば、保護期間が２秒で保護量が２０％でソースブロックに１０，０００ソースシンボルがある場合。１０，０００ソースシンボルとソースブロックのための２，０００リペアシンボルとが２秒の時間ウィンドウ（window of time）に渡って送られる。ソースブロック辺りの保護量と保護期間との両方は、次の１つのソースブロックとは異なることが可能である。例えば、ソースブロックはソースストリームにおけるあるソースパケット間に渡らないことが好ましく、例えば、最初のパケットはＭＰＥＧ２ビデオストリームにおける画像群（ＧＯＰ）の最後のパケットであり、２番目の連続したパケットは次のＧＯＰの最初のパケットであるとき、これが保護期間の最後よりも前に生じたとしてもソースブロックは２番目のパケットより前であって最初のパケットよりも後で終了してもよい。これは、ＦＥＣ保護ブロックがビデオコーディングブロックと提携することを可能とし、ビデオバッファリングおよびＦＥＣバッファリングによる受信器の待ち時間（latency）を最小化することができる長所を含む、多くの長所を持つことが可能となる。他のアプリケーションでは、それは各連続するソースブロックについて同じ保護期間および／またはソースブロックサイズをいつも維持するための様々な理由において有利になり得る。下記の説明の多くでは、単純化のために、保護期間と保護量との両方は後のソースブロックのそれぞれについて同じであると仮定される。当業者にとって、これが限定でないことは明らかであるべきであり、保護量あるいは保護期間のどちらかが又は両方が１つのソースブロックから次へ変化するとき、および、ソースブロックサイズが１から次へ変化するとき、この開示を読むことでどのようにここに説明された方法およびプロセスが適用されるか容易に判断することができる。

[0046] 後の議論のいくつかを単純化するために、オリジナルストリームのソースシンボルは安定したレートでＦＥＣコーディングを行う送信器へ到着し、一旦受信器が最初にソースシンボルを受信器で利用可能とし、次に後のソースシンボルが同じ安定したレートで受信器により利用可能になり、ソースシンボルが受信された最初のソースブロックにおいて、ソースシンボル損失がなくそして後のソースブロックのそれぞれにおいて符号化シンボル損失はうまくいくＦＥＣ復号をさせるための最大の可能性であるという仮定が、しばしば仮定される。この単純化する仮定は、後に説明された方法およびプロセスのデザインあるいはオペレーションにおいて固有ではなく、任意の方法でこの仮定にこれらプロセス限定することを目的としないが、方法およびプロセスのプロパティの説明のいくつかを単純化するためのツールとして単に導入される。例えば、可変レートストリームについて対応する条件は、送信器にそれらが到着するときと同じレートに近いあるいは同じで、ソースシンボルが受信器によって利用可能となることである。

[0047] 最小化するべき重要性のいくつかの鍵メトリクス（key metrics）は、送信器により導入された待ち時間である送信器待ち時間を含む。送信器待ち時間の最小化は、ビデオ会議のようなインタラクティブアプリケーションあるいはライブビデオストリーミングのようないくつかのアプリケーションにとって望ましい目標である。送信器待ち時間を最小化することを支援する全てのデザインの一態様は、送信器へそれらが送信器に届くときと同じ順序でソースシンボルを送ることである。送信器待ち時間を最小化する他のデザインの態様は後述される。

[0048] 別の重要な測定法はチャネルザッピング時間である。これは受信器がストリームを要求あるいは結合するときと、受信器がストリームから利用可能なソースシンボルを最初に生成するときまでストリームから符号化シンボルの受信を最初に開始するときとの間の時間である。例えばビデオストリームの再生について、ストリームが最初に利用可能になり始めるときと、ストリームが結合されるときとの間の時間も最小化し、それらが受信器により復号され渡される前にこれが受信器におけるストリーミングシンボルのためのメモリ要求を最小化するため、一般に、チャネルザッピング時間を最小化することがのぞましい。

[0049] 多くの既知のシステムについて、チャネルザッピング時間を最小化する重要な一態様は、送信器のためにソースシンボルのオリジナル送信順序（original sending order）を維持することである。後のセクションでは、我々は、ブロック内でソースシンボルを順序化し符号化（ordering and encoding）する新しい方法、ＦＥＣコードを適用すること、および、チャネルザッピング時間を最小化する方法において符号化データを各ソースブロックへ送信することを説明する。

[0050] 我々がいま説明するように、多くの既知のシステムにとって、チャネルザッピング時間は典型的に多数のコンポーネントを備えている。連続するソースブロックへ分割されるストリームのためのこれらのコンポーネントの一例は、図２に示される。図２は、各ソースブロックのための保護シンボルがそのソースブロックのためのソースシンボルの直後に送られる保護期間毎の単一のソースブロックがある古典的なＩＰＴＶ配置において使用されるかもしれないデザインを示し、例はソースブロックの開始において受信器がストリームを結合する場合を示す。この例におけるチャネルザッピング時間の２つのコンポーネントは保護期間と復号待ち時間（decode latency）である。受信器保護期間は受信器がソースブロックから受信された符号化シンボルをバッファする間の時間である。仮に送信器と受信器との間のチャネルが各ビット、バイト、シンボルあるいはパケットが送信器から受信器へ移動するためにかかる時間の量の期間における変化がない場合、送信器保護期間と受信器保護期間とは同じであることに注意する。したがって、事実上、送信器保護期間は配信におけるネットワークタイミング変化により同じソースブロックについて受信保護期間と異なっていてもよい。説明の単純化のために、我々は送信器保護期間と受信器保護期間とは各ソースブロックについて同じであると以下で仮定し、我々は送信器保護期間と受信器保護期間とに対して同じように「保護期間」という用語を使用する、つまり、ネットワーク配信時間は全てのデータについて同じであると我々は仮定し、当業者はネットワーク配信変動による送信器および受信器保護期間における差を考慮して、ここにおいて説明された装置および方法への必要な変更をすることができると我々は注意する。

[0051] 最初のソースブロックにおいていずれのソースシンボルの損失がない場合であっても、当業者は、後のソースブロックにおいて符号化シンボルの損失があるとき全ての後のソースシンボルの円滑なソースシンボル配信を保証するために、少なくとも保護期間の間、ソースシンボルを利用可能とし遅らせなければならないため、受信器待ち時間の保護期間コンポーネントは、これらの既知のシステムにおいて避けられない。保護期間中に、ソースブロックのいくつかあるいは大部分あるいは全てのＦＥＣコーディングは符号化シンボルの受信と同時に生じうる。保護期間の最後において、ソースブロックの最初のソースシンボルが受信器から利用可能となる前に生じる付加的なＦＥＣ復号があり得る、この期間は図２における復号待ち時間（decode latency）として名称付けられる。さらに、最初のソースシンボルが利用可能となった後であっても、ソースブロックの２番目および後のソースシンボルが利用可能となる前に生じる付加的なＦＥＣ復号があり得る。簡単のために、この付加的な復号は図２に示されず、この例において十分に速いレートで１番目の後の全てのソースシンボルを復号するための十分に利用可能なＣＰＵ資源があると仮定される。

[0052] これら既知のシステムにおいて、受信器がソースブロックの真ん中のストリームを結合しようとするとき、送信器によりソースパケットのオリジナル送信順が維持される限り、チャネルザッピング時間は最初の部分的なソースブロックからのソースシンボルの損失がないときの復号待ち時間と保護期間との和と同じくらい小さくなり得る。したがって、これらの既知のシステムについて、ソースシンボルのオリジナル送信順を維持することは送信器によって望ましい。

[0053] ストリーミング方法の別の目標は、ＦＥＣ復号が実行された後、受信器における再生にそれが利用可能であるときと、ソースパケットＦＥＣ符号化が実行される前に送信器においてソースパケットがストリーミングのために準備されるときとの間に、ＦＥＣの使用により導かれる待ち時間の全体で最悪の場合であるＦＥＣ末端間の待ち時間を最小化することであって、
[0054] ストリーミング方法の別の目標は、ＦＥＣが使用されるときの送信レートにおける変動を最小化することである。この目標の１つの理由は、パケットネットワーク内では、変動する送信レートでのストリームは、ストリームの送信レート内のピークが制限された容量でネットワーク内のポイントで他のトラヒックでピークと一致するときのバッファオーバフローあるいはデータ過剰によるパケット損失により影響を受けやすいことである。最小では、ＦＥＣ符号化ストリームのレートの変動はオリジナルソースストリームのレートの変動よりも悪くないべきであり、望ましくは、ＦＥＣ保護がオリジナルソースストリームへより適用されると、ＦＥＣ符号化ストリームのレートの変動がより小さくなる。特別の場合として、仮にオリジナルストリームが一定レートで送られる場合、ＦＥＣ符号化ストリームも一定数にできるだけ近いレートで送るべきである。

[0055] ストリーミング方法の別の目標は、受信器で出来るだけ単純なロジックで使用することである。受信器は限定されたコンピュータ計算のメモリおよび他の資源能力を持つ装置内に構築されるため、これは多くの事情において重要である。さらに、いくつかの場合において、送信におけるシンボルのかなりの破損あるいは損失があるかもしれず、したがって、受信器は、コンディションが改善するとき受信が継続しているストリーム内から理解するための状況がなくあるいは殆どない壊滅的な損失あるいは破損シナリオから回復しなければならないかもしれない。したがって、より単純でより強い受信器ロジックはより速く確実な受信器はストリームの受信からソースストリームのソースシンボルを再び利用可能とし、回復し始めることが出来るだろう。

[0056] あるソースブロックへ送られるＦＥＣ符号化データが、他のソースブロックへ送られるデータがインターリーブされたより大きな期間に渡って送られるとき、ソースブロックへのＦＥＣ符号化データの送信は、チャネルにおける破損あるいは損失に対する最良の可能な保護を保証するためにできるだけ一様な時間に渡って発送されるべきである。

[0057] ソースブロックへのデータの送信は、タイムリーな様式において、決定された優先順で受信器がソースブロックのソースデータを回復することが出来るような状態であるべきである。

[0058] ストリームへ送られたデータは、ヘッダーオーバヘッドを最小化するために、ストリームに対応するできるだけ小さなヘッダー情報とともに送られるべきである。好ましくは、ストリームとともにヘッダー情報が送られず、ヘッダー情報のいくつかあるいは全てはシステムに埋め込まれた他の情報からすでに利用可能であるか、あるいはそれから導出される、および／又は、ヘッダー情報のいくつかあるいは全ては受信器における情報の到着のタイミングのような他の情報から推測され得る。

[0059] 次のセクションでは我々は、いくつかあるいは全てのこれらの目標に適合する装置、プロセスおよび方法について説明する。
・改善された送信および受信方法とプロセス
[0060] ある場合には、ブロックとして配信されるべきデータは優先させることが可能である。他の場合には、ブロックとして配信されるべきデータは必ずしも優先されない。いずれの場合も、データのオリジナルストリームはソースブロックに分割され、ＦＥＣリペアデータは個々のそのようなソースブロックのために生成され、個々のそのようなソースブロックのための、そのソースブロックから生成されたＦＥＣリペアデータとオリジナルソースブロックデータとを備える符号化データは、ソースブロックのオリジナルプレイアウト時間よりも長い時間に渡って広げられる（したがって後のソースブロックのための符号化データは互いがインターリーブされる）。これらの場合には、適用されるＦＥＣコードは望まれる保護量までデータの損失に対するストリーム内のデータを保護する消去コードであり得、さらに、エラーを訂正するコードであるＦＥＣコード、あるいはデータの完全性を証明するために使用され得るＦＥＣコードのような他のタイプのＦＥＣコードも熟考するものである。これらの場合には、保護期間と称されるソースストリームの個々のソースブロックのための符号化データが送信される時間が長くなると、保護期間に渡って符号化データがより均等に広げられ、アプリケーション層ＦＥＣコードにより提供されたパケット損失に対する保護のレベルが良くなる。

[0061] 本発明の一実施例では、符号化データの送信は等しいサイズ、例えば１２０バイト毎、ここでは物理層パケットと称される中の物理チャネルに送られる。物理層パケットは、破損から物理層パケットそれぞれを保護するためにそれらに適用された物理層ＦＥＣコードを有していてもよい。ある場合には、物理層パケットの数は、スロット、例えば５１２の物理層パケットについて、等しい数の物理層パケットのスロットへ分割される。物理層のプロトコルは、時々、各タイムスロット内の物理層パケットを区別し、独自に認定することが出来る。これらの場合には、ＦＥＣシンボルは物理層パケットに直接マップされることができ、さらに、物理層パケットで搬送されるシンボルの識別は、シンボルデータとともに各物理層パケット内でシンボル識別データを搬送するための必要性を完全に取り除くこと、必要性を軽減すること、あるいは、物理層パケットの同一性を決定する方法により完全にあるいは大部分が決定され得る。ある場合には、シンボル識別データの部分的な量、あるいは、シンボルが生成されるソースブロックあるいはストリームの部分についてのいくつかの情報は、シンボルとともに物理層パケットに搬送されることが好ましい。例えば、１２１バイトの物理層パケットについて、１バイトのそのようなシンボル識別データがあってもよく、シンボルサイズは残りの１２０バイトであってもよく、一方で、オリジナルソースストリームからシンボルがどのように生成されたか完全に判断することは、例えば物理層を含むフレームおよび／または物理層パケットの受信タイミングにより、および／または、物理層パケットを含むフレームの識別子による、および／または、フレーム内の物理層パケットの位置によって、物理層パケットが独自に識別された方法およびシンボルとともに物理層パケット内に搬送されたシンボル識別データの組み合わせのからであるかもしれない。例えば、ソースシンボルが由来する多数のストリームのストリームにより分類された、および／または、ソースブロックの部分が一部であるデータの優先により分類されたソースブロックの例えば異なる部分から、１バイトの識別子は、シンボルが由来するソースブロックの部分を識別する。

[0062] 例えば「ＦＥＣストリーミング」で説明されたように、仮にソースパケットよりも前にリペアパケットが送られる場合、ある改良は上記プロセスに成すことが可能である。ソースパケットは一般にリペアパケットの後に送られるためバッファに保存されるため、このアプローチは送信器において付加的な遅延の注入する損害がある。別の例として、リペアデータは全てのまたは一部のソースブロックのいずれかから生成され得る。例えば、リペアデータの部分は、ソースブロックの全体から生成されてもよく、他の部分は１以上のソースブロックの他の優先層から生成されてもよい。１以上の物理層パケットに渡り得るアプリケーション層パケットまたは物理層パケットにシンボルとともに搬送された識別シンボルデータがある場合、リペアシンボルのためのこの識別シンボルデータの部分はそれが生成されたソースブロックの部分を識別するかもしれない。
・シグナリング方法
[0063] いくつかの実施例では、各シンボルについて、シンボルに関連するヘッダーデータ、例えばヘッダーデータの１バイトは、そのシンボルについての信号情報、例えばもし１ストリーム以上ある場合にはストリーム識別子、もし１以上の物理層ブロックに渡って送られるべきソースブロックがある場合にはセグメント識別子、もしソースブロックが多数のサブブロックを備える場合にはサブブロック識別子、ソースブロック内のシンボルのシンボル順によるソースブロック内のシンボルの位置、等のために使用され得る。いくつかの実施例では、いくつか又は全てのこのヘッダーデータは物理層パケットにおける各シンボルとともに送信され得る。他の実施例では、各シンボルのためのヘッダーデータは、主としてあるいは殆ど他の情報から得られ、物理層パケット内で各シンボルとともに送られるヘッダーデータはない、あるいは殆どない。
・ソースブロック内のシンボル
[0064] 好ましくは、ソースブロックのシンボルの順序は、明示的にあるいは暗黙のいずれかに決定され、受信器と送信器と同じ順序である。順序におけるある他の望ましい特性は、時々、ストリーミングあるいはオブジェクト配信アプリケーションに有益である。好ましい特性は、例えば、ソースブロックのシンボルの順序は、全てのリペアシンボルが続く順で最初に全てのソースシンボルを有する。別の例は、シンボルはソースブロックのサブブロック構造により決定された順である、例えば、全てのソースブロックの最初のサブブロックに関連する全てのシンボルが最初に順序付けされ、ソースブロックの２番目のサブブロックと関連する全てのシンボルが２番目に順序付けされる等である。以前に説明したように、シンボルは多数のサブシンボルを備えていても良い。
・ソースブロック内のＥＳＩ
[0065] ＥＳＩ（符号化シンボル識別子（encoded symbol identifier））は、ソースブロックにおいてソースシンボルの数のような他の情報と協同するいくつかの場合では、シンボルがソースブロックからどのように生成されるか決定する任意の識別子である。ＥＳＩは、送信器においシンボルを生成するために、あるいは、受信器においてシンボルを回復するおよび／又は識別するために明白に使用され得る、又は、ＥＳＩは暗黙に使用され得る。好ましくは、各ソースブロックのシンボルは、送信器と受信器とがシンボル順序内のシンボルの位置から得られるシンボルのＥＳＩを決定し得る方法で順序付けられる。例えば、シンボルはソースブロックのシンボル順でｊ番目のシンボルである場合、ｊが正整数であり、そのシンボルのＥＳＩがｊである場合であるかもしれない。

[0066] 好ましくは、しかし排他的でなく、シンボルのＥＳＬ間の配置およびシンボル順序は、送信器と受信器との両方により容易に計算することが出来る。例えば、順序付けされたシンボルの組みの連続するＥＳＩは、０、１、２、３、・・・ｊ、ｊ＋１、等であってもよく、すなわち、ＥＳＩはゼロで始まる連続する整数列であり、この場合では、したがってシンボル位置はＥＳＩと同じである。別の例として、順序付けされたシンボルの組の連続するＥＳＩは、５、１０、１５、２０、・・・、５＊ｊ、５＊（ｊ＋１）、等である。シンボル順序内でシンボル位置が与えられたシンボルが与えられるためのＥＳＩを決定することを受信器と送信器との両方が可能とする順序付けされたシンボルの組のＳＥＩの配置を決定する多くの他の方法がある。好ましくは、送信器と受信器との両方により計算することが容易であるＥＳＩシーケンスは、ソースブロックと関連するシンボルのシンボル順を表現するためにしようされ得る。
・物理層ブロック内の物理層パケット
[0067] 物理層パケットが物理層ブロックで送られるとき、物理層ブロック内での物理層パケットの順序付けは全体的な構造の特性によりしばしば決定され得る。さらに、別の物理層ブロックからある物理層ブロックの区別は、例えば物理層シグナリングとタイミング情報とに基づいて、送信器および受信器により決定され得る。順序付けられたシンボルは、線形一致マッピングを含む様々な異なる方法を使用する、あるいは、連続するシンボルが、物理層ブロックの送信内で時間変化に富んだ方法で送信される物理層パケットへ配置されることを保証するマッピングを使用する物理層パケットへ配置されてもよく、例えば各連続するシンボルは、物理層ブロックの送信の異なる時象限で送られた物理層パケットに配置され、あるいは、連続するシンボルは主として異なる周波数の組（divergent sets of frequencies）で物理層パケットへ配置される。物理層ブロックで送られるべき順序付けされたシンボルの組は、全てのセグメント識別子の数が１以上であってもよい場合に、３番目のセグメント識別子と関連するシンボルが後続する、２番目のセグメント識別子と関連するシンボルが後続する１番目のセグメント識別子と関連するシンボル、等で構成されてもよい。各セグメント識別子と関連するシンボルの中で、シンボルはＥＳＩを連続的に増加させることにより順序付けされるかもしれない。望ましい特性は、物理層ブロック内で物理層パケットと順序付けされたシンボルとの間をマッピングがよく知られている（明示的にあるいは暗黙に）、および、送信器および受信器により決定することが容易であることである。

[0068] 前に説明したように、シンボルは多数のサブシンボルで構成されてもよく、各物理層パケットは１以上のサブシンボルを搬送することが可能であってもよいが、シンボルを搬送するために十分大きくないかもしれない。この場合では、物理層パケットへシンボルをマッピングするためのプロセスおよび方法の前の説明は、この一層の考察を考慮に入れるために容易に修正され得る。例えば、ＥＳＩは、シンボルだけでなくシンボル内の特定のサブシンボルも識別するために修正されることが可能で、例えば、ＥＳＩはシンボルおよびサブシンボル識別子の両方である。別の例として、マッピングはシンボルのサブシンボルがいつも連続的に送られるような状態でもよく、順序付けられたシンボルから物理層パケットへのマッピングはシンボルの最初のサブシンボルを搬送する物理層パケットを識別する。

[0069] ある場合には、多くのシグナリングデータ（signaling data）は、物理層ブロック、例えば、物理層ブロックヘッダー情報内で搬送される他の情報、物理層ブロック識別子、および、物理層ブロック内で物理層パケットの位置からシンボルの順序付けにおけるシンボルの位置あるいはシンボルのＥＳＩを導く機能において利用可能であり得る。

[0070] 本発明のある実施例において、１つのシンボル、ソース又はリペアシンボルのいずれかは、ヘッダー識別データの最小の量とともに各物理層パケットにおいて搬送される。ソースブロックの順序付けられたシンボルの組は、送信器と受信器との両方に良く知られたプロセスを使用する物理層ブロック内で物理層パケットに連続して配置される。例えば、順序付けされた５１２シンボルの組は５１２の物理層パケットに連続して配置され得る。シンボルの順序付けは、送信器で決定され、帯域外で明白に受信器と通信するあるいは各ブロックのシンボルの順序を決定する前もって定義されたプロセスを通じて送信器と受信器との間で望ましくは暗黙に通信されることのいずれかが可能である。１以上のソースブロックに由来するシンボルが同じ物理層ブロック内に物理層パケットに配置されるべきとき、仮にソースブロックが順序付けされるならば、ソースブロックの順序とともに各ソースブロックについてのシンボルの順序付けは、物理層ブロック内で物理層パケットに配置されるべき全てのシンボルの順序付けを決定するために使用され得る。他の実施例では、多数のシンボルは各物理層パケットにおいて搬送される。まだ他の実施例では、シンボルは１つ以上の物理層パケットに渡ってもよく、例えば、シンボルがサブシンボルに分割されるとき各サブシンボルは物理層パケット内に搬送される。当業者は、ここに説明された方法およびプロセスがこれらの他の実施例にも適用可能であることを認識するだろう。

[0071] ある実施例において、物理層ブロックは異なる層でのブロック、例えば論理ブロックあるいはデータ、又は、データのアプリケーション定義ブロック、又は、送信ブロック、又は、メディア層ブロックであり得る。さらに、物理層パケットは送信パケット、又は、論理パケット、又は、アプリケーションパケット、又は、メディア層パケットであり得る。当業者はこれらの実施例の多くの本質的に等価な変形があることを認識するだろう。
・セグメント
[0072] ソースブロックに関連したソースおよびリペアシンボルは１以上の物理層ブロック内に送られることが可能である。ソースあるいはリペアシンボルのセグメント識別子は、好ましくは逆順で、ソースブロックの任意のシンボルを搬送する最初の物理層に比べてシンボルがどの物理層ブロックに搬送されるかを示すために使用されることが可能である。例えば、ソースブロックに関連した全てのシンボルは、セグメント識別子０を有し得るソースブロックの任意のシンボルを搬送する最後の物理層ブロックに搬送され、個々の前の物理層ブロック内の全てのシンボルのセグメント識別子は、そのソースブロックの任意のシンボルを搬送する後の物理層ブロック内のセグメント識別子よりも１大きいセグメント識別子を有することが出来る。全ての継続する物理層ブロックがそのソースブロックのシンボルを搬送する物理層ブロック内の特定のソースブロックのシンボルを搬送するとは限らないかもしれない、例えば、最初の物理層ブロックはシンボルをあるソースブロックへ搬送し、次の２番目の物理層ブロックはそのソースブロックへいずれのシンボルも搬送しないかもしれないが、次の３番目の物理層ブロックはそのソースブロックへシンボルを搬送するかもしれない。他の場合では、ソースブロックのセグメント構造は、別のソースブロックの新しいセグメントの開始およびあるソースブロックのあるセグメントの終わりを示すセグメント境界指標である物理層ブロック、又は、物理層パケットの順序内での例えば物理層パケット位置を示すことにより示されてもよい。例えば、最初の５００の物理層パケットは最初のソースブロックに由来するセグメントに対応し、次の６００の物理層パケットは２番目のソースブロックに由来するセグメントに対応し、残りの９００の物理層パケットは３番目のソースブロックに由来するセグメントに対応する、２０００の物理層パケットを備えた物理層ブロックについて、セグメント境界指標５００、６００は、最初のソースブロックのセグメントが最初の５００の物理層パケットに対応すること、２番目のソースブロックのセグメントが次の６００の物理層パケットに対応すること、そして、３番目のソースブロックのセグメントが残りの９００の物理層パケットに対応することを示すために使用されてもよい。あるいは、セグメント境界識別子はシンボルのユニットで表現されてもよく、物理層ブロック内でのシンボルの順序に関連して決定されてもよい。

[0073] ある好ましい実施例では、各物理層ブロック内で、各セグメント識別子に関連した高々１つのソースブロックがあり、したがって、セグメント識別子は異なるソースブロックに由来するシンボルの独自の区別のために使用されることが可能で、したがって、これらの場合にはセグメント識別子は物理層ブロック内に搬送されたシンボルを区別するためのソースブロック識別子として使用される。他の実施例では、シンボルのソースブロック識別子は他の手段、例えば、各シンボルに関連したヘッダー情報内のソースブロック識別子を含むこと、又は各物理層ブロックに関連したヘッダーデータ内のソースブロック識別子を含むことによって搬送される。ソースブロック識別子が物理層ブロックのヘッダー内で必ずしも搬送されないが、他の代替の場所、例えばコントロールデータストリーム、多数の物理層ブロックのヘッダー情報を含む個別の物理層ブロック内、あるいは、別のネットワークを介する送信で搬送されることが可能である他の変形がある。当業者は多くの同様の変形を認識するだろう。
・サブブロック
[0074] 符号化されたあるいは符号化されなかったソースブロックは１以上のサブブロック、例えば、論理的に関連したシンボルの部分に対応するソースブロックに関連した異なるソースおよびリペアシンボルに対応したサブブロックを備えていてもよい。例えば、１番目のサブブロックを備えた１番目のソースおよび／またはリペアシンボルの組は、ソースブロックに関連したビデオの部分の低解像度ビデオを表示するために使用することが出来るソースブロックの部分に対応してもよく、しかし。２番目のサブブロックを備える２番目のソースおよび／またはリペアシンボルの組は、１番目のサブブロックのいくつか又は全てとともに使用されたときソースブロックと関連したビデオの部分の高解像度ビデオを表示することが可能であってもよい。別の例として、サブブロック識別子はいくつか又は全てのソースブロックに関連したリペアシンボルを識別してもよく、あるいは、サブブロック識別子はいくつか又は全てのソースブロックに関連したソースシンボルを識別してもよい。ある場合には、サブブロック識別子は番号で明示的に各サブブロックにラベルを付すことにより示されてもよい。例えば、ソースブロックの１番目のサブブロックはサブブロック識別子０を有してもよく、しかし、ソースブロックの２番目のサブブロックはサブブロック識別子１を有してもよい。他の例では、サブブロック構造は、例えばシンボル順又はＥＳＩ内での新たなサブブロックの開始およびあるサブブロックの最後を示すサブブロック境界指標であるシンボル順内でのシンボルの位置あるいはＥＳＩを示すことにより示されてもよい。例えば、９００のソースシンボルと１００のリペアシンボルとを備えたソースブロックについて、シンボルのＥＳＩはゼロで始まる整数の連続であり、１番目のサブブロックはソースシンボルを備え、２番目のサブブロックはリペアシンボルを備え、サブブロック境界指標９００は１番目のサブブロックは０から８９９までのＥＳＩを有するシンボルに対応し、２番目のサブブロックは９００のＥＳＩを有するシンボルで開始することを示すために使用されてもよい。ソース又はリペアシンボルのサブブロック識別子はシンボルがどのサブブロックの部分かを示す。
・各シンボル方法で送信されたヘッダーデータ
[0075] 一実施例では、物理層パケット内のシンボルとともに送られるべき各シンボルに関連したヘッダーデータはセグメント識別子、サブブロック識別子、および、ＥＳＩを備えている。例えば、可能なセグメント識別子の数が８で、可能なサブブロック識別子の数が８で、ＥＳＩの数が１０２４である場合、ヘッダーデータの等しく２バイト、つまり１６ビットは各シンボルにとって十分である。物理層ブロック内の各物理層パケット内で、物理層パケットのコンテンツはシンボルに関連したヘッダーデータとともにシンボルを備え、ヘッダーデータはセグメント識別子とサブブロック識別子とを備える。

[0076] この実施例では、受信器は以下のように物理層ブロック内の受信された物理層パケットを処理するかもしれない。物理層ブロック内の物理層パケットの受信に際して、受信器はそれが可読である各物理層パケット内でシンボルに関連したヘッダーデータから決定する。ヘッダーデータから、受信器は物理層パケット内に含まれるシンボルのＥＳＩ、サブブロック識別子、およびセグメント識別子を決定することが出来る。セグメント識別子から、受信器はシンボルが可能なソースブロックの中に対応付けられるソースブロックを決定することが出来る。サブブロック識別子から、受信器はシンボルがソースブロックの可能なサブブロック内に関連付けられるサブブロックを決定することが出来る。ＥＳＩから、受信器は、ソースブロックに対するおよびソースブロックのサブブロックに対するシンボルの関係を決定することができ、ＥＳＩはソースブロック内のシンボルのシンボル位置を決定することに使用され、および／または、受信したリペアシンボルおよび他のソースシンボルから失ったソースシンボルを回復するためのＦＥＣ復号において使用されることが可能である。

[0077] 受信器は、その後、この情報に基づいてある行動を決定することが出来る。例えば、受信器は異なる目的のシンボルに関連したサブブロックを使用してもよい。例えば、サブブロックデータはソースブロックのいくつか又は全てを回復するためにどのようにＦＥＣ復号するか決定するため部分的に使用されてもよい。受信器内でより高いレベルの機能性をサポートする、例えば、マルチメディアの再生のためのマルチメディアプレイヤーへ全体として、受信されたソースブロックのどの部分上で渡すか決定するために、サブブロックデータは、上位層アプリケーション例えば、受信器内のマルチメディアプレイヤープロセスに、データの一部が渡されるべきであることを決定するためにしようされてもよい。例えば、受信器が１番目の物理層ブロックを受信したとき、１番目のセグメント識別子に関連したシンボルの部分は、１番目のセグメント識別子に対応したソースブロックに対応した低品質ビデオ部の再生のためにマルチメディアプレイヤーに渡されるかもしれない１番目のサブブロックに関連しているかもしれない。

受信器は、おそらくシンボルのサブブロックの組あるいはシンボルのサブブロックのユニットにおいて、メディアプレイヤーへ渡すこと、および／または、ＦＥＣ復号化のために、これらのシンボルを組み合わせ、後の物理層ブロックにおいて受信された同じソースブロックのために、シンボルとともにそれらを組み合わせるために、最初のセグメント識別子以外のセグメントとソースブロックに関連した回復されおよび／または抽出したシンボルを保存することも決定してもよい。

[0078] 当業者は、上記実施例の組み合わせおよび変形があることを認識するだろう。例えば、シンボルとともに送られるシンボルのヘッダーデータは、セグメント識別子とサブブロック識別子とを含み、ＥＳＩを含まなくてもよい。別の変形例として、ＥＳＩだけがシンボルとともにヘッダーデータ内で送信され、セグメント識別子あるいはサブブロック識別子のような他のデータが使用される場合は他のデータから決定される。
[0079] 他の変形例として、各シンボルに関連したヘッダーデータは、サブブロック識別子を含まなくてもよい。この場合、サブブロック識別子は、例えば、導出されたＥＳＩにより暗黙に決定されてもよく、あるいはサブブロックはソースブロックのセグメントと一致し、あるいは、サブブロッキングは用いられない。

[0080] 他の変形例として、各シンボルに関連したヘッダーデータはセグメント識別子を含まなくても、含んでもよい。この場合、セグメント識別子は、各物理層ブロック内で例えば固定された量の物理層パケットの配置により暗黙に決定されてもよく、あるいはサブブロックはセグメントと一致し、あるいは、分割することは用いられない。

[0081] 別の変形例として、各シンボルに関連したヘッダーデータはストリーム識別子も含んでもよい。この場合、ストリーム識別子は、ストリームの小さい数の中のどのストリームで、シンボルが例えばビデオストリームあるいはオーディオストリームと関連付けられるか決定してもよい。ストリーム識別子は例えば、ストリームが論理的に接続された場合に同じプログラムセグメントに対するオーディオおよびビデオストリームのような、他の識別子により算定されてもよく、例えばサブブロック識別子はストリーム識別子の全てあるいはいくつかを算定してもよいことに注意する。ストリーム識別子は、例えばストリームが論理的に独立している場合、異なるプログラムセグメントのためのオーディオ／ビデオストリームのような他の識別子を算定してもよく、例えばストリーム識別子はサブブロック識別子の全てあるいはいくつかを算定してもよい。
・各シンボル方法で送られたヘッダーデータがない
[0082] 別の実施例では、物理層パケットに搬送されたシンボルに関連したヘッダーデータはない。代わりに、ある最小のデータは物理層ブロックのヘッダーデータ内に搬送され得る。最小のデータは、例えば、セグメントテーブルを含むことができ、セグメントテーブルの各行は、物理層ブロックに搬送されたソースブロックのセグメントのシンボルの全ての中のソースブロックのセグメントのシンボル順序における１番目のシンボルのＥＳＩと物理層ブロックに搬送されたソースブロックのセグメントのシンボルの数を備えたセグメント識別子に対応する。例えば各セグメント内のシンボルの数がすべての物理層ブロックに渡っていつも同じであるため、セグメント内のシンボルの数はいくつかの実施例において含まれなくてもよい。

[0083] いくつかの実施例では、同じセグメント識別子が同じ物理層ブロック内で２以上のソースブロックに使用されるべきである場合において、セグメントテーブルはソーステーブルに代わってもよい。

[0084] 最小のデータは、例えば、いずれのサブブロックが物理層ブロック内に搬送された各ソースブロックのシンボルであるのかを示すサブブロックテーブルを備えることができる。このサブブロックテーブルのための多くの形式があり、例えば、サブブロック情報はセグメントテーブル内の適切なセグメント識別子行の各行に追加されてもよく、あるいは、別の例として、サブブロック情報が個別のテーブルに格納されてもよい。いくつかの実施例では、例えば、サブブロッキングが使用されないため、あるいは、サブブロッキングのシグナリングがより高いアプリケーション層で扱われるため、サブブロックテーブルは含まれなくてもよい。

[0085] この実施例では、受信器は、以下のような物理層ブロック内の受信した物理層パケットを処理するかもしれない。受信器は物理層ブロックヘッダーデータからサブブロックテーブルおよび／又はセグメントテーブルを読み格納する。セグメントテーブルから、受信器は物理層ブロックと共に搬送されたシンボルあるためにソースブロックの各セグメントに関連した初期のＥＳＩとシンボルの数とを決定することができる。シンボルを搬送する物理層パケットの位置の物理層識別子から、各セグメントに関連した初期ＥＳＩおよび数を含むセグメントテーブルから、および、物理層ブロックにおいて物理層パケットへ含まれたソースブロックの全てのセグメントから順序付けられ組み合わせられたシンボルの組のマッピングから、シンボルがどのソースブロックに関連付けられているかおよびシンボルのＥＳＩを決定することができる。サブブロックテーブルから、同様に受信器はソースブロックのそのサブブロックがシンボルと関連付けられているか決定することが出来る。

[0086] ＥＳＩから受信器は、ソースブロックのサブブロックとソースブロックとに対するシンボルの関係を決定することができ、ＥＳＩは他のソースシンボルおよび受信したリペアシンボルから受信されなかったソースシンボルを回復するためのＦＥＣ復号において使用されるべき、および／又は、ソースブロック内でシンボルのシンボル位置を決定するためにしようされることが出来る。

[0087] 受信器は、この情報に基づいて、ここに説明された「各シンボルと共に送信されたヘッダーデータ」方法として上述されたものを含むある動作を決定することが出来る。

[0088] 当業者は、上記の多くの変形があることを認識するだろう。一つの変形例として、各シンボルに関連したヘッダーデータは、例えばこの目的のために各物理層パケットの１バイトの部分を使用するサブブロック識別子を備えてもよい。サブブロック構造がソースブロック全体に渡るときこれはいくつかの場合において好ましいだろう、しかし、各シンボルとともに送られるヘッダーデータ内でサブブロック識別子をこのように搬送することは、ソースブロックの送信の最中にチャネルをつなぐ受信器がサブブロックのサブブロッキング構造を速く理解することを可能としてもよく、ソースブロックへのデータ送信はいくつかの物理層ブロックに渡ってもよい。

[0089] 別の例として、サブブロッキングは使用されなくてもよい。

[0090] 別の例として、各物理層パケットに関連したヘッダーデータは、例えば同じ物理層ブロック内で個別のデータとして送られ、あるいは、他の手段により受信器と通信され、あるいは、別の例として多数の物理層ブロックのヘッダーデータを含む個別の物理層ブロックで送られ、あるいは、別の例として他のネットワークを介して送られてもよい。

[0091] 別の例として、各シンボルに関連したヘッダーデータはストリーム識別子も含んでよい。この場合、ストリーム識別子は、ストリームの小さい数の中のどのストリームとシンボルが関連付けられているか決定してもよく、例えばオーディオストリームあるいはビデオストリームである。ストリーム識別子は他の識別子により算定さてもよく、例えば、ストリームが論理的に接続されている、例えば同じプログラムセグメントのオーディオおよびビデオストリームのような場合、例えばサブブロック識別子はストリーム識別子の全てあるいはいくつかを算定してもよいことに注意する。ストリーム識別子は他の識別子を算定してもよく、例えば、ストリームが論理的に独立している、例えば、異なるプログラムセグメントのオーディオ／ビデオストリームのような場合、例えばストリーム識別子はサブブロック識別子の全てあるいはいくつかを算定してもよい。ストリーム識別子は、サブブロック識別子とセグメント識別子とのための上述されたものと同様のフォーマットにおいて物理層ブロックのヘッダーデータ内に含まれてもよく、その場合では、受信器とストリーム構造を通信するための各シンボルに関連したヘッダーデータ内のストリーム識別子を含むことは必要ではないかもしれない。

[0092] 一例として、ソースブロック毎のセグメントの数が４であり、サブブロックの数が３であり、物理層ブロック毎の物理層パケットの数が５１２であり、１００バイト毎の３つのシンボルが３００バイトの各物理層パケットに含まれると仮定すると、各物理層ブロックは３＊５１２＝１５３６のシンボルを含む。そして、特定の１番目の物理層ブロックの１番目のセグメントテーブルおよび２番目の物理層ブロックの２番目のセグメントテーブルは図３に示されるようであってよく、２番目の物理層ブロックは１番目の物理層ブロックの後に連続的に送信される。この例において、セグメント識別子はセグメントテーブルに明示的に搬送されなくてもよいが、その代わり、テーブルの行数、すなわち、セグメント識別子ｊに対応する行ｊにより暗示されてもよい。

[0093] １番目のセグメントテーブルにおいて、識別子０のセグメントのシンボルの数は４５０であり、最初の４５０のシンボルが物理層パケットマッピングのための順序付けられたシンボルに従って配置された１５０の物理層パケットにより搬送されるだろう。この例では、セグメント識別子０のシンボルのＥＳＩは、０から４４９までの連続する整数である。識別子１のセグメントのシンボルの数は３００であり、３００のシンボルが物理層パケットマッピングのための順序付けられたシンボルに従って配置された最初の１５０物理層パケットの後に１００の物理層パケットにより搬送されるだろう。この例では、セグメント識別子１のシンボルのＥＳＩは４２０から７１９までの連続する整数である。

[0094] ２番目のセグメントテーブルにおいて、識別子０のセグメントのシンボルの数は４２０であり、最初の４２０のシンボルが物理層パケットマッピングのために順序付けられたシンボルに従って配置された１４０の物理層パケットにより搬送されるだろう。ｊ＝０、１、２について、１番目のセグメントテーブルにおいてセグメント識別子ｊのソースブロックは、２番目のセグメントテーブルにおいてセグメント識別子ｊ＋１のソースブロックと同じであることに注意する。したがって、１番目のセグメントテーブルにおいて識別子ｊのセグメントの初期のＥＳＩは、このマッピングの下で２番目のセグメントテーブルにおいて識別子ｊ＋１のセグメントのシンボルの数と初期のＥＳＩの和である。

[0095] データは物理層ブロックのヘッダーに必ずしも搬送されず、しかし、代わりの他の場所、例えば、コントロールデータストリーム、多数の物理層ブロックのヘッダー情報を含む個別の物理層ブロックへ伝送され得、あるいは、別のネットワークを介する送信され得る。当業者は上述の方法の多くの他の同様の変形を認識するだろう。
・ＦＥＣペイロードＩＤ間のマッピング
[0096] 例えば、コメント５０５２のためのインターネット技術特別調査委員会要求(IETF RFC 5052：Internet Engineering Task Force Request for Comments 5052)およびコメント５０５３のためのインターネット技術特別調査委員会要求(IETF RFC 5053：Internet Engineering Task Force Request for Comments 5053)で説明されたように、多くのアプリケーション層に対して標準に記述され、アプリケーション層内に送られたサブシンボルのグループあるいはシンボルのグループあるいはシンボルに典型的に関連したＦＥＣコードはＦＥＣペイロードＩＤ（識別子）である。最も単純な場合について、ＦＥＣペイロードＩＤはシンボルに関連し、ＦＥＣペイロードＩＤはシンボルが生成されたソースブロック数、シンボルのＥＳＩ、およびいくつかの場合では最小の関連したＥＳＩを伴うリペアシンボルの初期ＥＳＩ（この初期ＥＳＩは、ソースシンボルが２番目のサブブロックの部分としてのリペアシンボルおよび１番目のサブブロックの部分であることを識別する、サブブロック識別子としてみることができる。）とを備える。

[0097] 上述したプロセスおよび方法のいくつかにおいて、ＦＥＣペイロードＩＤは各シンボルとともに送られず、代わりの他の方法はチャネル容量を最大にするために各シンボルと共に送られるヘッダーデータの量を最小にすることを説明する。それは、この情報を受信器へ伝えるために上述された方法を使用するものへＦＥＣペイロードＩＦを使用するものから送信フォーマットを変換する送信器においていくつかの場合では有用である。さらに、それは、ＦＥＣペイロードＩＤを使用するものへ受信器にこの情報を伝えるための上述の方法を使用するものから送信フォーマットを変換する受信器においてもいくつかの場合に有用である。例えば、シンボルを識別するためのＦＥＣペイロードＩＤを使用するすでに開発されたソフトウエアがあるかもしれないし、上述された方法を使用する送信フォーマットと共存する関連したデータおよびシンボルのストリームの出力を生成するためのこのソフトウエアを使用して生成された関連したヘッダーデータおよびシンボルのストリームの出力をとることが便利かもしれない。

[0098] ＦＥＣペイロードＩＤ間のマッピング方法フォーマットは上に提供された記述から容易に導かれるだろう。
・チャネルザッピングを最適化する配列の送信
[0099] チャネル上で送られるべき優先されたストリームについて、ここで送られるべきデータは異なる物理層ブロック、例えばフレームあるいはスーパーフレームに分割され、ソースブロックへ送られるべきデータは、それらの優先の逆の順で、優先された方法におけるそのような複数の物理層ブロック上でインターリーブされることが可能である。例えば、「ＦＥＣストリーミング」において説明したように、ソースブロックのリペアデータは、これらの説明の文脈において、チャネルザッピング時間を減らすためにソースブロックのソースデータに対して優先に送られ得る。ソースブロックへ与えられた優先順位でデータを含むデータは、サブブロック内で一まとめにされ得る。例えば、上述の例を継続すると、リペアシンボルは優先度のより低いサブブロックであり、ソースシンボルは２番目に高い優先度のサブブロックであると考えられ、したがって、より低い優先度のサブブロックはより高い優先度のサブブロックに対して優先に送られ得る。

[0100] 図４は、一実施例がサブブロック内でデータを優先付けし、および優先付けした送信順でサブブロックを配置してもよい方法の一例を示す。図４では、データストリーム４７０はデータの様々なサブブロックおよびブロックで表される。例えば、データストリーム４７０は、P1-Px ４２０−４２２、 b1-bz４３０−４３５、および B1-By４４０−４４２のようなシンボルの様々なサブブロックおよびＩ−フレーム（ＺＩ）のような様々なビデオブロックおよびオーディオブロック４５０で示される。図４では、P1４２０はストリーム内の最も高い優先度のサブブロックを表し、b1-bz４３０−４３５、 B1-By４４０−４４２, P2-Px４２１−４２２、オーディオブロック４５０、 および I−フレーム (ZI)４１０がそれぞれ後に続く。これらの優先レベルを与えられると、ストリームのサブブロックおよびブロックは送信配列４８０により示されるように配列され得る。最も低い優先度のブロック（ZI４１０）は、送信の開始時に受信器へ送信されることが可能で、一方、最も高い優先度のデータ（P1４２０）は最後に送信され得る。さらに、様々なサブブロック間の従属性は送信順序の優先付けを生成するときに考慮に入れることも可能である。例えば、いくつかの実施例によれば、サブブロックｂ１、Ｂ１およびｂ２はＰ１に依存してもよい。これらの実施例では、Ｐ１が送信される前に、これらの依存するサブブロックを送信することが有利かもしれない。したがって、Ｐ１が受信されるとすぐに、その依存したサブブロックの全ておよびＰ１内のデータが受信器で速く利用可能とすることができる。一旦、送信配列が決定されると、送信配列は状況に応じて異なる物理層ブロックにデータを分割するためにしようされることができる。

[0101] 物理層ブロックへ優先付けられたサブブロックを配置して各物理層ブロックへサブブロックを配置するための一つの方法。図５は、この方法の１つの実施例の例を示す。図５は様々な物理層ブロック５０１−５０４内での壊れた１セットのデータ５００を示す。図５のブロックは、矢印５０９により示された方向で送信されるものとして表される。例えば、物理層ブロック５０１は、物理層ブロック５０４に先立って送信され（したがって、物理層ブロック５０４の前に送信され）、そして物理層ブロック５０１内でセクション５８０はセクション５２０に先立って送信される。図５に示されたように、データ５００のいくつかは、各物理層ブロック５０１−５０４内に配置される。各セグメントは各物理層ブロックの対応するセクション内に配置されるが、明確性のために、データ５００内のデータの各セグメントは物理層ブロック５０１−５０４の一つ内の配置のみを示す。ＦＥＣデータ５１０は、５２０−５２３で物理層ブロック内に配置され、Ｐ１データ４２０は５４０−５４３で物理層ブロック内に配置され、b1-bzデータ４３０−４３５は５３０−５３３で物理層ブロック内に配置され、B1-Byデータ４４０−４４２は５５０−５５３で物理層ブロック内に配置され、P2-Pxデータ４２１−４２２は５６０−５６３で物理層ブロックに配置され、オーディオデータ４５０は５７０−５７３で物理層ブロック内に配置され、そして、Ｉ−フレーム（ＺＩ）４１０は物理層ブロック５８０−５８３内に配置される。図５に示すような方法で物理層ブロック内にサブブロックを配置する１つの利点は、各物理層ブロック内に各優先グループのセグメントが含まれるため、受信器での再生動作がより予測可能となることである。しかしながら、様々な優先レベルが典型的には異なるデータ量を含むため、各物理層ブロック内での様々なセグメントが典型的には異なるサイズである。これは、データを解くために受信器でより複雑な処理により受信器で潜在的な性能の問題に先行することができ、異なるセグメントサイズによるスタット・マキシング（stat-muxing）の問題があるかもしれない。

[0102] 別の方法は異なる物理層ブロック上でできるだけ均等にシンボルデータを広げることであり、これは一般にチャネル悪化に対して最良の保護を提供する。図６はこの方法の一実施例の例を示す。図６は様々な物理層ブロック６０１−６０４内の壊れた１セットのデータ６００を示す。図６中のブロックは矢印６０９により示された方向で送信されることとして表される。例えば、物理層ブロック６０１は物理層ブロック６０４の前に送信され（したがって、物理ブロック６０４の前に送信され）、物理層ブロック６０１内でセクション６４０はセクション６１０の前に送信される。図６に示すように、シンボルデータ６００内で優先する様々なデータはブロック６０５−６０８内で一まとめにされる。ブロック６５０−６０８は、次に、等しい量で、物理層ブロック６０１−６０４へ配置される。明確性のために、データ６００の各セグメントは各物理層ブロックの対応するセクション内に配置されるが、物理層ブロック６０１−６０４の１つの中の配置のみを示す。例えば、ブロック６０５は６１０−６１３内に配置され、ブロック６０６は６２０−６２３内に配置され、ブロック６０７は６３０−６３３内に配置され、ブロック６０８は６４０−６４３内に配置され、図６に示された配置の結果、いくつかのサブブロックはグループ間に分離している。例えば、セグメントB1-By４４０−４４２からのデータはブロック６０６および６０７の両方内に含まれてもよい。さらに、与えられた物理ブロックは特定の優先度からのデータを含んでいなくてもよい。例えば、ブロック６０１は６１０でＦＥＣ５２０データを含んでいなくてもよく、一方、ブロック６０４は６１３でP1４２０からのデータを含んでいなくてもよい。図６に示された方法の１つの利点は、物理層ブロックのセグメントが同じサイズであるので、受信器はセグメントを解くためにより少ない処理を要求するであろうことである。これは受信器の性能の改善に帰着してもよい。さらに、一定のセグメントサイズは、スタット・マキシング（stat-muxing）をより簡単にする。しかしながら、所定の物理層ブロックに含まれる正確な優先レベルに関して保障がなく、受信器での再生動作はそれほど予測可能でなくなるかもしれない。

[0103] データをマッピングする間の関心事は、この高い優先順位データが受信されるとすぐに受信器が再生を開始可能とするために、ソースブロックの十分な高い優先順位のデータが1番目の物理層ブロックに送られることである。ここで、いくつかのソースブロックの高い優先順位のデータが、受信器が１番目の物理層ブロックを受信した後に利用可能となるべき場合に、Ｎはデータがソースブロックへ送られるべき物理層ブロックの数であり、これを構築するための１つの方法は、高い優先順位のデータの量がソースブロックへ送られるべきデータの総量の最大１／Ｎの比である方法のように符号化されたあるいは符号化されていないソースブロック内でデータを優先付けすることである。一般に、受信器がＫ物理層ブロックを受信した後に、データの最初のＪ優先順位がある１番目のソースブロックに利用可能となると仮定すると、最初のＪ優先順位におけるデータの比が最大でＫ／Ｎである場合に構築されることができる。

[0104] 好ましい分割ストラテジーの一例は下記であり、上記の方法が使用されても使用されなくても、使用することができる。ソースブロックへの送信データがＮ物理層ブロック内に送られることになっていると仮定すると、送信データは、もしあれば、送られるべきソースブロックから生成されたＦＥＣリペアシンボルおよびソースブロックのソースシンボルを備える。ソースブロックの送信データがＫ優先順位に分割されると仮定すると、優先順位ｊの送信データの比はｊ＝１、…、KについてP_jである。

[0105] 上記のように、優先順位ｊの送信データはサブブロックｊと称される、サブブロックへグループ化され得る。そして、最後の物理層ブロック内で送信データの比はP1と１／Ｎとの最大値であり得、すなわち、出来る限り残りのデータのいくつかおよび最も高い優先順位のサブブロック１内の全てのデータは最後の物理層ブロックＮで送信される。M_1をこの最大値にさせ、L_1＝１−M_1をデータの比M_1が最後の物理層ブロックＮ で送信される後に物理層ブロックN-1、…、で送られるべきデータの残りの比とする。そうすると、物理層ブロックN-1で送信される送信データの比はP_1＋P_2−M_1および１／Ｎ −１の最大値となり得、すなわち、２番目に高い優先順位のサブブロックおよび最も高い優先順位のサブブロックの全ては最後の２つの物理層ブロックで送信され、可能な限り残りのデータのいくつかも同様である。これは、２つの物理層ブロックが受信された後、最初の２つの優先順位のデータが受信器において再生されるべきであると仮定している。

[0106] 各物理層ブロックでどの送信データを送るかを決定するためにこの方法は拡張することができる。この方法は、送信されたソースブロックデータを再生する受信器への受信器要求が異なる例えば、優先順位２の送られたデータ２つの物理層ブロックの後に代わって３つの物理層ブロックを受信する後に再生されるべきである場合のために拡張することができる。上記の方法は、同じ物理チャネル上で一括のストリームあるいは多くの異なるストリームの多重化の要求により修正され得、各物理層ブロックにおいて利用可能なスペースの量は、一括ストリームあるいは各ストリームの送信データの各優先順位のどれくらいが各ブロックで送られるべきか決定するために使用される。

[0107] 上記の優先順位は完全な順序付けを説明する必要はなく、すなわち、優先順位は部分的な順序でよく、その場合には、いくつかの実施例において、実際に優先順位の大部分で比較不能である優先付けられたデータは送信順序で混合されてもよく、優先付けられたデータの配置する順序を選択するための選択がある。

[0108] 上述のように、これらの提案された送信配列のいくつかを実施することは、ここで説明されたプロセス、例えば、各シンボルとともに送信されるヘッダーデータ、各シンボルとともに送信されたヘッダーデータではない等、を含むＥＳＩ、改善された送信および受信方法のいずれかを使用して遂行され得る。
・ソースブロックの部分的なＦＥＣコーディング
[0109] ＦＥＣリペアデータはソースブロック全体から生成することができ、ソースブロックから生成されたリペアシンボルとソースブロックからの十分なソースシンボルが受信された場合にソースブロックの全体あるいは重要な部分を回復する能力を提供する。ＦＥＣリペアデータはソースブロックの部分のみから生成されてもよく、例えば、ＦＥＣリペアデータの１セットはソースブロックの１番目の部分から生成されてもよく、ＦＥＣリペアデータの２番目のセットはソースブロックの２番目の部分から生成されてもよい。一例として、ソースブロックの２番目の部分はソースブロックのある付加的な部分とソースブロックの１番目の部分とを含んでもよい。ソースブロックのソースシンボルは高い優先順位のソースサブブロックと、低い優先順位のソースサブブロックへ分割されると仮定する。その後、ＦＥＣリペアシンボルの１番目のサブブロックは高い優先順位のソースサブブロックから生成され得、ＦＥＣリペアシンボルの２番目のサブブロックは高い優先順位のソースサブブロックと低い優先順位のソースサブブロックとの連結から生成され得る。サブブロックの送信順序は、次のとおりであり得る：ＦＥＣリペアシンボルの２番目のサブブロック、低い優先順位のソースサブブロック、ＦＥＣのリペアシンボルの１番目のサブブロック、高い優先順位のソースサブブロック。この場合、受信器が高い優先順位のソースサブブロックの部分あるいは全部のみを受信する場合、破損があり過ぎなければ、これを直ちに再生しようとすることができる。受信器が高い優先順位のソースサブブロックおよびＦＥＣリペアシンボルの１番目のサブブロックの部分あるいは全てを受信する場合、破損があり過ぎなければ、ＦＥＣリペアシンボルの１番目のサブブロックを使用する高い優先順位のソースサブブロックを回復しようとすることができる。受信器が高い優先順位のソースサブブロック、ＦＥＣリペアシンボルの１番目のサブブロック、および低い優先順位のソースサブブロックの部分あるいは全てを受信する場合、受信器はＦＥＣリペアシンボルの１番目のサブブロックを使用する高い優先順位のソースサブブロックの破損した部分を回復し、メディアプレイヤーに低い優先順位のソースサブブロックの受信した部分と高い優先順位のソースサブブロックの回復した部分とを送ろうとすることができる。受信器が４つのサブブロック全ての部分をあるいは全部を受信した場合、受信器はすべてのＦＥＣリペアシンボルを使用してソースシンボルの全てを回復することができる。

[0110] 上記方法は個々のサブブロック上で別々にＦＥＣ保護を提供することが好ましく、例えば、単に低い優先順位のソースサブブロックに代わってソースブロック全体を保護するＦＥＣリペアシンボルの２番目のサブブロックを有することが好ましいことに注意する。例えば、２つのソースサブブロックのそれぞれが、１００ソースシンボルずつ備え、２つのＦＥＣサブブロックのそれぞれが５０リペアシンボルずつ備えると仮定する。上位方法を使用することは、高い優先順位のソースサブブロックから６０のソースシンボルが損失し、低い優先順位のソースサブブロックから３０のソースシンボルが損失した場合であっても全てのソースブロックの回復を可能とするが、２つのソースサブブロックが２つのＦＥＣリペアサブブロックにより独立に保護されている場合、高い優先順位のサブブロックの回復は可能ではない（サブブロックの６０のソースシンボルが損失し、サブブロックを保護する５０のリペアシンボルしかない）。そのようなＦＥＣ保護は、例えば、リード・ソロモンコードを使用して実現され、ここで、オーバラップするサブブロックを保護する上記の方法において使用されるとき、リード・ソロモンコードが殆ど理想的な回復特性を示すことを実験が示している。

[0111] これらの方法は、長すぎる期間に渡る保護が受信されたデータの全時間にときどき消失する場合の保護のために有用である。代わりに、短いブロック上でＦＥＣ保護を提供し、短いブロックを含むより長いブロック上でもＦＥＣ保護を提供することは好ましい。このように、周囲の期間において多すぎない損失を伴う機能停止、そして、短いブロックに渡るＦＥＣ保護はそれらに回復することを可能とし、しかしより長いブロックに渡る付加的なＦＥＣ保護はより長い期間上により多くの損失があることを可能にする。
・多数の物理層ブロックストリームを受信すること
[0112] 論理的に接続されたストリームが物理層ブロックのシグナルストリーム上で送られるストリーミングアプリケーションについて、物理チャネル全体は多数のそのような物理層ブロックストリームにより構成されるかもしれない。例えば、この例では各物理層ブロックストリームは２５６Ｋｂｐｓ、あるいは１Ｍｂｐｓであってもよく、しかし、５０のそのようなストリームがある結果、利用可能な物理チャネル全体は１２．５から５０Ｍｂｐｓかもしれない。

[0113] 典型的に、受信器は、メモリの問題およびパワーの問題を含む様々な異なる理由により。物理層ブロックのストリームの１つを一度に受信してもよい。しかしながら、物理層ブロックの１以上のストリームを受信することは受信器にとって利点があり得る。例えば、受信が全てのそのようなストリームを受信することである場合、１つのストリームから別のものへのチャネルザッピングは殆ど即座に生じ得、新しいストリームの全てのデータは受信器がそのストリームへチャネルを変更する前の期間に到着するため、そして受信器が移動する新しいストリームは高い品質レベルで最初から再生されることができる。例えば、時々Ｉ−フレームと称され、時々ＩＤＲフレーム（Independent Data Refresh frames）と称されるビデオストリーム内のリフレッシュフレームがそれらの大きなサイズによりたまに送られるとき、ストリームが高度に圧縮されるような方法でビデオ符号化された場合であっても、あるいは、ストリームが長い保護期間でＦＥＣ保護を使用して保護される場合であっても当てはまる。これは典型的にＧＯＰ（Group of Pictures）により広げられた時間が高度に圧縮されたビデオストリームにおいてある程度大きくなり得ることを意味する。例えば、ビデオストリームのＧＯＰの期間は１０秒であってよく、ＦＥＣ保護は１０秒のＧＯＰ全体を保護することを提供されてもよい。この場合、ストリームからの高い優先順位のデータが出来るだけ速く表示され、より低い優先順位のデータもストリーム再生向上するように速く再生の質を向上する表示される上記方法のいくつかを使用しないで、受信器が同時に１つのチャネルのみを受信した場合チャネルザッピング時間が１０秒と同じくらい高くなり得、しかし、受信器が全てのチャネルを受信する場合チャネルザッピング時間は殆ど瞬間であり得る。

[0114] 受信器が物理層パケットの１以上のストリームを同時に受信する解決策を考慮する場合、いくつかの最適化が可能である。例として、例えば再生のためのメディアプレイヤーへ容易に送信されるストリームのみ、誤り訂正復号（error-correction decoding）あるいは消去保護復号（erasure protection decoding）のいずれかを受信器が例えば行うＦＥＣコードのためにのみ必要である。受信器がチャネルを変更する場合他のストリームのデータは格納されＦＥＣ復号のみされることができ、ＦＥＣ復号は、新しいチャネルへ受信されたデータ上で非常に速く生じ得、メディア再生を殆ど直ちに開始する。

[0115] 別の可能な最適化として、受信器が一度に１つのストリームのみを受信するとき、受信器が最初にストリームを結合するとき受信器が再生可能なストリームの前の部分を有していた場合、必要とされないストリームに含まれる重複データがあってもよい。そのような重複データの例は、たとえそれが低い品質であったとしても、受信器がストリームを結合して殆ど直ちにいくつかのビデオを再生開始することができるように、ビデオストリーム単独に非常に頻繁に含まれる低品質のＩＤＲフレームであるかもしれない。受信器が、高品質のＩＤＲフレームと前に送信された全ての後のフレームとを含むストリームの前の部分を含む場合、頻繁な低品質のＩＤＲフレームを含むことは必要ないだろう。低い品質のＩＤＲフレームは利用可能な帯域幅のかなりの量を使用し得る、例えば、低い品質のＩＤＲフレームのそれぞれは３ＫＢでありそれらが２５６Ｋｂｐｓのストリームで各秒に送られる場合、低い品質のＩＤＲフレームは利用可能な帯域幅の９％以上を使用する。もし受信器が、そのストリームへチャネルを変更することに先立って受信器が変更するストリームのデータを受信する場合、低い品質のＩＤＲフレームの送信は必要ではない。

[0116] 物理層ブロックの多数のストリームを聞く１つの欠点は、それがシグナルストリームを聞くよりも受信器でよりパワーを使用することである。さらに、シグナルストリームより多数のストリームから受信されたデータを格納するためにはより多くのメモリおよび他のリソースが必要である。これらの欠点を最小化するために使用することができるいくつかの方法がある。１つのそのような方法は、上記利点を達成するために受信器が一度に少数のストリームのみを受信すること必要とするような方法で利用可能なストリーム上で全体的にデータおよび／または論理を体系付けることである。

[0117] 例えば、受信器がどのストリームへチャネルを変更してもよいか予測することができる論理がある場合、その論理は受信器がそのチャネルへ実際の変更の前にこれらの適当なチャネルを受信するような状態であり得る。

[0118] 別の例として、物理層ブロックストリーム内のデータは、ＩＤＲストリームと称される、全ての他のビデオストリームのＩＤＲフレームの全てを搬送する１つの物理層ブロックストリームがあるように体系付けられてもよく、各他の物理層ブロックストリームはビデオストリームのＩＤＲフレームを除くビデオストリームの１つのデータの全てを搬送する。この例では、受信器はメディアプレイヤーにより現在再生されるビデオストリームの現在の物理層ブロックストリームを受信し、一方ＩＤＲストリームを同時に（常にあるいは断続的に適切なとき）受信してもよい。したがって、受信器はビデオストリームのいくつかあるいは全てのＩＤＲフレームを利用可能とすることができ、それはチャネル変更が受信器で生成されたとき新しいビデオストリームの表示を開始するための使用、あるいは、サムネイルチャネルガイドモードで利用可能なビデオストリームのいくつかあるいは全てについての情報の再生のいずれかのために使用することができる。ＩＤＲストリームはいつでも受信されてよく、あるいは継続的に受信されてもよく、例えば、現在再生するビデオストリームのためのＩＤＲフレームを含むＩＤＲストリームからの物理層ブロックを単に受信する。全ての場合で、もし望まれれば、ＦＥＣ保護は各物理層ブロックストリーム上で提供され得る。これらの方法の１つの長所は、受信器がどんな時点でも高々２つの物理層ブロックストリームにおいて受信するし、物理層ブロックチャネルを全て同時に受信するという長所の全てあるいは殆どを得る。

[0119] 発明は典型的な実施例に関して記述されているが、当業者は多数の変更が可能であることを認識するだろう。例えば、ここに説明されたプロセスは、ハードウエアコンポーネント、ソフトウエアコンポーネント、および／またはそれらの組み合わせを使用して実行されてもよい。例えば、ここで説明された方法は、方法を実行するためのコンピュータプロセッサを管理することが出来るコンピュータ実行可能コードを含むＣＤ−ＲＯＭ、ＤＶＤ等のようなコンピュータ可読媒体上で、具体化されてもよい。したがって、発明は典型的な実施例について説明されたが、次の請求項の範囲内の変更および等価物の全てをカバーするように発明が意図されることは正しく認識されるだろう。

[0119] 発明は典型的な実施例に関して記述されているが、当業者は多数の変更が可能であることを認識するだろう。例えば、ここに説明されたプロセスは、ハードウエアコンポーネント、ソフトウエアコンポーネント、および／またはそれらの組み合わせを使用して実行されてもよい。例えば、ここで説明された方法は、方法を実行するためのコンピュータプロセッサを管理することが出来るコンピュータ実行可能コードを含むＣＤ−ＲＯＭ、ＤＶＤ等のようなコンピュータ可読媒体上で、具体化されてもよい。したがって、発明は典型的な実施例について説明されたが、次の請求項の範囲内の変更および等価物の全てをカバーするように発明が意図されることは正しく認識されるだろう。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］ 放送チャネル上でデータストリームを配信するための電子配信システムであって、前記放送チャネルは、１以上のソースから複数の受信器へ信号を送るためのチャネルであって、各受信器は同じ信号を実質的に受信することを試み、
物理層ブロックの物理層パケット内で前記データストリームのためのデータを送信する送信システムを備え、送られたデータが前記データストリームとどのように関係があるのかの表示は、少なくとも前記物理層ブロックに基づいている、電子配信システム。
［Ｃ２］ 前記送られたデータが前記データストリームとどのように関係があるかの表示は、少なくとも前記物理層ブロックのヘッダー内の情報に基づき、送信システムは前記物理層の前記ヘッダーが前記表示を含むように構成する、Ｃ１記載の電子配信システム。
［Ｃ３］ 前記送られたデータが前記データストリームとどのように関係があるかの表示は、少なくとも一部分、前記物理層パケットのヘッダー内の情報に基づいているＣ１記載の電子配信システム。
［Ｃ４］ 前記送られたデータは、データのソースブロック内の複数のシンボルへ体系付けられ、前記表示は１つのシンボルがソースブロックと１つのシンボルとソースブロックとの間の関連性の表示とから、どのように形成されるかの表示を備えるＣ１記載の電子配信システム。
［Ｃ５］ 前記表示は符号化シンボル識別子であって、前記符号化シンボル識別子は少なくとも部分的に物理層ブロックのヘッダー内に搬送される、Ｃ４記載の電子配信システム。
［Ｃ６］ 前記表示は、符号化シンボル識別子であって、前記符号化シンボル識別子はコントロールデータチャネル内で搬送される、Ｃ４記載の電子配信システム。
［Ｃ７］ シンボルとソースブロックとの間の関連性は、物理層ブロックのヘッダーから主に決定され得る、Ｃ４記載の電子配信システム。
［Ｃ８］ データの前記送られたシンボルはソースブロックから生成されたＦＥＣ修復データを含む、Ｃ４記載の電子配信システム。
［Ｃ９］ データの１以上の論理ストリームは物理層ブロックの単一ストリーム内に送られる、Ｃ４記載の電子配信システム。
［Ｃ１０］ データの送られたシンボルは物理層ブロックの１以上のストリーム上で送られる、Ｃ４記載の電子配信システム。
［Ｃ１１］ データの前記送られたシンボルが前記ストリーム又はオブジェクトデータとどのように関係するかの表示は、送られるデータの前記シンボルを搬送する物理層パケットに少なくとも部分的に搬送される、Ｃ４記載の電子配信システム。
［Ｃ１２］ ソースブロックへ送られた前記データは、異なる優先順位の異なるサブブロックへ体系付けられる、Ｃ４記載の電子配信システム。
［Ｃ１３］ ソースブロックの前記サブブロック構造の表示は、物理層ブロックのヘッダーから主に決定される、Ｃ１２記載の電子配信システム。
［Ｃ１４］ ソースブロックの前記サブブロック構造の表示は、物理層ブロックへ搬送された物理層パケットから主に決定され得る、Ｃ１２記載の電子配信システム。
［Ｃ１５］ データの前記送られたシンボルは、サブブロックの結合および異なるサブブロックから生成されたＦＥＣ修復データを含む、Ｃ１２記載の電子配信システム。
［Ｃ１６］ 優先順位の前記サブブロックは、前記サブブロックの送信順を決定するために利用される、Ｃ１２記載の電子配信システム。
［Ｃ１７］ 優先順位の前記サブブロックは、前記物理層ブロックへ前記サブブロックを位置づけるために利用される、Ｃ１２記載の電子配信システム。
［Ｃ１８］ 前記物理層ブロックへ位置づけられた優先順位の前記サブブロックは、異なる物理層ブロック間で分割される、Ｃ１７記載の電子配信システム。
［Ｃ１９］ 放送チャネル上でデータストリーム配信するための電子配信システムの送信器から受信器へデータを送信するための方法であって、ここにおいて、前記放送チャネルは１以上のソースから複数の受信器へ信号を送るためのチャネルであって、各受信器は実質的に同じ信号を受信しようとする：
物理層ブロックの物理層パケット内の前記データストリームへ前記送信器からデータを送信することを備え、送られたデータが前記データストリームとどのように関連するかの表示は少なくともブロックの前記物理層の少なくとも一部に基づく、方法。
［Ｃ２０］ Ｃ１９に記載された前記方法を実行するためのコンピュータ実行可能コードを備えるコンピュータ可読媒体。

Claims (20)

1. 放送チャネル上でデータストリームを配信するための電子配信システムであって、前記放送チャネルは、１以上のソースから複数の受信器へ信号を送るためのチャネルであって、各受信器は同じ信号を実質的に受信することを試み、
   物理層ブロックの物理層パケット内で前記データストリームのためのデータを送信する送信システムを備え、送られたデータが前記データストリームとどのように関係があるのかの表示は、少なくとも前記物理層ブロックに基づいている、電子配信システム。
2. 前記送られたデータが前記データストリームとどのように関係があるかの表示は、少なくとも前記物理層ブロックのヘッダー内の情報に基づき、送信システムは前記物理層の前記ヘッダーが前記表示を含むように構成する、請求項１記載の電子配信システム。
3. 前記送られたデータが前記データストリームとどのように関係があるかの表示は、少なくとも一部分、前記物理層パケットのヘッダー内の情報に基づいている請求項１記載の電子配信システム。
4. 前記送られたデータは、データのソースブロック内の複数のシンボルへ体系付けられ、前記表示は１つのシンボルがソースブロックと１つのシンボルとソースブロックとの間の関連性の表示とから、どのように形成されるかの表示を備える請求項１記載の電子配信システム。
5. 前記表示は符号化シンボル識別子であって、前記符号化シンボル識別子は少なくとも部分的に物理層ブロックのヘッダー内に搬送される、請求項４記載の電子配信システム。
6. 前記表示は、符号化シンボル識別子であって、前記符号化シンボル識別子はコントロールデータチャネル内で搬送される、請求項４記載の電子配信システム。
7. シンボルとソースブロックとの間の関連性は、物理層ブロックのヘッダーから主に決定され得る、請求項４記載の電子配信システム。
8. データの前記送られたシンボルはソースブロックから生成されたＦＥＣ修復データを含む、請求項４記載の電子配信システム。
9. データの１以上の論理ストリームは物理層ブロックの単一ストリーム内に送られる、請求項４記載の電子配信システム。
10. データの送られたシンボルは物理層ブロックの１以上のストリーム上で送られる、請求項４記載の電子配信システム。
11. データの前記送られたシンボルが前記ストリーム又はオブジェクトデータとどのように関係するかの表示は、送られるデータの前記シンボルを搬送する物理層パケットに少なくとも部分的に搬送される、請求項４記載の電子配信システム。
12. ソースブロックへ送られた前記データは、異なる優先順位の異なるサブブロックへ体系付けられる、請求項４記載の電子配信システム。
13. ソースブロックの前記サブブロック構造の表示は、物理層ブロックのヘッダーから主に決定される、請求項１２記載の電子配信システム。
14. ソースブロックの前記サブブロック構造の表示は、物理層ブロックへ搬送された物理層パケットから主に決定され得る、請求項１２記載の電子配信システム。
15. データの前記送られたシンボルは、サブブロックの結合および異なるサブブロックから生成されたＦＥＣ修復データを含む、請求項１２記載の電子配信システム。
16. 優先順位の前記サブブロックは、前記サブブロックの送信順を決定するために利用される、請求項１２記載の電子配信システム。
17. 優先順位の前記サブブロックは、前記物理層ブロックへ前記サブブロックを位置づけるために利用される、請求項１２記載の電子配信システム。
18. 前記物理層ブロックへ位置づけられた優先順位の前記サブブロックは、異なる物理層ブロック間で分割される、請求項１７記載の電子配信システム。
19. 放送チャネル上でデータストリーム配信するための電子配信システムの送信器から受信器へデータを送信するための方法であって、ここにおいて、前記放送チャネルは１以上のソースから複数の受信器へ信号を送るためのチャネルであって、各受信器は実質的に同じ信号を受信しようとする：
    物理層ブロックの物理層パケット内の前記データストリームへ前記送信器からデータを送信することを備え、送られたデータが前記データストリームとどのように関連するかの表示は少なくともブロックの前記物理層の少なくとも一部に基づく、方法。
20. 請求項１９に記載された前記方法を実行するためのコンピュータ実行可能コードを備えるコンピュータ可読媒体。

Images