JP4664413B2 - 順方向エラー修正方法及びシステム - Google Patents

Description

本発明は、データ送信及び受信のためのシステム及び方法に係る。

移動ハンドヘルドターミナルに利用されるサービスは比較的低い帯域巾を必要とする。ＭＰＥＧ−４のような進歩型圧縮を使用して映像をストリーミングするために確立された最大ビットレートは、数百キロビット／秒程度であり、１つの実際的な限界は、３Ｇ環境から生じる３８４ｋｂｐｓである。ファイルのダウンロードのような他の形式の幾つかのサービスは、著しく高い帯域巾を必要とすることがある。それ故、融通性が要求される。

ＤＶＢ送信システムは、通常、１０Ｍｂｐｓ以上の帯域巾を与える。これは、時分割多重化（ＴＤＭ）に基づく構成を導入することにより、平均ＤＢＶ受信器消費電力を著しく減少することができる。この導入された構成は、タイムスライシングと称される。

タイムスライシングの考え方は、データが静的な帯域巾を使用して送信される場合に必要とされる帯域巾に比して著しく高い帯域巾を使用してデータをバーストで送信することである。１つのバースト内では、次のバーストの開始までの時間（Δｔ）が指示される。バーストとバーストとの間には、サービスのデータが送信されず、他のサービスが、そのサービスに割り当てられた帯域巾を使用するのを許す。これは、受信器が、要求されたサービスのバーストを受信しながら、時間の一部分のみアクティブに留まることができるようにする。移動ハンドヘルドターミナルが一定の低いビットレートを要求する場合には、受信したバーストをバッファすることでこれを行うことができる。

特別な利点として、タイムスライシングは、オフ時間中に受信器を使用して隣接セルを監視する能力もサポートする。又、オフ時間中に搬送ストリームから別のストリームへ受信の切り換えを行うことで、サービスの受信が表面上中断しない。通常のＤＶＢ−Ｔシステムでは、滑らかなハンドオーバーを行うのに、単一のターミナルに２つのフロントエンドが必要となる。

データは、例えば、ヨーロッパ規格ＥＮ３０１ １９２のセクション７「Digital Video Broadcasting(DVB); DVB specification for data broadcasting.」に基づくマルチプロトコルエンキャプスレータを使用することによりフォーマットされる。このマルチプロトコルエンキャプスレータは、カプセル化されたデータをデジタルブロードキャスト送信器へ送信して、タイムスライシング信号としてデジタルブロードキャスト受信器へブロードキャストする。タイムスライシング信号は、連続する一連の送信バーストで構成される。

ＤＶＢに関する更に別の情報が、例えば、各々参考としてここに取り上げる次のＥＴＳＩ（ヨーロピアン・テレコミュニケーションズ・スタンダーズ・インスティチュート）ドキュメントに見られることに注意されたい。
ＥＴＳＩ ＴＲ １０１２０２デジタルビデオブロードキャスティング（ＤＶＢ）「Implementation guidelines for Data Broadcasting」；
ＥＴＳＩ ＥＮ ３００４６８デジタルビデオブロードキャスティング（ＤＶＢ）「Specification for Service Information (SI) in DVB systems」；及び
ＥＴＳＩ ＥＮ ３００７４４「Digital Video Broadcasting(DVB) Framing structure, channel coding and modulation for digital terrestrial television」

ＥＴＳＩ（ヨーロピアン・テレコミュニケーションズ・スタンダーズ・インスティチュート）ドキュメント ＥＴＳＩ ＴＲ １０１２０２デジタルビデオブロードキャスティング（ＤＶＢ）「Implementation guidelines for Data Broadcasting」； ＥＴＳＩ ＥＮ ３００４６８デジタルビデオブロードキャスティング（ＤＶＢ）「Specification for Service Information (SI) in DVB systems」；及び ＥＴＳＩ ＥＮ ３００７４４「Digital Video Broadcasting(DVB) Framing structure, channel coding and modulation for digital terrestrial television」

近年、種々の目的でワイヤード及びワイヤレスネットワークの使用が増大してきた。例えば、メディア、アプリケーション、及びパーソナル通信の送信及び受信にネットワークが益々使用されている。例えば、この利用の増加に鑑み、このようなネットワークに適用できる技術に関心が持たれている。通常、データの送信及び受信は、あるクオリティ問題を引き起こすことがあり、それ故、異なる種類のエラー修正機構が存在する。特に、移動ターミナルが問題であるときには、エラー修正データと、修正されるべきデータとに異なる情報を使用する必要がある。

本発明によれば、データ送信方法において、１つ以上のデータセグメントを、第１の方向性構成及び第２の方向性構成を有する二次元データ構造体に入れるステップであって、前記第１の方向性構成は、機能的に前記第２の方向性構成に対して垂直であり、そして前記データセグメントを入れることは、前記第１の方向性構成に対して行われるようなステップと、前記第２の方向性構成の各々に、１つ以上の対応する計算された特性値を追加するステップと、前記特性値の部分を保持する１つ以上の前記第１の方向性構成のコンテンツを送信するステップと、前記１つ以上のデータセグメントを送信するステップであって、前記二次元構造体に入れられたデータセグメントを第１の特定フォーマットに基づいて送信し、そして前記特性値の部分を保持する前記第１の方向性構成を、搬送ストリームにおいて第２の特定のフォーマットで送信するようなステップと、を備えた方法が提供される。

前記第１の特定フォーマットに基づいて送信するステップは、前記二次元構造体に入れられたデータセグメントを、第１ヘッダを有する１つ以上のデータパケットへとカプセル化することを含み、そして前記第２の特定フォーマットに基づいて送信するステップは、前記特性値の部分を保持する各々の第１の方向性構成におけるデータを、第２のヘッダを有するデータパケットへとカプセル化することを含む。

各パケットヘッダは、データ構造体に入れる情報、及び／又はデータセグメント境界を指示するデータを含むことができる。

前記特性値の部分を保持する１つ以上の前記第１の方向性構成の前記カプセル化されたコンテンツは、前記カプセル化されたデータセグメントから異なるバーストにおいて送信することができる。

本発明によれば、前記方法を実行するように構成された送信器ノードも提供される。
本発明によれば、更に、データを受信する方法において、１つ以上のデータセグメントを搬送ストリームにおいて受信するステップと、第１の方向性構成及び第２の方向性構成を有する二次元データ構造体を与えるステップであって、前記第１の方向性構成は、前記第２の方向性構成に対して機能的に垂直であり、そして前記データセグメントを入れることは、前記第１の方向性構成に対して行われ、更に、前記二次元構造体に入れられたデータセグメントを、第１の特定のフォーマットに基づいて受信し、前記第１の方向性構成は、前記搬送ストリームにおいて第２の特定のフォーマットで受信された特性値の部分も受信するようなステップと、前記受信した特性値を使用して前記第２の方向性構成に対してデータセグメントを処理して、前記第１の方向性構成に対して修正されたデータセグメントを与えるステップと、を備えた方法が提供される。
本発明によれば、更に、データを受信する前記方法を実行するための受信器ノードが提供される。本発明の更に別の特徴及び効果は、特許請求の範囲から明らかとなろう。
本発明を更に完全に理解するために、添付図面を参照して本発明の実施形態を一例として詳細に説明する。

本発明の第１実施形態による通信システムを示す図である。 本発明の実施形態によるデータ送信に含まれるステップを例示する図である。 本発明の実施形態によるデータ受信に含まれるステップを例示する図である。 本発明の実施形態による第１ロード技術を示す図である。 本発明の実施形態による第２ロード技術を示す図である。 本発明の実施形態に使用できる汎用コンピュータを示す図である。 本発明の実施形態に使用できるノードを例示する機能的ブロック図である。 本発明の実施形態のプロトコルスタックを示す図である。 ＭＰＥ−ＦＥＣ及びＭＰＥセクションのヘッダセクションフォーマットを示す図である。 本発明の実施形態のＭＰＥ−ＦＥＣフレーム構造を示す図である。 ＭＰＥ及びＭＰＥ−ＦＥＣセクションシンタックスの記述を示すテーブルである。

図１は、本発明の第１実施形態による通信システム１のブロック図である。この通信システムは、コンテンツプロバイダー２を備え、これは、オーディオ−ビジュアルコンテンツ、データファイル又は映像のようなコンテンツのソース３、４にアクセスすることができる。コンテンツは、ＩＰを使用して、ＤＶＢ−Ｔネットワークのようなデジタルブロードバンドネットワークを経て、ＩＰデータキャスティング（ＩＰＤＣ）サービスとして知られているものにおいて、１つ以上の受信装置５ａ、５ｂへ送信することができる。受信装置５ａ、５ｂ、例えば、ビデオ機能を伴う移動電話は、少なくとも２つの異なる通信チャンネルからデータを受信するように構成される。

コンテンツデータは、ネットワーク要素６へ送信され、これは、コンテンツデータを受信して、そのコンテンツデータの順方向エラー修正に使用するための回復データを発生するように構成されたサーバーである。コンテンツデータは、第１チャンネルを経て受信装置５ａ、５ｂに送信される。この例では、第１通信チャンネルは、デジタルブロードキャスティング（ＤＶＢ−Ｔのような）ネットワーク７により与えられ、これは、送信器８を含む。コンテンツは、第１通信ネットワーク７に関連したセル内で全ての適当な受信装置５ａ、５ｂにブロードキャスト、マルチキャスト又はユニキャストされる。

回復データは、少なくとも送信器１０を含む例えば第３世代（３Ｇ）移動ネットワーク９により与えられる第２の通信チャンネルを経て受信装置５ａ、５ｂに送信される。

コンテンツ及び回復データに対する通信経路は、図１では、簡単な形態で示されていることに注意されたい。しかしながら、更に別の送信器、ネットワーク要素又はネットワークのような他の要素がこれら通信経路に配置されてもよい。図１に示すネットワークでは、送信器ノードが、受信器又は受信者ノードを構成する受信装置５ａ、５ｂへデータを送信し、以下の説明ではこれらの用語が使用されることが理解されよう。

一般的動作
本発明の種々の実施形態によれば、データ送信及び受信のためのシステム及び方法が提供される。種々の実施形態によれば、アドレス可能な記憶位置の二次元アレー等を形成することができ、及び／又は送信ノードによりそこにアクセスすることができる。

図２を参照すれば、このような実施形態では、おそらく特定のバーストにおいてノードにより送信されるべきデータに対応するパケット等を、列方向に二次元アレー等にロードできる（ステップ１０１）ことに注意されたい。このようなパケット等は、例えば、インターネットプロトコル（ＩＰ）パケットでよい。従って、ロードされたパケット等のコンテンツは、１つ以上の列の１つ以上のアドレス可能な記憶位置を占有することができる。

次いで、１つ以上の特性値を、二次元アレー等の各行に対して計算することができる（ステップ１０３）。このような特性値は、例えば、順方向エラー修正（ＦＥＣ）データを表わしてもよい。特定の例として、このようなＦＥＣデータは、リードソロモン（ＲＳ）エラー修正データでよい。行に対応する計算された特性値を、ＦＥＣデータとして次に書き込むことができる。従って、特性値は、その行の１つ以上のアドレス可能な記憶位置を占有することができる。

種々の実施形態において、特性値を計算する仕方は動的に変化し得ることに注意されたい。特定の例として、特性値がＦＥＣデータ（例えば、リードソロモンデータ）に対応する場合には、追加されるべきパリティデータの量が動的に変化し得る。例えば、より多くの送信エラーを生じると予想されるネットワーク条件が発生した場合には、より多くのパリティデータを追加することができる。更に、送信のクオリティを評価し、そしてエラー修正の判断を定義することができる。

次のステップとして、二次元アレー等が列方向に空にされる（ステップ１０５）。このように空にするときには、最初にロードされたパケット等を抽出することができる。種々の実施形態において、各々の最初にロードされたパケットは、アレー等のどこに記憶されていたかの指示を含むようにノードにより変更されてもよい。この指示は、例えば、パケット等により占有されていた第１のアドレス可能な記憶位置に対応する行及び／又は列アドレスを示す。

このような指示は、例えば、パケット等に対応するヘッダに記憶されてもよい。パケット等に対応する指示は、例えば、ノードがそれをアレー等に入れた直後にノードによりそのパケット等に追加されてもよい。別の例として、ノードは、アレー等からパケットをアンロードする直前に指示を入れてもよい。

更に、列方向に空にするときに、計算された特性値に対応するデータがアンロードされて、１つ以上のパケット等に入れられる（ステップ１０７）。１つ以上のパケット等は、例えば、ＩＰパケットでよい。このようなパケットは、例えば、アレー等の特定の列に記憶された計算された特性値に対応する全てのデータを含むことができる。従って、このようなパケットは、２つ以上の特性値に対応するデータを含むことができる。例えば、このようなパケットは、１つ以上の特性値の各々に対応するデータの部分を含むことができる。特定の特性値に対応するデータは、２つ以上のこのようなパケット間に分散し得ることに注意されたい。種々の実施形態において、このようなパケットに付随するのは、それが保持するデータがアレー等においてどこに記憶されたかの指示である。この指示は、例えば、その保持されたデータにより占有された第１のアドレス可能な記憶位置に対応する列アドレスを示す。

