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

Abstract

多数の物理層ブロック内でソースブロック送信のシグナリングは、ストリーミングとオブジェクト伝送アプリケーションとの両方へ実行され、最小の付加オーバヘッドを使用して、いくつかの場合オーバヘッドを使用せずに、ソースブロックの順位付けされたデータの表示および送信を示し、それらが生成されるソースブロックと記号がどのように関連するか示し、物理層ブロック内でインターリーブされたソースブロックを示す。１以上のチャネル上でストリームを送りおよび体系付けることは、伝送されたストリームの質の向上のために実行可能であり、その上、受信器電力源およびチャネルリソースの必要な量の改善および最小化が必要であった。

Description

本特許出願は２００８年５月７日出願の「放送チャネル上の高品質ＦＥＣストリーム保護および高速チャネルザッピング」と題する仮出願番号第６１／０５１，３２５号に対する優先権を要求する。

本発明は、一般に、ストリーミングとオブジェクトデリバリに関し、特に、送出されたストリームの質を保護するためのＦＥＴを用いる確実性の低いチャネル上のオブジェクトデリバリとストリーミングに関する。

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

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

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

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

ソースストリームの保護を提供するために使用することができるＦＥＣコードの多くの例がある。リード・ソロモンコード（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」という）に記述されたような、連鎖反応コードおよびマルチステージ連鎖反応コード、を含み、それぞれ、すべての目的のためにここに組込まれる。

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

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

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

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

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

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

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

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

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

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

詳細な説明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

当業者は、上記実施例の組み合わせおよび変形があることを認識するだろう。例えば、記号とともに送られる記号のヘッダーデータは、セグメント識別子とサブブロック識別子とを含み、ＥＳＩを含まなくてもよい。別の変形例として、ＥＳＩだけが記号とともにヘッダーデータ内で送信され、セグメント識別子あるいはサブブロック識別子のような他のデータが使用される場合は他のデータから決定される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (20)

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

Images