(57)【特許請求の範囲】
【請求項１】
第１方向の配列と、該第１方向と直交する方向である第２方向の配列と、を有する単一の二次元データ構造に、複数のパケット全体を収納することを決定するステップであって、収納が、前記第１方向の配列に沿って行われる、ステップと、
前記第２方向の配列のそれぞれに、対応する計算された１つ以上の特性値を付加することを決定するステップと、
ディジタルビデオ放送網を通して、前記特性値の一部を含む前記第１方向の配列の１つ以上の内容を送信することを決定するステップと、
前記複数のパケット全体のそれぞれに、前記単一の二次元データ構造における当該パケット全体の位置を搬送するデータ構造での位置指標を付加することを決定するステップと、
ディジタルビデオ放送網を通して、単一バーストにおいて前記１つ以上の複数のパケット全体を送信することを決定するステップと、を含む方法。
【請求項２】
ディジタルビデオ放送網を通して、単一バーストにおいて複数のパケット全体を受信するステップであって、前記複数のパケット全体の各々について、単一の二次元データ構造における該パケット全体の位置を搬送するデータ構造での位置指標が受信される、ステップと、
前記受信した複数のパケット全体を前記単一の二次元データ構造に収納することを決定するステップであって、前記単一の二次元データ構造が、第１方向の配列と、該第１方向と直交する方向である第２方向の配列とを有し、収納が、前記第１方向の配列に沿って、行われる、ステップと、
１つ以上の前記第２方向の配列のそれぞれに、対応する１つ以上の受信した特性値を適用することを決定するステップであって、該適用により１つ以上の前記パケットを訂正する、ステップと、
前記単一の二次元データ構造から、複数の訂正されたパケット全体を取り出すことを決定するステップであって、収納が、前記データ構造での位置指標に従っている、ステップと、を含む方法。
【請求項３】
少なくとも１つのプロセッサと、コンピュータ・プログラムコードを含む少なくとも１つのメモリと、を備える装置であって、
該少なくとも１つのメモリと該コンピュータコードは、前記少なくとも１つのプロセッサを用いて、前記装置に、少なくとも、
第１方向の配列と、該第１方向と直交する方向である第２方向の配列と、を有する単一の二次元データ構造に、複数のパケット全体を収納することを決定することであって、収納が、前記第１方向の配列に沿って行われる、ことと、
前記第２方向の配列のそれぞれに、対応する計算された１つ以上の特性値を付加することを決定することと、
ディジタルビデオ放送網を通して、前記特性値の一部を含む前記第１方向の配列の１つ以上の内容を送信することを決定することと、
前記複数のパケット全体のそれぞれに、前記単一の二次元データ構造における当該パケット全体の位置を搬送するデータ構造での位置指標を付加することを決定することと、
ディジタルビデオ放送網を通して、単一バーストにおいて前記複数のパケット全体を送信することを決定することと、を実行させるように構成される、
装置。
【請求項４】
パケット群の各パケットが、前記特性値の一部を含む前記第１方向の配列の１つ以上の内容を含む、請求項３に記載の装置。
【請求項５】
前記特性値の計算がチャネル符号化に対応する、請求項３に記載の装置。
【請求項６】
少なくとも１つのプロセッサと、コンピュータ・プログラムコードを含む少なくとも１つのメモリとを備える装置であって、
該少なくとも１つのメモリと該コンピュータコードは、前記少なくとも１つのプロセッサを用いて、前記装置に、少なくとも、
ディジタルビデオ放送網を通して、単一バーストにおいて複数のパケット全体を受信することであって、前記複数のパケット全体の各々について、単一の二次元データ構造における該パケット全体の位置を搬送するデータ構造での位置指標が受信される、ことと、
前記単一の二次元データ構造に、前記複数のパケット全体を収納することを決定することであって、前記単一の二次元データ構造が、第１方向の配列と、該第１方向と直交する方向である第２方向の配列とを有し、収納が、前記第１方向の配列に沿って、行われる、ことと、
１つ以上の前記第２方向の配列のそれぞれに、対応する１つ以上の受信した特性値を適用することを決定することであって、該適用により１つ以上の前記複数のパケット全体を訂正する、ことと、
前記単一の二次元データ構造から、複数の訂正されたパケット全体を取り出すことを決定することであって、収納が、前記データ構造での位置指標に従っている、ことと、を実行させるように構成される、
装置。
【請求項７】
前記第１方向の配列のそれぞれが、前記訂正されたパケットのうちの２つ以上に対応するデータを含むことができる、請求項６に記載の装置。
【請求項８】
前記の特性値を適用することを決定することが、チャネル復号に対応する、請求項６に記載の装置。
【請求項９】
前記単一の二次元データ構造の性質が、受信した、データ構造の性質に関する指標に従う、請求項６に記載の装置。
【請求項１０】
パンクチャした前記第１方向の配列を明示的な形では通知しない、請求項１に記載の方法。
【請求項１１】
前記少なくとも１枚のメモリと前記コンピュータコードは、さらに、前記少なくとも１つのプロセッサを用いて、前記装置に、二次元データ構造の性質に関する指標を送信することを決定させる、ように構成される、請求項３に記載の装置。
【請求項１２】
１つ以上の前記第１方向の配列の残部を埋めるため、スタッフデータを収納する、請求項３に記載の装置。
【請求項１３】
パンクチャした前記第１方向の配列を明示的な形では通知しない、請求項３に記載の装置。
【請求項１４】
パケットのためのヘッダが、対応する最初に占められるアドレス可能な記憶位置のアドレスの指標を含んでいる、請求項３に記載の装置。
【請求項１５】
スタッフデータだけを含む１つ以上の前記第１方向の配列を、非スタッフデータを含む１つ以上の前記第１方向の配列の隣に配置する、請求項３に記載の装置。
【請求項１６】
受信したパケットの位置に、信頼性が高いという印を付ける、請求項６に記載の装置。
【請求項１７】
前記少なくとも１枚のメモリと前記コンピュータコードは、さらに、前記少なくとも１つのプロセッサを用いて、前記装置に、１つ以上の前記第１方向の配列の埋まっていない部分をスタッフデータで埋めることを決定させる、ように構成される、請求項６に記載の装置。
【請求項１８】
失われたセグメントに対応する穴に、信頼性が低いという印を付ける、請求項６に記載の装置。
【請求項１９】
パケットのためのヘッダが、対応する最初に占められるアドレス可能な記憶位置のアドレスの指標を含んでいる、請求項６に記載の装置。
【請求項２０】
スタッフデータだけを含む１つ以上の前記第１方向の配列を、非スタッフデータを含む１つ以上の前記第１方向の配列の隣に配置する、請求項６に記載の装置。
【請求項２１】
コンピュータ実行可能なプログラムコードを備えるコンピュータ・プログラムであって、該プログラムコードが、
第１方向の配列と、該第１方向と直交する方向である第２方向の配列と、を有する単一の二次元データ構造に、複数のパケット全体を収納することを決定させるコードであって、収納が、前記第１方向の配列に沿って、行われる、コードと、
前記第２方向の配列のそれぞれに、対応する計算された１つ以上の特性値を付加することを決定させるコードと、
ディジタルビデオ放送網を通して、前記特性値の一部を含む前記第１方向の配列の１つ以上の内容を送信することを決定させるコードと、
前記複数のパケット全体のそれぞれに、前記単一の二次元データ構造における当該パケット全体の位置を搬送するデータ構造での位置指標を付加することを決定させるコードと、
ディジタルビデオ放送網を通して、単一バーストにおいて前記複数のパケット全体を送信することを決定させるコードと、を含む、
コンピュータ・プログラム。
【請求項２２】
コンピュータ実行可能なプログラムコードを備えるコンピュータ・プログラムであって、該プログラムコードが、
ディジタルビデオ放送網を通して、単一バーストにおいて前記複数のパケット全体の受信をさせるコードであって、前記複数のパケット全体のそれぞれについて、単一の二次元データ構造における該パケット全体の位置を搬送するデータ構造での位置指標が受信される、コードと、
前記単一の二次元データ構造に、前記受信した複数のパケット全体を収納することを決定させるコードであって、前記単一の二次元データ構造が、第１方向の配列と、該第１方向と直交する方向である第２方向の配列とを有し、収納が、前記第１方向の配列に沿って、行われる、コードと、
１つ以上の前記第２方向の配列のそれぞれに、対応する１つ以上の受信した特性値を適用させることを決定するコードであって、該適用により１つ以上の前記複数のパケット全体を訂正する、コードと、
前記単一の二次元データ構造から、複数の訂正されたパケット全体を取り出すことを決定させるコードであって、収納が、前記データ構造での位置指標に従っている、コードと、を含む、
コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データを送受信するためのシステムと方法に関する。
【背景技術】
【０００２】
移動携帯端末で利用されているサービスに必要な帯域幅は比較的狭い。MPEG-4などの最新の圧縮技術を利用してビデオを流すための推定最大ビット・レートは1秒に数百キロビットのオーダーであり、実際的な1つの限界は、3G環境からの384kbpsである。他のタイプのサービス（例えばファイルのダウンロード）は、はるかに広い帯域幅を必要とする可能性があるものもある。したがって柔軟性が必要とされる。
【０００３】
DVB送信システムは、通常は10Mbps以上の帯域幅を提供する。これは、時分割多重化（TDM）に基づくスキームを導入することにより、DVB受信機の平均電力消費を顕著に減らせる可能性があることを示している。導入されるスキームは、時間スライシングと呼ばれる。
【０００４】
時間スライシングの考え方は、データが静的帯域幅を用いて送信される場合に必要な帯域幅と比べてはるかに広い帯域幅を利用し、データをバーストとして送るというものである。1つのバースト内には、次のバーストが始まるまでの時間（Δt）が示される。バースト間には、そのサービスのデータは送信されないため、そのサービスに割り当てられた帯域幅以外の帯域幅を他のサービスが利用することができる。そのため受信機は一部の時間だけアクティブな状態を維持し、要求したサービスのバーストを受信することが可能になる。移動携帯端末がより低い一定のビット・レートを要求する場合には、受信したバーストをバッファすることによってそれが可能になろう。
【０００５】
別の利点として、時間スライシングは、オフの時間に受信機を近隣セルのモニターに使用する可能性もサポートする。受信を、転送されているあるストリームの受信から別のストリームの受信へとオフの期間に切り換えることにより、サービスの受信が中断されないように見える。通常のDVB-Tシステムでは、スムーズなハンドオーバのためには、1つのターミナル内に2つのフロント-エンドが必要とされよう。
【０００６】
データは、例えばヨーロッパ規格EN 301 192“ディジタルビデオ・ブロードキャスティング（DVB）；データ・ブロードキャスティングのためのDVB仕様”の第7節に従うマルチプロトコル・カプセル化装置を利用してフォーマット化される。カプセル化されたデータは、マルチプロトコル・カプセル化装置によりブロードキャスティングのためのディジタル・ブロードキャスティング送信機へ送られ、時間スライシング信号としてディジタルブロードキャスティング受信機に送られる。時間スライシング信号は、連続した一連の送信バーストを含んでいる。
【０００７】
DVBに関するさらに別の情報は、例えば以下のETSI（欧州電気通信標準化協会）の文献に見いだすことができることに注意されたい。なおそのそれぞれが、参考としてこの明細書に組み込まれているものとする。
ETSI TR 101202ディジタルビデオ・ブロードキャスティング（DVB）“データブロードキャスティングの実施ガイドライン”
ETSI EN 300468ディジタルビデオ・ブロードキャスティング（DVB）“DVBシステムにおけるサービス情報（SI）の仕様”
ETSI EN 300 744“ディジタルビデオ・ブロードキャスティング（DVB）のフレーミング構造、チャネル符号化、ディジタル地上テレビのための変調”
【０００８】
近年、さまざまな目的で有線や無線のネットワークがますます多く利用されるようになっている。例えばメディア、アプリケーション、個人的な通信を送受信するのに、ネットワークがますます多く利用されている。例えばこのように利用が増大していることを考慮すると、このようなネットワークに適用できる技術は興味深い。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】ヨーロッパ規格EN 301 192“ディジタルビデオ・ブロードキャスティング（DVB）；データ・ブロードキャスティングのためのDVB仕様”
【非特許文献２】ETSI TR 101202ディジタルビデオ・ブロードキャスティング（DVB）“データブロードキャスティングの実施ガイドライン”
【非特許文献３】ETSI EN 300468ディジタルビデオ・ブロードキャスティング（DVB）“DVBシステムにおけるサービス情報（SI）の仕様”
【非特許文献４】ETSI EN 300 744“ディジタルビデオ・ブロードキャスティング（DVB）のフレーミング構造、チャネル符号化、ディジタル地上テレビのための変調”
【発明の概要】
【課題を解決するための手段】
【００１０】
本発明のさまざまな実施態様によって、データの送信および／または受信に二次元アレイ等を使用できるシステムと方法が提供される。本発明のさらに別のさまざまな実施態様によると、送信されるデータに関する特性値を計算することができ、その特性値をそのデータとともに送信することができる。このような特性値は、データの受信に利用できる。特性値としては、例えば、順方向誤り訂正（FEC）データ、または他のチャネル符号化データなどが挙げられる。
【００１１】
本発明の実施態様は、多くのタイプのネットワーク（例えばディジタルビデオ・ブロードキャスティング（DVB）ネットワーク）で利用することができる。
【００１２】
本発明のさまざまな実施態様において、元のデータと特性値（例えばFECデータ、他のチャネル符号化データ（例えばリード-ソロモン符号化データ））がインターリーブされる。バースト・データを含み得るパケット等に対して垂直に符号化を行うため、このインターリーブは、上位層に限定されない。従来のDNBシステムでは、インターリーブは下位層においてなされる。
【００１３】
さらに、送信機と受信機には利用できるメモリがすでにあるため、本発明の実施態様において時間スライシング・システムを容易に実現することができる。追加のメモリは不要であり、余分な遅延が導入されることもない。時間スライシング受信機では、受信するバーストは、データに何らかの操作を行なう前に記憶される。
【００１４】
本発明のさまざまな実施態様によると、送信されるデータに対応するパケット等は、インターリーブなしの元のままの形で通過するのに対し、対応する特性値（例えばFECデータ）はインターリーブ状態にされる可能性があることに注意されたい。
【００１５】
本発明のさまざまな実施態様は、“下位互換性”がある。なぜなら、特性値が別々のバーストで送られるかどうかに関係なく、特性値（例えばFECデータ）を捨てることができ、元のデータはインターリーブ状態にされないからである。
【００１６】
本発明の実施態様は、インターリーブの位置決めとインターリーブ解除のためのさまざまな条件に準拠していることにも注意されたい。
【図面の簡単な説明】
【００１７】
【図１】本発明の実施態様によるデータ送信に関係するステップの具体例を示した説明図である。
【図２】本発明の実施態様によるデータ受信に関係するステップの具体例を示した説明図である。
【図３】本発明の実施態様による第1のローディング法の説明図である。
【図４】本発明の実施態様による第2のローディング法の説明図である。
【図５】本発明の実施態様で利用できる汎用コンピュータの一例を示す図である。
【図６】本発明の実施態様で利用できるノードの一例に関する機能ブロック図である。
【発明を実施するための形態】
【００１８】
（一般的な動作）
本発明のさまざまな実施態様によると、データを送受信するためのシステムと方法が提供される。本発明のさまざまな実施態様によると、記憶位置のアドレス指定が可能な二次元アレイ等を作ること、および／または送信ノードによってそのような二次元アレイ等にアクセスすることができる。
【００１９】
図1を参照すると、このような実施態様では、ノードによって送信されるデータに対応するパケット等は、おそらく特定のあるバーストにおいて、二次元アレイ等に列方向にロードされることがわかる（ステップ101）。このようなパケット等は、例えばインターネット・プロトコル（IP）パケットとしてよい。したがってロードされたパケット等の内容は、1つ以上の列内の、1つ以上のアドレス可能な記憶位置を占めることができる。
【００２０】
次に、二次元アレイ等のそれぞれの行に沿って1つ以上の特性値を計算することができる（ステップ103）。このような特性値は、例えば順方向誤り訂正（FEC）データを表わすことができる。特別な一例として、このようなFECデータは、リード-ソロモン誤り訂正データにすることが可能である。次に、ある1つの行に対応する計算した特性値を記憶しておき、その行に付加することができる。したがってその特性値は、その行の1つ以上のアドレス可能な記憶位置を占めることができる。
【００２１】
さまざまな実施態様において、特性値を計算する方法を動的に変えてもよいことに注意されたい。特別な一例として、特性値がFECデータ（例えばリード-ソロモン・データ）に対応する場合、付加するパリティ・データの量を動的に変えてもよい。例えばより多くの送信エラーが生じることが予想されるネットワーク条件となる場合には、より多くのパリティ・データを付加できよう。
【００２２】
次のステップとして、二次元アレイ等の中身を列方向に取り出すことができる（ステップ105）。このように取り出すとき、ロードした元のパケット等を取り出すことができる。さまざまな実施態様では、ロードした元のそれぞれのパケットをノードによって変更し、それがアレイ等の内部のどこに記憶されているかの指標を含むようにすることができる。指標は、例えば、そのパケット等が占めるアドレス可能な最初の記憶位置に対応する行および／または列のアドレスにすることができる。
【００２３】
このような指標は、例えば、そのパケット等に対応するヘッダに記憶させることができる。1つのパケット等に対応する指標は、例えば、ノードがそのパケット等をアレイ等の中に収納するとすぐに、ノードによってそのパケット等に付加することができる。別の一例として、ノードは、アレイ等からパケットを取り出す直前に指標を収納することができる。
【００２４】
列方向に取り出すときにはさらに、計算した特性値に対応するデータを取り出し、1つ以上のパケット等の中に収納することができる（ステップ107）。その1つ以上のパケット等は、例えば、IPパケットにすることが可能である。このようなパケットは、例えば、アレイ等の特定の列に記憶されている計算した特性値に対応するすべてのデータを含むことができる。したがってこのようなパケットは、2つ以上の特性値に対応するデータを含むことができる。例えばこのようなパケットは、所定の1つ以上の特性値それぞれに対応するデータの一部を含むことができる。特定の特性値に対応するデータは、このような2つ以上のパケットに分散させ得ることに注意されたい。さまざまな実施態様では、このようなパケットに、アレイ等のどこにそのパケットが保持しているデータが記憶されているかの指標を付加することができる。指標は、例えば、保持されているデータが占めているアドレス可能な最初の記憶位置に対応する列アドレスを表わすことができる。
【００２５】
次に、ノードは、特性値またはその一部を保持している作り出したパケット等と、ロードされた元のパケット等あるいは変更されているパケット等とを1つ以上の受信ノードに送信するステップを実行できる。さまざまな実施態様では、特性値を保持している作り出したパケット等は、ロードされたパケット等あるいは変更されているパケット等とは別のバーストで送れることに注意されたい。本発明のさまざまな実施態様では、特性値またはその一部は、最初にロードされた元のパケット等あるいは変更されているパケット等に付加できる。
【００２６】
本発明のいくつかの実施態様では、特性値を有するデータが含まれた列の1つ以上を送信しないこととしてよい。特性値がリード-ソロモン符号のパリティ・データである場合には、データ列を省略することにより、例えばRS符号のパンクチャに対応してもよい。送信されない列の数を、例えば、フレーム間で動的に変えてもよい。本発明のさまざまな実施態様では、省略された列の数を通知することができる。本発明のさまざまな実施態様では、省略された第1の列、または省略された第1の列のアドレスを通知できることにも注意されたい。省略された列は、例えば、パリティ・データの最下位バイトを保持する列にすることができる。
【００２７】
図2を参照すると、上記説明したパケット等は、次に受信ノードに到着する場合が示される（ステップ205）。受信ノードは、送信ノードによって提供される特性値を利用してもしなくてもよいことに注意されたい。例えば受信ノードは、特性値を利用することができないこともある。別の一例として、ある受信ノードに対応するユーザーは、おそらくグラフィカル・ユーザー・インターフェイス（GUI）等のインターフェイスを通じ、そのノードにおいて特性値を利用すべきではないことを指示できる。さらに別の一例として、受信ノードは、後で詳しく説明するように、特性値を利用すべきかどうかに関する判断を行なうことができる。
【００２８】
さまざまな実施態様では、例えば、特性値を利用できない受信者端末、および／または特性値を利用しないことに決めた受信者端末、および／または特性値を利用しないことを通知された受信者端末は、送信ノードから送られるパケット等をまったく受信しないか、それを受信し、自分の選択に従ってその一部または全部を記憶するようにできることに注意されたい。次に、ノードは、ロードされた元のあるいは変更されている受信したパケット等を従来と同じように利用する。ノードは、特性値に対応する受信したパケットを記憶装置から削除することができる。このようなさまざまな実施態様では、特性値に対応する受信したパケットをまったく記憶しなくてもよいことに注意されたい。そのようなパケットは、例えばPID（プログラム識別子）などの識別子を通じて認識することができる。
【００２９】
あるいはこのような受信ノードは、特性値を保持しているパケット等を記憶せずに飛ばすこともできる。さまざまな実施態様では、受信ノードは、多くの方法でこのようなパケット等を認識することができる。このようなパケットは、例えばそのパケットのヘッダによって認識することができる。さらに詳しく説明すると、このようなパケットのヘッダは、例えば、ロードされた元のパケット等あるいは変更されているパケット等のヘッダによって指定されるのとは異なるソースIPアドレス等を指定することができる。
【００３０】
受信ノードが、特性値を利用すると決定した場合、および／または特性値を利用できるという指示を受信した場合には、その受信ノードは、おそらく受信したパケット等を自分が選択した方法で記憶した後、特性値を使用するかどうかを決める適切な動作を実行することができる。このような決定については、後で詳しく説明する。受信ノードが、特性値を使用しないと決定した場合、および／または特性値は利用されないという指示を受信した場合には、その受信ノードは、おそらく受信したパケット等を自分が選択した方法で記憶した後、ロードされた元のあるいは変更されている受信したパケット等を、従来と同じように利用する。
【００３１】
受信ノードが、特性値を利用すると決定した場合、および／または特性値が利用されるという指示を受信した場合には、その受信ノードは、送信ノードが作り出した、および／またはアクセスしたアレイに対応する二次元アレイ等を作り出すこと、および／またはそのような二次元アレイ等にアクセスすることができる。受信ノードが作り出した、および／またはアクセスしたアレイ等は、例えば、送信ノードが作り出した、および／またはアクセスしたアレイ等と共通する1つ以上の性質を持つことができる。例えば受信ノードが作り出した、および／またはアクセスしたアレイ等は、送信ノードが作り出した、および／またはアクセスしたアレイ等と同じサイズにすること、および／または同じ方法でアクセスすることができる。
【００３２】
さまざまな実施態様では、送信ノードは、例えば、受信ノードに、その受信ノードが作り出した、および／またはアクセスしたアレイ等に関係する性質の指標を送ることができる。そのような性質としては、例えば、アレイ等の列のサイズ、行のサイズ、アドレス情報などが挙げられる。別の一例として、列挙したこのような性質を、指定したすべての送信ノードと受信ノードが観察できるようにすることができる。このような性質は、例えばシステムの管理者等が設定することができる。
【００３３】
受信ノードは、アレイ等を作り出す、および／またはアレイ等にアクセスするのに必要なあらゆるステップを実行した後、特性値を保持している受信したパケット等や、ロードされた元のあるいは変更されている受信したパケット等を、自分のアレイ等にロードすることができる（ステップ207）。ロード作業は、行アドレスおよび／または列アドレスに関して受信した上記の任意のタイプの指標に基づいて行なうことができる。したがってこのようなロード作業を通じ、受信ノードのアレイ等を送信ノードのアレイ等と一致させることができ、その後アレイからデータを取り出す。さまざまな実施態様では、受信ノードが自分のアレイ等にロードして送信ノードのアレイ等と一致させた後にそのアレイ等からデータを取り出すために、そのようなアドレス指標を受信することが必要ないことに注意されたい。例えばマルチプロトコル・カプセル化（MPE）を送信ノードまたは受信ノードで利用する場合には、受信ノードは、自分のアレイ等にこのようにロードするとき、転送ストリーム（TS）連続カウンタの値を利用することができる。
【００３４】
本発明のさまざまな実施態様では、受信機は、受信したデータ・パケットまたはデータ・セクションに対してCRC-32チェックを行なった後、受信したデータ・パケットをアレイに記憶させる。受信したセクションが正しいことをCRC-32チェックの結果が示しているときには、データ・パケットの位置に“信頼性が高い”という印を付け、アレイ内のセクション・ヘッダにおいて指定されているアドレスから始まる位置に入れることができる。CRC-32チェックは、元のデータ・パケット等に対して、および／または特性値のデータまたはその一部（例えばRS符号）を保持しているセクションに対して行なうことができる。本発明のさまざまな実施態様では、CRC-32チェックに合格しないセクションは、空のままにしておくこと、あるいはフレーム中の“穴（ホール：hole）”であることを示す所定のデータで満たすことができる。“穴”は、失われたセクションに対応するとみなすことができ、RSの復号において“信頼性が低い”という印を付けることができる。このような実施態様では、すべてのバイト位置は、“信頼性が高い”か“信頼性が低い”のどちらかの印を適切に付けることができ、RS復号器は、誤っているバイトまたは信頼性が低いバイトを訂正することができる。特別な一例として、パリティ・バイトが64あるRS符号の場合には、RS復号器は、255バイトのコードワード1つにつき64バイトまで訂正することができる。
【００３５】
1行の中に信頼性が低いバイト位置が64を超える場合には、さまざまな実施態様では、RSデコーダは、訂正をまったくせずに、例えば誤り訂正なしでバイト・エラーを出力することとしてよい。したがって受信機は、RSの復号後、フレーム内に残っているあらゆるバイト・エラーの位置を完全に知ることができる。受信したデータ・パケットまたはセクション・パケットの一部しか訂正されていない場合には、受信機はそれを検出することができ、場合によってはこのデータグラムを廃棄する。
【００３６】
受信ノードは、データを取り出す前に自分のアレイ等を送信ノードのアレイ等と効率的に一致させて、上記の特性値を再構成する（ステップ209）。次のステップとして、受信ノードは、1つ以上の特性値それぞれをアレイ等の中の対応する行に適用することができる（ステップ211）。このような適用操作により、例えば、ロードされた元のあるいは変更されている受信したパケット等に対してFECを実施することができる。
【００３７】
いくつかの実施態様では、すべての特性値が適用されるわけではないことに注意されたい。例えば1行に2つ以上の特性値が存在している場合、そのすべてよりも少ない数の特性値をその行に適用してよい。別の一例として、対応する特性値を、1つ以上の所定の行のそれぞれに適用してよく、一方で対応しない特性値を、1つ以上の他の行に適用してよい。
【００３８】
次のステップとして、受信ノードは、自分のアレイ等から列方向の取り出しを行なって、ロードされた元のパケット等を取り出してもよい（ステップ213）。このパケット等は1つ以上の特性値に従って変更され、訂正などの作用を受けていることもある。次にこのノードは、取り出したそのパケット等を従来と同じようにして利用することができる。
【００３９】
上の説明では、受信ノードは、ロードされた元のパケット等あるいは変更されているパケット等がアレイ等に記憶されるときに作用を与える（例えば訂正する）としたが、さまざまな実施態様では、そのような操作は、例えばアレイ等から取り出した後のそのようなパケットに対して実施できることに注意されたい。さらに、さまざまな実施態様では、受信機で特性値（例えばリード-ソロモン・データ）を繰り返して使用できることに注意されたい。例えばターボ復号を利用することができる。そのようなターボ復号の性能は、例えば、特性値および／またはその値を適用して得られるデータを行方向と列方向で繰り返し利用することを伴ってもよい。この繰り返しは、提案されているFEC復号と、ソフト・ビット情報を提供することのできるより下位層のFEC復号との間でも実施することができる。
【００４０】
さらに、この明細書に記載した実施態様ではパケット等の利用について説明しているが、本発明の実施態様は、例えばビット・ストリーム等にも同様に適用される。さらに、この明細書に記載した実施態様では行に沿って特性値の計算を行うことについて説明しているが、他の方法も利用できることに注意されたい。例えばさまざまな実施態様では、特性値をジグザグ方式で計算することができる。
【００４１】
さらに、この明細書に記載した実施態様では、アレイ等に列方向にローディングすることについて説明しているが、本発明のさまざまな実施態様は別の形態で実現することができる。例えばこのようなローディングは行方向に行なうことも可能である。このような実施態様は、この明細書に記載した実施態様と機能は同様だが、本明細書における列方向の操作が行方向に実施され、本明細書における行方向の操作が列方向に実施される。
【００４２】
特性値と特性値のセット（集合）は、アレイ内に行方向または列方向に配置された1つ以上のデータ・エレメントを含むデータ・セグメントを有するアレイから多数のデータ・エレメントを選択し、その選択したエレメントに対して計算を行ない、得られた特性値を、同じアレイ内または別のアレイ内で特性値のために確保した所定の1つ以上の場所に収納することによって計算できる。データ・エレメントの選択は、1つの行または列にあるエレメントのすべてまたはいくつかを選択する操作を含んでいる。他の選択法として、例えばアレイ内の1本以上の対角線からエレメントを選択する（ジグザグ）方法や、所定のパターンに従ってデータ・エレメントを選択する方法がある。
【００４３】
さらに、さまざまな実施態様では、データ・エレメントは、アレイからランダムに選択する。その場合、エレメントの数は固定されており、そのランダムな選択パターンが送信機及び受信機に既知である。本発明のいくつかの実施態様では、アレイ内の全データ・エレメントが必ずしも計算に用いられるわけではなく、本発明の別の実施態様では、エレメントのいくつかを2回以上使用して1つ以上の特性値を計算することができる。
【００４４】
本発明の特別な一実施態様についてこれから説明する。
【００４５】
この実施態様によれば、送信されるデータは、変更されたDVBエンカプシュレータ（カプセル化手段）が取り扱う。エンカプシュレータは、イーサネット（登録商標）のフレームから持ち越されたIPパケットを受信してTSパケットを出力する能力を有する。
【００４６】
この実施態様の第1ステップとして、変更されたエンカプシュレータは、イーサネット（登録商標）のフレームを順番に受信する。エンカプシュレータは、例えばイーサネット（登録商標）のMACアドレスおよび／またはIPパケット・アドレスに基づき、フレームを並べること、および／または抜かすことができる。基準は、例えば送信されるデータの性質に基づいてあらかじめ決めることができる。このステップにおいて、イーサネット（登録商標）のフレーム構造が除去される。
【００４７】
次のステップとして、選択したIPパケットをマルチプロトコル・カプセル化（MPE）データグラム（例えばDSM-CC（ディジタル記憶媒体のコマンドと制御）セグメント）に入れる。
【００４８】
この実施態様の次のステップとして、IPデータグラムを符号テーブルまたはアレイに列方向に記憶させる。メモリ内のそれぞれのIPデータグラムのアドレスは、ヘッダに記憶される。例えばメモリ内のあるIPデータグラムのアドレスをそのヘッダのMAC（媒体アクセス制御）アドレス・バイトに記憶させることができる。時間スライス実時間パラメータ（time slice real-time parameter）をこの位置に挿入することができる。
【００４９】
次に、所望の量のIPデータグラムがメモリに記憶された後、FECの計算を行方向に行なう。上記したようにIPデータグラムが列方向に記憶されるのではなく行方向に記憶された場合、FECは列方向に計算されることに注意されたい。いずれの場合でも、IPデータグラムの記憶とFECの計算は、互いに90°ずれていると考えることができる。IPデータグラムは、FECの計算と並行して送信もできることにも注意されたい。この場合には、IPデータグラムのコピーをメモリに残し、FECの計算に使用することができる。
【００５０】
次に、FECの計算がすべて終了すると、計算されたFECバイトをMPEセグメントに収納する。この操作の後、すべてのIPデータグラムがTSパケット・ペイロードに収納される。この実施態様では、IPデータグラムが、同じPID値を持つTSパケットに送られる。別の方法として、FECデータを含むMPEセクションは、IPパケット・データを運ぶTSパケットとは異なるPID値を持つTSパケットとともに送ることができる。
【００５１】
受信ノードにおける操作を、そのノードがFECを計算する場合について、本発明の特別な実施例に従ってこれから説明する。
【００５２】
第1のステップとして、受信ノードは、所望のTSパケット（例えばPID値が“A”であるパケット）をフィルタリングした後に、TSパケット・ヘッダを除去し、TSパケット・ペイロード・データからIPデータグラムを形成する。
【００５３】
次に、受信ノードは、受信したIPデータグラムを復号テーブルまたはアレイに記憶させる。その際、受信ノードは、IPデータグラムのヘッダからのアドレス値を利用する。
【００５４】
次に、受信ノードは、受信データのFEC復号を行なう。この操作の後、IPパケット・データを含む訂正されたIPデータグラムを、好ましくは同じインターリービング・メモリに記憶させる。次のステップとして、IPデータグラムを順番に処理し、IPデータグラムのヘッダとトレーラを除去する。得られたIPパケットは、従来のように使用される。
【００５５】
受信ノードにおける操作を、そのノードがFECの復号を行なわない場合について、本発明の特別な実施例に従ってこれから説明する。
【００５６】
第1のステップとして、受信ノードは、所望のTSパケット（例えばPID値が“A”であるパケット）をフィルタリングした後に、TSパケット・ヘッダを除去し、TSパケット・ペイロード・データからIPデータグラムを形成する。
【００５７】
次に、受信ノードは、IPデータグラムを受信機のメモリに記憶させる。メモリは、復号テーブルまたはアレイである必要はなく、受信ノードが代わりに、自分が選択した方法でデータを記憶できることに注意されたい。
【００５８】
次に、IPデータグラムを順番に処理し、IPデータグラムのヘッダとトレーラを除去する。得られたIPパケットは、従来のように使用される。
【００５９】
（二次元アレイ等へのローディング、アドレス指定、サイジング）
上記のタイプの二次元アレイ等に対しては、本発明のさまざまな実施態様によると、多数の方法でロードすることができる。例えばローディングが列方向になされるさまざまな実施態様では、列1つにつき1つのパケット等（例えばIPパケット）だけをロードすることができる。
【００６０】
このような実施態様では、アレイの行および／または列のサイズは、1つの列が最大サイズのパケット等を保持できるように選択することができる。1つの列にロードされたパケット等が最大サイズに満たない場合には、その列の残部を“スタッフデータ（stuff data）”で埋める。特別な一例として、残部をゼロで埋めることができる。
【００６１】
図3には、上述のローディング法が示してある。図3では、パケット等301は最大サイズであるため、このパケット等が存在している列303にスタッフデータは付加されていない。他方でパケット等305は最大サイズに満たないため、スタッフデータ307がその列に付加されて、パケット等305とスタッフデータ307がその列全体を占めている。1つ以上の列全体がスタッフデータだけで占められていることもありうる。そのような列は、データを含む列の前、間、後に配置することや、これらの組み合わせにすることができる。
【００６２】
ローディングが列方向になされるさまざまな実施態様の別の一例として、パケット等が、そのパケット等がロードされた列を完全には埋めない場合には、その列に、アレイ等にロードされる次のパケット等が続けてロードされるようにできる。さらに、ある列にロードされているパケットがその列を完全には収まりきらない場合には、収まりきらない部分を1つ以上の別の列に収納することができる。
【００６３】
例えば特定のパケット等がある列にピタリと収まらなかった場合には、このような機能は、その列が、その列のアドレス可能な最後のエレメント（例えばその列のエレメントで、最上位の行方向アドレスを有するエレメント）までそのパケット等の内容で埋まるようにした後、そのパケット等の残部を、次の列に、その列のアドレス可能な最初のエレメント（例えばその列のエレメントで、最下位の行方向アドレスを有するエレメント）から始まるように収納することによって実現できる。
【００６４】
図4には、上記したローディング法が示してある。図4では、パケット等401は、そのパケット等401がロードされる列403を完全には埋めていないため、列403の残部はパケット等405の一部で埋められる。しかしパケット等405は、列403のうちでパケット等401によって埋められずに残った部分にはピタリと収まらないため、そのパケット等405の残部を、列407に、この実施例では第1のエレメント（例えば列のエレメントで、最下位の行方向アドレスを有するエレメント）から始まるように配置する。
【００６５】
上記したタイプのさまざまな実施態様では、スタッフデータはパケット等の間に収納されることに注意されたい。このような機能は、例えばパケット等の長さを丸め、1つのパケット等とそれに付随するスタッフデータの長さが、例えばワード長（バイト）の複数倍の長さになるようにすることを目的として実現することができる。このような機能を利用した実施態様では、ローディングが列方向にある実施態様で行方向のアドレス指定を1バイト全体粒度で実現できるため、対応するアレイ等でのアドレス方式を簡単化することができる。上記のタイプの実施態様では、データで埋められた列の間、前、後のいずれかにスタッフデータの列を用いることや、これらの方法の組み合わせにすることもできる。
【００６６】
列1つにつき1つのパケット等だけが収納されるようにローディングする実施態様では、特定のパケット等を対応するアレイのどこに収納するかに関する上記のタイプの指標は、ローディングが列方向にある場合には、アレイ内のどこにそのパケット等を記憶させたかに対応する列アドレスとだけ関係づける必要があることに注意されたい。
【００６７】
例えば受信ノードでは、指示された列のアドレス可能な第1のエレメント（例えばその列のエレメントで、最下位の行方向アドレスを有するエレメント）に受信されたパケット等が収納され、その列の埋められていない部分はスタッフデータで埋められるようにできることが理解されよう。他方、列1つにつき2つ以上のパケット等が収納されるローディングを行なう実施態様では、上記のタイプの指標は、行と列の両方のアドレスを指定する必要があることに注意されたい。
【００６８】
ここでアドレス指定に移ると、本発明のさまざまな実施態様では、アドレス指定方式を上記のタイプのアレイ等に関して決定できることに注意されたい。特定のサイズのアレイ等に関して考えると、アドレス指定方式の選択は、そのアレイ等のアドレス可能なエレメントの数を決定する効果を有するとみなすことができる。
【００６９】
特定のサイズのアレイ等に関して考えると、行方向のアドレス方式の選択は、上記のタイプのアレイ等における行の数を決定する効果を有するとみなせるのに対し、列方向のアドレス方式の選択は、上記のタイプのアレイ等における列の数を決定する効果を有するとみなせることにも注意されたい。さらに、行方向と列方向のアドレス方式の選択は、特定のサイズのアレイ等に関して考えると、そのアレイ等のアドレス可能なエレメントのサイズの選択であると考えられることにも注意されたい。
【００７０】
特別な一例として、上記のタイプのアレイ等は、行と列の両方のアドレス指定が1バイトの粒度でなされるように実現することができる。別の特別な一例として、上記のタイプのアレイ等にデータが列方向にロードされる場合には、列方向のアドレス指定を選択し、利用可能なアドレス空間を最大限に利用するようにすることができる。例えば32ビットのアドレス指定が利用できる場合、列方向のアドレス指定を選択し、可能な最大数の列が利用できるようにする。そのとき、おそらくアレイ等に記憶されるデータ（例えばIPパケット）の最大サイズを考慮して決定を行なう。
【００７１】
ローディングが列方向になされるさらに別の特別な一例として、行方向のアドレス指定を実現し、そのときの行の数がチャネル・エラーの挙動に関して最適になるようにすることができる。ローディングが列方向になされるさらに別の特別な一例として、行方向のアドレス指定を実現し、そのときの行の数が、特定の特性値（例えばFEC）を決定する方法の特性と一致するようにする。
【００７２】
ここでサイズに移ると、上記のタイプのアレイ等のサイズの選択は、そのアレイ等の行の幅と列の高さの選択としてアプローチできることに注意されたい。サイズの選択は、本発明のさまざまな実施態様によれば、多数の方法で実現することができる。例えばローディングが列方向である場合には、列の高さは、アレイ等にロードされるタイプのパケット等の最大サイズと一致するように選択することができる。あるいは他のいくつかの値を選択することもできる。このような選択は、例えばシステムの管理者またはそれ以外の個人が行なうことができる。
【００７３】
列の高さをこのように選択したアレイ等の行の幅は、多数の方法で選択することができる。例えば行の幅は、1つのバースト内で送ることのできるパケット等の最大数を決めた後、対応する1つまたは複数の特性値に必要なアレイ内の空き空間を決定することによって選択することができる。このような実施態様では、アレイ等の特性は、あらかじめ送信ノードと受信ノードが知ることができる。アレイの幅は、特性値を計算するのに選択した方法に合うように選択するとよい。選択した方法は、データのための列の数と、特性値のための列の数の両方を決めることができる。一例として、255個のリード-ソロモン符号を選択すると、データのための191個の列と、特性値のための64個の列になる。
【００７４】
ローディングが列方向である別の一例として、送信ノードは、送られるバーストごとにアレイ等のサイズを変えることができる。特別な一例として、送信ノードは、対応するアレイ等が、特定の1つのバースト内で送られるすべてのパケット等と、対応するあらゆる特性データとを保持できるように列の高さと行の幅を選択することができる。別の一例として、送信ノードは、同様に、但し指定されたおよび／または固定された列の高さまたは行の幅に従って動作することができる。例えば列の高さが指定されているとき、その列の高さは、アレイ等にロードされるタイプのパケット等の最大サイズに一致していてもよいし、他の何らかの値でもよい。列の高さおよび／または行の幅が固定されていない実施態様では、送信ノードは、すでに述べたように、受信ノードにサイズの指標を1つ以上送ることができる。アレイ等のサイズが固定されているさまざまな実施態様では、アレイ等のすべてが利用されないのであれば、送信ノードは、アレイ等のどの部分を利用するかの指示を受信ノードに送ることができることに注意されたい。このような指示は、例えばアドレスにすることができる。
【００７５】
本発明のさまざまな実施態様では、1つのバースト内で送られるデータは、例えば255個の列と可変数の行を有するアレイの構成になったフレームにすることができる。行の数は、フレームのヘッダ内の記述子によって通知することができる。この実施例では、最も左側にある191個の列をOSI層の第3データグラム（例えばIPデータグラム）のために確保し、残る64個の列をパリティ情報のために確保することができる。上記の191個の列は、“アプリケーション・データ・テーブル”と呼ぶことができ、上記の64個の列は、RSデータ・テーブルと呼ぶことができる。アレイ内のそれぞれの位置は、例えば1バイトの情報を含むことができる。このようなそれぞれのバイト位置は、列番号と行番号によってアドレス指定することができる。最も左側にある191個の列のうちのいくつかは、データグラムがその列を完全に埋めないのであれば、アレイのこの部分を完全に埋めるためにパッド（pad）またはスタッフ（例えばゼロのバイト）で埋めてよい。パッド・バイトの数は、おそらく、フレームのヘッダによって通知することができる。さまざまな実施態様では、受信機がこの通知情報を利用し、受信機内のアレイを埋めることができる。
【００７６】
この実施例に関してはさらに、最も左側にある191個の列がすべて埋まっている場合には、アレイのそれぞれの行について、データと（存在する可能性のある）パッドの191バイトから、64個のパリティ・バイトを計算できることに注意されたい。得られるパリティ・バイトは、最も右側にある64個の列に収納することができる。この実施例の計算に用いる符号は、リード-ソロモンRS（255、191、64）である。次に、アレイのそれぞれの行は、1つのRSコードワードを含んでいる。フレームを送信する場合、RSデータ・テーブル内の列の一部または全部を廃棄して送信しなくともよい。これは、パンクチャに対応する。本発明のさまざまな実施態様では、パンクチャされるRS列の数を明示的な形で通知しなくともよく、その数を、フレームごとに動的に変えてもよい。本発明のさまざまな実施態様ではさらに、パンクチャされるRS列の数は、通知される、フレーム内の最後のセクションの番号に基づいて計算できることに注意されたい。本発明のさまざまな実施態様では、受信機がこの通知情報を利用してRSテーブルを完成させることができる。パンクチャは、RSデータによって導入されるオーバーヘッドを減らし、したがって帯域幅を狭くする働きを持つことができる。パンクの可能な欠点は、符号化速度がより遅いことであろう。
【００７７】
アプリケーション・データ・テーブルおよび／またはRSデータ・テーブルのそれぞれのセクションは、さまざまな実施態様では、バイト位置のアドレスを含む実時間パラメータを含むことができる。アプリケーション・データ・テーブルとRSデータ・テーブルのセクションのための実時間パラメータは、例えば対応するセグメントのMACアドレス・フィールドの中に含めることができる。本発明のさまざまな実施態様では、アドレス・フィールドが、セクション内に含まれるペイロード・データの最初のバイトのためのバイト位置を指定することができる。さまざまな実施態様では、セクションは、例えばアドレスの数値に従って昇順で提供することができる。バイト位置は、アプリケーション・データ・テーブルおよび／またはRSデータ・テーブル内のゼロを基準とする線形アドレス（zero-based linear address）にすることができ、第1列の第1行から始まってその列の末尾に向かって増大していく。その列の終わりに来ると、次のバイト位置は、次の列の第1行にすることができる。
【００７８】
本発明のさまざまな実施態様では、フレームのデータを含む最初のセクションは、フレームがアプリケーション・データだけを含んでいるか、アプリケーション・データとRSデータを含んでいる場合には、“0”のアドレスにアプリケーション・データ・データグラムを含むセクションにすることができる。所定のフレームのアプリケーション・データ・データグラムを含むすべてのセクションは、さまざまな実施態様では、そのフレームのRSデータを含む最初のセグメントよりも前に送信することができる（例えばアプリケーション・データ・データグラムを含むセクションは、単一のフレーム内ではRSデータを含むセクションとインターリーブされない）。そのフレームの最初のセクションと最後のセクションの間にあるすべてのセクションは、例えばそのフレームに属するデータを含むことができる（例えばアプリケーション・データおよび／またはRSデータだけが許容される）。アプリケーション・データとRSデータを提供するセクションは、さまざまな実施態様では、インターリーブされない。さまざまな実施態様では、アプリケーション・データテーブル内のデータグラムは重ならないことにも注意されたい。
【００７９】
本発明に従うフレームに関するアプリケーション・データ・データグラムを含む最後のセクションに続くセクションは、例えば、同じフレームのRSデータを含む最初のセクションか、次のフレームの第1のアプリケーション・データ・セクションを含むことができる。後者の場合、第1のフレームに関係するRSデータは送信されない。
【００８０】
本発明のさまざまな実施態様では、それぞれのフレームごとに、アドレス・フィールドが値“0”に設定された1つのアプリケーション・データ・セクションを正確に送信することとしてよい。その代わりに、あるいはそれに加えて、RSデータが送信されるそれぞれのフレームについては、アドレス・フィールドが値“0”に設定された1つのRSデータ・セグメントを正確に送信することとしてよい。アプリケーション・データ・テーブルやRSデータ・テーブル内でのアドレス指定は、さまざまな実施態様では、ゼロから始まることが好ましい。本発明のさまざまな実施態様では、提供されたアプリケーション・データ内にパッドもスタッフもなくてもよい。さらに、さまざまな実施態様では、RS表内の提供されたRSデータにはパッドもスタッフも含まなくともよい。さらに、本発明のさまざまな実施態様では、時間スライシングを利用するとき、アプリケーション・データ・テーブルおよび／またはRSデータ・テーブルを含むフレームを1つのバースト内で送信してよいことに注意されたい（例えば1つのフレームのデータが複数のバーストに分割されなくてもよい）。
【００８１】
上記のように、これまでは列方向にロードされたアレイ等について説明してきたが、さまざまな実施態様では、ローディングを行方向に行なえることと、そのような実施態様では、機能は上に説明したのと同じだが、行方向の特徴が列方向になり、逆も同様であることに注意されたい。
【００８２】
（特性データを使用すべきかどうかの判断）
すでに説明したように、本発明のさまざまな実施態様によれば、受信ノードは、受信した特性値を利用すべきかどうかを判断する適切な動作を実施することができる。そのような動作は、例えばその受信ノードのユーザーが、例えばGUIその他のインターフェイスを通じて入力する命令に従って実施することができる。ノードは、特性値を利用できるかどうかを判断するのにさまざまなスキームを利用することができる。
【００８３】
例えば受信した特性値がFEC等に対応している実施態様では、受信ノードが、対応する送信ノードによってロードされた元のあるいは変更されている受信されたパケット等に誤りがあるかどうかを調べるスキームを利用することができる。受信ノードは、判断するために、例えばCRC（巡回冗長検査）法を利用することができる。誤りが見つかった場合には、受信ノードは、受信した1つ以上の特性値を利用する。他の下位層チャネルの復号を利用して判断することもできる。下位層チャネルの復号を利用すると、どこに誤りがあるかも示される。
【００８４】
パケット等のローディングが列方向であり、1つ以上の行について2つ以上の特性値が決定される実施態様の別の一例として、受信ノードは、そのそれぞれの行について、対応する特性値のうちの1つだけを採用してよい。受信ノードは、例えば検出した誤りに対応する特徴に基づいてその選択を行なう。その特徴としては、例えば誤りのタイプ、誤りの程度などが挙げられる。
【００８５】
パケット等のローディングが列方向である実施態様のさらに別の一例として、受信ノードは、所定の行だけに関し、対応する特性値を適用することを選択する。上記のように、受信ノードは、例えば検出した誤りに対応する特徴に基づいてその選択を行なう。
【００８６】
さらに別のスキームの一例によると、受信ノードは、十分なメモリを利用できると判断した場合には、受信した特性値を利用する動作だけを行なう。十分なメモリがあるとは、例えば、対応する送信ノードが作り出した、および／またはアクセスしたアレイ等に対応するアレイ等を作り出す、および／またはそのようなアレイ等にアクセスするのに十分なメモリを有すること、および／または受信した特性値に関して操作を行なうのに十分なメモリを有することを意味する。
【００８７】
このようなスキームの性能としては、例えばアレイ等に必要なサイズの仕様を受信ノードが問い合わせること、自由なメモリおよび／または自由にできるメモリの量を決定すること、十分なメモリを利用できるかどうかを決定することなどが挙げられよう。別の一例として、このようなスキームの性能としては、その代わりに、あるいはそれに加えて、受信ノードが、受信した特性値に関して操作を行なうためのメモリの量を決定することが挙げられよう。必要なサイズの仕様は、例えば送られる上記のタイプの指標に含めることができる。別の一例として、必要なサイズの仕様は、すでに説明したように、すべてのアレイ等で使用するために設定したサイズに合うようにすることができる。
【００８８】
さらに別のスキームの一例によると、受信ノードは、特性値を利用するのに十分なエネルギー（例えばバッテリの電力）および／または処理能力があると判断した場合には、受信した特性値を採用する動作だけを行なう。このような機能は、多数の方法で実現することができる。例えば受信ノードは、訂正すべき誤りのタイプ、程度などに関する上記の判断を行なうことができる。受信ノードは、次に、含まれる特性データ（リード-ソロモン・データ）のタイプをおそらく考慮し、誤りを訂正するのに必要なエネルギーおよび／または利用可能な処理能力を推定する。受信ノードは、決定した利用可能なエネルギーおよび／または処理能力をもとにした推定結果を考慮し、特性データを利用するのに十分なエネルギーおよび／または処理能力があるかどうかを判断することができる。
【００８９】
ノードは、例えばアクセス可能なアルゴリズム、ソフトウエア・モジュールなどを用いて計算を行なうことにより、推定を行なうことができる。別の一例として、ノードは、訂正すべき誤りのタイプ、誤りの程度などを、必要なエネルギーおよび／または利用可能な処理能力と関係づけるアクセス可能な記憶装置を参照することにより、推定を行なうことができる。ノードは、例えばオペレーティング・システムおよび／またはロードされたソフトウエア・モジュールが提供する機能を利用し、利用可能なエネルギーおよび／または処理能力を決定することができる。
【００９０】
さらに別のスキームの一例によると、受信ノードは、所定のサービス、チャネル、データのタイプなどに関して受信した特性値を利用する動作だけを行なう。例えば受信ノードは、ソフトウエアおよび／またはファイルのダウンロードに関する受信した特性値を利用する動作だけを行なう。ノードのユーザーは、さまざまな実施態様では、受信した特性データを利用すべきサービス、チャネル、データのタイプを指定することができる。さらに、さまざまな実施態様では、これらは、システムの管理者などが指定することができよう。
【００９１】
さらに別のスキームの一例によると、送信ノードは、所定のサービス、チャネル、データのタイプなどに関してだけ特性値を計算して利用することができる。
【００９２】
カプセル化操作
【００９３】
さまざまな実施態様では、MPEを本発明のさまざまな実施態様で利用することができる。すでに説明したように、このようなMPEは、例えばDSM-CC MPEにすることができる。MPEに関する情報は、例えばETSI文書のTR 101 202に見いだすことができ、その内容は参考としてこの明細書に組み込まれているものとする。本発明の実施態様に従ってMPEを利用した1つの例を図1に示してある。
【００９４】
図1に示したように、送信ノードは、MPE DSM-CCセクションに、計算した特性値に対応するデータを含むパケット等（例えばIPパケット）および／またはロードされた元のパケット等あるいは変更されているパケット等（例えばIPパケット）を収納することができる（ステップ109）。次のステップとして、DSM-CCセクションを例えばMPEG-2 TSパケットの中に収納することができる（ステップ111）。さまざまな実施態様では、第1のPID値は、ロードされた元のパケット等あるいは変更されているパケット等に対応するデータを含むTSパケットと関係づけ、第2のPID値は、特性値に対応するデータを含むTSパケットと関係づけることができる。TSパケットは、次にリンク（例えばDVBリンク）を通じて送信することができる。
【００９５】
さらに、図2に示したように、上記のタイプのTSパケットを受信した（ステップ201）受信ノードは、そのパケットに含まれるDSM-CCセクションを取り出すことができる（ステップ203）。次に、受信ノードは、そのDSM-CCセクションから、計算した特性値に対応するデータを含むパケット等（例えばIPパケット）および／またはロードされた元のパケット等あるいは変更されているパケット等（例えばIPパケット）を取り出すことができる（ステップ205）。
【００９６】
DSM-CC MPEについてこれまで説明してきたが、他のMPE法も利用できることに注意されたい。さらに、DSM-CCセクションがアレイ等の中に収納されないようにしてMPEを実現することについてこれまで説明してきたが、さまざまな実施態様では、上記のパケット等を含むDSM-CCセクションをアレイ等の中に収納できることにも注意されたい。
【００９７】
本発明のさまざまな実施態様では、RSデータ・テーブルの列のデータは、1つ以上のデータ・フィールドを含むヘッダを付加することにより、送信または提供の前にカプセル化することができる。これらデータ・フィールドは、例えばネットワーク情報テーブル（NIT）および／またはIP/MAC通知テーブル（INT）で使用されるような記述子にすることができる。これら記述子は、例えば、時間スライシングおよび／または本発明のフレームが基本的なストリームで使用されるかどうかを識別することができる。これら記述子が時間スライシングおよび／または上記フレームを指定するために使用される場合には、さまざまな実施態様では、関連するサービスのサービス記述テーブル（SDT）内に通知される。通知は、例えばMACアドレス・バイトが、複数の受信機を区別する以外の目的で使用されることを示す。記述子は、さまざまな実施態様では、その記述子の長さ、時間スライシングの利用、本発明のタイプのフレームの利用に関する指標、フレーム内の行の数、1つのバーストの最大持続時間などを指定するデータ・フィールドを含んでいる。
【００９８】
例えばアプリケーション・データ・テーブルとRSデータ・テーブルを含む本発明のタイプのフレームを利用する場合には、RSデータを含むセクションは、さまざまな実施態様では、そのセクションの長さ、パッド・バイトだけで埋まったアプリケーション・データ・テーブル内の列の合計数、RSデータを含むセクションの数、現在のフレームでRSデータを含む最後のセクションを示す番号、RSデータ・バイト、そのセクションについて計算したCRC-32検査データなどの指標を含んでいる。セクションの番号は、例えばゼロから始めること、および／またはRSデータを含む次のセクションで1大きくすることができる。
【００９９】
（ハードウエアとソフトウエア）
この明細書に記載したいくつかのプロシージャ等は、コンピュータによって、あるいはコンピュータの助けを借りて実行することができる。この明細書では、“コンピュータ”、“汎用コンピュータ”などの用語は、おそらくJava（登録商標）や.Netをサポートしているオペレーティング・システム（例えばOS X、リナックス（登録商標）、ダーウィン、ウインドウズCE（登録商標）、ウインドウズXP（登録商標）、パームOS、シンビアンOSなど）が走るプロセッサ・カード・スマート・カード、媒体装置、パーソナル・コンピュータ、エンジニアリング・ワークステーション、PC、マッキントッシュ（登録商標）、PDA、コンピュータ化された腕時計、有線または無線の端末、サーバー、ネットワーク・アクセス・ポイント、ネットワーク・マルチキャスト・ポイントなどを意味するが、具体例はこれだけではない。
【０１００】
“汎用コンピュータ”、“コンピュータ”などの用語は、1つ以上のメモリまたは記憶ユニットに動作可能に接続された1つ以上のプロセッサも意味するが、これに限定されるものではない。そのメモリまたは記憶ユニットは、データ、アルゴリズム、プログラム・コードなどを収容することができ、プロセッサは、そのプログラム・コードを実行すること、および／またはそのプログラム・コード、データ、アルゴリズムを操作することができる。例えば図5に示したコンピュータ5000は、2つのプロセッサ5051および5052に動作可能に接続されたシステム・バス5050と、ランダム・アクセス・メモリ（RAM）5053と、読み出し専用メモリ（ROM）5055と、入出力（I/O）インターフェイス5057および5058と、記憶装置インターフェイス5059と、ディスプレイ・インターフェイス5061とを備えている。記憶装置インターフェイス5059はさらに、大容量記憶装置5063に接続されている。それぞれのI/Oインターフェイス5057と5058は、イーサネット（登録商標）、IEEE 1394、IEEE 1394b、IEEE 802.11a、IEEE 802.11b、IEEE 802.11g、IEEE 802.16a、IEEE P802.20、ブルートゥース（登録商標）、地上ディジタルビデオブロードキャスティング（DVB-T）、衛星ディジタルビデオ・ブロードキャスティング（DVB-S）、ディジタルオーディオ・ブロードキャスティング（DAB）、汎用パケット無線サービス（GPRS）、汎用移動通信サービス（UMTS）、あるいは公知の他のインターフェイスにすることができる。
【０１０１】
大容量記憶装置5063は、ハード・ドライブ、光学ドライブ装置などにすることができる。プロセッサ5057と5058は、それぞれ一般に知られているプロセッサであり、例えばIBMまたはモトローラのパワーPC、AMDのアスロン、AMDのオプテロン、インテルのARM、インテルのXScale、トランスメタのクルーソー、インテルのペンティナム（登録商標）などがある。この実施例に示したコンピュータ5000は、ディスプレイ・ユニット5001と、キーボード5002と、マウス5003も備えている。別の実施態様では、キーボード5002および／またはマウス5003の代わりに、および／またはそれらに加えて、タッチ・スクリーン、ペン、キーパッド・インターフェイスにすることができる。コンピュータ5000はさらに、カード読み取り機、DVDドライブ、フロッピー（登録商標）・ディスク・ドライブなどを備えること、あるいはこれらに接続することができる。そうすることにより、プログラム・コードを収容した媒体を、コンピュータにコードをロードすることを目的として挿入することができる。
【０１０２】
本発明によれば、コンピュータは、上記の1つ以上の操作を実行するように設計した1つ以上のソフトウエア・モジュールを走らせることができる。そのようなモジュールは、従来技術に従い、Java（登録商標）、オブジェクト指向C、C、C#、C++などの言語を用いてプログラムすることができる。対応するプログラム・コードを媒体（例えばDVD、CD-ROM、フロッピー（登録商標）・ディスク）上に収納することができる。特定のソフトウエア・モジュール間での動作の分割に関する上記の説明はどれも例示を目的としたものであり、動作を別の形に分割できることに注意されたい。したがって1つのソフトウエア・モジュールによって実行されている上記のあらゆる動作は、複数のソフトウエア・モジュールで実行することができる。同様に、複数のモジュールで実行されている上記のどの動作も、単一のモジュールで実行させることができる。
【０１０３】
さらに、本発明の実施態様では、所定の装置上で動作するいくつかのソフトウエア・モジュールや層などを開示したが、別の実施態様では、そのモジュールや層などは、説明したのとは別の装置上に分散させて走らせることができる。例えば特定の1つのコンピュータが実行するとして開示した動作は、複数のコンピュータに実行させることができる。さらに、さまざまな実施態様では、グリッドコンピューティングを利用できることに注意されたい。
【０１０４】
図6には、本発明のさまざまな実施態様で使用できる端末の一例についての機能ブロックダイヤグラムが示してある。図6の端末についてこれまでに説明してきた。以下の説明では、対応する参照記号は対応する部分に適用される。図6の端末6000は、この明細書に記載したあらゆる実施態様で使用することができる。端末6000は、処理ユニットCPU603と、マルチキャリア信号端末部605と、ユーザー・インターフェイス（601、602）とを備えている。マルチキャリア信号端末部605とユーザー・インターフェイス（601、602）は、処理ユニットCPU603に接続されている。1つ以上のダイレクト・メモリ・アクセス（DMA）チャネルが、マルチキャリア信号端末部605とメモリ604の間に存在している。ユーザー・インターフェイス（601、602）は、ディスプレイと、ユーザーが端末6000を使用できるようにするためのキーボードとを備えている。ユーザー・インターフェイス（601、602）はさらに、音声信号を受信して再生するマイクロフォンとスピーカも備えている。ユーザー・インターフェイス（601、602）は、音声認識装置（図示せず）も備えている。
【０１０５】
処理ユニットCPU603は、マイクロプロセッサ（図示せず）と、メモリ604と、場合によりソフトウエアとを備えている。受信したデータとソフトウエアは、メモリ604の中に記憶させることができる。マイクロプロセッサは、そのソフトウエアに基づき、端末6000の動作を制御する。制御するのは、例えば、データ・ストリームの受信、特性データを利用するかしないかの判断、データ受信におけるパルス状バースト・ノイズの許容度、ユーザー・インターフェイスにおける出力のレンダリング、ユーザー・インターフェイスから受信した入力の読み込みなどである。動作については上に説明した。このハードウエアは、信号を検出する回路と、復調のための回路と、パルスを検出する回路と、大量のパルス状ノイズが存在している記号のサンプルを空白にする回路と、推定値を計算する回路と、特性データの使用を決定する回路と、欠陥のあるデータを訂正する回路とを備えている。
【０１０６】
やはり図6を参照すると、別の方法として、ミドルウエアまたはソフトウエアを提供することもできる。端末6000は、ユーザーが手軽に持ち運ぶことのできる携帯装置にすることができる。端末6000は、マルチキャスト送信ストリームを受信するためのマルチキャリア信号端末部605を備える携帯電話にすることが好ましい。したがって端末6000は、サービス・プロバイダと相互作用することができる。
【０１０７】
（関連事項と範囲）
【０１０８】
上記の説明には多くの特別な例が含まれているが、それらは単に本発明の例示として示したのであり、本発明がそれらに限定されると考えてはならない。したがって、当業者であれば、本発明の範囲を逸脱することなく、本発明のシステムや方法に対してさまざまな変更をなしうることがわかるであろう。
【図１】
0004700112.tif 000002
【図２】
0004700112.tif 000003
【図３】
0004700112.tif 000004
【図４】
0004700112.tif 000005
【図５】
0004700112.tif 000006
【図６】
0004700112.tif 000007