次いで、送信器ノードは、特定のセクションヘッダを伴う特性値又はその部分を保持する形成されたパケット等と、おそらく変更された最初にロードされたパケット等とを、１つ以上の受信者ノードへ送信するステップを実行する。種々の実施形態において、特性値を保持する形成されたパケット等は、おそらく変更された最初にロードされたパケット等から個別のバーストにおいて発送することができる。本発明の種々の実施形態では、このおそらく変更された最初にロードされたパケット等に特性値又はその部分を追加することができる。

図３を参照すれば、上述したパケット等は、受信者ノードに到達する（ステップ２０５）。受信者ノードは、送信側ノードにより供給される特性値を使用してもよいし使用しなくてもよいことに注意されたい。例えば、受信者ノードは、特性値を使用できないことがある。別の例として、受信者ノードに対応するユーザは、おそらく、グラフィックユーザインターフェイス（ＧＵＩ）又は他のインターフェイスを経て、特性値がノードにより使用されてはならないことを指定してもよい。更に別の例として、受信者ノードは、以下に詳細に述べるように、特性値を使用すべきかどうかの判断を行ってもよい。

例えば、特性値を使用することができず、及び／又は特性値を使用するかしないかを決定し及び／又はそのような指示を受けた受信者ターミナルは、種々の実施形態において、送信側ノードにより発送されたパケット等を全く受信しないか、或いはそれらを受信してそれらの幾つか又は全部をそれ自身選択する仕方で記憶するように動作してもよいことに注意されたい。次いで、ノードは、その受信した、おそらく変更された、最初にロードされたパケット等を従来のやり方で使用してもよい。ノードは、特性値に対応するその受信したパケットを記憶装置から除去してもよい。このようなパケットは、例えば、ＰＩＤ（プログラム識別子）等の識別子を介して確認することができる。

或いは又、このような受信者ノードは、特性値を保持するパケット等を、それらを記憶せずに、ドロップするように動作してもよい。種々の実施形態によれば、ノードは、このようなパケット等を多数の仕方で確認することができる。例えば、このようなパケットは、それらのヘッダにより確認することができる。より詳細には、このようなパケットのヘッダは、例えば、おそらく変更された最初にロードされたパケット等のヘッダにより指定されるものとは異なるソースＩＰアドレス等を指定してもよい。

受信者ノードが、特性値を使用できると決定し及び／又はそのような指示を受け取った場合には、そのノードは、おそらく、それ自身が選択する仕方でその受信したパケット等を記憶した後に、適当な動作を行って、その特性値が使用されるかどうか決定することができる。このような決定は、以下に詳細に説明する。受信者ノードが、特性値を使用すべきでないと決定し及び／又はそのような指示を受け取る場合には、そのノードは、おそらく、それ自身が選択する仕方でその受信したパケット等を記憶した後に、その受信した、おそらく変更された最初にロードされたパケット等を従来の仕方で使用するように動作できる。

受信者ノードが、特性値を使用すべきであると決定し及び／又はそのような指示を受け取った場合には、その受信者ノードは、送信側ノードにより形成され及び／又はアクセスされるアレー等に対応する二次元アレー等を形成し及び／又はそれにアクセスすることができる。受信者ノードにより形成され及び／又はアクセスされるアレー等は、例えば、送信側ノードにより形成され及び／又はアクセスされるアレー等と共通に１つ以上のプロパティを所有することができる。例えば、受信者ノードにより形成され及び／又はアクセスされるアレー等は、送信側ノードにより形成され及び／又はアクセスされるアレー等と同じサイズであり及び／又はそれと同様にアドレスすることができる。

種々の実施形態において、送信側ノードは、例えば、その形成され及び／又はアクセスされるアレー等に関連したプロパティの指示を受信者ノードへ発送することができる。このようなプロパティは、例えば、アレー等の列サイズ、行サイズ、アドレス情報等を含むことができる。別の例として、指示されたこのようなプロパティを、全ての指定の送信側及び受信者ノードにより観察するように確立できる。システムアドミニストレータ等がこのようなプロパティをセットできる。

アレー等を形成し及び／又はそれにアクセスできるようにするに必要なステップを実行すると、受信者ノードは、特性値を保持する受信したパケット等と、おそらく変更された最初にロードされたパケット等を、そのアレー等へロードする（ステップ２０７）。このロードは、上述した種類の受信した行及び／又は列アドレス指示に基づいて行うことができる。従って、このようなロードにより、受信者ノードのアレー等は、空にされる前の送信側ノードのアレー等にマッチングさせることができる。種々の実施形態において、このようなアドレス指示は、受信者ノードが、空にされる前の送信側ノードのアレー等にマッチングするようにそのアレー等にロードできるようにするために受信される必要がないことに注意されたい。例えば、マルチプロトコルカプセル化（ＭＰＥ）が使用される場合には、受信者ノードは、そのアレー等にロードするのに搬送ストリーム（ＴＳ）連続性カウンタ値を使用してもよい。

そのアレー等を、空にされる前の送信側ノードのアレー等に効率的にマッチングさせると、受信者ノードは、上述した特性値を再アッセンブルする（ステップ２０９）。次のステップとして、受信者ノードは、１つ以上の特性値の各々を、アレー等におけるその対応行に適用することができる（ステップ２１１）。このような適用は、例えば、受信した、おそらく変更された最初にロードされたパケット等に対してＦＥＣを実行することができる。

ある実施形態では、全ての特性値が適用されるのではないことに注意されたい。例えば、行当りに２つ以上の特性値がある場合には、その行に適用される値が全部より少なくてもよい。別の例として、１つ以上のある行の各々に対応特性値が適用される一方、１つ以上の他の行に対応特性値が適用されなくてもよい。

次のステップとして、受信者ノードは、そのアレー等を列方向にアンロードし、１つ以上の特性値に基づいておそらく変更され且つおそらく作用された（例えば、修正された）最初にロードされたパケット等を抽出するように働くことができる（ステップ２１３）。次いで、ノードは、これら抽出されたパケット等を従来の仕方で使用することができる。

以上、受信者ノードが、おそらく変更された最初にロードされたパケット等がアレー等に記憶されるときにそれに作用を及ぼす（例えば、修正する）として説明したが、種々の実施形態において、このような適用は、例えば、アレー等から抽出した後のパケットに対して実行されてもよいことに注意されたい。更に、種々の実施形態において、特性値（例えば、リードソロモンデータ）の反復使用を受信器において実行できることに注意されたい。例えば、ターボデコーディングを使用することができる。このようなターボデコーディングの実行は、例えば、特性値及び／又はこれら値の適用から得られるデータの行方向及び列方向の繰り返し反復使用を含むことができる。又、反復は、提案されたＦＥＣデコーディングと、ソフトビット情報を配送できるある下位レイヤのＦＥＣデコーディングとの間で実行することもできる。

更に、ここに説明する実施形態は、パケット等の使用について述べるが、本発明の実施形態は、例えば、ビットストリーム等にも同様に適用できる。更に、ここに説明する実施形態は、行に対する特性値の計算について述べるが、他の技術も使用できることに注意されたい。例えば、種々の実施形態において、特性値はジグザグ形態で計算されてもよい。

更に、ここに説明する実施形態は、アレー等の列方向のロード動作について述べるが、本発明の種々の実施形態は、異なる仕方で動作してもよい。例えば、このようなロード動作は、行方向であってもよい。このような実施形態の機能は、ここに述べるものと同様であるが、列の演算が行方向に行われ、そして行方向の演算が列のように行われる。

特性値、及び特性値のセットは、１つ以上のデータエレメントが行方向又は列方向に配置されたデータセグメントを有するアレーから多数のデータエレメントを選択し、その選択されたエレメントに計算を適用し、そしてそれにより得られた特性値を、同じ又は別のアレーにおいて特性値に対して指定された１つ以上の所定の場所に入れることにより、計算することができる。データエレメントの選択は、１つの行又は列においてエレメントの全部又は幾つかを選択することを含む。例えば、アレーにおける１つ以上の対角方向からエレメントを選択し（ジグザグ）、そして規定のパターンに基づいてデータエレメントを選択するような他の選択方法を使用してもよい。

更に、種々の実施形態において、データエレメントがアレーからランダムに選択され、ここで、エレメントの数は固定され、そして送信器及び受信器は、ランダムな選択パターンを知っている。本発明のある実施形態では、アレー内の全てのデータエレメントが必ずしも計算に使用されず、そして本発明の他の実施形態では、あるエレメントが１つ以上の特性値の計算に２回以上使用される。

本発明の特定の実施形態を以下に説明する。
この実施形態によれば、送信されるべきデータは、変更型ＤＶＢエンキャプスレータにより取り扱われる。このエンキャプスレータは、イーサネット（登録商標）フレームを経て搬送されるＩＰパケットを受信しそしてＴＳパケットを出力する能力を有する。

この実施形態の第１ステップとして、変更型エンキャプスレータは、イーサネット（登録商標）フレームを順次に受信する。エンキャプスレータは、例えば、イーサネット（登録商標）ＭＡＣアドレス及び／又はＩＰパケットアドレスに基づいてフレームをアレンジ及び／又はドロップするように動作してもよい。その基準は、例えば、送信されるべきデータの性質に基づいて予め決定することができる。このステップでは、イーサネット（登録商標）フレーム構造が除去される。

次のステップとして、選択されたＩＰパケットは、マルチプロトコルカプセル化（ＭＰＥ）セクション、例えば、ＤＳＭ−ＣＣ（デジタル記憶メディアコマンド及び制御）セクションに入れられる。

この実施形態の次のステップとして、レイヤ３（例えば、ＩＰ）データグラムがコードテーブル又はアレーに列方向に記憶される。メモリ内の各ＩＰデータグラムのアドレスがヘッダに記憶される。例えば、メモリ内のＩＰデータグラムのアドレスは、そのヘッダのＭＡＣ（メディアアクセス制御）アドレスバイトに記憶することができる。タイムスライスリアルタイムパラメータをこの段階で挿入することができる。

次いで、希望量のＩＰデータグラムがメモリに記憶された後に、ＦＥＣの計算が行方向に行われる。ＩＰデータグラムが、上述した列方向ではなく、行方向に記憶される場合には、ＦＥＣが列方向に計算されることに注意されたい。いずれにせよ、ＩＰデータグラムの記憶及びＦＥＣの計算は、機能的に互いに９０°の角度に配置されると考えることができる。或いは又、ＩＰデータグラムは、並列なＦＥＣ計算において送信できることにも注意されたい。このような場合に、ＦＥＣの計算に使用するようにＩＰデータグラムのコピーをメモリに残すことができる。メモリ内の各ＭＰＥ−ＦＥＣセクションのアドレスがヘッダに記憶される。例えば、ＭＰＥセクションのヘッダにおけるＭＡＣアドレスバイトの幾つかをこの目的のために指定することができ、この場合、メモリ内のＭＰＥ−ＦＥＣセクションのアドレスは、ＭＡＣ（メディアアクセス制御）アドレスバイトに記憶することができる。

次いで、全てのＦＥＣ計算が完了すると、計算されたＦＥＣバイト、即ちＲＳデータテーブル内のＦＥＣデータ（ＭＰＥ−ＦＥＣセクションにおいて搬送される）が、アプリケーションデータ（ＭＰＥセクションにおいて搬送される）から分離される。アプリケーションデータは、ＭＰＥセクション内で搬送され、一方、ＲＳデータは、ＭＰＥ−ＦＥＣセクション内で搬送される。ＭＰＥ−ＦＥＣフレームが送信中に混合されるのを防止するために、各ＭＰＥセクション及びＭＰＥ−ＦＥＣセクションは、１つのＭＰＥ−ＦＥＣフレームのみからデータを搬送する。ＭＰＥ−ＦＥＣフレームの全てのデータを搬送するために、多数のＭＰＥセクション及び／又はＭＰＥ−ＦＥＣセクションが必要とされることがある。その後、ＭＰＥ特有のセクションフォーマットをもつ全てのＩＰデータグラムと、ＭＰＥ−ＦＥＣ特有のセクションフォーマットをもつＦＥＣデータとが、図１０に示すＭＰＥ−ＦＥＣフレームとしてＴＳパケットペイロードに入れられる。この実施形態では、アプリケーションデータ及びＲＳデータは、同じＰＩＤ値をもつＴＳパケットにおいて送信される。この場合も、異なるＭＰＥ−ＦＥＣフレームが混合されるのを防止するために、異なるＭＰＥ−ＦＥＣフレームからのデータを搬送するＭＰＥセクション及びＭＰＥ−ＦＥＣセクションをインターリーブすることは許されない。

