(57)【要約】地上デジタルビデオ放送（ＤＶＢ−Ｔ）ネットワークが、マルチプロトコルカプセル化（ＭＰＥ）を用いて、ＩＰデータグラムを受信デバイスへ送信するために使用される。ＭＰＥデータグラムセクション、および、もし、前進型誤信号訂正（ＦＥＣ）が使用された場合は、ＭＰＥ−ＦＥＣデータグラムセクションは、タイムスライシングパラメーター、例えば、次のバーストが送信されるまでの時間を特定するための”ｄｅｌｔａ−ｔ”パラメーターのようなパラメーターや、バーストの最後を示すためのフラッグのようなものを含み得る。したがって、ＭＰＥ、および、ＭＰＥ−ＦＥＣデータグラムセクションは、バースト内で送信され得る。しかしながら、その他のタイプのセクションは、そういったタイムスライシングパラメーターを含まず、通常バースト内では送信されることができない。それにもかかわらず、ｄｅｌｔａ−ｔを特定する少なくとも一つのＭＰＥ、または、ＭＰＥ−ＦＥＣデータグラムセクション、および、バーストの最後にその位置を示すＭＰＥ、または、ＭＰＥ−ＦＥＣデータグラムセクションを含んだバーストを組み立てることによって、その他のタイプのセクションは、バーストで送信されるという利益を得ることができる。
2006526350.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークにおけるバーストの送信方法であって、
当該方法が、
バーストを記述するためのいかなるタイムスライシングパラメーターをも伴わない第１のデータ構造を提供し、
タイムスライシングパラメーターのセットを伴う第２のデータ構造を提供し、
前記第１および第２のデータ構造を含んだバーストを形成する、
ことを含むことを特徴とする方法。
【請求項２】
請求項１に記載の方法において、
前記バーストを形成することが、
前記第２のデータ構造を前記バーストの最後に配置する、
ことを含むことを特徴とする方法。
【請求項３】
請求項１または２に記載の方法であって、
前記第２のデータ構造において、前記バーストの最後を示唆するデータを提供する、
ことを含むことを特徴とする方法。
【請求項４】
請求項３に記載の方法において、
前記バーストの最後を示唆する前記データを提供することが、
前記第２のデータ構造の中で第１のあらかじめ決められた位置に前記データを配置する、
ことを含むことを特徴とする方法。
【請求項５】
請求項１乃至４のいずれか一つに記載の方法であって、
前記第２のデータ構造において、引き続くバーストに関連したデータを提供する、
ことを含むことを特徴とする方法。
【請求項６】
請求項１乃至５のいずれか一つに記載の方法であって、
前記第２のデータ構造において、隣接する、引き続くバーストに関するデータを提供する、
ことを含むことを特徴とする方法。
【請求項７】
請求項５または６に記載の方法において、
前記引き続くバーストに関連したデータ、または、前記引き続く隣接するバーストに関するデータを提供することが、
引き続くバーストの開始までの時間を特定する、
ことを含むことを特徴とする方法。
【請求項８】
請求項５、６または７に記載の方法において、
前記引き続くバースト、または、前記引き続く隣接するバーストに関連するデータを提供することが、
前記バーストにおける前記第２の構造の位置と相対的に引き続くバーストの開始を特定する、
ことを含むことを特徴とする方法。
【請求項９】
請求項２乃至５のいずれか一つに記載の方法において、
前記引き続くバースト、または、引き続く隣接するバーストに関連した前記データを提供することが、
前記第２のデータ構造において第２のあらかじめ決められた位置に前記データを配置する、
ことを含むことを特徴とする方法。
【請求項１０】
請求項１乃至９のいずれか一つに記載の方法であって、
タイムスライシングパラメーターのセットを伴う第３のデータ構造を提供し、
前記第１、第２および第３のデータ構造を含んだバーストを形成する、
ことを含むことを特徴とする方法。
【請求項１１】
請求項１乃至１０のいずれか一つに記載の方法であって、
前記第３のデータ構造において、引き続くバーストに関連するデータを提供する、
ことを含むことを特徴とする方法。
【請求項１２】
請求項１乃至１１のいずれか一つに記載の方法であって、
前記第３のデータ構造において、隣接する、引き続くバーストに関連するデータを提供する、
ことを特徴とする方法。
【請求項１３】
請求項１１または１２に記載の方法において、
前記引き続くバースト、または、前記引き続く隣接するバーストに関連するデータを提供することが、
引き続くバーストまでの時間を特定する、
ことを含むことを特徴とする方法。
【請求項１４】
請求項１１、１２または１３に記載の方法において、
前記引き続くバースト、または、前記引き続く隣接するバーストに関連するデータを提供することが、
前記バースト内で、前記第３の構造の位置と相対的に引き続くバーストの開始を特定する、
ことを含むことを特徴とする方法。
【請求項１５】
請求項１１乃至１４のいずれか一つに記載の方法において、
前記引き続くバースト、または、前記引き続く隣接するバーストに関連した前記データを提供することが、
前記第３のデータ構造において第３のあらかじめ決められた位置に前記データを配置することを含み、
前記第３のデータ構造における前記第３のあらかじめ決められた位置が前記第２のデータ構造における前記第２のあらかじめ決められた位置と一致する、
ことを特徴とする方法。
【請求項１６】
請求項１乃至１５のいずれか一つに記載の方法であって、
前記第１のデータ構造において前記第１のデータ構造を第１のタイプとして特定するための第１の識別子を含み、
前記第２のデータ構造において前記第２のデータ構造を異なる第２のタイプとして特定するための第２の識別子を含む、
ことを含むことを特徴とする方法。
【請求項１７】
請求項１６に記載の方法において、
前記第１および第２の識別子が、
前記第１のデータ構造において、第４のあらかじめ決められた位置で前記第１の識別子を提供し、
前記第２のデータ構造において、第５のあらかじめ決められた位置で前記第２の識別子を提供する、
ことを含み、
前記第１のデータ構造における前記第４のあらかじめ決められた位置が、前記第２のデータ構造において前記第５のあらかじめ決められた位置と一致する、
ことを特徴とする方法。
【請求項１８】
請求項１乃至１７のいずれか一つに記載の方法において、
前記第２のデータ構造を提供することが、
マルチプロトコルカプセル化（ＭＰＥ）セクションを提供する、
ことを含むことを特徴とする方法。
【請求項１９】
請求項１８に記載の方法において、
前記第２のデータ構造を提供することが、
ＤＳＭ−ＣＣ（Ｄｉｇｉｔａｌ  Ｓｔｏｒａｇｅ  Ｍｅｄｉａ  Ｃｏｍｍａｎｄ  ａｎｄ  Ｃｏｎｔｒｏｌ）セクションフォーマットを使用して、データフォーマットを行なう、
ことを含むことを特徴とする方法。
【請求項２０】
請求項１８または１９に記載の方法であって、
少なくとも一つのメディアアクセスコントロール（ＭＡＣ）アドレスフィールドによって形成されたデータ領域の少なくとも一部内で前記タイムスライシングパラメーターのセットを特定する、
ことを含むことを特徴とする方法。
【請求項２１】
請求項１８乃至２０のいずれか一つに記載の方法であって、
四つのメディアアクセスコントロール（ＭＡＣ）アドレスフィールドによって形成されるデータ領域の少なくとも一部の中で前記タイムスライシングパラメーターのセットを特定する、
ことを含むことを特徴とする方法。
【請求項２２】
請求項１乃至２１のいずれか一つに記載の方法において、
前記第１のデータ構造を提供することが、
ＭＰＥＧ−２プライベートセクションを提供する、
ことを含むことを特徴とする方法。
【請求項２３】
請求項１乃至２２のいずれか一つに記載の方法において、
前記第１および２のデータ構造が階層的には実質的に等しいことを特徴とする方法。
【請求項２４】
通信ネットワークにおいてネットワーク要素を操作する方法であって、
前記方法が、
データのバーストを記述するためのタイムスライシングパラメーターのセットを伴う第１のデータ構造、および、いかなるタイムスライシングパラメーターを伴わない第２のデータ構造を含んだバーストを形成する、
ことを含むことを特徴とする方法。
【請求項２５】
通信ネットワークにおいて受信デバイスを操作する方法であって、
前記方法が、
バーストを記述するためのタイムスライシングパラメーターのセットを伴う第１のデータ構造、および、いかなるタイムスライシングパラメーターをも伴わない第２のデータ構造を含むバーストを受信し、
前記第１のデータ構造を特定し、
前記第１のデータ構造から少なくとも一つのタイムスライシングパラメーターを取り出す、
ことを含むことを特徴とする方法。
【請求項２６】
請求項２５に記載の方法において、
前記第１のデータ構造を特定することが、
前記第１および第２のデータ構造のそれぞれの中で第１のあらかじめ決められたフィールドを検査する、
ことを含むことを特徴とする方法。
【請求項２７】
請求項２５または２６に記載の方法において、
前記第１のデータ構造から前記少なくとも一つのタイムスライシングパラメーターを取り出すことが、
前記第１の構造の中で第２のあらかじめ決められたフィールドを検査し、
引き続くバーストの関連するデータを、前記第２のあらかじめ決められたフィールドから読み出す、
ことを含むことを特徴とする方法。
【請求項２８】
請求項２７に記載された方法であって、更に、
引き続くバーストに関連する前記データを記憶する、
ことを含むことを特徴とする方法。
【請求項２９】
請求項２５乃至２８のいずれか一つに記載された方法であって、更に、
前記第１の構造の中で第３のあらかじめ決められたフィールドを検査し、
前記第３のあらかじめ決められたフィールドから、前記バーストの最後を示唆するデータを読み出す、
ことを含むことを特徴とする方法。
【請求項３０】
請求項１乃至２９に記載の方法を実行するためのデータ処理装置をもたらすためのコンピュータプログラム命令を含むコンピュータプログラム。
【請求項３１】
データのバーストを記述するためのタイムスライシングパラメーターのセットを伴う第１のデータ構造、および、いかなるタイムスライシングパラメーターをも伴わない第２のデータ構造を含んだバーストを形成するように構成されたネットワーク要素。
【請求項３２】
請求項３１に記載のネットワーク要素において、
前記第１のデータ構造が、
マルチプロトコルカプセル化（ＭＰＥ）セクション、
を含むことを特徴とするネットワーク要素。
【請求項３３】
請求項３１または３２に記載のネットワーク要素において、
前記第１のデータ構造が、
マルチプロトコルカプセル化−前進型誤信号訂正（ＭＰＥ−ＦＥＣ）セクション、
を含むことを特徴とするネットワーク要素。
【請求項３４】
請求項３１乃至３３のいずれか一つに記載のネットワーク要素において、
前記第２のデータ構造が、
ＭＰＥＧ−２プライベートセクション、
を含むことを特徴とするネットワーク要素。
【請求項３５】
請求項３１乃至３４のいずれか一つに記載のネットワーク要素であって、
当該ネットワーク要素が送信器である、
ことを特徴とするネットワーク要素。
【請求項３６】
ハンドセットであって、
前記ハンドセットが、
受信器と、
処理装置と、
を備え、
前記ハンドセットが、バーストを記述するためのタイムスライシングパラメーターのセットを伴う第１のデータ構造、および、いかなるタイムスライシングパラメーターをも伴わない第２のデータ構造を含んだバーストを受信し、前記第１のデータ構造を特定し、かつ、少なくとも一つのタイムスライシングパラメーターを前記第１のデータ構造から取り出すように構成されたことを特徴とするハンドセット。
【請求項３７】
通信ネットワークにおいてバーストを送信するためのシステムであって、
当該システムが、
バーストを記述するためのいかなるタイムスライシングパラメーターをも伴わない第１のデータ構造を提供する機能と、
タイムスライシングパラメーターのセットを伴う第２のデータ構造を提供する機能と、
前記第１と第２のデータ構造を含んだバーストを形成する機能と、
を含むことを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムにおいてバーストを送信する方法に関する。排他的な意味ではないが、特に、デジタルビデオ放送（ＤＶＢ）ネットワークにおけるバーストを送信する方法に関する。
【背景技術】
【０００２】
移動体通信システムは、例えば、ＭＰＥＧ−４のような、高度な圧縮技術を用いることで、ストリーミングビデオを可能とするための十分な回線容量を提供できることが知られている。例えば、第３世代移動体通信ネットワークは、最大３８４キロビット毎秒（ｋｂｐｓ）の回線容量を有する。しかしながら、これは、例えば、ファイルのダウンロードといったような、いくつかのサービスにとっては、十分な帯域幅とはいえない。
【０００３】
とはいっても、より高速な伝送システムが知られている。例えば、デジタルビデオ放送（ＤＶＢ）送信システムは１０Ｍｂｐｓ、または、それ以上の回線容量の提供を可能とする。したがって、より高速な伝送システムを用いることで、移動体通信システムを増補することが可能である。
【０００４】
ＤＶＢ受信器は、例えば、デジタルテレビのような形態で適用されることが知られている。通常、ＤＶＢ受信器は固定され、コンセントから電源を得る。しかし、携帯型の手持ち用端末は通常電池により電源を得るものであり、その電力には限界がある。
【０００５】
ＤＶＢ受信器の平均電力消費量は時分割多重（ＴＤＭ）に基づく方式を使用することで削減することができる。そのような方式はタイムスライシングと呼ばれる。
【０００６】
あるサービスが要求された場合に、タイムスライシングを用いてデータを送信することが可能である。バーストデータは、静的な帯域幅を用いたデータ送信のために必要とされる帯域幅に比べて、非常に高速な回線容量を用いて送信される。各バーストは、次のバーストが開始する時間の指示を含んでおり、それは、「ｄｅｌｔａ−ｔ」として参照される。バーストの間では、データは送信されず、そのサービスのために割り当てられた回線容量をその他のサービスが使用することを許容する。従って、この受信器は、バーストを受信する時間の部分だけアクティブであれば足りるのである。とはいっても、比較的より一定、かつ、低速度で、受信されたバーストはバッファされ、処理される。
【０００７】
現時点においては、タイムスライシングは、いくつかのデータタイプのためには、使用することができない。これは、ＥＭＭ（Ｅｎｔｉｔｌｅｍｅｎｔ  Ｍａｎａｇｅｍｅｎｔ  Ｍｅｓｓａｇｅ）メッセージを送信するために使用されるＥＭＭセクションのようなデータ構造は、例えば、ｄｅｌｔａ−ｔのようなタイムスライシング情報に合わせることができない。
【０００８】
本発明は、この欠点を改善することを追及する。
【発明の開示】
【課題を解決するための手段】
【０００９】
本発明に従うと、通信ネットワークにおけるバーストの送信方法が提供される。その方法は、バーストを記述するためのいかなるタイムスライシングパラメーターも伴わない第１のデータ構造を提供し、タイムスライシングパラメーターのセットを伴う第２のデータ構造を提供し、第１と第２のデータ構造を含んだバーストを形成することを含む。
【００１０】
これは、前記第１のデータ構造がバーストで送信されることを可能とする利点を有している。
【００１１】
バーストを形成することは、バーストの最後に、第２のデータ構造を配置することを含む。この方法は、第２の構造の中にバーストの最後を示唆するデータを提供することを含み得る。バーストの最後を示唆するデータの提供することは、第２のデータ構造の中で第１のあらかじめ決められた位置にデータを配置することを含み得る。この方法は、第２のデータ構造において、引き続くバーストに関連するデータを提供することを含み得る。この方法は、第２のデータ構造において、隣接する、引き続くバーストに関連するデータを提供することを含み得る。引き続くバーストまたは引き続く隣接するバーストに関連するデータを提供することは、引き続くバーストの最初までの時間を特定することを含み得る。引き続くバーストまたは引き続く隣接するバーストに関連するデータを提供することは、バースト内の第２の構造の位置に関連して、引き続くバーストの最初を特定することを含み得る。引き続くバーストまたは引き続く隣接するバーストに関連するデータを提供することは、第２のデータ構造内で第２のあらかじめ決められた位置にデータを配置することを含む。この方法は、タイムスライシングパラメーターのセットを伴う第３のデータ構造を提供し、第１、２および３のデータ構造を含んだバーストを形成することを含む。この方法は、第３のデータ構造において、引き続くバーストに関連するデータを含み得る。この方法は、第３のデータ構造において、隣接する、引き続くバーストに関連するデータを提供することを含む。引き続くバースト、または、引き続く隣接するバーストに関連するデータを提供することは、引き続くバーストの開始までの時間を特定することを含み得る。引き続くバースト、または、引き続く隣接するバーストに関連するデータを提供することは、バーストにおける第３の構造の位置から相対的に引き続くバーストの開始を特定することを含み得る。引き続くバースト、または、引き続く隣接するバーストに関連するデータを提供することが、第３のデータ構造内で、第３のあらかじめ決められた位置にデータを配置することを含み得る。この場合において、第３のデータ構造内の第３のあらかじめ決められた位置が、第２のデータ構造内の第２のあらかじめ決められた位置と一致するかもしれない。この方法は、第１のデータ構造において第１のデータ構造を、第１タイプのものであるとして、特定するための第１の識別子を提供し、第２のデータ構造において、第２のデータ構造を、異なる第２のタイプのものであるとして、特定する第２の識別子を提供することを含み得る。第１および第２の識別子を提供することは、第１のデータ構造内で第４のあらかじめ決められた位置で第１の識別子提供し、第２のデータ構造内で第５のあらかじめ決められた位置で第２の識別子を提供することを含み得る。
この場合において、第１のデータ構造内の第４のあらかじめ決められた位置が第２のデータ構造内の第５のあらかじめ決められた位置に一致する。第１と第２のデータ構造のうちの一つは、第１と第２のデータ構造のもう一方をフォローし得る。
【００１２】
第２のデータ構造を提供することは、マルチプロトコルカプセル化（ＭＰＥ）セクション、および／または、マルチプロトコルカプセル化−前進型誤信号訂正（ＭＰＥ−ＦＥＣ）セクションを含み得る。第２のデータ構造を提供することは、ＤＳＭ−ＣＣ（Ｄｉｇｉｔａｌ  Ｓｔｏｒａｇｅ  Ｍｅｄｉａ  Ｃｏｍｍａｎｄ  ａｎｄ  Ｃｏｎｔｒｏｌ）セクションフォーマットを使用した、データフォーマッティングを含み得る。この方法は、少なくとも一つのメディアアクセスコントロール（ＭＡＣ）アドレスフィールドによって形成された少なくとも一つのデータ領域の部分内にタイムスライシングパラメーターのセットを配置することを含み得る。この方法は、４つのメディアアクセスコントロール（ＭＡＣ）アドレスフィールドによって形成された、少なくとも一つのデータ領域の部分内にタイムスライシングパラメーターのセットを配置することを含み得る。第１のデータ構造を提供することは、ＭＰＥＧ−２プライベートセクションを提供することを含み得る。第１および第２のデータ構造は階層的には、実質的に等しい。
【００１３】
本発明に従うと、通信ネットワークにおけるネットワーク要素を操作する方法もまた提供され、この方法は、バーストを記述するためのタイムスライシングパラメーターのセットを伴う第１のデータ構造、および、いかなるタイムスライシングパラメーターをも伴わない第２のデータ構造を含むバーストを形成することを含み得る。
【００１４】
本発明に従うと、通信ネットワークにおける受信デバイスの操作方法をも提供し、この方法は、バーストを記述するためのタイムスライシングパラメーターのセットを伴う第１のデータ構造、および、いかなるタイムスライシングパラメーターをも含まない第２のデータ構造を含むバーストを受信し、第１のデータ構造を特定し、少なくとも一つのタイムスライシングパラメーターを、第１のデータ構造から取り出すことを含む。
【００１５】
第１のデータ構造を特定することは、第１および第２のデータ構造それぞれの中で第１のあらかじめ決められたフィールドを検査することを含み得る。少なくとも一つのタイムスライシングパラメーターを第１のデータ構造から取り出すことは、第１のデータ構造の中のあらかじめ決められた第２のフィールドを検査し、第２のあらかじめ決められたフィールドから、引き続くバーストに関連したデータを読み出すことを含む。この方法は、更に、引き続くバーストに関連したデータを記憶することを含む。この方法は、更に、第１のデータ構造の中の第３のあらかじめ決められたフィールドを検査し、その第３のあらかじめ決められたフィールドからバーストの最後を示唆するデータを読み出すことを含む。
【００１６】
本発明に従うと、当該方法を実行するためのデータ処理装置をもたらすコンピュータプログラム命令を含んだコンピュータプログラムもまた提供される。
【００１７】
本発明に従うと、データのバーストを記述するためのタイムスライシングパラメーターのセットを伴う第１のデータ構造、および、いかなるタイムスライシングパラメーターを伴うことのない第２のデータ構造を含むバーストを形成するために構成されたネットワーク要素もまた提供される。
【００１８】
第１のデータ構造がマルチプロトコルカプセル化（ＭＰＥ）セクションまたはマルチプロトコルカプセル化−前進型誤信号訂正（ＭＰＥ−ＦＥＣ）セクションを含み得る。第２のデータ構造は、ＭＰＥＧ−２プライベートセクションを含み得る。ネットワーク要素は送信器であることが考えられる。
【００１９】
本発明に従えば、受信器と処理装置を備えたハンドセットもまた提供され、このハンドセットは、バーストを記述するためのタイムスライシングパラメーターのセットを伴う第１のデータ構造、および、いかなるタイムスライシングパラメーターをも含まない第２のデータ構造を含んだバーストを受信し、第１のデータ構造を特定し、少なくとも一つのタイムスライシングパラメーターを、第１のデータ構造から取り出すために構成されている。
【００２０】
本発明に従えば、通信ネットワークにおいて、バーストを送信するためのシステムを提供もまた提供され、このシステムは、バーストを記述するためのいかなるタイムスライシングパラメーターも伴わない第１のデータ構造を提供し、タイムスライシングパラメーターのセットを伴う第２のデータ構造を提供し、かつ、第１と第２のデータ構造を含んだバーストを形成する。
【発明を実施するための最良の形態】
【００２１】
“通信システム１”
図１を参照すると、通信システム１が示されている。この通信システム１は、オーディオビジュアルコンテンツ、データファイルや画像等のようなコンテンツソース３1、３2へのアクセス手段を有するコンテンツプロバイダ２を含んでいる。
【００２２】
コンテンツ４は、地上デジタルビデオ放送（ＤＶＢ−Ｔ）ネットワークのようなデジタル放送ネットワークによって、インターネットプロトコル（ＩＰ）を使用して、一つかそれ以上の受信デバイス５1、５2へ送信される。受信デバイス５1、５2は、ビデオ機能を有した携帯電話であって、少なくとも二つの異なる通信チャネル６、７からデータを受信するように構成される。
【００２３】
コンテンツデータ４は、コンテンツデータ４を受信し、コンテンツデータ４の誤り訂正に使用するためのリカバリーデータ９を生成するネットワーク要素８に送信される。コンテンツデータ４は、第１の通信チャネル６を経由して受信デバイス５1、５2に送信される。この例においては、第１の通信チャネル６は、ＤＶＢ−Ｔネットワークのような、放送ネットワークであって、送信器１１を含む放送ネットワークである第１のネットワーク１０によって提供される。コンテンツ４は、第１の通信ネットワーク１０に関連付けられた（図には示されていない）セルの中の受信デバイス５1、５2へ放送、マルチキャスト、または、ユニキャストされる。
【００２４】
リカバリーデータ９は、第２の通信チャネル７を経由して受信デバイス５1、５2へ送信される。この例においては、第２の通信チャネル７は、例えば、第３世代（３Ｇ）移動体通信ネットワークのような移動体通信ネットワークである第２の異なる通信ネットワーク１２によって提供され、その第２の通信ネットワーク１２は、送信器１３を含んでいる。リカバリーデータ９、および、例えば、音声データのようなその他のデータは、第２の通信ネットワーク１２に関連付けられた（図には示されていない）セルの中の受信デバイス５1、５2へ送信される。この第２の通信ネットワーク１２は第２世代（２Ｇ）または第２．５世代（２．５Ｇ）ネットワークとすることが考えられる。
【００２５】
図１においては、通信システム１が単純化して示されている。その他の要素、例えば、（図には示されていない）更なる送信器、（図には示されていない）ネットワーク要素、または、（図には示されていない）ネットワークが含まれることが考えられる。
【００２６】
送信器１１、１３は、それぞれ受信デバイス５1、５2へデータを送信するための送信ノード（Ｎｏｄｅ）を提供し、それは、受信器または受信ノードを構成する。
【００２７】
“ネットワーク要素８”
図２において、ネットワーク要素８は、ＤＶＢマルチプロトコルカプセル化（ＭＰＥ）エンカプスレーター（ｅｎｃａｓｕｌａｔｏｒ）である。このネットワーク要素８は、ＭＰＥＧプログラムスペシフィックインフォメーション（ＰＳＩ）やＤＶＢサービスインフォメーション（ＳＩ）のような、ＩＰデータグラム１４、および、サービスデータ１５を受信し、かつ、ＩＳＯ／ＩＥＣ  １３８１８１に従ってトランスポートストリーム１６を生成する。このトランスポートストリーム１６は、一般的には１８８バイト長である、トランスポートストリーム（ＴＳ）パケット１７を含む。
【００２８】
図３についても参照すると、トランスポートストリーム１６は、複数の論理チャネルへ分割されることがわかる。ＴＳパケット１７が帰属する論理チャネルは、パケット識別子（ＰＩＤ）１９を使用してパケットヘッダ１８の中で定義される。ＴＳパケットペイロード２０のコンテンツを特定するために、パケット識別子を使用することも可能である。
【００２９】
例えば、第１のＴＳパケット１７1のコンテンツは、ＰＩＤ値を（１６進数表記で）０ｘ００３０から０ｘ１ＦＦＥの間で指定することで、ビデオ、オーディオ、またはその他の種類のデータであると特定することが考えられる。第２のＴＳパケット１７2のコンテンツは、ＰＩＤ＝０ｘ００１０と指定することで、ネットワークインフォメーションテーブル（ＮＩＴ）のすべて、または、一部を含むものとして特定される。以下で更に詳細を説明するように、ＮＩＴ、および、その他の種類の表は、タイムスライシングパラメーター、および、その他の前進型誤信号訂正に関連したパラメーターを受信デバイス５1、５2（図１）へ信号として送信するために使用されることが考えられる。
【００３０】
ＭＰＥエンカプスレーター８もまた、その他の機能を実行し、かつ、以下で更にこれらの詳細を述べる。
【００３１】
“受信デバイス５1、５2”
図４を参照すると、各受信デバイス５1、５2は、マルチメディア機能を有した携帯電話であることが好ましい。
【００３２】
各受信デバイス５1、５2は、第１と第２のアンテナ２１1、２１2、受信器２２1、および、送信器２２2を含む。この例においては、第１のアンテナ２１1、および、受信器２２1は、第１の通信ネットワーク１０、ここでは、ＤＶＢ−Ｔネットワークからの信号を受信するために使用される。第２のアンテナ２１2、および、送信器２２2は、第２の通信ネットワーク１０へ、そして、第２の通信ネットワーク１０から信号を送信し、受信するために使用される。この受信器および送信器２２1、２２2は、受信信号を増幅し、復号するためにそれぞれ（図には示されていない）無線信号処理回路を含み、かつ、チャネル復号と逆多重化するための（図には示されていない）それぞれのプロセッサを含む。
【００３３】
各受信デバイスは、制御器２３、ユーザーインターフェース２４、メモリ２５、スマートカードリーダー２６、スマートカードリーダー２６によって受け入れられるスマートカード２７、符号器／復号器（ｃｏｄｅｃ）２８、アンプ３０に対応したスピーカー２９、および、プリアンプ３２に対応したマイク３１を含む。
【００３４】
ユーザーインタフェース２４は、ディスプレイ３３およびキーパッド５４を含む。従来の携帯電話のディスプレイに比べてより大きい、および／または、より大きな解像度を有していること、および、カラー画像機能を有するため、ディスプレイ３３は画像およびビデオを表示することに適している。各受信デバイス５1、５2は電池３５もまた含む。
【００３５】
制御器２３は、メモリ２５内の（図には示されない）コンピューターソフトウェアの命令に基づいて受信デバイス５1、５2の操作を管理する。例えば、制御器２３は、ディスプレイ３３のための出力を提供し、かつ、キーパッド３４からの入力を受信する。
【００３６】
図５を参照すると、電池３５および第１のアンテナ２１1および受信器２２1が、電池パック３６に組み込まれていることが示されている。（図には示されていないが）従来の携帯電話器のバッテリーを、受信器を含んだバッテリーパック３６に交換し、かつ、適切なソフトウェアを提供することによって、（図には示されていないが）従来の携帯電話器は、第１の通信ネットワーク１０を経由してデータを受信できるように修正されることができる。もう一つの方法として、第１のアンテナ２１1および受信器２２1は、（図には示されていない）従来の携帯電話器のための（図には示されていない）カバーに組み込まれることが可能である。
【００３７】
第１と第２の通信ネットワーク１０、１２（図１）から信号を受信するために適応された単一の受信器、および、第２の通信ネットワーク１２（図１）へ信号を送信するために適応された送信器を提供するように、受信デバイス５1、５2が、修正されることが考えられる。もう一つの方法として、両方のネットワーク１０、１２のための単一の送信器を提供することも考えられる。
【００３８】
図６を参照すると、受信器２２1は、第１の通信ネットワーク１０からの信号３７を受信することが示されている。信号３７は増幅され、復号され、チャネル復号され、逆多重化される。（図には示されていない）結果としての逆多重化された信号は、データグラムのバースト３８を取り出すために、フィルタリングされる。タイムスライスされていないデータグラムのストリーム４０を生成するために、データグラムバースト３８は、タイムスライスバッファ３９へ入力される。このタイムスライスバッファは、制御器２３およびメモリ２５によって提供される。好ましくは、このデータグラムストリーム４０は実質的に、連続的であり、一定の速度である。
【００３９】
受信デバイス５1、５2は、携帯情報端末（ＰＤＡ）か、少なくとも第１の通信ネットワーク１０を経由して信号を受信する機能を有しているその他の携帯端末であることが考えられる。受信デバイス５1、５2は、車のような乗物で運ばれる端末のような、準固定または準持ち運び可能であることも考えられる。
【００４０】
“ＭＥＰエンカプスレーター８の操作”
ＭＰＥエンカプスレーター８は多くの機能を実行する。それらのいくらかは二つのカテゴリーに分類することができる。一つは、バーストにおけるアプリケーションデータの準備及び送信を含む処理であり、もう一つは、タイムスライシングおよび前進型誤信号訂正パラメーターの準備および信号伝達を含む処理である。
【００４１】
“ＭＰＥおよびＭＰＥ−ＦＥＣデータグラムを用いた、バーストにおけるアプリケーションデータの準備及び送信”
図７および８を参照すると、ＭＰＥエンカプスレーター８（図１）が、前進型誤信号訂正符号およびフォーマットデータ、この場合は、ＤＳＭ−ＣＣ（Ｄｉｇｉｔａｌ  Ｓｔｏｒａｇｅ  Ｍｅｄｉａ  Ｃｏｍｍａｎｄ  ａｎｄ  Ｃｏｎｔｒｏｌ）セクションフォーマットを生成する処理が記載されている。
【００４２】
ＭＰＥエンカプスレーター８（図１）は、コンテンツプロバイダ２（図１）から、この場合はＩＰデータグラムとするデータパケット４１1、４１2、４１3、４１4を受信する。そして、もし必要であれば、ＭＰＥエンカプスレーター８（図１）は、順番に配置し、および／または、例えばＩＰアドレスに基づいて選択されたデータグラムをドロップし、それらの前処理を行なう（ステップＳ１）。ＭＰＥエンカプスレーター８（図１）は（図に示されていない）イーサーネットフレームを受信することが考えられ、したがって、イーサーネットフレーム構造を取り除くような追加的な処理が要求されることが考えられる。
【００４３】
任意的に、データパケット４１1、４１2、４１3、４１4のために前進型誤信号訂正符号が計算される（ステップＳ２）。
【００４４】
このパケット４１1、４１2、４１3、４１4は符号化表または配列４２に格納される（ステップＳ２．１）。このパケット４１1、４１2、４１3、４１4は、アプリケーションデータ表４４として参照される表４２の一部の列、この場合だと、表４２の一番左の部分の列４３1、４３2、４３3、４３4に順次格納される。パケット４１1、４１2、４１3、４１4を、一つかそれ以上の列４３1、４３2、４３3、４３4の一つかそれ以上のアドレス可能な格納先に格納することができる。
【００４５】
一度、所与のパケット数を格納し、または、アプリケーションデータ表４４が埋められると、前進型誤信号訂正（ＦＥＣ）データ４５1、４５2、４５3が計算される（ステップＳ２．２）。好ましくは、リード−ソロモン方式のデータであるこのＦＥＣデータ４５1、４５2、４５3が、各行４６1、４６2、４６3のために計算され、リード−ソロモンデータ表４７として参照される表４２の一部に入力される。
【００４６】
好ましくは、符号化表４２は２５５列を有する。例えば、アプリケーションデータ表４４は１９１列を含み、かつ、リード−ソロモン表４７が６４列を含むことが考えられる。好ましくは、アプリケーションデータ表が表４２の一番左側の部分を占拠し、リード−ソロモン表が表４２の一番右側の部分を占拠する。符号化表４２は、最大で１０２４行とする選択可能な行数を有する。好ましくは、表４２は１バイトのアドレス可能な要素を含む。したがって、２５５列、および、１０２４行を伴う表は、最大２Ｍｂｉｔｓのデータを格納することができる。
【００４７】
パケット４１1、４１2、４１3、４１4が順次行に格納され、ＦＥＣデータパケット４５1、４５2、４５3がそれぞれの列のために計算されることが考えられる。換言すれば、行と列は、置き換えることが可能である。パケット４１1、４１2、４１3、４１4の長さまたはサイズが可変であることもまた考えられる。パケット４１1、４１2、４１3、４１4は、同じサイズでないかもしない。アプリケーションデータ表４４は、スタッフィング（ｓｔｕｆｆｉｎｇ）インフォメーションで、例えば、表の最後を埋められることが考えられる。スタッフィングインフォメーションは、ＦＥＣデータ４５1、４５2、４５3を計算するときに取り除かれる。
【００４８】
パケット４１1、４１2、４１3、４１4およびＦＥＣパケット４８1、４８2、４８3は、符号化表から読み出される（ステップＳ２．３）。ＦＥＣパケット４８1、４８2は、行ごとに読み出される。パケット４１1、４１2、４１3、４１4およびＦＥＣパケット４８1、４８2は分離され、フォーマットされる（ステップＳ３）。
【００４９】
ＭＰＥエンカプスレーター８（図１）は、好ましくは、ヨーロッパ電気通信規格研究所（ＥＴＳＩ）規格３０１  １９２、「デジタルビデオ放送（ＤＶＢ）；データ放送のためのＤＶＢ仕様」Ｖ１．３．１（２０００３−０１）の第７節に従って、データをフォーマットする。ＥＴＳＩ  ＴＲ  ３０１  １９２、「デジタルビデオ放送（ＤＶＢ）；データ放送のための実装ガイドライン」Ｖ１．２．１（２００３−０１）の第４節もまた参照される。
【００５０】
図９を参照すると、ＭＰＥエンカプスレーター８は、パケット４１1、４１2、４１3、４１4を、以下の表１に定義されたシンタックス（ｓｙｎｔａｘ）を使用して、ＤＳＭ−ＣＣセクションフォーマットに従ったＭＰＥデータグラムセクション４９1、４９2、４９3、４９4に配置する。
【００５１】
【表１】
2006526350.tif 000003
【００５２】
図８をまだ参照すると、以下に示す表２の中で定義されるシンタックスを使用することで、ＭＰＥエンカプスレーター８が、ＦＥＣパケット４８1、４８2を、ＭＰＥ−ＦＥＣデータグラムセクションと呼ばれる５０1、５０2に配置する。
【００５３】
【表２】
2006526350.tif 000004
【００５４】
図１０を参照すると、ＭＰＥセクション４９、または、ＭＰＥ−ＦＥＣセクション５０の一般的な構成が示されている。ＭＰＥ／ＭＰＥ−ＦＥＣセクション４９、５０は、ヘッダ５１、ペイロード５２およびトレーラー（ｔｒａｉｌｅｒ）５３を含む。ペイロード５２は、上記表１、２で定義されているように、パケット４１1、４１2、４１3、４１4（図９）、または、ＦＥＣパケット４８1、４８2（図９）を含む。
【００５５】
ヘッダ５１は、冗長なＭＡＣ＿ａｄｒｅｓｓ  １からＭＡＣ＿ａｄｒｅｓｓ  ４フィールドによって提供される、ｔａｂｌｅ＿ｉｄフィールド５２、セクション長フィールド５３およびリアルタイムまたはタイムスライシングパラメーター５４フィールドを含む。リアルタイムまたはタイムスライシングパラメーター５４フィールドは、フレーム境界線を示すためにｄｅｌｔａ−ｔフィールド５５およびフラッグ５６を含む。
【００５６】
図１１を参照すると、ＭＰＥセクション４９1、４９2、４９3、４９4、および、ＭＰＥ−ＦＥＣセクション５０1、５０2は、バースト５９1を含む。後述する詳細のように、バースト５９1は、エレメンタリーストリーム（ｅｌｅｍｅｎｔａｒｙ  ｓｔｒｅａｍ）上で配送され、単一のＰＩＤで特定される。バースト５９1と次のバースト５９2の間（図１３）においては、同じエレメンタリーストリームでは、セクションは送信されない。
【００５７】
図１２を参照すると、ＩＳＯ／ＩＥＣ１３８１８−１に従って、ＭＰＥセクション４９1、４９2、４９3、４９4、および、ＭＰＥ−ＦＥＣセクション５０1、５０2を含む第１番目のバースト５９1が、ＴＳパケット６０1、６０2、６０3の中に配置される（ステップＳ５）。
【００５８】
この例においては、ＴＳパケット６０1、６０2、６０3は、複数のＭＰＥセクション４９1、４９2、４９3、４９4およびＭＰＥ−ＦＥＣセクション５０1、５０2を含むことが考えられる。しかし、ＭＰＥセクション４９1、４９2、４９3、４９4、または、ＭＰＥ−ＦＥＣセクション５０1、５０2は、多数のＴＳパケット６０1、６０2、６０3の間で、分割され得る。ＴＳパケット６０1、６０2、６０3は、同じＰＩＤでラベルを付けられる。
【００５９】
図１３も参照すると、バースト５９1は、エレメンタリーストリームにおける次のバースト５９2の開始時間を示唆することができる。これは、エレメンタリーストリームにおいて、タイムスライスおよび／またはＦＥＣが、使用されていること、および、エレメンタリーストリームにおいて引き続くバーストに関連する情報を送信していることを、受信デバイス５1、５2へ信号送信を行なうことで達成される。
【００６０】
再び、上記、図１０および、表１、２を参照すると、信号送信は、サービス記述セクションを使用して送信されるＳＤＴ（Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｔａｂｌｅ）における、データ放送記述子を含むことを伴う。それは、ＭＡＣ＿ａｄｒｅｓｓ  １からＭＡＣ＿ａｄｒｅｓｓ  ４フィールドがエレメンタリーストリームにおいて、受信器の識別をするために使用されていないが、ｄｅｌｔａ−ｔ５７のようなリアルタイムパラメーター５６を搬送するのに使用されていることを示している。サービス記述セクションおよびデータ放送記述子は、ＥＴＳＩ  ＥＮ  ３０１  ４６８  「Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）；Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｆｏｒ  Ｓｅｒｖｉｃｅ  Ｉｎｆｏｒｍａｔｉｏｎ（ＳＩ）  ｉｎ  ＤＶＢ  ｓｙｓｔｅｍ」Ｖ１．５．１（２００３−０１）に、より詳細に記載されている。
【００６１】
引き続いて到来するバーストに関連した情報を送信することは、各ＭＰＥセクション４９1、４９2、４９3、４９4、および、各ＭＰＥ−ＦＥＣセクション５０1、５０2の上記表１または２において定義されているように、各ヘッダのＭＡＣ＿ａｄｄｒｅｓｓ＿１乃至ＭＡＣ＿ａｄｄｒｅｓｓ＿４フィールドにおけるいわゆるリアルタイムパラメーター５６を含む。例えば、以下の表３は、リアルタイムパラメーターのシンタックスを示す。
【００６２】
【表３】
2006526350.tif 000005
【００６３】
ｄｅｌｔａ＿ｔフィールド５７の使用は、関係するエレメンタリーストリーム上でタイムスライシングが使用されているか否かに依存する。
【００６４】
もし、タイムスライシングが使用されていれば、エレメンタリーストリームで、ｄｅｌｔａ＿ｔ５７フィールドは、次のタイムスライスバーストまでの時間６１1、６１yを示唆する。ｄｅｌｔａ−ｔは、バースト５４1におけるすべてのＭＰＥ／ＭＰＥ−ＦＥＣセクション４９1、４９2、４９3、４９4、５０1、５０2に含まれ、かつ、セクションごと、例えば、第１のＭＰＥセクション４９2から最後のＭＰＥ−ＦＥＣセクション５０y、の値６１1、６１yは異なることが考えられる。ｄｅｌｔａ＿ｔの分解能は、１０ｍｓである。例えば、値が０ｘＣ００（１６進数表現）＝３０７２（１０進数表現）であることは、次のバーストまでの時間が３０．７２ｓであることを示唆している。値０ｘ００は、そのエレメンタリーストリームにおいては、もうこれ以上バーストが送信されないことを示唆するために予約されている。換言すれば、サービスの終了を示している。そういった場合には、バースト５９1におけるすべてのＭＰＥ／ＭＰＥ−ＦＥＣセクション４９1、４９2、４９3、４９4、５０1、５０2のこのフィールドは、同じ値を有している。ｄｅｌｔａ＿ｔは、現在のＭＰＥセクション４９1、４９2、４９3、４９4の１番目のバイトを搬送するｔｒａｎｓｐｏｒｔ＿ｐａｃｋｅｔから次のバーストの第１番目のバイトを搬送するｔｒａｎｓｐｏｒｔ＿ｐａｃｋｅｔで定義される。従って、バースト５９1におけるすべてのＭＰＥ／ＭＰＥ−ＦＥＣセクション４９1、４９2、４９3、４９4、５０1、５０2は、それぞれ異なることが考えられる。
【００６５】
ｄｅｌｔａ＿ｔによって示唆された時間は、実際のバーストの最大バースト期間の終了を越える。これによって、復号器が、一つのエレメンタリーストリームでの二つの連続したバーストを確実に区別することを補償することを助ける。
【００６６】
バースト５９1は、完全なＭＰＥ／ＭＰＥ−ＦＥＣセクション４９1、４９2、４９3、４９4、５０1、５０2を包含する。言い換えると、ＭＰＥ／ＭＰＥ−ＦＥＣセクション４９1、４９2、４９3、４９4、５０1、５０2は、バースト５４1の間では分割されない。バースト５４1は、完全なデータグラム４１1、４１2、４１3、４１4、４８1、４８2を包含する。言い換えると、データグラム４１1、４１2、４１3、４１4、４８1、４８2は、バースト５４1の間で寸断されない。ペイロードを伴わないＭＰＥセクションである空のＭＰＥセクションの送信は、好ましくは、避けられる。
【００６７】
好ましくは、（図には示されていない）ネットワークレイヤーのアドレスを含んだ適切なデータグラム４１1、４１2、４１3、４１4、４８1、４８2を搬送する、少なくとも一つのＭＰＥセクション４１1、４１2、４１3、４１4、４８1、４８2を、各バースト５９1は包含する。（図には示されていない）そのアドレスは、エレメンタリーストリームに関連付けられたＩＮＴ（ＩＰ／ＭＡＣ  Ｎｏｔｉｆｉｃａｔｉｏｎ  Ｔａｂｌｅ）のアドレスのうちの一つである。
【００６８】
もし、タイムスライシングが使用されないが、ＭＰＥ−ＦＥＣは使用される場合には、ｄｅｌｔａ＿ｔフィールドは、エレメンタリーストリームの中でサイクリック（ｃｙｃｌｉｃ）ＭＰＥ−ＦＥＣフレームインデックスをサポートする。ｄｅｌｔａ＿ｔフィールドの値は、各連続するＭＰＥ−ＦＥＣフレーム４２ごとに一ずつ増加する。値「１１１１１１１１１１１１」のあとは、このフィールドは、「００００００００００００」から再開する。もし、データの大きな部分が失われた場合は、このパラメーターは、受信されたセクションが、どのＭＰＥ−ＦＥＣフレームに帰属するのかを特定することを可能とする。
【００６９】
ｔａｂｌｅ＿ｂｏｕｎｄａｒｙフィールドは、フラグである。このフラグが「１」に設定されたときは、現在のセクションが、現在のＭＰＥ−ＦＥＣフレームにおける表の最後のセクションであることを示唆している。もし問題になっているセクションが、ＭＰＥセクション４９1、４９2、４９3、４９4であれば、そのフラグは、セクション４９1、４９2、４９3、４９4が、アプリケーションデータ表４４（図８）の最後のセクションであることを示している。ＭＰＥ−ＦＥＣをサポートしていない復号器は、すべての連続するセクションを、ｆｒａｍｅ＿ｂｏｕｎｄａｒｙフィールドを用いて示されるＭＰＥ−ＦＥＣフレーム４２の最後まで無視するかもしれない。ＲＳデータ４７が送信される、各ＭＰＥ−ＦＥＣフレーム４２のために、一つのＦＥＣセクション４８1が、このフラッグセットとともに送信される。もし、ＭＰＥ−ＦＥＣがエレメンタリーストリーム上でサポートされていなければ、このフラッグは、将来の使用のために予約される。使用されないときは、このフラッグは「０」に設定される。
【００７０】
ｆｒａｍｅ＿ｂｏｕｎｄａｒｙフィールド５８はフラグである。このフラグ５８が、「１」に設定されているときは、もし、タイムスライシングがサポートされていれば、現在のセクション５０yが、現在のバースト５４1における最後のセクションであることを示し、もし、ＭＰＥ−ＦＥＣがサポートされていれば、ＭＰＥ−ＦＥＣフレーム４２における最後のセクションであることを示している。各タイムスライスバースト５９1のために、一つのＭＰＥセクション４９1、４９2、４９3、４９4が、このフラッグセット５８とともに送信される。各ＭＰＥ−ＦＥＣフレーム４２のために、ひとつのＭＰＥ／ＭＰＥ−ＦＥＣセクション４９1、４９2、４９3、４９4、５０1、５０2が、このフラッグセット５８とともに送信される。
【００７１】
ａｄｄｒｅｓｓフィールドは、セクション内で搬送されるペイロードの第１番目のバイトのための、対応するＭＰＥ−ＦＥＣフレーム表４２の中のバイト位置を特定する。ＭＰＥ−ＦＥＣフレーム表４２のためのデータを配送するすべてのセクションが、このフィールドの値に従って昇順で配送される。このバイト位置は、ＭＰＥ−ＦＥＣフレームテーブル４２の中で、ゼロベースのリニアアドレスであり、このリニアアドレスは、第１番目の列の第１番目の行から開始し、列の最後に向けて増加する。列の最後の次のバイトポジションは、次の列の第１番目の行である。
【００７２】
所与のＭＰＥ−ＦＥＣフレームのデータを搬送する第１番目のセクションは、ａｄｄｒｅｓｓ「０」のアプリケーションデータグラムを搬送するＭＰＥセクションである。ＭＰＥ−ＦＥＣフレーム４２のＲＳデータを搬送する第１番目のセクションに先立って、所与のＭＰＥ−ＦＥＣフレーム４２のアプリケーションデータデータグラムを搬送するすべてのセクションが送信される。換言すると、アプリケーションデータデータグラムを搬送するセクション４９1、４９2、４９3、４９4は、単一のＭＰＥ−ＦＥＣフレーム４２の中でＲＳデータを搬送するセクション５０1、５０2とともにインターリーブされないということである。ＭＰＥ−ＦＥＣフレーム４２の第１と最後のセクションの間で搬送されるすべてのセクションは、ＭＰＥ−ＦＥＣフレーム４２に帰属するデータを搬送する。すなわち、アプリケーションデータ４４およびＲＳデータ４７のみが使用される。異なるＭＰＥ−ＦＥＣフレームのデータを配送するセクションは、インターリーブされない。
【００７３】
ＭＰＥ−ＦＥＣフレーム４２におけるアプリケーションデータデータグラムを搬送する最後のセクションに引き続くセクションは、同じＭＰＥ−ＦＥＣフレームのＲＳデータを搬送する第１番目のセクションか、もしくは、次のＭＰＥ−ＦＥＣフレームの第１番目のアプリケーションデータセクションを包含する。後者の場合、第１番目のＭＰＥ−ＦＥＣフレームのＲＳデータは送信されない。各ＭＰＥ−ＦＥＣフレーム４２のために、ａｄｄｒｅｓｓフィールドを「０」と設定して、一つのＭＰＥセクションが送信される。任意のＲＳデータが送信される各ＭＰＥ−ＦＥＣフレーム４２では、一つのＦＥＣセクションは、ａｄｄｒｅｓｓフィールドを「０」と設定して送信される。アプリケーションデータ表４４における配送されるアプリケーションデータにおいて、パディングは使用されない。アプリケーションデータ表においては、データグラムは重複しない。ＲＳ表４２における配送されるＲＳデータにおいては、パディングは使用されない。
【００７４】
各ＭＰＥ−ＦＥＣフレーム表の中で、アドレッシングはゼロから開始する。もし、タイムスライシングとＭＰＥ−ＦＥＣの両方が、エレメンタリーストリーム上で使用されれば、エレメンタリーストリーム上の各バーストは、きっちり一つのＭＰＥ−ＦＥＣフレーム４２を含む。換言すれば、ＭＰＥ−ＦＥＣフレーム４２は複数のバーストにまたがって、分割されることはない。
【００７５】
もし、ＭＰＥ−ＦＥＣがエレメンタリーストリーム上でサポートされていなければ、ａｄｄｒｅｓｓフィールドは将来の使用のために予約される。使用されていないときは、ａｄｄｒｅｓｓフィールドは０ｘ００に設定される。
【００７６】
多くの修正が上記実施例に為され得る事が理解されるであろう。例えば、固定受信デバイスを使用することが考えられる。
【００７７】
“ＭＰＥＧ−２プライベートセクションの準備と送信”
図１４および１５を参照すると、ＭＰＥエンカプスレーター８（図１）、または、その他の（図示されていない）ネットワーク要素が、いわゆる「プライベートセクション」を生成することができる方法が示される。プライベートセクションは、ＩＳＯ／ＩＥＣ１３８１８−１によって定義され、そして、ＭＰＥでもＭＰＥ−ＦＥＣデータグラムセクションでもない。ＩＳＯ／ＩＥＣ１３８１８−１によって定義されるプライベートセクションは単純にＭＰＥＧ−２プライベートセクションとしても参照され得る。
【００７８】
この例においては、ＥＭＭ（ｅｎｔｉｔｌｅｍｅｎｔ  ｍａｎａｇｅｍｅｎｔ  ｍｅｓｓａｇｅ）セクションの準備と送信が記載される。
【００７９】
ＭＰＥエンカプスレーター８は、コンディションアクセス（ＣＡ）データ６２1、６２2、６２3、６２4を含むＥＭＭメッセージを受信し（ステップＳ６）、それらをＣＡメッセージセクション６３1、６３2、６３3、６３4の中に配置する（ステップＳ７）。例えば、ＭＰＥＧ−２プライベートセクション構造を受けて、以下の表４に示されるシンタックスを利用した、ヨーロッパ電気通信規格研究所（ＥＴＳＩ）テクニカルレポート（ＥＴＲ）２８９に従って定義される。
【００８０】
【表４】
2006526350.tif 000006
【００８１】
ＣＡメッセージセクション６３1、６３2、６３3、６３4は、以下、ＥＭＭセクションと呼ぶ。
【００８２】
図１６を参照すると、ＭＰＥＧ−２プライベートセクション、この場合は、ＥＭＭセクション６３が示される。このセクション６３は、ヘッダ６４、ペイロード６５およびオプションとしてのトレーラー６６を含む。
【００８３】
ヘッダ６４はｔａｂｌｅ＿ｉｄフィールド６７およびｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈ６８を含む。例えば、ＥＭＭセクション６３のためには、ｔａｂｌｅ＿ｉｄ＝０ｘ８１（１６進数）とする。
【００８４】
図１７を参照すると、ＥＭＭセクション６３1、６３2、６３3、６３4は、ＴＳパケット７０1、７０2、７０3、７０4の中に配置される（ステップＳ８）。
【００８５】
図１８を参照すると、６３1、６３2、６３3、６３4は、（図には示されない）その他のエレメンタリーストリームと多重され得る、連続するエレメンタリーストリーム７０の中で送信される。
【００８６】
この場合、ＥＭＭセクション６３1、６３2、６３3、６３4は、タイミングよくバースト内で送信することはできない。なぜなら、タイムスライシングパラメーターが提供されないからである。タイムスライシングパラメーターをＥＭＭセクションに追加することは、現実的な解決方法ではない。標準規格によって固定されたＥＭＭセクションの構造の修正を必要とするためである。
【００８７】
ｄｅｌｔａ−ｔのようなタイムスライシングパラメーターなしに、受信デバイス５1、５2（図１）は、次のバーストが予期されるタイミングを知らない。したがって、受信デバイス５1、５2における受信器２２1（図４）は、通常は、いつも電源が入っており、ＥＭＭメッセージを失わないように補償することを助けている。
【００８８】
この問題はＥＭＭメッセージに限定されない。他の種類のデータが、ＭＰＥＧ−２プライベートセクションに基づいたセクションにおいて送信される。例えば、ＤＶＢ−ＳＩはＭＰＥＧ−２プライベートセクション構造の後に続くセクションにおいて搬送される表のセットを含む。特に、ネットワークインフォメーションテーブル（ＮＩＴ）は、ＥＴＳＩ  ＥＮ  ３００  ４６８で定義されるｎｅｔｗｏｒｋ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｓｅｃｔｉｏｎｓによって搬送される。それは、ＩＮＴを様様なネットワーク構成において配置するための信号送信メカニズムを定義する。ＩＮＴは、ＮＩＴの中に配置される一つかそれ以上のリンケージ（ｌｉｎｋａｇｅ）記述子、または、ＩＰ／ＭＡＣノーティフィケーションＢＡＴを経由してアクセスされる。ＩＰ／ＭＡＣノーティフィケーションＢＡＴ／ＮＩＴそれ自身は、ネットワーク上の一つかそれ以上のトランスポートストリーム上で使用可能であり、かつ、ＮＩＴの中のリンケージ記述子を通して方向の欠如した更なるレベルを経由して配置されることが可能であろう。非常に大きなネットワークにおいては、この最後の方式が、主に適用可能である。ＴＲ  １０１  １６２もまた参照される。
【００８９】
それにもかかわらず、バーストにおいて、ＭＰＥＧ−２プライベートセクションを送信すること、または、都合の良い方法でバーストの中でＭＰＥＧ−２プライベートセクションを送信することが望ましい。
【００９０】
“バーストにおけるＭＰＥＧ−２プライベートセクションの準備と送信”
図１９を参照すると、ＭＰＥエンカプスレーター８（図１）がバーストを生成するための方法が示される。
【００９１】
一つかそれ以上のＭＰＥまたはＭＰＥ−ＦＥＣセクション４９4、４９5、４９6は、ＭＰＥＧ−２プライベートセクション、この例においては、ＥＭＭセクションに基づいたその他のセクション６３5、６３6、６３7、６３8を搬送するエレメンタリーストリームに追加され、バースト７１1を生成する（ステップＳ９）。
【００９２】
バースト７１1は、少なくとも一つのＭＰＥまたはＭＰＥ−ＦＥＣセクション４９4、４９5、４９6を含み、かつ、バースト７１1の最後のセクションは、ＭＰＥまたはＭＰＥ−ＦＥＣセクション４９6を含む。
【００９３】
バースト７１1の最後において、ＭＰＥまたはＭＰＥ−ＦＥＣセクション４９6は、バースト７１1の最後であることを示すために使用される。これは、タイムスライシングパラメーターを使用する、特に、ｆｒａｍｅ＿ｂｏｕｎｄａｒｙフィールド５８（図１０）を使用することで特定される。
【００９４】
少なくとも一つかそれ以上のＭＰＥまたはＭＰＥ−ＦＥＣセクション４９4、４９5、４９6は、次のバースト７１2の開始を示すために使用される。これは、もう一方のタイムスライシングパラメーターを使用することで特定される。すなわちｄｅｌｔａ＿ｔフィールド５７（図１０）を使用する。もし、バースト７１1の最後において、ＭＰＥまたはＭＰＥ−ＦＥＣセクション４９6以外のその他のＭＰＥまたはＭＰＥ−ＦＥＣセクション４９4、４９5が提供されなかった場合、または、その他のＭＰＥまたはＭＰＥ−ＦＥＣセクション４９4、４９5は提供されたが、ｄｅｌｔａ−ｔの値が特定されなかった場合には、バースト７１1の最後におけるＭＰＥまたはＭＰＥ−ＦＥＣセクション４９6もまた、そのｄｅｌｔａ＿ｔフィールド５７（図１０）の中にｄｅｌｔａ−ｔ７４2（図２１）を含む。
【００９５】
したがって、バースト７１1の最後が定義されるだけでなく、次のバースト７１2が予期されるタイミングの指示が提供される（図２１）。
【００９６】
ＭＰＥ／ＭＰＥ−ＦＥＣセクション構造は、特に利点である。なぜなら、ｔａｂｌｅ＿ｉｄ５４、ｄｅｌｔａ＿ｔフィールド５７およびｆｒａｍｅ＿ｂｏｕｎｄａｒｙフィールド５８が固定されているからである。言い換えれば、セクションの始めとフィールド、例えば、ｄｅｌｔａ＿ｔフィールド５７の間のオフセットが、ＭＰＥ／ＭＰＥ−ＦＥＣセクションから次のセクションまで、同じであるということである。したがって、セクションがＭＰＥ／ＭＰＥ−ＦＥＣセクションであるかを決定し、もしそうであるならば、ｄｅｌｔａ−ｔの値を取り出し、かつ／または、ｆｒａｍｅ＿ｂｏｕｎｄａｒｙフラッグ５８を確認することを決定することは容易であると考えられる。
【００９７】
ＭＰＥまたはＭＰＥーＦＥＣセクション４９4、４９5、４９6は、単に、ヘッダ情報を含んでいるだけであり、したがって、４９4、４９5、４９6の残りは、スキップされることができる。
【００９８】
図２０を参照すると、セクション４９4、４９5、４９6、６３5、６３6、６３7、６３8は、ＩＳＯ／ＩＥＣ１３８１８−１に従って、ＴＳパケット７２1、７２2、７２3の中に配置される（ステップＳ１０）。それぞれが同じＰＩＤを有しており、したがって、それらが、どのエレメンタリーストリームに属しているのかを特定することができる。
【００９９】
図２１を参照すると、ＭＰＥ／ＭＰＥ−ＦＥＣセクションおよびｎｏｎ−ＭＰＥ／ＭＰＥ＿ＦＥＣセクションを含んだ複数のバースト７１1、７１2、７１3を示す。続いて発生するバースト７１2、７１3は前述した方法と同様に組み立てられる。しかし、ＭＰＥ／ＭＰＥ＿ＦＥＣセクションおよびｎｏｎ−ＭＰＥ／ＭＰＥ＿ＦＥＣセクションの数および順番は、一つのバーストと次のバーストの間で異なることが考えられる。
【０１００】
前述したように、ｄｅｌｔａ−ｔの値は、一つのセクションからもう一方のセクションで変化し得る。例えば、第１のＭＰＥセクション４９4は第１のｄｅｌｔａ−ｔ７３1の値を特定し、第２のＭＰＥセクション４９6は第２の異なる値をｄｅｌｔａ−ｔ７３2の値として特定する。
【０１０１】
“受信デバイス５1、５2の操作”
図４および２２を参照すると、受信デバイス５1、５2の操作方法が示される。
受信器２２1は、任意のエレメンタリーストリームに関連したバースト７３1、７３2、７３3を搬送する（図には示されない）トランスポートストリームについてリッスン（ｌｉｓｔｅｎ）し、セクション４９4、４９5、４９6、６３5、６３6、６３7、６３8を取り出す（ステップＳ１１）。受信器２２1は、セクション４９4、４９5、４９6、６３5、６３6、６３7、６３8の開始位置を特定する（ステップＳ１２）。受信器２２1は、ｔａｂｌｅ＿ｉｄフィールド５４、６７を調査し（ステップＳ１３）、かつ、ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールド５５、６８を調査する（ステップＳ１４）。受信器２２1は、セクション４９4、４９5、４９6、６３5、６３6、６３7、６３8の残りのバイトを読む（ステップＳ１５）。セクション４９4、４９5、４９6、６３5、６３6、６３7、６３8が、ＭＰＥ／ＭＰＥ−ＦＥＣセクション４９4、４９5、４９6であるか否かを決定するために、受信器２２1は、ｔａｂｌｅ＿ｉｄフィールド５４、６７を調査する。例えば、ｔａｂｌｅ＿ｉｄフィールド５４、６７における値が０ｘ７４（１６進数）であるか否か確認することが考えられる。
【０１０２】
もし、受信器２２1が、セクション４９4、４９5、４９6、６３5、６３6、６３7、６３8を、ＭＰＥ／ＭＰＥ−ＦＥＣセクション４９4、４９5、４９6として特定した場合、ｄｅｌｔａ＿ｔフィールド５７を読み、そのｄｅｌｔａ＿ｔの値を記憶する（ステップＳ１７）。
【０１０３】
受信器２２1は、ｆｒａｍｅ＿ｂｏｕｎｄａｒｙ５８をもまた読み（ステップＳ１８）、フラッグを検査し、ＭＰＥ／ＭＰＥ−ＦＥＣセクション４９4、４９5、４９6がバースト７１1の最後か否かを決定する（ステップＳ１９）。
【０１０４】
もし受信器２２1が、ＭＰＥ／ＭＰＥ−ＦＥＣセクション４９4、４９5、４９6がバースト７１1の最後であると決定したときは、記憶されたｄｅｌｔａ−ｔ７３2の値を使用して、現在のバースト７１1の最後から次のバースト７１2の最初までの“ｏｆｆ−ｔｉｍｅ”を決定する（ステップＳ２０）。
【０１０５】
それ以外の場合は、受信器２２1がそのセクションを処理し（ステップＳ２１）、バースト７１1における次のセクションを受信することを続ける（ステップＳ１）。
【０１０６】
この処理が、各７１1、７１2、７１3のために実行される。
【０１０７】
この方法で、受信器２２1は、バースト７１1を受信するためにスイッチを入れて動作し、次のバースト７１2の開始を特定するためにｄｅｌｔａ−ｔの情報を取り出し、現在のバーストの最後を特定するために、フレーム境界を取り出し、それによって、次のバースト７１2のまで、スイッチを切って動作を止め、そして、それを続けることができる。
【０１０８】
多くの修正が前記実施形態において行われ得ることが、認識されるであろう。例えば、ＭＰＥ／ＭＰＥ−ＦＥＣセクションが記載されているが、タイムスライシングパラメーターを含んだセクションのその他のタイプをＭＰＥ／ＭＰＥ−ＦＥＣの代わりに使用することが考えられる。二つより多くののセクションのタイプが一つのバーストに含まれることも考えられる。
【図面の簡単な説明】
【０１０９】
【図１】図１は、通信システムを示す。
【図２】図２は、トランスポートストリームパケットを出力するマルチプロトコルカプセル化（ＭＰＥ）エンカプスレーターを示す。
【図３】図３は、トランスポートストリームパケットを示す。
【図４】図４は、携帯電話端末の概略図である。
【図５】図５は、携帯電話端末の電池パックの概略図である。
【図６】図６は、受信器と図４に示された携帯電話端末に含まれるタイムスライシングバッファを示す。
【図７】図７は、図２に示されたＭＰＥエンカプスレーターにより実行される第１番目の処理の処理フローチャートである。
【図８】図８は、前進型誤信号訂正データを計算する処理を示す。
【図９】図９は、ＭＰＥデータグラムセクションに配置されるデータグラムを示す。
【図１０】図１０は、ＭＰＥデータグラムセクションを示す。
【図１１】図１１は、ＭＰＥセクションを含むバーストを示す。
【図１２】図１２は、トランスポートストリームパケットにおけるＭＰＥデータグラムセクションのカプセル化を示す。
【図１３】図１３は、ＭＰＥセクションを含む複数のバーストを示す。
【図１４】図１４は、ＭＰＥセクションではないセクション内に配置されるデータを示す。
【図１５】図１５は、図２に示されたＭＰＥエンカプスレーターによって実行される第二の処理の処理フローチャートである。
【図１６】図１６は、ｎｏｎ−ＭＰＥデータグラムセクションを示す。
【図１７】図１７は、トランスポートストリームパケットにおけるｎｏｎ−ＭＰＥデータグラムセクションのカプセル化を示す。
【図１８】図１８は、ｎｏｎ−ＭＰＥセクションの送信を示す。
【図１９】図１９は、ＭＰＥセクションとｎｏｎ−ＭＰＥセクションを含んだバーストの組み立てを示す。
【図２０】図２０は、トランスポートストリームパケットにおけるＭＰＥセクションとｎｏｎ−ＭＰＥセクションのカプセル化を示す。
【図２１】図２１は、ｎｏｎ−ＭＰＥセクションを含んだ複数のバーストを示す。
【図２２】図２２は、図４に示した携帯電話端末によって実行される処理の処理フローチャートである。
【図１】
2006526350.tif 000007
【図２】
2006526350.tif 000008
【図３】
2006526350.tif 000009
【図４】
2006526350.tif 000010
【図５】
2006526350.tif 000011
【図６】
2006526350.tif 000012
【図７】
2006526350.tif 000013
【図８】
2006526350.tif 000014
【図９】
2006526350.tif 000015
【図１０】
2006526350.tif 000016
【図１１】
2006526350.tif 000017
【図１２】
2006526350.tif 000018
【図１３】
2006526350.tif 000019
【図１４】
2006526350.tif 000020
【図１５】
2006526350.tif 000021
【図１６】
2006526350.tif 000022
【図１７】
2006526350.tif 000023
【図１８】
2006526350.tif 000024
【図１９】
2006526350.tif 000025
【図２０】
2006526350.tif 000026
【図２１】
2006526350.tif 000027
【図２２】
2006526350.tif 000028
【国際調査報告】
2006526350.tif 000029
2006526350.tif 000030
2006526350.tif 000031
2006526350.tif 000032
2006526350.tif 000033