受信ノードがＦＥＣを計算するように動作する場合のノードの動作を、本発明の特定の実施形態に基づいて以下に説明する。
第１ステップとして、受信ノードは、おそらく希望のＴＳパケット（例えば、ＰＩＤ値「Ａ」をもつパケット）をフィルタリングした後に、ＴＳパケットヘッダを除去し、そして送信ノードと同様の各テーブルを各ＩＰデータグラムから形成すると共に、ＦＥＣデータをＴＳパケットペイロードデータから形成する。

次いで、受信ノードは、受信したアプリケーションデータ（ＭＰＥセクションにおいてそこに送信された）と、ＲＳデータ（ＭＰＥ−ＦＥＣセクションにおいて送信された）とを、デコーディングテーブル又はアレーに記憶する。このようにするとき、受信ノードは、ＭＰＥセクションヘッダ及びＭＰＥ−ＦＥＣセクションヘッダからのアドレス値を使用する。受信器は、受信したデータを受信器バッファメモリに配列する。これは、リアルタイムパラメータ（セクションヘッダ）からの「アドレス」ビットに基づいて行う。アドレスは、アプリケーションテーブルにおけるアプリケーションデータデータグラムの位置、及びＦＥＣ（ＲＳ）テーブルにおけるＭＰＥ−ＦＥＣセクションペイロードの位置を指定する。

次いで、受信ノードは、受信したデータに対してＦＥＣデコーディングを実行する。ＭＰＥ−ＦＥＣフレームの最初と最後のセクションは、アドレス及びバースト境界ビットにより各々識別される。ＭＰＥ及び／又はＭＰＥ−ＦＥＣセクションヘッダには、「ｔａｂｌｅ＿ｂｏｕｎｄａｒｙ」及び「ｆｒａｍｅ＿ｂｏｕｎｄａｒｙ」フラグが含まれる。例えば、ＭＰＥ−ＦＥＣフレームについて考えると、ＦＥＣの最後のＭＰＥ−ＦＥＣセクション以外の全てについて、フラグｆｒａｍｅ＿ｂｏｕｎｄａｒｙ＝０であり、そしてフレームの最後のＭＰＥ−ＦＥＣセクションについては、フラグｆｒａｍｅ＿ｂｏｕｎｄａｒｙ＝１で、これは、フレームの終わりを意味する。同様に、アプリケーションデータ及びＲＳデータテーブル（図１１）の最後のセクション以外の全てにおいてｔａｂｌｅ＿ｂｏｕｎｄａｒｙは０の値をもつことができる。ＭＰＥ−ＦＥＣフレームのサイズを知るために、列の数が既知であると仮定すれば、次の方法を使用することができる。即ち、ＭＰＥ−ＦＥＣフレームの各ＭＰＥ−ＦＥＣセクションのサイズが等しいと仮定すれば、行の数は、単一のＭＰＥ−ＦＥＣセクションのペイロードサイズにＭＰＥ−ＦＥＣセクションの数を乗算して、その結果を、ＲＳデータテーブルに使用された列の数で除算したものである。各ＭＰＥ−ＦＥＣセクション内の「ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ」フィールドは、ＭＰＥ−ＦＥＣフレーム内のＭＰＥ−ＦＥＣセクションの数を示す。

その後、ＩＰパケットデータを含む修正されたＩＰデータグラムが、好ましくは、同じインターリービングメモリに記憶されるか、或いは受信器が取り付けられたターミナルのＩＰスタックにデータが転送される。次のステップとして、ＩＰデータグラムが順次に処理され、そしてＩＰデータグラムのヘッダ及びトレーラーが除去される。それにより得られるＩＰパケットが、従来の使用のために通される。

一実施形態では、時分割多重化（ＴＤＭ）又はタイムスライシング構成が使用され、ここでは、受信器が規定の受信時間中だけオンにされる。受信器は、バーストの始め及び／又は終りを検出し、そして受信器は、フレームの始め及び／又は終りも検出する。一実施形態では、ＭＰＥ−ＦＥＣフレーム及びタイムスライシングを一緒に使用でき、従って、タイムスライスバーストがＭＰＥ−ＦＥＣフレームに対応する。しかし、タイムスライシングなしにＦＥＣを、そしてＦＥＣなしにタイムスライシングを使用することもできる。

ＭＰＥセクション及びＭＰＥ−ＦＥＣセクションは、同じバーストにおいて搬送されてもよい。このようなケースでは、バーストのサイズは、ＭＰＥ及びＭＰＥ−ＦＥＣに対して一緒にカウントされる。
一緒に属するＭＰＥ及びＭＰＥ−ＦＥＣセクションは、同じ基本的ストリーム（ＥＳ）において送信される。このＥＳは、搬送ストリームパケットヘッダの属性であるＰＩＤにより識別される（搬送ストリームパケットは、プロトコルスタック画像におけるＭＰＥＧ−２レイヤを形成する）。

ＦＥＣがタイムスライシングなしに使用される場合には、ターミナルは、ＦＥＣ＿ｆｒａｍｅ＿ｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒ（ＭＰＥセクションヘッダ及びＭＰＥ−ＦＥＣセクションヘッダにおいて各々搬送されるリアルタイムパラメータの１つ）により、どのＭＰＥセクション及びＭＰＥ−ＦＥＣセクションが同じＭＰＥ−ＦＥＣフレームに属するか分かる。

ＦＥＣがタイムスライシングと共に使用される場合には、ＦＥＣ＿ｆｒａｍｅ＿ｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒが不要である。ターミナルは、どのＭＰＥセクション及びＭＰＥ−ＦＥＣセクションが同じＭＰＥ−ＦＥＣフレーム（バーストと同一）に属するかタイミングで分かり、即ちそれがウェイクアップし、バーストのＭＰＥ及びＭＰＥ−ＦＥＣセクションを受信し、次いで、次のバーストがスタートするまで再びスリープ状態になることにより分かる。

ＭＰＥセクション及びＭＰＥ−ＦＥＣセクションに対して異なるバーストを可能にするために、タイムスライシングの再送信特徴を使用することができる。このようなケースでは、ＭＰＥセクションは「オリジナルバースト」において搬送され、そしてＭＰＥ−ＦＥＣセクションは、「コピーバースト」において搬送される。リアルタイムパラメータを、ＭＰＥヘッダセクションヘッダ：ＳＩ記述子に関連して使用することで、バーストを「オリジナルバースト」及び「コピーバースト」として区別することができる。
モード １（１モード）又は２（３モード）ビット
ｍａｘ＿ｂｕｒｓｔ＿ｄｕｒａｔｉｏｎ ３ビット
ｍａｘ＿ｆｒａｍｅ＿ｓｉｚｅ Ｎビット
ｄａｔａ＿ｐａｄｄｉｎｇ＿ｃｏｌｕｍｎｓ Ｎビット
ｒｓ＿ｐａｄｄｉｎｇ＿ｃｏｌｕｍｎｓ Ｎビット
リアルタイムパラメータ：
ｄｅｌｔａ＿ｔ／ｆｒａｍｅ＿ｉｎｄｅｘ １２ビット
ｔａｂｌｅ＿ｂｏｕｎｄａｒｙ １ビット
ｆｒａｍｅ＿ｂｏｕｎｄａｒｙ １ビット
ａｄｄｒｅｓｓ １８ビット
ａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａ＿ｐａｄｄｉｎｇ ８ビット

この例では、各個々のバーストに対して２Ｍｂの限界が適当である。
しかしながら、ＭＰＥ及びＭＰＥ−ＦＥＣセクションに対する異なるバーストの解決策は、受信器が長時間オンであり、従って、より多くの電力を消費するので、好ましいものではない。

１つの基本的ストリーム内で、ＭＰＥ−ＦＥＣフレームの最初と最後のセクション間の全てのセクションは、最初と最後のセクションと同じＭＰＥ−ＦＥＣフレームに属する。１つの基本的ストリーム内で、フレームの全てのセクションは、フレームの最初と最後のセクションの間（それらを含む）で送信されねばならない（即ち、異なるＭＰＥ−ＦＥＣフレームのインターリーブするセクションは許されない）。１つのフレーム内の最初と最後のセクション間では、セクションを整然と送信してもよいし、又、そうでなくてもよい。ＭＰＥ−ＦＥＣフレームは、１つの基本的ストリーム内で区別することができ、例えば、最初と最後のセクションを次のオプションによりフレーム内で識別することができる。

連続性カウンタ、又はＭＰＥ−ＦＥＣフレーム間に長い時間を追加する。これは、例えば、１つのタイムスライスバースト内に配送されるべき１つのフレームをバインディングすることにより達成でき、即ち受信器がバーストの始め及び／又は終りを検出すると、受信器は、フレームの始め及び／又は終りも各々検出する。

異なるＭＰＥ−ＦＥＣフレームストリーム（順次のＭＰＥ−ＦＥＣフレームで構成される）の区別は、フレームを互いに識別するために低レベルプロトコル（ＤＶＢにおけるＴＳ）識別子（ＤＶＢにおけるＰＩＤ）により行うことができ、即ちＤＶＢにおいて、ＭＰＥ−ＦＥＣフレームストリーム当たり１つの基本的ストリーム（例えば、ＰＩＤにより識別された）を使用することができる。

二次元アレー等のロード動作、アドレス動作及びサイズ決め
上述した種類の二次元アレー等は、本発明の種々の実施形態に基づき、多数の仕方でロードすることができる。例えば、ロードを列方向に行うべき種々の実施形態では、列当たり１つのパケット等（例えばＩＰパケット）だけをロードするように実施することができる。

このような実施形態の場合に、アレーの行及び／又は列のサイズは、列が最大サイズのパケット等を保持できるように選択することができる。列にロードされるパケット等が最大サイズ未満である場合には、列の残りの部分が「スタッフデータ」で埋められる。特定例として、残りの部分にゼロを埋めてもよい。

図４には、上述した種類のロード動作が例示されている。図４において、例示的パケット等３０１は、最大サイズとされ、従って、それが存在する列３０３にはスタッフデータが追加されない。一方、パケット等３０５は、最大サイズ未満であり、従って、その列にはスタッフデータ３０７が追加され、パケット等３０５とスタッフデータ３０７との組み合わせで列全体を占有する。又、１つ以上の全列がスタッフデータのみを含むことも考えられる。このような列は、データを含む列の前、その中間、又はその後に配置されてもよく、或いはそれらの組み合わせが使用されてもよい。

ロードを列方向に行うべき種々の実施形態においてロードを行う別の例として、パケット等が、それがロードされる列を完全に占有しない場合には、次のパケット等をアレー等にロードして列のロードを継続できるように実施することができる。更に、列にロードされるパケットがその列に完全に適合し得ない場合には、その適合しない部分を１つ以上の付加的な列に入れることができる。

このような機能は、例えば、特定のパケット等が列内に完全に適合しない場合に、列の最後のアドレス可能なエレメント（例えば、最高の行方向アドレスを有する列のエレメント）までパケット等のコンテンツでその列を埋め、そしてパケット等の残りを、その次の列に、その列の最初のアドレス可能なエレメント（例えば、最低の行方向アドレスを有する列のエレメント）で始めて、入れるようにして、実施することができる。

図５に例示するのは、上述した種類のロード動作である。図５において、例示的なパケット等４０１は、それがロードされる列４０３を完全に埋めず、従って、列４０３の残りは、パケット等４０５の部分で埋められる。しかしながら、パケット等４０５は、パケット等４０１で埋められないでいる列４０３の部分には完全に適合できないので、そのパケット等の残りは、列４０７に、この例では最初のエレメント（例えば、最低の行方向アドレスを有する列のエレメント）で始めて、入れられる。

上述した種類の種々の実施形態において、入れられたパケット等の間にスタッフデータを入れてもよいことに注意されたい。このような機能は、例えば、パケット等及びそれに関連したスタッフデータが、例えば、ワード長さ（バイト）の整数倍の長さを有するように、パケット等の長さを丸めるという目標で、実施されてもよい。このような機能が使用される実施形態では、対応するアレー等に対するアドレッシング機構を簡単化することができる。というのは、ロードを列方向に行うべき実施形態では、行方向アドレッシングを全バイトの粒度で実施できるからである。又、ここに述べる種類の実施形態では、データで埋められた列と列の間に、又はデータで埋められた列の前又は後に、或いはこれら両方の技術の組み合わせにより、スタッフデータの完全な列を使用することができる。

列当たり１つのパケット等だけが入れられるようにしてロードを実行する実施形態では、特定のパケット等がそれに対応するアレー等のどこに入れられるかに関連した前記種類の指示は、ロードが列方向である場合に、アレー等のどこにパケット等が記憶されたかに対応する列アドレスに関連するだけでよいことに注意されたい。

例えば、受信者ノードにおいて、受信したパケット等を、指示された列の最初のアドレス可能なエレメント（例えば、最低の行方向アドレスを有する列のエレメント）に入れるべきであること、及びこのような列の埋められていない部分をスタッフデータで埋めるべきであることが理解されるように実施することができる。一方、列当たり２つ以上のパケット等が入れられるようにしてロードを実行する実施形態では、上述した種類の指示は、行方向及び列方向の両アドレスを指定することが必要である。

アドレス動作に説明を転じると、本発明の種々の実施形態に基づき、上述した種類のアレー等に対してアドレス機構を決定することができる。特定サイズのアレー等について考えると、アドレス機構の選択は、そのアレー等におけるアドレス可能なエレメントの数を決定する作用を有すると考えられる。

特定サイズのアレー等について考えるときには、行方向のアドレス機構の選択は、上述した種類のアレー等における行の数を決定する作用を有すると考えられ、一方、列方向のアドレス機構の選択は、上述した種類のアレー等における列の数を決定する作用を有すると考えられる。更に、行方向及び列方向のアドレス機構の選択は、特定サイズのアレー等について考えるときには、そのアレー等の各アドレス可能なエレメントのサイズの選択として考えられることに注意されたい。

特定例として、上述した種類のアレー等は、行及び列の両アドレッシングが１バイトの粒度で実施されるように実施できる。上述した種類のアレー等にデータを列方向にロードすべきである別の特定例として、列方向のアドレッシングを、使用可能なアドレス空間を最大限利用するように選択できる。例えば、３２ビットアドレッシングが使用できる場合には、考えられる最大の列数を許すように列方向アドレッシングを選択することができ、その決定は、おそらく、アレー等に記憶されるべき最大データサイズ（例えば、ＩＰパケット）を考慮して行われる。

ロードを列方向に行うべき更に別の特定例として、得られる行数がチャンネルエラー振舞いに対して最適化されるように行方向アドレッシングを実施することができる。ロードを列方向に行うべき更に別の特定例として、得られる行数が、特定の特性値決定（例えば、ＦＥＣ）技術のプロパティと一貫したものになるように行方向アドレッシングを実施することができる。

サイズに説明を転じると、上述した種類のアレー等のサイズの選択は、アレー等に対して行の巾及び列の高さを選択することに関して達成できることに注意されたい。サイズの選択は、本発明の種々の実施形態によれば、多数の仕方で実施できる。例えば、ロードを列方向に行うべき場合には、列の高さを、アレー等にロードされるべき種類のパケット等の最大サイズに一貫したものとなるように選択できる。或いは又、何らかの他の値が選択されてもよい。このような選択は、例えば、システムアドミニストレータ又は他の個人により行われてもよい。

列の高さがこのように選択されたアレー等に対する行の巾は、多数の仕方で選択することができる。例えば、行の巾は、バースト内で送信することが許されるパケット等の最大数を判断し、次いで、対応する特性値（１つ又は複数）に必要とされるアレー等における特別な余地を決定することにより、選択できる。このような実施形態の場合に、アレー等の特性は、送信ノード及び受信者ノートにより前もって知ることができる。アレーの巾は、特性値を計算するために選択された方法に適合するように選択されてもよい。選択された方法は、データに対する列の数と、特性値に対する列の数の両方を決定することができる。例えば、リードソロモンエンコーディング２５５の選択は、データに対して１９１の列と、特性値に対して６４の列とを招く。

ロードを列方向に実行すべき別の例として、送信側ノードは、発送される各バーストに対してアレー等のサイズを変更することができる。特定例として、送信側ノードは、対応するアレー等が、全てのパケット等と、特定のバースト内で送信されるべきそれに対応する特性データとを保持できるように、列の高さ及び行の巾を選択してもよい。別の例として、送信側ノードは、同様に、しかし、指定の及び／又は固定の列高さ又は行巾に基づいて、動作することができる。例えば、列の高さが指定される場合には、このような列の高さは、アレー等にロードされるべき種類のパケット等の最大サイズに一貫したものとなるか、或いは何らかの他の値でもよい。列の高さ及び／又は行の巾が固定されない実施形態では、送信側ノードは、上述したように、１つ以上のサイズ指示を受信者ノードへ発送することができる。アレー等のサイズが固定される種々の実施形態では、アレー等が全部使用されるのではない場合に、送信側ノードは、アレー等のどの部分を使用すべきかの指示を受信者ノードに送信してもよい。このような指示は、例えば、アドレスでよい。

上述したように、以上の説明は、列方向にロードされるアレー等に関して述べたものであるが、種々の実施形態では、ロードを行方向に行うこともでき、そしてそのような実施形態では、機能は上述したものと同様であるが、行方向の観点が列方向となり且つその逆にもなることに注意されたい。

特性データを使用すべきかどうかの決定
上述したように、本発明の種々の実施形態によれば、受信者ノードは、受信した特性値を使用すべきかどうか決定するために適切な動作を遂行できる。このような動作は、例えば、ノードのユーザにより、例えば、ＧＵＩ又は他のインターフェイスを経て入れられる命令に基づいて実行される。特性値を使用できるかどうか決定するために、種々の機構をノードにより使用することができる。

例えば、受信した特性値がＦＥＣ等に対応する実施形態では、対応する送信側ノードにより最初にロードされた、受信した、おそらく変更された、パケット等にエラーがあるかどうかを受信者ノードが決定するような機構を使用することができる。受信者ノードは、例えば、ＣＲＣ（繰り返し冗長チェック）技術を使用して、その決定を行うことができる。エラーが見つかった場合には、受信者ノードは、受信した特性値の１つ以上を使用するように動作してもよい。又、他の下位レイヤのチャンネルデコーディングを使用して決定を行ってもよい。又、下位レイヤのチャンネルでコーディングは、どこでエラーが生じたかの指示を与えてもよい。

パケット等のロードが列方向である実施形態の別の例として、１つ以上の行に対して２つ以上の特性値が決定される場合に、受信者ノードは、これら行の各々に対して、対応する特性値の１つのみを使用するように動作できる。受信者ノードは、例えば、検出されたエラーに対応する特性に基づいてこのような選択を行うことができる。このような特性は、例えば、エラー形式、程度等を含む。

パケット等のロードが列方向である実施形態の更に別の例として、受信者ノードは、対応する特性値を、ある行に対して適用するが、他の行には適用しないように選択することができる。上述したように、受信者ノードは、このような選択を、例えば、検出したエラーに対応する特性に基づいて行うことができる。

更に別の例示的構成によれば、受信者ノードは、使用可能な充分なメモリを有すると決定された場合だけ、受信した特性値を使用するように動作することができる。充分なメモリをもつことは、例えば、対応する送信側ノードにより形成され及び／又はアクセスされるアレー等に対応するアレー等を形成し及び／又はそれにアクセスするに充分なメモリを有し、及び／又は受信した特性値に関して動作を実行するに充分なメモリを有することを意味する。

このような構成を実行することは、例えば、受信者ノードが、アレー等について必要なサイズの仕様を協議し、空き及び／又は解放可能なメモリの量を決定し、そして充分なメモリが使用できるかどうか決定することを含み得る。別の例として、このような構成を実行することは、それとは別に、又はそれに加えて、受信者ノードが、受信した特性値に関して動作を行うためのメモリの量を決定することを含み得る。必要なサイズの仕様は、例えば、上述した種類の発送される指示に含ませることができる。別の例として、必要なサイズの仕様は、上述したように全てのアレー等に使用されるようにセットされたサイズに適合することができる。

更に別の例示的構成によれば、受信者ノードは、それを行うに充分なエネルギー（例えば、バッテリ電力）及び／又は使用可能な処理容量があると決定された場合だけ、受信した特性値を使用するよう動作することができる。このような機能は多数の仕方で実施することができる。例えば、受信者ノードは、修正されるべきエラーの形式、程度等の前記決定を実行することができる。ノードは、次いで、おそらく、含まれた特性データの形式（例えば、リードソロモンデータ）を考慮に入れて、エラーを修正するに必要なエネルギー及び／又は使用可能な処理容量の推定を行う。決定された使用可能なエネルギー及び／又は処理容量を考慮した推定に鑑み、ノードは、特性データを使用するのに充分なエネルギー及び／又は処理容量があるかどうか判断することができる。

ノードは、例えば、アクセス可能なアルゴリズム、ソフトウェアモジュール等を使用して計算を実行することにより推定を行うことができる。別の例として、ノードは、修正されるべきエラー形式、エラー程度等に関連したアクセス可能な記憶装置を必要なエネルギー及び／又は使用可能な処理容量と共に協議することにより推定を行うことができる。又、ノードは、例えば、そのオペレーティングシステム及び／又はロードされたソフトウェアモジュールにより与えられる機能を使用して、使用可能なエネルギー及び／又は処理容量を決定することができる。

更に別の例示的構成によれば、受信者ノードは、あるサービス、チャンネル、データ形式等に対してのみ、受信した特性値を使用するように動作できる。例えば、受信者ノードは、ソフトウェア及び／又はファイルのダウンロードに対してのみ、受信した特性データを使用するように動作できる。ノードのユーザは、種々の実施形態において、受信した特性データを使用すべきところのサービス、チャンネル、データ形式等を指定することができる。更に、種々の実施形態において、これらは、システムアドミニストレータ等により指定することもできる。更に別のサービス、チャンネル、データ形式等がそれらの支払いに対して影響を及ぼすと共に、ターミナルのグラフィックユーザインターフェイス（ＧＵＩ）を経て行うことができる。

更に別の例示的な構成によれば、送信側ノードは、あるサービス、チャンネル、データ形式等に対してのみ、特性値を計算しそして使用することができる。

図８には、送信プロトコルスタックの実施形態が示されている。ここに実施される本発明の送信の基礎は、ＩＳＯ／ＩＥＣ１３８１８−１ ＭＰＥＧ−２に基づくストリーム送信をベースとすることができる。例えば、ＴＳは、ＩＳＯ／ＩＥＣ１３８１８−１に基づく送信をベースとすることができる。ＰＳＩ／ＳＩテーブルは、送信されたサービスを通知しそして発見するのに必要な情報を含むのが好ましい。ＭＰＥ及びＦＥＣテーブルは、基本的ＰＳＩ／ＳＩ情報に対して並列に、図８のプロトコルスタックに追加できるのが好都合である。ＰＳＩは、焦点を当たるためのテーブル、即ちプログラムアソシエーションテーブル（ＰＡＴ）及びプログラムマップテーブル（ＰＭＴ）を定義し、更に、ＳＩは、ネットワークインフォメーションテーブル（ＮＩＴ）及びＩＰ／ＭＡＣノーティフィケーションテーブル（ＩＮＴ）を定義し、これらは全てストリームについての情報を与えることに関連している。例えば、基本的ストリーム又は搬送ストリームは、適用されるサービスのレイヤに基づいている。ＭＰＥは、ＩＰデータパケット、即ちＩＰペイロードに焦点を当てる。ペイロードは、ヘッダと共にＭＰＥセクションパケットに含まれる。ＭＰＥセクションパケットは、エラー修正手順に対して高レベルＦＥＣフレームに適用することができる。ＦＥＣは、ＦＥＣペイロードに焦点を当てる。ある実施形態では、ＦＥＣに基づく情報及びＭＰＥに基づく情報を互いに分離することができる。ＦＥＣに基づく情報等及びＭＰＥに基づく情報等は、必ずしも良好なものについて分離されず、ある実施形態における考え方は、ＦＥＣ情報及びＭＰＥ情報を異なるヘッダで識別することである。ＦＥＣに基づく情報及びＭＰＥに基づく情報は、好ましくは、ＰＳＩ及びＳＩハイアラーキーレイヤレベルに対して並列であり、従って、ある実施形態では、おそらくブロードキャスト送信／受信の早期段階で分離の基礎を設定して実行することができる。ＰＳＩ／ＳＩは、早期の基本的サービス発見の基礎を設定する。

従って、図９を参照すれば、ＭＰＥアプリケーションデータテーブル又はＭＰＥセクションパケットに関連した保護ペイロードのヘッダを、独特の識別値又は名前で表示することができる。図９の例には、Ｎに対応するようにセットされた値Ｔａｂｌｅ＿ｉｄが与えられる。又、ＦＥＣデータのヘッダも、独特の識別値又は名前で表示することができる。図９の例には、値Ｍを指示するようにセットされた値Ｔａｂｌｅ＿ｉｄが与えられる。ＭＰＥアプリケーションデータテーブル及びＦＥＣデータテーブルを独特に又は少なくとも互いに分離し且つ識別するように他の値／特性を表示できることに注意されたい。

カプセル化動作
ＭＰＥは、本発明の種々の実施形態に使用することができる。又、上述したように、このようなＭＰＥは、例えば、ＤＳＭ−ＣＣ ＭＰＥでよい。ＭＰＥに関する情報は、例えば、参考としてここに取り上げるＥＴＳＩドキュメントＴＲ１０１２０２に見ることができる。本発明の実施形態に基づくＭＰＥの使用例が図２に示されている。

図２に示すように、送信側ノードは、計算された特性値に対応するデータを搬送するＭＰＥ ＤＳＭ−ＣＣセクションパケット等（例えば、ＩＰパケット）、及び／又はおそらく変更された最初にロードされたパケット等（例えば、ＩＰパケット）にデータセグメントを入れる（ステップ１０９）。次のステップとして、ＤＳＭ−ＣＣセクションは、例えば、ＭＰＥＧ−２ ＴＳパケットに入れることができる（ステップ１１１）。種々の実施形態において、第１のＰＩＤ値は、おそらく変更された最初にロードされたパケット等に対応するデータを搬送するＴＳパケットに関連付けられ、一方、第２のＰＩＤ値は、特性値に対応するデータを搬送するＴＳパケットに関連付けられる。ＴＳパケットは、例えば、ＤＶＢリンクのようなリンクを経て、即ち共通の基本的ストリームにおいて、送信することができる。図２についての以上の説明から、特性値は、ＲＳコードのようなＦＥＣデータであり、且つカプセル化されたデータは、図１０に示すように、ＭＰＥ−ＦＥＣフレームに入れられることが理解される。より詳細には、アプリケーションデータセグメントは、レイヤ３データグラム、即ちＩＰデータグラムを含んでもよい。これらのＩＰデータグラムは、図２を参照して上述したように、送信器ノードにおいて二次元アレー構造体へ列方向に書き込まれる。図２に示す列１０１は、図１０に示すＭＰＥ−ＦＥＣフレームにおいてアプリケーションデータテーブルへロードされる。アレーの各位置は、情報バイトをホストする。より詳細には、フレームの左部分は、ＯＳＩレイヤ３（ネットワークレイヤ）データグラム（例えば、ＩＰデータグラム）及び考えられるパッディングに対して専用の１９１個の最も左の列より成り、そして図１０において「アプリケーションデータテーブルＡＤＴ」と称される。フレームの右部分は、ＦＥＣコードのパリティ情報に対して専用の６４個の最も右の列より成り、そして図１０において「ＲＳデータテーブル」と称され、ＲＳＴと示されている。アプリケーションデータテーブルにおける各バイト位置は、０から１９１ｘ行数−１の範囲のアドレスを有する。同様に、ＲＳデータテーブルにおける各バイト位置は、０から６４ｘ行数−１の範囲のアドレスを有する。レイヤ３データグラムは、マトリクスの左上隅の第１データグラムの第１バイトで始めて第１列を下方に進んで、データグラムごとに導入される。データグラムの長さは、データグラムごとに任意に変化し得る。１つのデータグラムの終りの直後に、次のデータグラムが始まる。データグラムが正確に列の終りで終わらない場合には、次の列の最上部へ続く。全てのデータグラムがアプリケーションデータテーブルに入力すると、埋められていないバイト位置にゼロバイトが詰め込まれて、最も左の１９１個の列を完全に埋める。ＲＳデータテーブルにおける配送されたＲＳデータの位置は、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒで指示される。セクション０は、ＲＳデータテーブルの第１（最も左）の列を搬送し、セクション１は、第２の列を搬送し、等々となる。配送されない列は、常に、ＲＳデータテーブルの最も右の列である。

この１８ビットフィールドは、図１０のアプリケーションデータテーブル又はＲＳデータテーブルにおけるバイト位置を、セクション内で搬送されるペイロードの第１バイトに対して指定する。アプリケーションデータテーブル又はＲＳデータテーブルに対するデータを配送する全てのセクションは、このフィールドの値に基づいて上昇順に配送される。

バイト位置は、アプリケーションデータテーブル又はＲＳデータテーブル内のゼロベース直線アドレスで、第１列の第１行から始めて、列の終りに向かって増加する。列の終りにおいて、次のバイト位置は、次の列の第１行となる。

所与のＭＰＥ−ＦＥＣフレームのデータを搬送する第１セクションは、アドレス「０」のアプリケーションデータデータグラムを搬送するＭＰＥセクションである。所与のＭＰＥ−ＦＥＣフレームのアプリケーションデータデータグラムを搬送する全てのセクションは、ＭＰＥ−ＦＥＣフレームのＲＳデータを搬送する第１セクションの前に送信される（即ち、アプリケーションデータデータグラムを搬送するセクションは、単一のＭＰＥ−ＦＥＣフレーム内でＲＳデータを搬送するセクションとインターリーブされてはならない）。ＭＰＥ−ＦＥＣフレームの最初のセクションと最後のセクションとの間に搬送される全てのセクションは、ＭＰＥ−ＦＥＣフレームに属するデータを搬送する（即ち、アプリケーションデータ及びＲＳデータのみが許される）。異なるＭＰＥ−ＦＥＣフレームのデータを配送するセクションは、インターリーブされない。

ＭＰＥ−ＦＥＣフレームにおいてアプリケーションデータデータグラムを搬送する最後のセクションに続くセクションは、同じＭＰＥ−ＦＥＣフレームのＲＳデータを搬送する第１セクション、或いは次のＭＰＥ−ＦＥＣフレームの第１アプリケーションデータセクションのいずれかを含む。後者のケースでは、第１のＭＰＥ−ＦＥＣフレームのＲＳデータは、例えば、受信者ノードにより必要とされないときには送信されない。

各ＭＰＥ−ＦＥＣフレームに対して、アドレスフィールドが値「０」にセットされた厳密に１つのＭＰＥセクションが送信される。ＲＳデータが送信されるところの各ＭＰＥ−ＦＥＣフレームに対して、アドレスフィールドが値「０」にセットされた厳密に１つのＭＰＥ−ＦＥＣセクションが送信される。アプリケーションデータテーブルの配送されたアプリケーションデータ内にパッディングが存在してはならない。データグラムは、アプリケーションデータテーブルにおいて重畳しない。ＲＳデータテーブルの配送されたＲＳデータ内にはパッディングが存在しない。

図１０は、等しい長さの列方向データグラムに対応する概略図である。これは、理論的に可能なもので、ネットワークをマネージし且つ管理するネットワークオペレータは、列の高さを定義することができる。しかしながら、実際には、ＩＰデータグラムのサイズは、データグラムごとに変化し、通常、そのサイズは、〜１００・・・１５００バイトであり、そしてデータグラムの埋められていない部分は、上述したように「０」パッディングで埋めることができる。

次いで、図２に示すコンフィギュレーション１０３を形成するように図１０のアプリケーションデータテーブル１０１のアレーの行を考慮することによりＲＳデータが計算され、そしてそれにより得られるＲＳデータの行が図１０のＲＳデータテーブルにロードされる。ＲＳコードは、ＲＳ（２５５、１９１又は６４）のような所定の解像度に対して計算され、且つ各行に対して個別に計算される。次いで、図２のステップ１０５に対して、図１０のＭＰＥ−ＦＥＣフレームは、アプリケーションデータテーブルの最初のＩＰデータグラムで始めて、空にされる。ＩＰデータグラムは、ＭＰＥセクションにパックされる。（ＭＰＥセクション当たり１つのＩＰデータグラム）

アプリケーションデータテーブル１０１におけるＩＰデータグラムのアドレスがＭＰＥセクションのヘッダフィールドに入れられる。タイムスライシング又はＭＰＥ−ＦＥＣが使用される基本的ストリームにおいて、各ＭＰＥセクション及びＭＰＥ−ＦＥＣセクションは、以下のテーブル１に示すように、そのヘッダフィールドにおいてリアルタイムパラメータを搬送する。ＭＰＥセクションの場合に、リアルタイムパラメータは、未使用のＭＡＣ＿ａｄｄｒｅｓｓ＿４・・・ＭＡＣ＿ａｄｄｒｅｓｓ＿１内で搬送され、従って、帯域巾を最適化する。
テーブル１

又、同じステップにおいて、他のリアルタイムパラメータもＭＰＥセクションヘッダフィールドに入れられる。ＭＰＥセクションにおける最後のＩＰデータグラムの後に、リアルタイムパラメータテーブル境界が「１」にセットされ、このＭＰＥセクションがアプリケーションデータテーブルからの最後のＩＰデータグラムを含むことを指示する。

次いで、図１０のＲＳテーブルの列が、最初の列（＝アプリケーションデータテーブルに最も近い列）から始めて、空にされる。ＭＰＥ−ＦＥＣテーブルの各列のＲＳバイトは、個々のＭＰＥ−ＦＥＣセクションと共にパックされる。図１１に示すように、ＲＳバイトは、ＲＳ−ＦＥＣバイトに入れられる。リアルタイムパラメータは、前記ＭＰＥセクションの場合と同様に、ＭＰＥ−ＦＥＣセクションヘッダに各々結合される。

ＭＰＥ−ＦＥＣセクション−（ＭＰＥ−ＦＥＣセクションヘッダ＋トレーラー）の長さは、ＭＰＥ−ＦＥＣフレームに使用される行の数を受信器に指示する。行の数は、ｔｉｍｅ＿ｓｌｉｃｅ＿ｆｅｃ＿ｄｅｓｃｒｉｐｔｏｒにおいて受信器にシグナリングされる。これに対する最大許容値は、１０２４であり、これは、全ＭＰＥ−ＦＥＣフレームを、この例では、ほぼ２Ｍビットにする。例えば、エンドユーザがクオリティの低いサービスでも良い場合には、容量及び／又はサービスクオリティに基づいて、全ての計算されたＲＳデータバイトを送信する必要はない。例えば、このようなパケットは、１つ以上の特性値の各々に対応するデータの部分を含むことができる。パンクチャーされるＲＳ列の厳密な量を明確にシグナリングする必要はなく、フレーム間で動的に変化してもよい。アプリケーションデータテーブルのパッディング列の厳密な数は、各ＭＰＥ−ＦＥＣセクションのヘッダにおいてシグナリングされる。この８ビットフィールドは、パッディングバイトのみで埋められた実際のＭＰＥ−ＦＥＣフレームのアプリケーションデータテーブルの全列の数を指示する。指示される値は、０から１９０でなければならない。この値は、フレームごとに変化してもよいことに注意されたい。パンクチャーされるＲＳ列の数は、６３−ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒとして計算することができる。というのは、このｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは、最後のセクションのセクション番号を指示するからである。セクション番号はゼロベースであるから、指示される番号は、列の数より１つ小さい。

受信器は、ＭＰＥ−ＦＥＣセクションで指示されるように、アプリケーションデータテーブルにパッディングバイトの数を導入する。これらのパッディングバイトは、それを確実であるとマークする。又、受信器は、ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒから計算されるものとしてパンクチャーされるＲＳ列の数を導入する。この導入されたパンクチャーされるＲＳ列の実際のデータは、パンクチャーされる全てのデータが不確実と考えられるので、無関係である。

全てのＭＰＥ及びＭＰＥ−ＦＥＣセクションは、エラーのある全てのセクションを確実に検出するＣＲＣ−３２コードにより保護される。アプリケーションデータテーブル又はＲＳデータテーブルに属する正しく受信された各セクションに対して、受信器は、セクションヘッダにおいて、そのセクション内のペイロードのスタートアドレスを探索し、次いで、各テーブルの右部分にペイロードを入れることができる。

更に、図３に示すように、受信者ノードは、前記種類のＴＳパケットを受信すると（ステップ２０１）、これらパケットにより搬送されるＤＳＭ−ＣＣセクションを抽出することができる（ステップ２０３）。次いで、ノードは、これらＤＳＭ−ＣＣセクションから、計算された特性値、及び／又は搬送されたおそらく変更された最初にロードされたパケット等（例えば、ＩＰパケット）に対応するデータを搬送するパケット等（例えば、ＩＰパケット）を抽出する（ステップ２０５）。

ＤＳＭ−ＣＣ ＭＰＥをここに説明するが、他のＭＰＥ技術も使用できることに注意されたい。更に、ＤＳＭ−ＣＣセクションがアレー等に入れられないようにＭＰＥを実施することについて上述したが、種々の実施形態において、前記パケット等を搬送するＤＳＭ−ＣＣセクションをそこに入れることができることにも注意されたい。

パンクチャリング
マザーコードより実際に弱いコードレートが、前記で簡単に述べたパンクチャリングにより得られる。パンクチャリングは、全ての特性値（全ての列）を計算することに対応するが、ある列は破棄され、即ち「パンクチャリング」され、それ故、送信されない。パンクチャリングは、ここに述べる実施形態では、最後のＲＳデータ列の１つ以上を破棄することにより実行できる。破棄される（パンクチャリングされる）ＲＳ列の数は、ＭＰＥ−ＦＥＣフレーム間において［０−６３］の範囲内で動的に変化することができ、そしてＲＳ列が送信されないケース（パンクチャリングは６４列）を除いて、６３−ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒとして計算することができる。パンクチャリングは、ＲＳデータにより導入されるオーバーヘッドを減少し、従って、必要とされる帯域巾を減少する。パンクチャリングの欠点は、実際に弱いエラーチェックコードレートである。種々の実施形態において、特性値を計算する仕方を動的に変更できることに注意されたい。特性値がＦＥＣデータ（例えば、リードソロモンデータ）に対応する特定例として、追加されるべきパリティデータの量を動的に変化させることができる。例えば、より多くの送信エラーを生じると予想されるネットワーク状態が生じる場合には、より多くのパリティデータを追加することができる。より少ないパリティ情報で満足であるときの更に別の状態も存在し得る。

タイムスライシング
この記述子は、基本的ストリームにタイムスライシングが使用されるかＭＰＥ−ＦＥＣが使用されるか識別する。この記述子が、基本的ストリームがタイムスライスされ及び／又はＭＰＥ−ＦＥＣが使用されることを指定するときには、ｄａｔａ＿ｂｒｏａｄｃａｓｔ＿ｄｅｓｃｒｉｐｔｏｒパラメータが特定サービスのサービス記述に与えられることに注意されたい。これは、値０ｘ０１又は０ｘ０２のＭＡＣ＿ａｄｄｒｅｓｓ＿ｒａｎｇｅを定義し、これは、基本的ストリーム内で受信器を区別するのにＭＡＣ＿ａｄｄｒｅｓｓ＿１・・・４が使用されないことを示す。この記述子は次のテーブルにおいて許される。

− ネットワーク情報テーブル（ＮＩＴ）
− 第１記述子ループに位置するときには、記述子は、実際のテーブル内に通知される全ての搬送ストリームに適用される。搬送ストリームのいずれかにｓｔｒｅａｍ＿ｔｙｐｅ０ｘ０Ｄを伴う全ての基本的ストリームが適用される。
− 第２記述子ループに位置するときには、記述子は、関連搬送ストリームに適用される。ｓｔｒｅａｍ＿ｔｙｐｅ０ｘ０Ｄを伴う全ての基本的ストリームが適用される。この記述子は、第１記述子ループにおいて考えられる記述子にオーバーライトする。
− ＩＰ／ＭＡＣノーティフィケーションテーブル（ＩＮＴ）

− プラットホーム記述子ループに位置するときには、記述子は、テーブル内に参照される全ての基本的ストリームに適用される。
− ターゲット記述子ループに位置するときには、記述子は、記述子が現れた後で当該ターゲット記述子ループ内に参照される全ての基本的ストリームに適用される。この記述子は、プラットホーム記述子ループ及びＮＩＴにおいて考えられる記述子にオーバーライトする。基本的ストリームがＩＮＴ内の多数の位置から参照されるケースでは、その各々が同じシグナリングを含まねばならない。

タイムスライス及びＦＥＣ識別子記述子に対するセマンティクスを以下に詳細に説明する。
ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ：これは、規格によって合意された所定のそれ自身の値を有する。
ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ：この８ビットフィールドは、このフィールドの直後の記述子のバイト数を指定する。

ｔｉｍｅ＿ｓｌｉｓｉｎｇ：この１ビットフィールドは、参照された基本的ストリームがタイムスライスされるかどうか指示する。値「１」は、タイムスライシングが使用されることを指示し、値「０」は、タイムスライシングが使用されないことを指示する。
ｍｐｅ＿ｆｅｃ：この２ビットフィールドは、参照される基本的ストリームがＭＰＥ−ＦＥＣを使用するかどうか、及びどんなアルゴリズムが使用されるかを指示する。コードは、以下のテーブル２に明記された通りである。

ｍａｘ＿ｂｕｒｓｔ＿ｄｕｒａｔｉｏｎ：この８ビットフィールドは、当該基本的ストリームにおいて最大バースト時間巾を指示するのに使用される。バーストは、Ｔ１の前にスタートしてはならず、そしてＴ２の後に終了してはならない。但し、Ｔ１は、以前のバーストにおいてΔｔにより指示される時間であり、そしてＴ２は、Ｔ１＋最大バースト時間巾である。最大バースト時間巾に対して指示された値は、２０ｍｓから５．１２ｓまででなければならず、解像度は、２０ｍｓであり、そしてフィールドは、次の式に基づいてデコードされる。
最大バースト時間巾＝ｍａｘ＿ｂｕｒｓｔ＿ｄｕｒａｔｉｏｎ＊２０ミリ秒
ｔｉｍｅ＿ｓｌｉｃｉｎｇが「０」にセットされる（即ち、タイムスライシングが使用されない）場合には、このフィールドは、将来使用するように予約され、そして使用されないときには０ｘ００にセットされねばならない。

ｆｒａｍｅ＿ｓｉｚｅ：この５ビットフィールドは、デコーダを使用してそのバッファの使用に適応させることができるという情報を与えるのに使用される。厳密な解釈は、タイムスライシング及び／又はＭＰＥ−ＦＥＣが使用されるかどうかに依存する。

タイムスライシングが使用される（即ち、ｔｉｍｅ＿ｓｌｉｃｉｎｇが「１」にセットされる）ときには、このフィールドは、基本的ストリームのタイムスライスバースト内に許されたセクションレベルにおいて最大ビット数を指示する。ビットは、ｔａｂｌｅ＿ｉｄフィールドの始めからＣＲＣ＿３２フィールドの終りまで計算される。ＭＰＥ−ＦＥＣが使用される（即ち、ｍｐｅ＿ｆｅｃが「１」にセットされる）場合には、このフィールドは、基本的ストリームの各ＭＰＥ−ＦＥＣフレームにおける厳密な行数を指示する。

タイムスライシング及びＭＰＥ−ＦＥＣの両方が当該基本的ストリームに使用されるときには、両限界（即ち、最大バーストサイズ及び行数）が適用される。
コードは、テーブル３に基づく。ｍａｘ＿ｆｒａｍｅ＿ｓｉｚｅが「ｒｅｓｅｒｖｅｄ＿ｆｏｒ＿ｆｕｔｕｒｅ＿ｕｓｅ」として示された値を有する場合には、受信器は、最大バーストサイズが２Ｍビットより大きく且つＭＰＥ−ＦＥＣフレームが１０２４より大きいと仮定しなければならない。

テーブル２：ＭＰＥ−ＦＥＣアルゴリズム
値 ＭＰＥ−ＦＥＣアルゴリズム
０ｘ００ ＭＰＥ−ＦＥＣ 使用されず ｎ／ａ
０ｘ０１ ＭＰＥ−ＦＥＣ 使用 リードソロモン（255、191、64）
０ｘ０２・・・０ｘ０３ 将来の使用のために予約

テーブル３：サイズコーディング
サイズ 最大バーストサイズ ＭＰＥ−ＦＥＣフレーム行
０ｘ００ 128kbits=131072bits ６４
０ｘ０１ 256kbits １２８
０ｘ０２ 384kbits １９２
０ｘ０３ 512kbits ２５６
０ｘ０４ 640kbits ３２０
０ｘ０５ 768kbits ３８４
０ｘ０６ 896kbits ４４８
０ｘ０７ 1024kbits ５１２
０ｘ０８ 1152kbits ５７６
０ｘ０９ 1280kbits ６４０
０ｘ０Ａ 1408kbits ７０４
０ｘ０Ｂ 1536kbits ７６８
０ｘ０Ｃ 1664kbits ８３２
０ｘ０Ｄ 1792kbits ８９６
０ｘ０Ｅ 1920kbits ９６０
０ｘ０Ｆ 2048kbits １０２４
０ｘ１０・・・０ｘ１Ｆ 将来の使用のために予約

タイムスライシングが使用されず、即ちＭＰＥ−ＦＥＣフレームがタイムスライシングなしに送信される場合には、基本的フレーム内で繰り返しＭＰＥ−ＦＥＣフレームインデックスをサポートするフィールドを制御の目的で使用することができる。フィールドの値は、その後の各ＭＰＥ−ＦＥＣフレームに対して１だけ増加する。値「１１１１１１１１１１１１」の後に、フィールドは、「００００００００００００」からスタートする。

ハードウェア及びソフトウェア
ここに述べる幾つかの手順等は、コンピュータにより又はコンピュータの助けで実行することができる。ここで使用する「コンピュータ」、「汎用コンピュータ」等の用語は、プロセッサカード、スマートカード、メディアデバイス、パーソナルコンピュータ、エンジニリアリングワークステーション、ＰＣ、マッキントッシュ、ＰＤＡ、コンピュータ化されたウオッチ、ワイヤード又はワイヤレスターミナル、サーバー、ネットワークアクセスポイント、ネットワークマルチキャストポイント等であって、おそらく、ＯＳＸ、Ｌｉｎｕｘ、Ｄａｒｗｉｎ、Ｗｉｎｄｏｗｓ（登録商標） ＣＥ、Ｗｉｎｄｏｗｓ（登録商標） ＸＰ、Ｐａｌｍ ＯＳ、Ｓｙｍｂｉａｎ ＯＳ等のオペレーティングシステムを実行し、おそらく、Ｊａｖａ（登録商標）又は．Ｎｅｔに対するサポートを伴うものを指すが、これらに限定されない。

又、「汎用コンピュータ」、「コンピュータ」等の用語は、１つ以上のメモリ又は記憶ユニットに作動的に接続された１つ以上のプロセッサであって、メモリ又は記憶装置がデータ、アルゴリズム、及び／又はプログラムコードを含み、そしてプロセッサ（１つ又は複数）がプログラムコードを実行し、及び／又はプログラムコード、データ、及び／又はアルゴリズムを操作するようなものを指すが、これらに限定されない。従って、図６に示す例示的コンピュータ５０００は、システムバス５０５０を備え、これは、２つのプロセッサ５０５１及び５０５２と、ランダムアクセスメモリ５０５３と、リードオンリメモリ５０５５と、入力／出力（Ｉ／Ｏ）インターフェイス５０５７及び５０５８と、記憶装置インターフェイス５０５９と、ディスプレイインターフェイス５０６１とを作動的に接続する。記憶装置インターフェイス５０５９は、次いで、大量記憶装置５０６３に接続される。Ｉ／Ｏインターフェイス５０５７及び５０５８の各々は、イーサネット（登録商標）、ＩＥＥＥ１３９４、ＩＥＥＥ１３９４ｂ、ＩＥＥＥ８０２．１１ａ、ＩＥＥＥ８０２．１１ｂ、ＩＥＥＥ８０２．１１ｇ、ＩＥＥＥ８０２．１６ａ、ＩＥＥＥＰ８０２．２０、ブルーツース、地上デジタルビデオブロードキャスト（ＤＶＢ−Ｔ）、衛星デジタルビデオブロードキャスト（ＤＶＢ−Ｓ）、デジタルオーディオブロードキャスト（ＤＡＢ）、汎用パケット無線サービス（ＧＰＲＳ）、ユニバーサル移動テレコミュニケーションサービス（ＵＭＴＳ）、又は他の周知のインターフェイスでよい。

大量記憶装置５０６３は、ハードドライブ、光学的ドライブ等でよい。プロセッサ５０５７及び５０５８は、各々、一般に知られたプロセッサ、例えば、ＩＢＭ又はモトローラのパワーＰＣ、ＡＭＤＡｔｈｌｏｎ、ＡＭＤＯｐｔｅｒｏｎ、インテルＡＲＭ、インテルＸＳｃａｌｅ、Ｔｒａｎｓｍｅｔａ Ｃｒｕｓｏｅ、又はインテル・ペンティウムでよい。又、この例に示されたコンピュータ５０００は、ディスプレイユニット５００１、キーボード５００２及びマウス５００３も備えている。別の実施形態では、キーボード５００２、及び／又はマウス５００３は、タッチスクリーン、ペン及び／又はキーパッドインターフェイスと置き換えられてもよいし、及び／又はそれらで増強されてもよい。コンピュータ５０００は、更に、カードリーダー、ＤＶＤドライブ、フロッピー（登録商標）ディスクドライブ等を含むか又はそれらに取り付けられてもよく、これにより、プログラムコードを含む媒体を、コンピュータにコードをロードする目的で挿入することができる。

本発明によれば、コンピュータは、上述したオペレーションの１つ以上を実行するように設計された１つ以上のソフトウェアモジュールを実行することができる。このようなモジュールは、この分野で知られた方法に基づいて、Ｊａｖａ（登録商標）、Ｏｂｊｅｃｔｉｖｅ Ｃ、Ｃ、Ｃ＃、及び／又はＣ＋＋のような言語を使用してプログラムすることができる。それに対応するプログラムコードを、例えば、ＤＶＤ、ＣＤ−ＲＯＭ、及び／又はフロッピー（登録商標）ディスクのような媒体に入れることもできる。特定のソフトウェアモジュールの中のオペレーションのここに述べる分割は、単なる例示に過ぎず、オペレーションの別の分割を使用してもよいことに注意されたい。従って、１つのソフトウェアモジュールにより実行されるとして説明するオペレーションは、複数のソフトウェアモジュールにより実行されてもよい。同様に、複数のモジュールにより実行されるとして説明するオペレーションは、単一のモジュールで実行されてもよい。

更に、本発明の実施形態は、あるソフトウェアモジュール、ティア等をある装置上で動作するとして開示するが、別の実施形態では、これらのモジュール、ティア等は、ここに述べる以外の装置上で実行するように分散されてもよい。例えば、特定のコンピュータにより実行されるとして開示されるオペレーションは、複数のコンピュータによって実行されてもよい。種々の実施形態では、グリッド計算技術を使用してもよいことに注意されたい。

図７は、本発明の種々の実施形態に使用できる例示的ターミナルの機能的ブロック図である。受信装置５ａは、マルチメディア能力をもつ移動電話であって、１つ以上のアンテナ１４又は多数のアンテナ及び１つ以上の受信器１５を使用して到来するデータを受信する。例えば、多数のアンテナ１４及び受信器１５は、第１及び第２の通信ネットワークが異なる無線技術を使用する場合に必要となる。特に、これは、他の通信リンク、例えば、ＧＳＭ、ＧＰＲＳ又は３Ｇ形式の通信リンクや、図１で述べたＤＶＢ通信リンクのような他の１つのデジタルブロードバンドが使用される場合である。バッテリ２３は、移動電話５ａに通電する。データの受信は、バッテリ電力の大きな割合を消費するので、例えば、受信器が要求に応じて又は必要なときだけオンになる場合にはバッテリの消費を制御することができ、このような装置にとって特に効果的である。他の通信ネットワークを経て冗長なパケットを与える方法は、エラー修正を実施しないターミナル（低エンドターミナル）をもつことができるようにする。「高エンド」ターミナルを有する加入者は、第２ネットワークから回復パケットを得るという能力を特別な利益として得ることができる。図７のターミナルは、前記で説明した。以下、対応する参照符号を、対応する部分に適用する。図７のターミナル５は、ここに述べるいずれかの／全ての実施形態に使用することができる。ターミナル５は、処理ユニットＣＰＵ２０と、マルチキャリア信号ターミナル部分１５と、ユーザインターフェイス２４とを備えている。マルチキャリア信号ターミナル部分１５及びユーザインターフェイス２４は、処理ユニットＣＰＵ２０に結合される。マルチキャリア信号ターミナル部分１５とメモリ２１、２２との間には１つ以上の直接メモリアクセス（ＤＭＡ）チャンネルが存在し得る。ユーザインターフェイス２４は、ユーザがターミナル５を使用できるようにするディスプレイ及びキーボードを備えている。更に、ユーザインターフェイス２４は、音声信号を受信し及び発生するためのマイクロホン及びスピーカを備えている。又、ユーザインターフェイス２４は、音声確認（図示せず）を備えてもよい。

処理ユニットＣＰＵ２０は、マイクロプロセッサ（図示せず）、メモリ６０４、及びおそらくソフトウェアを備えている。ソフトウェアは、メモリ２１、２２に記憶することができる。マイクロプロセッサは、ソフトウェアに基づき、ターミナル５のオペレーション、例えば、データストリームの受信、データ受信におけるインパルスバーストノイズの許容、ユーザインターフェイスにおける出力の表示、及びユーザインターフェイスから受信した入力の読み取りを制御する。これらのオペレーションは、上述した。ハードウェアは、信号を検出する回路と、復調回路と、インパルスを検出する回路と、著しい量のインパルスノイズが存在する場合にこれら記号サンプルをブランキングする回路と、推定を計算する回路と、崩壊したデータの修正を実行するための回路とを備えている。

或いは又、図７を更に参照すれば、ミドルウェア又はソフトウェア実施を適用することもできる。ターミナル５は、ユーザが心地良く携帯できるハンドヘルド装置である。又、ターミナル５は、マルチキャスト送信ストリームを受信するためのマルチキャリア信号ターミナル部分１５を備えたセルラー移動電話であるのが好都合である。それ故、ターミナル５は、おそらくサービスプロバイダーと対話することができる。

効果及び範囲
前記説明は、多数の細部を含むが、それらは、単に本発明を例示するものに過ぎず、本発明の範囲を何ら限定するものではない。従って、当業者であれば、本発明の範囲から逸脱せずに、ここに述べたシステム及び方法において種々の変更や修正がなされ得ることが明らかであろう。

Claims (62)

1. データ送信方法において、
   複数のインターネットプロトコルデータグラムを、第１の方向性構成及び第２の方向性構成を有する二次元データ構造体に入れるステップであって、前記第１の方向性構成は、
   機能的に前記第２の方向性構成に対して垂直であり、そして前記インターネットプロトコルデータグラムを入れることは、前記第１の方向性構成に対して行われるようなステップと、
   前記第２の方向性構成の各々に、１つ以上の対応する計算された特性値を追加するステップと、
   前記特性値の部分を保持する１つ以上の前記第１の方向性構成のコンテンツを送信するステップと、
   前記インターネットプロトコルデータグラムを送信するステップであって、前記二次元構造体に入れられた前記インターネットプロトコルデータグラムを、マルチプロトコルカプセル化セクションの第１の特定フォーマットに基づいて、マルチプロトコルカプセル化セクション当たり１つのインターネットプロトコルデータグラムで送信し、そして前記特性値の部分を保持する前記第１の方向性構成を、搬送ストリームにおいて、マルチプロトコルカプセル化セクションの第２の特定のフォーマットで送信するようなステップと、
   を備え、
   前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダはデータ構造体に入れる情報を含み、該情報は、前記インターネットプロトコルデータグラムの、又は、前記特性値の部分を保持する前記第１の方向性構成の、前記二次元構造体における位置を指示する、方法。
2. 前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダはデータセグメント境界を指示するデータを含む、請求項１に記載の方法。
3. 前記特性値の部分を含む１つ以上の前記第１の方向性構成の前記カプセル化されたコンテンツは、前記カプセル化されたインターネットプロトコルデータグラムから異なるバーストで送信される、請求項１又は２に記載の方法。
4. 前記特性値は順方向エラー修正のためのものである、請求項１から３のいずれかに記載の方法。
5. 前記特性値はリードソロモンコードである、請求項１から４のいずれかに記載の方法。
6. 前記第１の方向性構成はデータアレーの列に対応し、そして前記第２の方向性構成はその行に対応する、請求項１から５のいずれかに記載の方法。
7. インターネットプロトコルデータグラムを保持する前記マルチプロトコルカプセル化セクションはテーブルを備え、該テーブル内の埋められていない位置をパッディングデータで埋めるステップを備えた、請求項１から６のいずれかに記載の方法。
8. 前記テーブルをパッディングデータで埋める量をシグナリングするステップを備えた、請求項７に記載の方法。
9. 前記テーブルにおけるパッティングデータの列の数をマルチプロトコルカプセル化セクションヘッダにおいてシグナリングするステップを備えた、請求項８に記載の方法。
10. 前記テーブル内の埋められていない位置をパッディングデータで埋める前記ステップは、１つ以上の完全に埋められていない第１の方向性構成をパッディングデータで埋めることを含む、請求項７又は８に記載の方法。
11. パッディングデータで完全に埋められた前記１つ以上の第１の方向性構成の数を、前記特性値の部分を保持する各々のマルチプロトコルカプセル化セクションのヘッダにおいてシグナリングするステップを備えた、請求項１０に記載の方法。
12. インターネットプロトコルデータグラムを保持する前記マルチプロトコルカプセル化セクション及び前記特性値の部分を保持する前記マルチプロトコルカプセル化セクションを同じ基本的ストリームにおいて送信するステップを備えた、請求項１から１１のいずれかに記載の方法。
13. 前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダは、複数のインターネットプロトコルデータグラムを保持する前記マルチプロトコルカプセル化セクション及び前記特性値の部分を保持する前記マルチプロトコルカプセル化セクションを備えたフレームに対応するフレームパラメータを含む、請求項１から１２のいずれかに記載の方法。
14. 前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダは、複数のインターネットプロトコルデータグラムを保持する前記マルチプロトコルカプセル化セクション又は前記特性値の部分を保持する前記マルチプロトコルカプセル化セクションを備えたテーブルに対応するテーブルパラメータを含む、請求項１から１３のいずれかに記載の方法。
15. 前記パラメータは、前記フレーム又はテーブルに対応する前記セクションの最後のものを指示する、請求項１３又は１４に記載の方法。
16. 前記マルチプロトコルカプセル化セクションのヘッダのデータは、前記セクションのコンフィギュレーションに対応するリアルタイムパラメータを含む、請求項１から１５のいずれかに記載の方法。
17. 前記リアルタイムパラメータはタイムスライシング情報を含む、請求項１６に記載の方法。
18. 繰り返し冗長コード（ＣＲＣ）を使用して、インターネットプロトコルデータグラムを保持する前記マルチプロトコルカプセル化セクション及び前記特性値の部分を保持する前記マルチプロトコルカプセル化セクションを保護するステップを備えた、請求項１から１７のいずれかに記載の方法。
19. 第２の方向性構成の数をシグナリングするステップを備えた、請求項１から１８のいずれかに記載の方法。
20. 第２の方向性構成の数をシグナリングする前記ステップは、記述子においてデータを指定することを含む、請求項１９に記載の方法。
21. 前記ヘッダデータは、前記データグラムのＭＡＣアドレスに対して予約されたバイト位置において搬送される、請求項１から２０に記載の方法。
22. 前記インターネットプロトコルデータグラムを、それらが前記二次元データ構造体へとロードされた同じ順序で送信するステップを備えた、請求項１から２１のいずれかに記載の方法。
23. 前記特性値に対応するデータをパンクチャーするステップを備えた、請求項１から２２のいずれかに記載の方法。
24. 前記データをパンクチャーするステップは、前記特性値の部分を保持する前記第１の方向性構成の少なくとも１つを破棄することを含む、請求項２３に記載の方法。
25. 前記二次元データ構造体における第１データセットに対する第１のパンクチャー量は、前記二次元データ構造体における第２データセットに対する第２のパンクチャー量とは異なる、請求項２３又は２４に記載の方法。
26. 前記第２のパンクチャー量は、これをシグナリングしない、請求項２５に記載の方法。
27. 特性値の部分を保持する破棄された第１の方向性構成の数を、最後のデータセグメント番号に基いて計算するステップを備えた、請求項２３又は２４のいずれかに記載の方法。
28. 特性値の部分を保持する破棄された第１の方向性構成の前記数の計算は、正の整数である定数から前記最後のデータセグメント番号を減算した結果を決定することを含む、請求項２７に記載の方法。
29. インターネットプロトコルデータグラムを保持する前記マルチプロトコルカプセル化セクションはＭＰＥセクションであり、前記特性値の部分を保持する前記マルチプロトコルカプセル化セクションはＭＰＥ−ＦＥＣセクションである、請求項１から２８のいずれかに記載の方法。
30. 請求項１から２９に記載の方法を実行するように構成された送信器ノード。
31. 複数のインターネットプロトコルデータグラムを搬送ストリームにおいて受信するステップと、
    第１の方向性構成及び第２の方向性構成を有する二次元データ構造体を設けるステップであって、前記第１の方向性構成は、前記第２の方向性構成に対して機能的に垂直であり、そして前記インターネットプロトコルデータグラムを入れることは、前記第１の方向性構成に対して行われ、更に、前記二次元構造体に入れられた前記インターネットプロトコルデータグラムを、マルチプロトコルカプセル化セクションの第１の特定のフォーマットに基づいて、マルチプロトコルカプセル化セクション当たり１つのインターネットプロトコルデータグラムで受信し、又、前記第１の方向性構成は、前記搬送ストリームにおいて、マルチプロトコルカプセル化セクションの第２の特定のフォーマットで受信される特性値の部分も受信するようなステップと、
    前記受信した特性値を使用して前記第２の方向性構成に対して前記インターネットプロトコルデータグラムを処理して、前記第１の方向性構成に対して修正されたインターネットプロトコルデータグラムを与えるステップと、
    を備え、
    前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダはデータ構造体に入れる情報を含み、前記方法は、前記データ構造に入れる情報を使用して、前記二次元データ構造体への前記受信した特性値及び／又はインターネットプロトコルデータグラムのロードを制御するステップを備えた、方法。
32. 前記特性値は順方向エラー修正に対するものである、請求項３１に記載の方法。
33. 前記特性値はリードソロモンコードである、請求項３１又は３２に記載の方法。
34. 前記第１の方向性構成はデータアレーの列に対応し、そして前記第２の方向性構成はその行に対応する、請求項３１から３３のいずれかに記載の方法。
35. 前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダは、データセグメント境界を指示する情報を含み、そして前記データセグメント境界情報を使用して、前記二次元データ構造体への前記受信した特性値及び／又はインターネットプロトコルデータグラムのロードを制御するステップを備えた、請求項３１から３４のいずれかに記載の方法。
36. インターネットプロトコルデータグラムを保持する前記マルチプロトコルカプセル化セクション及び前記特性値の部分を保持する前記マルチプロトコルカプセル化セクションを同じ基本的ストリームにおいて受信するステップを備えた、請求項３１から３５のいずれかに記載の方法。
37. 前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダは、複数のインターネットプロトコルデータグラムを保持する前記マルチプロトコルカプセル化セクション及び前記特性値の部分を保持するマルチプロトコルカプセル化セクションを備えたフレームに対応するデータを含む、請求項３１から３６のいずれかに記載の方法。
38. 前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダは、複数のインターネットプロトコルデータグラムを保持する前記マルチプロトコルカプセル化セクション又は前記特性値の部分を保持する前記マルチプロトコルカプセル化セクションを備えたテーブルに対応するデータを含む、請求項３１から３７のいずれかに記載の方法。
39. 前記特性値の部分を保持する前記マルチプロトコルカプセル化セクションの幾つかだけを受信するステップを備えた、請求項３１から３８のいずれかに記載の方法。
40. 前記マルチプロトコルカプセル化セクションのヘッダはタイムスライシング情報を含み、そしてこのタイムスライシング情報に基づいて受信器ノードの動作を制御するステップを備えた、請求項３１から３９のいずれかに記載の方法。
41. 前記特性値の部分を保持するマルチプロトコルカプセル化セクションのヘッダ内のデータに基づいて前記二次元データ構造体にパッディングデータを導入するステップを備えた、請求項３１から４０のいずれかに記載の方法。
42. 前記二次元データ構造体に導入された前記パッディングデータを確実であるとマークするステップを備えた、請求項４１に記載の方法。
43. 最後のデータセグメント番号に基づき、特性データ値の部分を保持する破棄された第１の方向性構成に置き換わるように、第１の方向性構成を導入するステップを備えた、請求項３１から４２のいずれかに記載の方法。
44. 前記二次元データ構造体に導入された前記データを、不確実であるとしてマークするステップを備えた、請求項４３に記載の方法。
45. 前記マルチプロトコルカプセル化セクションヘッダを検査して、データ構造体に入れる情報を得るステップを備えた、請求項３１から４４のいずれかに記載の方法。
46. 前記データ構造体に入れる情報に基づいてテーブル内の前記データ構造体に入れるステップを備えた、請求項４５に記載の方法。
47. インターネットプロトコルデータグラムを保持する前記マルチプロトコルカプセル化セクションはＭＰＥセクションであり、前記特性値の部分を保持する前記マルチプロトコルカプセル化セクションはＭＰＥ−ＦＥＣセクションである、請求項３１から４６のいずれかに記載の方法。
48. 請求項３１から４７のいずれかに記載の方法により動作するように構成された受信器ノード。
49. 複数のインターネットプロトコルデータグラムを、第１の方向性構成及び第２の方向性構成を有する二次元データ構造体へ入れるように動作できるプロセッサであって、前記第１の方向性構成は、前記第２の方向性構成に対して機能的に垂直であり、そして前記インターネットプロトコルデータグラムを入れること、前記第１の方向性構成に対して行われ、更に、前記第２の方向性構成の各々に１つ以上の対応する計算された特性値を追加するように動作できるプロセッサと、
    前記特性値の部分を保持する１つ以上の前記第１の方向性構成のコンテンツと、前記インターネットプロトコルデータグラムとを搬送ストリームにおいて送信するように動作できる送信器コンフィギュレーションであって、前記二次元構造体に入れられた前記インターネットプロトコルデータグラムを、マルチプロトコルカプセル化セクションの第１の特定のフォーマットに基づいて、マルチプロトコルカプセル化セクション当たり１つのインターネットプロトコルデータグラムで送信し、そして前記特性値の部分を保持する前記第１の方向性構成を、搬送ストリームにおいて、マルチプロトコルカプセル化セクションの第２の特定のフォーマットで送信するような送信器コンフィギュレーションと、
    を備え、
    前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダは、データ構造体に入れる情報を含み、該情報は、前記インターネットプロトコルデータグラムの、又は、前記特性値の部分を保持する前記第１の方向性構成の、前記二次元構造体における位置を指示する、装置。
50. 前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダは、データセグメント境界を指示するデータを含む、請求項４９に記載の装置。
51. 前記特性値の部分を保持する１つ以上の前記第１の方向性構成のコンテンツは、前記インターネットプロトコルデータグラムから異なるバーストにおいて送信される、請求項４９又は５０に記載の装置。
52. データを受信するための受信器ノードにおいて、
    搬送ストリームにおいて複数のインターネットプロトコルデータグラムを、マルチプロトコルカプセル化セクションの第１の特定フォーマットに基づいて、マルチプロトコルカプセル化セクション当たり１つのインターネットプロトコルデータグラムで受信すると共に、前記搬送ストリームにおいて、マルチプロトコルカプセル化セクションの第２の特定フォーマットに基づいて特性値の部分を受信し、そして第１の方向性構成及び第２の方向性構成を有する二次元データ構造体を与えるための処理回路であって、前記第１の方向性構成は前記第２の方向性構成に対して機能的に垂直であり、そして前記インターネットプロトコルデータグラム及び特性値を入れることは、前記第１の方向性構成に対して行われ、更に、前記受信した特性値を使用して前記第２の方向性構成に対して前記インターネットプロトコルデータグラムを処理して、前記第１の方向性構成に対して修正されたインターネットプロトコルデータグラムを与えるように動作できる処理回路を備える装置であって、
    前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダはデータ構造体に入れる情報を含み、前記処理回路は、前記データ構造に入れる情報を使用して、前記二次元データ構造体への前記受信した特性値及び／又はインターネットプロトコルデータグラムのロードを制御するように動作できる、装置。
53. 前記第１の方向性構成はデータアレーの列に対応し、そして前記第２の方向性構成はその行に対応する、請求項５２に記載の装置。
54. 前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダは、データセグメント境界を指示する情報を含み、そして前記処理回路は、前記データセグメント境界情報を使用して、前記二次元データ構造体への前記受信した特性値及び／又はインターネットプロトコルデータグラムのロードを制御するよう動作できる、請求項５２又は５３に記載の装置。
55. 前記特性値は順方向エラー修正に対するものである、請求項５２から５４のいずれかに記載の装置。
56. 前記特性値はリードソロモンコードである、請求項５２から５５のいずれかに記載の装置。
57. 移動テレコミュニケーション装置を備えた、請求項５２から５６のいずれかに記載の装置。
58. 行及び列のデータ構造体を与え、前記列の各々にＩＰデータグラムをロードして、アプリケーションデータテーブルを集合的に定義するアプリケーションデータセクションを形成し、前記アプリケーションデータセクションの行に対応するエラー修正データの更なる列を形成するように動作し得るプロセッサであって、前記エラー修正データはエラー修正テーブルを定義し、このエラー修正テーブルの列はエラー修正セクションを含むようなプロセッサと、
    マルチプロトコルカプセル化セクションの前記セクションを搬送ストリームにおいて送信するための送信器と、を備え、前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダはデータ構造体に入れる情報を含み、該情報は、前記インターネットプロトコルデータグラムの、又は、前記特性値の部分を保持する前記第１の方向性構成の、前記二次元構造体における位置を指示する、装置。
59. コンピュータに、
    複数のインターネットプロトコルデータグラムを、第１の方向性構成及び第２の方向性構成を有する二次元データ構造体に入れるステップであって、前記第１の方向性構成は、機能的に前記第２の方向性構成に対して垂直であり、そして前記インターネットプロトコルデータグラムを入れることは、前記第１の方向性構成に対して行われるような手順と、 前記第２の方向性構成の各々に、１つ以上の対応する計算された特性値を追加する手順と、
    前記特性値の部分を保持する１つ以上の前記第１の方向性構成のコンテンツを送信する手順と、
    前記インターネットプロトコルデータグラムを送信する手順であって、前記二次元構造体に入れられた前記インターネットプロトコルデータグラムを、マルチプロトコルカプセル化セクションの第１の特定フォーマットに基づいて、マルチプロトコルカプセル化セクション当たり１つのインターネットプロトコルデータグラムで送信し、そして前記特性値の部分を保持する前記第１の方向性構成を、搬送ストリームにおいて、マルチプロトコルカプセル化セクションの第２の特定のフォーマットで送信するような手順と、
    を実行させるためのプログラムであって、
    前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダはデータ構造体に入れる情報を含み、該情報は、前記インターネットプロトコルデータグラムの、又は、前記特性値の部分を保持する前記第１の方向性構成の、前記二次元構造体における位置を指示する、プログラム。
60. コンピュータに、
    複数のインターネットプロトコルデータグラムを搬送ストリームにおいて受信する手順と、
    第１の方向性構成及び第２の方向性構成を有する二次元データ構造体を設ける手順であって、前記第１の方向性構成は、前記第２の方向性構成に対して機能的に垂直であり、そして前記インターネットプロトコルデータグラムを入れることは、前記第１の方向性構成に対して行われ、更に、前記二次元構造体に入れられた前記インターネットプロトコルデータグラムを、マルチプロトコルカプセル化セクションの第１の特定のフォーマットに基づいて、マルチプロトコルカプセル化セクション当たり１つのインターネットプロトコルデータグラムで受信し、又、前記第１の方向性構成は、前記搬送ストリームにおいて、マルチプロトコルカプセル化セクションの第２の特定のフォーマットで受信される特性値の部分も受信するような手順と、
    前記受信した特性値を使用して前記第２の方向性構成に対して前記インターネットプロトコルデータグラムを処理して、前記第１の方向性構成に対して修正されたインターネットプロトコルデータグラムを与える手順と、
    を実行させるためのプログラムであって、
    前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダはデータ構造体に入れる情報を含み、前記方法は、前記データ構造に入れる情報を使用して、前記二次元データ構造体への前記受信した特性値及び／又はインターネットプロトコルデータグラムのロードを制御する手順を備えたプログラム。
61. コンピュータに、
    複数のインターネットプロトコルデータグラムを、第１の方向性構成及び第２の方向性構成を有する二次元データ構造体に入れるステップであって、前記第１の方向性構成は、機能的に前記第２の方向性構成に対して垂直であり、そして前記インターネットプロトコルデータグラムを入れることは、前記第１の方向性構成に対して行われるような手順と、
    前記第２の方向性構成の各々に、１つ以上の対応する計算された特性値を追加する手順と、
    前記特性値の部分を保持する１つ以上の前記第１の方向性構成のコンテンツを送信する手順と、
    前記インターネットプロトコルデータグラムを送信する手順であって、前記二次元構造体に入れられた前記インターネットプロトコルデータグラムを、マルチプロトコルカプセル化セクションの第１の特定フォーマットに基づいて、マルチプロトコルカプセル化セクション当たり１つのインターネットプロトコルデータグラムで送信し、そして前記特性値の部分を保持する前記第１の方向性構成を、搬送ストリームにおいて、マルチプロトコルカプセル化セクションの第２の特定のフォーマットで送信するような手順と、
    を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって、
    前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダはデータ構造体に入れる情報を含み、該情報は、前記インターネットプロトコルデータグラムの、又は、前記特性値の部分を保持する前記第１の方向性構成の、前記二次元構造体における位置を指示する、コンピュータ読み取り可能な記録媒体。
62. コンピュータに、
    複数のインターネットプロトコルデータグラムを搬送ストリームにおいて受信する手順と、
    第１の方向性構成及び第２の方向性構成を有する二次元データ構造体を設ける手順であって、前記第１の方向性構成は、前記第２の方向性構成に対して機能的に垂直であり、そして前記インターネットプロトコルデータグラムを入れることは、前記第１の方向性構成に対して行われ、更に、前記二次元構造体に入れられた前記インターネットプロトコルデータグラムを、マルチプロトコルカプセル化セクションの第１の特定のフォーマットに基づいて、マルチプロトコルカプセル化セクション当たり１つのインターネットプロトコルデータグラムで受信し、又、前記第１の方向性構成は、前記搬送ストリームにおいて、マルチプロトコルカプセル化セクションの第２の特定のフォーマットで受信される特性値の部分も受信するような手順と、
    前記受信した特性値を使用して前記第２の方向性構成に対して前記インターネットプロトコルデータグラムを処理して、前記第１の方向性構成に対して修正されたインターネットプロトコルデータグラムを与える手順と、
    を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって、
    前記マルチプロトコルカプセル化セクションの少なくとも１つのヘッダはデータ構造体に入れる情報を含み、前記方法は、前記データ構造に入れる情報を使用して、前記二次元データ構造体への前記受信した特性値及び／又はインターネットプロトコルデータグラムのロードを制御する手順を備えたコンピュータ読み取り可能な記録媒体。

Images