(57)【特許請求の範囲】
【請求項１】
データをストリーミングするための通信システムであって、前記データの全てが受信または送信される前に、受信機がストリーミングされたデータの使用を開始できるように、前記データは、送信機から前記受信機までストリーミングされ、前記送信機は、
前記送信されるデータを、可変オーバーヘッドを有する前方誤り訂正（ＦＥＣ）符号化し、それにより、
送信されるストリームにはデータとＦＥＣ情報とが含まれ、
前記データは、前記受信機での消費速度よりも高い送信速度を使用して送信され、
前記送信速度は、最大送信速度以下であり、ソース送信速度とリペア送信速度との合計に等しくなる、ロジック
を含み、ここで、ストリーミングすることは、少なくとも第１の保護期間と前記第１の保護期間の後に続く第２の保護期間とを含む、複数のＦＥＣソースブロック保護期間にわたって実行され、各保護期間は、ソース送信速度とリペア送信速度とを有し、ここで、ＦＥＣ保護のために使用されるオーバーヘッドの量とバッファを満たすために使用されるオーバーヘッドの量は、前記第１の保護期間におけるソース送信速度が前記第２の保護期間におけるソース送信速度よりも高く、前記第１の保護期間におけるリペア送信速度が前記第２の保護期間におけるリペア送信速度未満であるように、前記複数のＦＥＣソースブロック保護期間にわたって変更され、ここで、前記ソース送信速度と前記リペア送信速度とを変更するタイミングは、前記受信機での最小バッファリング時間に基づいている、通信システム。
【請求項２】
前記送信速度は、ストリーミング送信の時間のあいだ一定である、請求項１に記載の送信機。
【請求項３】
通信システムにおいてデータをストリーミングするための方法であって、前記データの全てが受信または送信される前に、受信機がストリーミングされたデータの使用を開始できるように、前記データは、前記データを伝達する電気信号を送信する送信機から、前記データのうちのいくらかを伝達し得る電気信号を受信する前記受信機まで、ストリーミングされ、前記方法は、
前記送信されるデータを、可変オーバーヘッドを有する前方誤り訂正（ＦＥＣ）符号化することと、
データとＦＥＣ情報とが含まれるストリームを送信することと
を含み、それにより、
前記データは、前記受信機での消費速度よりも高い送信速度を使用して送信され、
前記送信速度は、最大送信速度以下であり、ソース送信速度とリペア送信速度との合計に等しくなり、
ここで、前記ストリーミングすることは、少なくとも第１の保護期間と前記第１の保護期間の後に続く第２の保護期間とを含む、複数のＦＥＣソースブロック保護期間にわたって実行され、各保護期間は、ソース送信速度とリペア送信速度とを有し、ここで、ＦＥＣ保護のために使用されるオーバーヘッドの量とバッファを満たすために使用されるオーバーヘッドの量は、前記第１の保護期間におけるソース送信速度が前記第２の保護期間におけるソース送信速度よりも高く、前記第１の保護期間におけるリペア送信速度が前記第２の保護期間におけるリペア送信速度未満であるように、前記複数のＦＥＣソースブロック保護期間にわたって変更され、ここで、前記ソース送信速度と前記リペア送信速度とを変更するタイミングは、前記受信機での最小バッファリング時間に基づいている、方法。
【請求項４】
前記ストリームを送信することは、ストリーミング送信の時間のあいだ一定の送信速度を使用して送信することを含む、請求項３に記載の方法。
【請求項５】
記憶された命令を電子機器に供給するためのインターフェースを有するコンピュータ可読記憶媒体であって、前記電子機器は、通信システムにおいてデータのストリーミングを実現するために、前記供給された命令を実行し、前記データの全てが受信または送信される前に、受信機がストリーミングされたデータの使用を開始できるように、前記データは、送信機から前記受信機までストリーミングされ、前記コンピュータ可読記憶媒体は、
前記送信されるデータを、可変オーバーヘッドを有する前方誤り訂正（ＦＥＣ）符号化し、それにより、
送信されるストリームにはデータとＦＥＣ情報とが含まれ、
前記データは、前記受信機での消費速度よりも高い送信速度で送信され、
前記送信速度は、最大送信速度以下であり、ソース送信速度とリペア送信速度との合計に等しくなる、プログラムコード
を含み、ここで、前記ストリーミングすることは、少なくとも第１の保護期間と前記第１の保護期間の後に続く第２の保護期間とを含む、複数のＦＥＣソースブロック保護期間にわたって実行され、各保護期間は、ソース送信速度とリペア送信速度とを有し、ここで、ＦＥＣ保護のために使用されるオーバーヘッドの量とバッファを満たすために使用されるオーバーヘッドの量は、前記第１の保護期間におけるソース送信速度が前記第２の保護期間におけるソース送信速度よりも高く、前記第１の保護期間におけるリペア送信速度が前記第２の保護期間におけるリペア送信速度未満であるように、前記複数のＦＥＣソースブロック保護期間にわたって変更され、ここで、前記ソース送信速度と前記リペア送信速度とを変更するタイミングは、前記受信機での最小バッファリング時間に基づいている、コンピュータ可読記憶媒体。
【請求項６】
前記送信速度は、ストリーミング送信の時間のあいだ一定である、請求項５に記載のコンピュータ可読記憶媒体。
【請求項７】
データをストリーミングするための通信システムであって、前記データの全てが受信または送信される前に、受信機がストリーミングされたデータの使用を開始できるように、前記データは、送信機から前記受信機までストリーミングされ、前記送信機は、
前記送信されるデータを、可変オーバーヘッドを有する前方誤り訂正（ＦＥＣ）符号化するための手段と、
データとＦＥＣ情報とが含まれるストリームを送信するための手段と
を含み、それにより、
前記データは、前記受信機での消費速度よりも高い送信速度を使用して送信され、
前記送信速度は、最大送信速度以下であり、ソース送信速度とリペア送信速度との合計に等しくなり、
ここで、前記ストリーミングすることは、少なくとも第１の保護期間と前記第１の保護期間の後に続く第２の保護期間とを含む、複数のＦＥＣソースブロック保護期間にわたって実行され、各保護期間は、ソース送信速度とリペア送信速度とを有し、ここで、ＦＥＣ保護のために使用されるオーバーヘッドの量とバッファを満たすために使用されるオーバーヘッドの量は、前記第１の保護期間におけるソース送信速度が前記第２の保護期間におけるソース送信速度よりも高く、前記第１の保護期間におけるリペア送信速度が前記第２の保護期間におけるリペア送信速度未満であるように、前記複数のＦＥＣソースブロック保護期間にわたって変更され、ここで、前記ソース送信速度と前記リペア送信速度とを変更するタイミングは、前記受信機での最小バッファリング時間に基づいている、通信システム。
【請求項８】
前記送信速度は、ストリーミング送信の時間のあいだ一定である、請求項７に記載の送信機。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信システムにおけるデータの符号化及び復号化に関し、より詳細には、受信されたデータを素早く提供するという受信機のニーズを取り扱いつつ、通信データにおける誤りや切れ目を考慮したデータの符号化及び復号化に関するものである。
【背景技術】
【０００２】
本願は２００６年２月１３日出願の米国仮特許出願番号６０／７７３，１８５および２００６年２月１４日出願の米国仮特許出願番号６０／７７３，５０１の優先権を主張する非仮出願である。
【０００３】
以下の参考文献を本願明細書に引用し、すべての目的のために参照により組み込む。
【０００４】
ルビー（Luby）に対して発行された、”Information Additive Code Generator and Decoder for Communication Systems”というタイトルの米国特許第６，３０７，４８７号（以下、”ルビー”）。
【０００５】
ショクロラヒ（Shokrollahi）他に対して発行された、”Multi-Stage Code Generator and Decoder for Communication Systems”というタイトルの米国特許第７，０６８，７２９号（以下、”ショクロラヒ”）。
【０００６】
送り手と受け手との間で通信チャネルを介して行うファイルおよびストリームの転送は多くの文献の主題として取り上げられてきた。好ましくは、受け手は、送り手からチャネルを介して送信される正確なデータのコピーをあるレベルの確実性をもって受信することを望む。チャネルは完全な忠実度を有していない（物理的に実現可能な多くのシステムがそうである）ため、転送により消失するか歪められるデータを取り扱う方法に関心が生じる。受け手は、いつ破損データが誤ってデータ受信されたかの判断を常に行えるとは限らないので、通常、破損データ（誤り）に比較し欠落データ（消去）を取扱うのは容易である。多くの誤り訂正符号は、消去および／または誤りを訂正するために開発されてきた。
【０００７】
送信機および受信機が通信のために必要とされる演算能力および電力の全てを利用し、送受信装置間のチャネルが相対的にエラーフリーの通信を可能とするのに十分クリーンであるときに、データ転送は直接的に行なわれる。そして、チャネル環境が悪いか、または、送信機および／または受信機の能力が制限されている場合に、データ転送の問題は難しくなる。
【０００８】
１つのソリューションは、受信機が転送における消去および誤りを回復可能となるように、データを送信機で符号化する前方誤り訂正（ＦＥＣ）技術を活用する方法である。受信機から送信機へのリバースチャネルが利用可能な場合、受信機が送信機に誤りについての通信が可能であり、伝送プロセスを調整可能である。しかし、しばしばリバースチャネルは利用可能ではない。たとえば、送信機が多数の受信機に対して送信している場合、送信機はそれらの全ての受信機からのリバースチャネルを取り扱うことが不可能であり得る。その結果、通信プロトコルはしばしばリバースチャネルなしで設計されることを必要とし、そして、送信機はこれらのチャネル状況の全容無しに広く様々なチャネル状況を取扱わなければならないかもしれない。
【０００９】
パケット損失が発生し得るチャネルを介したデータ転送のために使用されるパケットプロトコルの場合、パケット網を通じて送信されるファイル、ストリームまたは他のデータブロックは、均等なサイズの入力シンボルに区切られ、入力シンボルと同一のサイズの符号化シンボルがＦＥＣ符号を使用して入力シンボルから生成され、符号化シンボルはパケットに配置され送信される。入力シンボルが実際にビットストリームに分解されるか否かに関わらず、入力シンボルの”サイズ”はビット単位で計測することができ、入力シンボルが２Ｍ個のシンボルのアルファベットから選択される場合、入力シンボルはＭビットのサイズを有する。この種のパケットベースの通信システムにおいて、パケットに基づいた消去ＦＥＣ符号化方法が適切である。ネットワーク内で消去が発生したにもかかわらず指定された受け手がオリジナルファイルの正確なコピーを回復可能な場合、高信頼なファイル転送と呼ぶことが出来る。ネットワーク内で消去が発生したにもかかわらず指定された受け手がタイムリーな方法でストリーム各部の正確なコピーを回復可能な場合、高信頼なストリーム転送と呼ぶことが出来る。また、ファイルまたはストリームの一部が回復可能でない、または、ストリーミングにおいてストリームの一部がただちに回復可能ではないという意味では、ファイル転送およびストリーム転送の双方についていくらかの信頼性があり得る。パケット損失は、しばしば、散発的な輻輳の発生によりルータのバッファリングメカニズムが処理限界に達し入力パケットが強制的にドロップされることにより生じる。そのため、転送中の消去発生に対する保護が多くの研究の主題とされてきた。
【００１０】
ビットを損なう可能性がある雑音の多いチャネルを介したデータ伝送のために使用されるプロトコルの場合、データ伝送チャネルを介して送信されるべきデータのブロックが同じサイズの入力シンボルに分割され、同じサイズの符号化シンボルが入力シンボルから生成され、符号化シンボルがチャネルを介して送信される。そのような雑音の多いチャネルに関して、シンボルのサイズは、シンボルが実際にビットストリームに分けられるか否かにかかわらず、概して１ビットか、または数ビットである。そのような通信システムにおいて、ビットストリーム指向の誤り訂正ＦＥＣコーディングスキームが好適である可能性がある。データ伝送が対象の受け手がエラー（チャネルにおいて検出されるか、または検出されないかのいずれかであるシンボルの破損）にもかかわらず元のブロックの正確なコピーを回復することを可能にする場合、そのデータ伝送は高信頼と呼ばれる。伝送は、回復後もブロックの一部が破損したままである可能性があるという意味でいくらかの信頼性がある可能性もある。シンボルは、散発的な雑音、周期的な雑音、干渉、微弱な信号、チャネルの遮断、および様々なその他の原因で破損されることが多い。
【００１１】
一部のＦＥＣ符号に関する１つの問題は、それらのＦＥＣ符号が、動作するために過大な計算能力またはメモリを必要とすることである。別の問題は、出力シンボル数が符号化プロセスの前に決定されなければならないことである。このことは、パケットの損失率が過大に見積もられる場合は非効率になる可能性があり、パケットの損失率が過小に見積もられる場合は障害につながる可能性がある。
【００１２】
連鎖反応符号は、ファイルまたはストリームの決まった入力シンボルからの任意の数の出力シンボルの生成を可能にするＦＥＣ符号である。この符号は、事前の決まった送信速度を持たず、あり得る出力シンボル数が入力シンボル数に依存しない可能性があるのでファウンテンＦＥＣ符号またはレートレス（rateless）ＦＥＣ符号と呼ばれることもある。連鎖反応符号を生成、使用、および操作するための新規の技術が、例えば、ルビーおよびショクロラヒにおいて示されている。
【００１３】
ショクロラヒに記載され、商標名”Ｒａｐｔｏｒ”符号としてデジタルファウンテン社（Digital Fountain, Inc.）によって開発されたマルチステージ連鎖反応（”ＭＳＣＲ”）符号などのＭＳＣＲ符号を使用することも知られている。マルチステージ連鎖反応符号は、例えば、ソースファイルまたはソースストリームから入力シンボルを受信し、入力シンボルから中間シンボルを生成する符号化器において使用され、中間シンボルは連鎖反応符号化器に対するソースシンボルである。
【００１４】
一部の応用に関して、その他のバリエーションの符号がより好適であるか、またはそうでなければ好ましい可能性がある。本明細書において使用される入力シンボルは、ファイルまたはストリームから受信されたデータを指し、ソースシンボルは、出力シンボルを生成するために使用されるシンボルを指す。場合によってはソースシンボルは入力シンボルを含み、場合によってはソースシンボルは入力シンボルである。しかし、入力シンボルがシンボルの中間的な集合に符号化および／または変換され、その中間的な集合が、入力シンボルを（直接）参照せずに出力シンボルを生成するために使用される場合がある。したがって、入力シンボルは、受信機に伝達されるべき送信機に知られている情報を含み、ソースシンボルは、符号化器の少なくとも１つ段階によって使用されるシンボルであり、入力シンボルから導出され、出力シンボルは、送信機によって受信機に送信されるシンボルを含む。
【００１５】
一部の応用において、受信機は、伝送が完了する前にデータを使用し始めることができる。例えば、ビデオオンデマンドシステムを用いる場合、受信機は、ビデオデータのほんのわずかな部分が受信された後にビデオを再生し始め、ビデオデータの残りはそれが必要とされる前に受信されると仮定する可能性がある。そのようなシステムにおいて、符号化は伝送全体にわたって行われてはならず、その理由は、その場合、伝送の終了時の一部の出力シンボルが、ビデオの開始時に必要とされる入力シンボルを符号化する可能性があり、その場合、それらの出力シンボルが、それらの情報が利用可能でないときにそれらの情報が必要とされ、それらの情報が利用可能なときにそれらの情報が必要とされないので無駄であるからである。これを避けるために、概して、データストリームはブロックに分割され、ブロックの入力データは次のブロックが準備される前に符号化および送信され、通常、ブロックはそれらのブロックの外の入力シンボルに依存しない。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
そのような応用に関して、信頼性と、伝送が始まるときとデータが使用され始めることができるときとの間のタイムラグとの間のトレードオフが存在することが多い。例えば、伝送の開始時のエラーが伝送の終了時のデータを使用して訂正されることができるように長編映画全体が符号化されるとすると、受信機は、その受信機が映画が再生可能であることをアプリケーション（またはアプリケーションのユーザ）に示す前に映画データの全てを受信するまで待つ可能性がある。しかし、総伝送時間が長い場合、それは、受け入れられないタイムラグである可能性がある。
【００１７】
１つのソリューションは、受信機が、何らかの少ないタイムラグの後で映画の再生を開始するために十分な情報を有し、受信機が、再生を続けるためにさらなる情報を間に合うように受信することを期待することができるようにデータのストリームを符号化することである。当然、伝送の最後に近いデータが伝送の開始時のデータに対する冗長性を提供する場合、その能力は、映画の最初の部分が、その後の情報が受信されるよりもはるかに前に再生されてしまっているので無駄である。したがって、概して、データの復号化に時間的に近い、冗長性が必要とされるときに利用可能な冗長性を有することが効率的である。しかし、制約が厳しすぎる場合、再生は、あまりにも速く始まらなければならない可能性があり、受信機が、その受信機がまだ復号化のための十分なデータを持たず、スキップまたは一時停止を引き起こす映画の再生点に達する確率を高める可能性がある。
【００１８】
ブロックを使用する場合、トレードオフが存在し、すなわち、小さすぎるブロックサイズおよび不十分な誤り保護が提供される一方、受信機がブロックが完全に回復されるのを待つので、大きすぎるブロックサイズおよび長すぎる遅延が受信機において見られる。
【課題を解決するための手段】
【００１９】
本発明の実施形態において、データが送信機から受信機にストリーミングされ、ここで、ストリーミングは、データが全て送信および受信される前にそのデータを使用して受信機が始動すると仮定してデータを転送することである。ストリーミングされるデータは前方誤り訂正（”ＦＥＣ”）を含み、データ消費の速度は変わることができる。送信機は、その送信機がその送信機の入力データを使い切る入力速度と、その送信機がそのデータ（および必要に応じてＦＥＣデータ）を送信する送信速度とを有し、これら２つの速度は、ＦＥＣの符号化に関連する何らかのオーバヘッドが存在するので、ＦＥＣが含まれるときは異なることができ、変わることができる。受信機において、（受信機がデータを受信する）受信速度と、（受信機がその受信機の出力のためにデータを使い切る）消費速度とが存在する。送信機は消費速度よりも高い送信速度を使用して送信し、追加の帯域幅がＦＥＣ保護およびバッファリングのために使用可能である。
【００２０】
一部の実施形態において、超過速度は、伝送期間にわたって変化する。
【００２１】
本明細書において開示される発明の性質および利点のさらなる理解が、本明細書の残りの部分および添付の図面を参照することによって得られることができる。
【発明を実施するための最良の形態】
【００２２】
本発明の実施形態において、データが送信機から受信機にストリーミングされ、ここで、ストリーミングは、データが全て送信および受信される前にそのデータを使用して受信機が始動すると仮定してデータを転送することである。ストリーミングされるデータは、パケット損失が検出される場合に、失われたパケットの再送が受信機によって要求される再送要求スキームを改善する前方誤り訂正（”ＦＥＣ”）を含む。
【００２３】
ストリーミングプロセスに関わる様々な速度が存在する。ストリーミングされるデータは前方誤り訂正（”ＦＥＣ”）を含み、データ消費の速度は変わることができる。送信機は、その送信機がその送信機の入力データを使い切る入力速度と、その送信機がそのデータ（および必要に応じてＦＥＣデータ）を送信する送信速度とを有し、これら２つの速度は、ＦＥＣの符号化に関連する何らかのオーバヘッドが存在するので、ＦＥＣが含まれるときは異なり得、変化し得る。受信機において、（受信機がデータを受信する）受信速度と、（受信機がその受信機の出力のためにデータを使い切る）消費速度とが存在する。チャネル上でデータ損失がない場合、受信速度は送信速度と同じである。ＦＥＣによるオーバヘッドを考慮しない、データが受信される速度である生(raw)の受信速度が存在する。例えば、受信機が１１メガビット／秒（ＭＢＳ）のビデオストリームをディスプレイデバイスに出力するビデオプレーヤである場合、消費速度は１１ＭＢＳである。消費されるデータがディスプレイ、オーディオ、プロセッサ、またはデータのその他のプレーヤ上で再生される場合、消費速度は、”再生”速度と呼ばれる可能性がある。
【００２４】
多くのストリームを用いる場合、消費は、ストリームされたデータの表示が止められないか、またはむらがないように継続的であることが望ましく、そのストリームされたデータの表示の停止またはむらは、受信機における全てのデータが消費され、受信速度が消費速度よりも低い場合に起こる。これを避けるために、概して、受信機はバッファを有し、したがって、受信速度は、消費するデータを使い果たすことなしに（パケット損失、混雑などによって）消費速度未満に一時的に落ちることができる。
【００２５】
受信速度が正に消費速度である場合、バッファされるべき余分な部分はない。受信機のバッファを満たすために、ストリーミングシステムは、送信速度が消費速度よりも高いか、または再生が始まる前に伝送が始まるように設定される可能性がある。どちらの場合も、少なくとも部分的に受信機のバッファを満たすのに十分な受信が存在する。
【００２６】
いずれの場合も、再送よりもＦＥＣを使用することがより優れたアプローチであることが多い。再送を用いる場合、受信機が再送要求を送信し、応答を受信する間にデータを再生し続けるために十分な受信機のバッファが存在する必要があり、そうでなければ、プレーヤは、そのプレーヤが、これから置き換えられなければならない欠落データに達するときに停止することになる。
【００２７】
特定の実施形態において、送信機は、消費速度よりも高い送信速度を使用して送信し、追加の帯域幅は、ＦＥＣ保護のために一部が使用され、再生を停止するリスクを削減するために十分なバッファを満たした状態で受信が始まった直後に再生が始まることができる”クイックスタート”などの機能を可能にするためにバッファを満たすために一部が使用される。
【００２８】
一部の実施形態において、ＦＥＣ保護のために使用される帯域幅と、バッファを満たすために使用されるオーバヘッドの量とは、時間の経過と共に変わる。例えば、送信ビットレート全体は消費速度よりも幾分高い一定値である可能性があり、伝送の開始時には超過のうちのより多くがバッファを満たすことに充てられ、後の時間においては超過のうちのより少ない部分がバッファを満たすことに充てられる。一定のビットレートを用いる場合、ＦＥＣ保護は、伝送の開始時にはより弱く、後の時間においてはより強い。一定のビットレートは要求されず、一定のＦＥＣオーバヘッドレートが使用される可能性がある。
【００２９】
＜概要＞
ＤＦ  Ｒａｐｔｏｒ（商標）符号化器および復号化器によって使用されるマルチステージ連鎖反応（ＭＳＣＲ）符号などのＭＳＣＲ符号を使用するストリーミングメディアのＦＥＣ保護のためのプロトコルが、ＤＶＢ−ＩＰＩアプリケーションを含むアプリケーションに関して以下で説明される。そのようなマルチステージ符号の例は、ショクロラヒに記載されている。本開示の目的のために、ＭＳＣＲ符号は、マルチステージ符号の単なる例として使用され、本開示の技術はショクロラヒに記載されているマルチステージ符号以外のマルチステージ符号と共に使用される可能性があることを理解されたい。
【００３０】
マルチステージ符号は、ＤＶＢ−ＩＰＩリアルタイムアプリケーション（ＭＰＥＧ−２トランスポートストリームカプセル化、ならびにＲＴＰ上のオーディオおよびビデオの直接転送の両方によるマルチキャストおよびユニキャストビデオ）のＦＥＣ保護のために使用される可能性がある。
【００３１】
ＩＥＴＦ高信頼マルチキャストワーキンググループによって定義されたＦＥＣビルディングブロック［３］は、ＦＥＣ符号自体の仕様からプロトコルの定義を分離する、ＦＥＣを使用するプロトコルの仕様に対するアプローチを記載する。これは、プロトコル設計の問題が、大きく異なるＦＥＣ符号の選択の問題と独立して対処されることを可能にする。ＦＥＣビルディングブロックの言葉では、別個の仕様が、”コンテンツ配信プロトコル”のために、および”ＦＥＣスキーム”のために提供され、前者はプロトコルを定義し、後者は実際のＦＥＣ符号を定義する。ＦＥＣビルディングブロックは、両方の種類の仕様が、それらの仕様が一緒に使用されることができるように従わなければならない規則を記載し、したがって、ＦＥＣビルディングブロックは、コンテンツ配信プロトコルとＦＥＣスキームとの間の”接着剤”を提供する。
【００３２】
このアプローチに従って、この仕様は、いくつかのモジュラコンポーネントとして編成される。そのとき、これらは、ＤＶＢ−ＩＰＩアプリケーションに好適な完全なプロトコルを形成するために組み合わされる。これらのコンポーネントは、（１）ＦＥＣをメディアストリームに適用するためのプロトコルフレームワーク全体を提供し、セクション２に記載されるＦＥＣストリーミングフレームワークと、（２）様々な部類のアプリケーションに好適なプロトコルコンポーネントを定義し、コアＭＳＣＲ符号がどのようにストリーミングアプリケーションに適用されるかを定義する、セクション３に定義されるいくつかのＦＥＣスキームと、（３）セクション４に示される、本明細書において定義されるＦＥＣストリーミングフレームワークおよびＦＥＣスキームに基づいてアプリケーションをサポートするために使用されることができるモジュラプロトコルコンポーネントと、（４）上記のビルディングブロックを使用して構築される、ＭＰＥＧ−２トランスポートストリームカプセル化、ならびにＲＴＰ上のオーディオおよびビデオの直接転送の両方によるマルチキャストおよびユニキャストビデオのためのプロトコルの仕様（セクション５）と、を含む。
【００３３】
＜用語および略語＞
0005550834.tif 000002
0005550834.tif 000003
【００３４】
＜符号化器および復号化器＞
図１は、マルチステージ符号化を使用し、本明細書で説明する可変ＦＥＣオーバヘッド技術を使用可能な通信システム１００のブロック図である。
【００３５】
通信システム１００において、入力ファイル１０１または入力ストリーム１０５は、入力シンボル生成器１１０に提供される。入力シンボル生成器１１０は入力されたファイルまたはストリームから１個以上の一連の入力シンボル（ＩＳ（０），ＩＳ（１），ＩＳ（２），．．．）を生成し、各入力シンボルは値および位置（図１の括弧内整数として示す）を有する。上述したように、入力シンボルの可能な値（すなわちアルファベット）は一般的に２Ｍ個のシンボルからなるアルファベットであり、各々の入力シンボルは入力ファイルのＭビットを符号化する。通常、Ｍの値は使用する通信システム１００により決定されるが、Ｍは用途により多様であるため汎用システムでは入力シンボル生成器１１０のためのシンボルサイズ入力を含むかもしれない。入力シンボル生成器１１０の出力は、符号化器１１５に提供される。
【００３６】
スタティックキー生成器１３０は、スタティックキーＳ０，Ｓ１．．．のストリームを生成する。通常、生成されるスタティックキーの数は制限されており特定実施形態の符号化器１１５に依存する。スタティックキーの生成は、以降で更に詳細に説明する。ダイナミックキー生成器１２０は、符号化器１１５により生成される各々の出力シンボルに対するダイナミックキーを生成する。各々のダイナミックキーは、同一の入力ファイルのダイナミックキーの大部分が一意（ユニーク）となるように生成される。たとえば、利用可能なキー生成器の実施形態がルビーＩに記載されている。ダイナミックキー生成器１２０およびスタティックキー生成器１３０の出力は、符号化器１１５に提供される。
【００３７】
ダイナミックキー生成器１２０によって提供された各々のキーＩから、符号化器１１５は、入力シンボル生成器により提供される入力シンボルから値Ｂ（Ｉ）の出力シンボルを生成する。符号化器１１５の動作については以下で更に詳細に説明する。各々の出力シンボルの値は、対応するキー、１個以上の入力シンボルの何らかの関数、おそらく入力シンボルから計算される冗長シンボルに基づいて生成される。ある特定の出力シンボルの源である入力シンボルおよび冗長シンボルの集合を、出力シンボルの”関連シンボル”または単にその”付随物（associates）”と呼ぶ。関数（”値関数”）および付随物の選択については、以降で更に詳細に記載されている処理に従って行われる。常にではないが、一般的にはＭは、入力シンボルおよび出力シンボルに対して同一である、すなわち、それら双方は同一ビット数に符号化する。
【００３８】
いくつかの実施形態では、符号化器１１５は付随物を選択するために入力シンボル数Ｋを使用する。入力がストリーミングファイルである場合のようにＫが前もって分からない場合には、Ｋは単に推定値であってもよい。また、値Ｋは、符号化器１１５により生成される入力シンボルおよび任意の中間シンボルの格納割り当てに、符号化器１１５により使用されるかもしれない。
【００３９】
符号化器１１５は送信モジュール１４０に出力シンボルを提供する。また、送信モジュール１４０にはダイナミックキー生成器１２０から各々の出力シンボルのキーが提供される。送信モジュール１４０は出力シンボルを送信し、送信モジュール１４０は送信された出力シンボルのキーに関する何らかのデータを使用するキーイング方法に従いチャネル１４５を介して受信モジュール１５０に送信するかもしれない。チャネル１４５は消去チャネルであるとみなされるが、それは通信システム１００が適切に動作するための必要条件ではない。送信モジュール１４０がチャネル１４５に出力シンボルおよび対応するキーに関する必要データを送信するのに適合し、受信モジュール１５０がチャネル１４５からシンボルおよび対応するキーに関する何らかのデータを受信するのに適合してさえいれば、モジュール１４０、１４５および１５０は、適切なハードウェア構成要素、ソフトウェア構成要素、物理媒体またはそのいかなる組合せによっても実現可能である。Ｋの値は、付随物を決定するために用いられる場合、チャネル１４５を介して送信されるか、または、事前に符号化器１１５および復号化器１５５に対して予めセットしておいてもよい。
【００４０】
上述したように、チャネル１４５はリアルタイムチャネル（例えば、インターネット、テレビ送信機からテレビ受信機への放送リンク、あるポイントから他のポイントへの電話接続）で有り得る他、チャネル１４５は格納チャネル（例えば、ＣＤ−ＲＯＭ、ディスク装置、ウェブサイト等）でも有り得る。さらに、チャネル１４５はリアルタイムチャネルおよび格納チャネルの組合せでも有り得、例えば、ある人がパソコンから電話回線を介してインターネットサービスプロバイダ（ＩＳＰ）まで入力ファイルを送信する際に形成されるチャネルのように、入力ファイルはウェブサーバに格納され、続いてインターネットを介して受け側に転送され得る。
【００４１】
チャネル１４５が消去チャネルであると仮定されるので、システム１００において、受信モジュール１５０から出力される出力シンボルと送信モジュール１４０に入力される出力シンボルとは１対１の対応があると仮定することは出来ない。実際、チャネル１４５がパケット網を含む場合、２個以上のパケットの相対的順序がチャネル１４５を通過中に保存されることを仮定することさえ出来ないかもしれない。従って、出力シンボルのキーは上述の１以上のキーイング方法を利用して決定され、必ずしも受信モジュール１５０から出力される出力シンボルの順序で決定されるというわけではない。
【００４２】
受信モジュール１５０は復号化器１５５に出力シンボルを提供し、受信モジュール１５０が受信するこれらの出力シンボルのキーに関する任意のデータはダイナミックキー再生器１６０に提供される。ダイナミックキー再生器１６０は、受信された出力シンボルのダイナミックキーを再生し、復号化器１５５にダイナミックキーを提供する。スタティックキー生成器１６３は、スタティックキーＳ０，Ｓ１．．．を再生し、復号化器１５５に提供する。スタティックキー生成器は、符号化および復号化プロセスの双方で使用する乱数発生器１３５にアクセスする。これは、この種のデバイスにより乱数が生成される場合、同一物理装置へのアクセスの形式でもよいし、同一の挙動となるように同一の乱数生成アルゴリズムへのアクセスの形式でもよい。復号化器１５５は、ダイナミックキー再生器１６０およびスタティックキー生成器１６３により提供される出力シンボルに対応するキーを使用し、入力シンボル（ＩＳ（０），ＩＳ（１），ＩＳ（２），．．．）を回復する。復号化器１５５は、入力ファイル１０１または入力ストリーム１０５のコピー１７０を生成する入力ファイル再構築器１６５に回復した入力シンボルを提供する。
【００４３】
符号化器１１５は、本明細書で示される可変オーバヘッドを有するＦＥＣ符号化の技術を用いてデータの符号化を行なうことができる。
【００４４】
＜２  ＦＥＣストリーミングフレームワーク＞
＜２．１  導入＞
このセクションは、ＵＤＰ上のストリーミングされるデータフローのＦＥＣ保護を提供する、ＦＥＣビルディングブロックの意味でのＣＤＰの定義のためのフレームワークを定義する。このセクションは、完全なコンテンツ配信プロトコルを定義しないが、それよりも、ＵＤＰ上のストリーミングデータをサポートする全てのコンテンツ配信プロトコルに共通すると期待される点だけを定義する。
【００４５】
このセクションにおいて定義されるフレームワークは、単一のストリーミングアプリケーションプロトコルに固有ではない。フレームワークは、ＵＤＰ上のアプリケーションプロトコルのフローに対して、および複数のそのようなフローの組み合わされた保護のためにＦＥＣ保護を提供する。例えば、複数のＲＴＰフローが、関連するＲＴＣＰフローと一緒に、および場合によってはＭＩＫＥＹパケットなどのその他の関連するフローとも一緒に保護されることができる。多くの損失条件における多くのＦＥＣスキームに関して、所与のＦＥＣオーバヘッドを有するＦＥＣの使用を通じて達成可能な信頼性の向上は、単一のブロックとして保護されるデータの量が増加するにつれて大きくなる。したがって、特に、受信機が、有用なサービスをユーザに提供するために全てのストリームを必要とする場合、複数のストリームを一緒に保護する能力に大きな利点が存在する。
【００４６】
このフレームワークは、保護されるべきフローがどのように決定されるかも、保護されるフローの詳細およびそれらのフローを保護するＦＥＣストリームがどのようにして送信機から受信機に伝達されるかも定義しない。セクション５において示される仕様などの完全なコンテンツ配信プロトコルの仕様が、これらのシグナリングの要件に対処する。しかし、このセクションは、送信機および受信機においてＦＥＣストリーミングフレームワークによって要求される情報、例えば、ＦＥＣで保護されるべきフローおよびＦＥＣ保護データを搬送する（１つまたは複数の）フローの詳細を確かに規定する。我々は、コンテンツ配信プロトコルがこの情報を伝達するために使用するＳＤＰ属性も規定する。
【００４７】
上で概説されたアーキテクチャが図２に示される。
【００４８】
＜２．２  手順の概要＞
＜２．２．１  概要＞
このセクションにおいて定義されるメカニズムは以下の３つのコンポーネントを含む。
（ｉ）１つまたは複数のＵＤＰパケットフローに属するソースメディアパケットからの‘ソースブロック’の構築。ＵＤＰフローは、例えば、ＲＴＰ、ＲＴＣＰ、およびＳＲＴＰパケット、ならびにストリームに関連するその他のプロトコルも含むことができる。
（ｉｉ）ソースブロックと、ソースパケットからの、およびソースパケットに関連するデータによって占められるソースブロック内の位置とを示すためのソースパケットのオプション拡張。
（ｉｉｉ）ソースブロックの欠落部分を再構築するためにＦＥＣ復号化器によって使用されることができる、ＵＤＰを介して送信されるリペアパケットの定義。
【００４９】
メカニズムは、ソースデータがＵＤＰを介して搬送されることを除いて、一緒に保護されることができるソースデータにいかなる制約も課さない。データは、一緒に保護されるいくつかの異なるＵＤＰフローからのものであることができる。概して、複数のソースブロックがストリームに対して構築され、それぞれのソースブロックはソースパケットの異なる集合から構築される。例えば、各ソースブロックは、ストリームの特定のセグメントに関連するそれらのソースパケットから遅れずに構築されることができる。
【００５０】
このストリーミングフレームワークをサポートする受信機は、ＦＥＣソースパケットに関するパケットフォーマットをサポートすべきであり、ＦＥＣリペアパケットに関するパケットフォーマットもサポートすべきである。
【００５１】
このセクションは、送信機がどのソースパケットがどのソースブロックに含まれるかをどのように決定するかを定義しない。特定のコンテンツ配信プロトコルがこのマッピングを定義する可能性があるか、またはこのマッピングは送信機に依存する実装に委ねられる可能性がある。しかし、ＣＤＰの仕様は、受信機がその受信機が任意の所与のソースブロックに関するＦＥＣリペアパケットを受信するのを待つべき時間の長さをどのように決定するかを定義すべきである。
【００５２】
送信機において、メカニズムは、元のＵＤＰパケットを処理して以下を生成する。
（ｉ）１つまたは複数の‘（１つまたは複数の）ソースブロック’の形態の、元のパケットの記憶されたコピー。ソースブロックは、ＦＥＣ符号が後で適用されるデータのロジカルブロックである。ソースブロックは、各ソースパケットに関する‘ソースパケット情報’（ＳＰＩ）を連結することによって構築される。概して、パケットに関するＳＰＩは、パケットが属するフローに関する短い識別子、パケットの長さ、ＵＤＰペイロード、および場合によってはパディングバイトを含む。
（ｉｉ）受信機への伝送のためのＦＥＣソースパケット。
【００５３】
ＦＥＣストリーミングフレームワークは、ソースブロックから所望の量のリペアシンボルを生成するために、使用中のＦＥＣスキームによって指定されたＦＥＣ符号化器を使用する。次に、これらのリペアシンボルは、ＦＥＣリペアパケットフォーマットを使用して受信機に送信される。ＦＥＣリペアパケットは、ＦＥＣストリーミング設定情報によって示されるように、元のＵＤＰパケットの（１つまたは複数の）送信先ポートのうちのいずれとも異なるＵＤＰ送信先ポートに送信される。
【００５４】
受信機は、受信された任意のＦＥＣソースパケットから元のソースパケットを直接回復する。また、受信機は、受信されたＦＥＣソースパケットを使用して、送信機において構築されたのと同じソースブロックフォーマットの元のパケットの記憶されたコピーを構築する。
【００５５】
所与のソースブロックに関連するいずれかのＦＥＣソースパケットが失われた場合、受信機におけるソースブロックのこのコピーは不完全になる。そのソースブロックに関連する十分なＦＥＣソースパケットおよびＦＥＣリペアパケットが受信された場合、ＦＥＣフレームワークは、ＦＥＣスキームによって定義されたＦＥＣ復号化アルゴリズムを使用してソースブロックの（できれば、しかし必ずではなく完全な）コピーを回復することができる。次に、欠落したソースパケットに関するＳＰＩが、ソースブロックの完成した部分から抽出されることができ、アプリケーションに渡されるべきソースパケットを再構築するために使用されることができる。
【００５６】
受信機は、受信または回復されたパケットの一部または全てがアプリケーションに渡される前にＦＥＣリペアパケットが到着し、ＦＥＣ復号化が実行されるための時間を与えるために受信ソースパケットをバッファする必要がある可能性があることに留意されたい。そのようなバッファが提供されない場合、アプリケーションは、必要とされるパケットの厳密な並べ替えを扱うことができなければならない。しかし、そのようなバッファリングは、コンテンツ配信プロトコルおよび／または実装に固有であり、ここでは規定されない。
【００５７】
ＦＥＣソースパケットの受信機は、ソースブロックと、各パケットから導出されたＳＰＩによって占められるソースブロック内の位置とを識別する。この情報は、ＦＥＣソースパケット識別情報として知られ、いくつかのやり方で伝達されることができる。ＦＥＣソースパケット識別情報は、ソースＦＥＣペイロードＩＤフィールドと呼ばれる、本明細書において定義されるＦＥＣソースパケットフォーマット内の特定のフィールドに符号化されることができる。ソースＦＥＣペイロードＩＤフィールドの厳密な内容およびフォーマットはＦＥＣスキームによって定義される。代替的に、ＦＥＣスキームまたはＣＤＰは、ＦＥＣソースパケット識別情報がソースパケット内のその他のフィールドからどのように導出されるかを定義することができる。この文書は、もし使用される場合は、ソースＦＥＣペイロードＩＤフィールドが、ＦＥＣソースパケットを形成するためにソースパケットに追加されるやり方を定義する。
【００５８】
ＦＥＣリペアパケットの受信機は、ソースブロック、および含まれるリペアデータと元のソースブロックとの間の関係を識別することもできるべきである。この情報は、ＦＥＣリペアパケット識別情報として知られる。この情報は、特定のフィールド、リペアＦＥＣペイロードＩＤフィールドに符号化されるべきであり、そのリペアＦＥＣペイロードＩＤフィールドの内容およびフォーマットはＦＥＣスキームによって定義される。
【００５９】
本明細書と関連して使用されるべき任意のＦＥＣスキームは、組織的ＦＥＣスキームであるべきであり、ソースブロックに基づくべきである。ＦＥＣスキームは、ＦＥＣソースパケットおよびＦＥＣリペアパケットに対して異なるＦＥＣペイロードＩＤフィールドフォーマットを定義することができる。
【００６０】
＜２．２．２  送信機の動作＞
送信機が、セッションに関する元のデータパケットを構築または受信したと仮定される。これらは、ＲＴＰ、ＲＴＣＰ、ＭＩＫＥＹ、またはその他のＵＤＰパケットである可能性がある。以下の動作は、仕様に準拠したＦＥＣソースパケットストリームおよびＦＥＣリペアパケットストリームを生成するためのあり得るやり方を記述する。
１．ソースブロックが、それぞれの元のソースパケットに関するＳＰＩを結合することによって、セクション２．３．２において規定されるように構築される。そのようにする際、ＦＥＣソースパケットのソースＦＥＣパケット識別情報が決定されることができ、使用される場合にはソースＦＥＣペイロードＩＤフィールドに含まれることができる。ＳＰＩにおいて、パケットのＵＤＰフローの識別情報が、本明細書において定義される短い‘ＵＤＰフローＩＤ’を使用して印される。ＵＤＰフローの仕様のＵＤＰフローＩＤへの関連付けは、ＦＥＣストリーミング設定情報によって定義される。
２．ＦＥＣソースパケットがセクション２．３．３に従って構築される。元のフローの識別情報は、特定のプロトコル（例えば、ＲＴＰ、ＲＴＣＰ、ＳＲＴＰ、ＭＩＫＥＹなど）の元のストリームから生成されたＦＥＣソースパケットを搬送するとき、コンテンツ配信プロトコルによって（例えば、ＤＶＢサービスディスカバリを使用して）示された同じＵＤＰポートおよびＩＰアドレスの使用を通じてソースパケットによって保持される。生成されたＦＥＣソースパケットは、通常のＵＤＰの手順に従って送信される。
３．ＦＥＣ符号化器が、ソースブロックからリペアシンボルを生成し、ＦＥＣストリーミングフレームワークが、これらのシンボルを（１つまたは複数の）受信機に運ばれるべきＦＥＣリペアパケットに入れる。これらのリペアパケットは、それらをソースパケットフローのいずれからも分けるために一意的な送信先ポートに通常のＵＤＰの手順を使用して送信される。ＦＥＣリペアパケットのために使用されるべきポートは、ＦＥＣストリーミング設定情報によって定義される。
【００６１】
＜２．２．３  受信機の動作＞
以下は、ＦＥＣソースまたはリペアパケットを受信するときのあり得る受信機のアルゴリズムを説明する。
１．ＦＥＣソースパケットが（そのＦＥＣソースパケットが受信されたＵＤＰフローによって示されるように）受信される場合、
ａ．元のソースパケットが、使用される場合はソースＦＥＣペイロードＩＤを削除することによって再構築される。結果として得られるパケットは、ＦＥＣリペアのための時間を与えるためにバッファリングされることができる。
ｂ．ソースＦＥＣパケット識別情報が、使用される場合はソースＦＥＣペイロードＩＤから、またはその他の手段によって判定される。
ｃ．結果として得られるパケットに関するＳＰＩが、ソースＦＥＣパケット識別情報、およびセクション２．３．２において説明されるソースブロックフォーマットに従ってソースブロックに入れられる。パケットが受信／送信されたＩＰアドレスおよびＵＤＰポートが、ＳＰＩ内のＵＤＰフローＩＤを決定するために使用される。
２．ＦＥＣリペアパケットが（そのＦＥＣリペアパケットが受信されたＵＤＰフローによって示されるように）受信される場合、含まれるリペアシンボルが、リペアＦＥＣペイロードＩＤに従ってソースブロックに関連付けられる。
３．ソースブロックに関して少なくとも１つのソースパケットが欠落しており、少なくとも１つのリペアパケットが受信された場合、ＦＥＣ復号化が望ましい可能性がある。ＦＥＣ復号化器は、ステップ１において構築されたソースブロックとステップ２において受信された関連するリペアシンボルとを合わせたものが、ソースブロック内の欠落したソースシンボルのうちの任意の欠落したソースシンボルまたは全ての欠落したソースシンボルの復号化のために十分なシンボルを含むかどうかを判定し、含む場合は復号化動作を実行する。
４．次に、復号化動作中に再構築された任意のＳＰＩが、欠落したソースパケットを再構築するために使用され、これらは、通常の受信ソースパケットとしてバッファリングされる（上記のステップ１ａを参照）。
【００６２】
上記の手順は、全ての元のソースパケットが回復されるわけではない状況をもたらす可能性があることに留意されたい。
【００６３】
正しく受信されたソースパケットおよび再構築されたソースパケットは、順番が狂っており、受信機への到着順と異なる順番でアプリケーションに配信される可能性がある。あるいは、受信されたソースパケットおよび再構築されたソースパケットをそれらのソースパケットがソースブロック内に入れられた順番に並べ替えることがアプリケーションによって必要とされる場合、バッファリングおよびパケットの並べ替えが、受信されたソースパケットおよび再構築されたソースパケットをそれらのソースパケットがソースブロック内に置かれた順番に並べ替えるために要求される可能性がある。
【００６４】
＜２．３  プロトコルの仕様＞
＜２．３．１  概要＞
このセクションは、ＦＥＣストリーミングフレームワークのためのプロトコルの要素を規定する。プロトコルは、以下のセクションにおいて説明される以下の３つのコンポーネントを含む。
１．ソースパケットからのソースブロックの構築。ＦＥＣ符号が、リペアデータを生成するためにこのソースブロックに適用される。
２．ソースデータを含むパケットに関するフォーマット。
３．リペアデータを含むパケットに関するフォーマット。
【００６５】
ＦＥＣストリーミングフレームワークの動作は、特定のＦＥＣストリーミング設定情報によって管理される。この設定情報も、このセクションにおいて定義される。このフレームワークを使用する完全なプロトコルの仕様は、この情報を決定し、送信機と受信機との間でこの情報を伝達するための手段を規定すべきである。
【００６６】
＜２．３．２  ソースブロックの構造＞
この章は、ソースブロックのレイアウトを定義する。ソースブロックは、少なくとも１つの元のソースＵＤＰパケットに関するＳＰＩの連結を含む。
ｎ    ソースブロック内のＵＤＰパケットの数であるものとする。ｎは、ソースブロックの構築プロセス中に動的に決定されることができる。
Ｔ    バイトで表したソースシンボルサイズであるものとする。注：この情報は、セクション２．３．６において定義されるようにＦＥＣスキームによって提供される。
Ｒ［ｉ］    ソースブロックに追加されるべきｉ番目のＵＤＰパケットのＵＤＰペイロードのオクテットを表し、０≦ｉ＜ｎであるものとする。
ｌ（ｉ）    オクテットで表したＲ［ｉ］の長さであるものとする。
Ｌ［ｉ］    ネットワークバイトオーダ（上位のオクテットが先）でｌ［ｉ］の値を表す２オクテットを表すものとする。
ｆ［ｉ］    ｉ番目のパケットが取得されたＵＤＰフローを特定する整数‘ＵＤＰフローＩＤ’を表すものとする。
Ｆ［ｉ］    ｆ［ｉ］の値を表す単一のオクテットを表すものとする。
ｓ［ｉ］    ｓ［ｉ］＊Ｔ≧（ｌ［ｉ］＋３）であるような最も小さい整数であるものとする。ｓ［ｉ］は、シンボルを単位として表したＳＰＩ［ｉ］の長さであることに留意されたい。
Ｐ［ｉ］    ｓ［ｉ］＊Ｔ−（ｌ［ｉ］＋３）個のゼロオクテットを表すものとする。注：Ｐ［ｉ］は、各ＵＤＰパケットの開始をシンボルの開始に合わせるためのパディングオクテットである。
ＳＰＩ［ｉ］    Ｆ［ｉ］、Ｌ［ｉ］、Ｒ［ｉ］、およびＰ［ｉ］の連結であるものとする。
【００６７】
そのとき、ソースブロックは、ｉ＝０，２，．．．ｎ−１に対するＳＰＩ［ｉ］を連結することによって構築される。そのとき、ソースブロックサイズＳは、ｓｕｍ｛ｓ［ｉ］＊Ｔ，ｉ＝０，．．．，ｎ−１｝によって与えられる。
【００６８】
ソースブロックは、整数であるソースブロック番号によって識別され、ソースブロック内のシンボルは、整数である符号化シンボルＩＤによって識別される。このセクションは、ソースブロック番号がソースブロックにどのように割り当てられるかを規定しない。シンボルは、ソースブロック内でゼロから始まって連続的に番号を振られる。各ソースパケットは、そのパケットに関するＳＰＩを含む第１のシンボルの符号化シンボルＩＤに関連付けられる。したがって、ｊ番目のソースパケットに関連する符号化シンボルＩＤの値は、以下によって与えられる。
ｊ＝０に対して、ＥＳＩ［ｊ］＝０
０＜ｊ＜ｎに対して、ＥＳＩ［ｊ］＝ｓｕｍ｛ｓ［ｉ］，ｉ＝０，．．．，（ｊ−１）｝
【００６９】
ソースＦＥＣパケット識別情報は、ソースブロックの識別情報、およびパケットに関連する符号化シンボルＩＤを含む。
【００７０】
ＵＤＰフローは、ＩＰ送信元および送信先アドレスならびにＵＤＰ送信元および送信先ポートの値によって一意的に定義される。ＵＤＰフローＩＤの値のＵＤＰフローへの割り当ては、ＦＥＣストリーミング設定情報の一部である。
【００７１】
＜２．３．３  ＦＥＣソースパケットに関するパケットフォーマット＞
ＦＥＣソースパケットに関するパケットフォーマットが、元のソースＵＤＰパケットのペイロードを転送するために使用されるべきである。図３に示されるように、そのパケットフォーマットは、元のＵＤＰパケットを含み、もし使用される場合には、その後にオプションでソースＦＥＣペイロードＩＤフィールドを含む。
【００７２】
ＩＰヘッダフィールドおよびＵＤＰヘッダフィールドは、元のソースパケットのＩＰヘッダフィールドおよびＵＤＰヘッダフィールドと同一であるべきである。元のＵＤＰペイロードフィールドは、元のソースパケットのＵＤＰペイロードと同一であるべきである。ＦＥＣソースパケットのＵＤＰペイロードは、元のＵＤＰペイロードと、その後のソースＦＥＣペイロードＩＤフィールドとによって構成されるべきである。
【００７３】
存在する場合、ソースＦＥＣペイロードＩＤフィールドは、ＦＥＣアルゴリズムの動作、特にソースＦＥＣパケット識別情報の導出のために必要とされる情報を含む。ソースＦＥＣペイロードＩＤのフォーマット、およびソースＦＥＣパケット識別情報の導出は、ＦＥＣスキームによって定義される。ＦＥＣスキームまたはＣＤＰは、ソースＦＥＣパケット識別情報をソースパケット内のその他の情報（例えば、ＲＴＰシーケンス番号）から導出するための手段を定義することができることに留意されたい。この場合、ここで説明されるソースＦＥＣペイロードＩＤフィールドはパケットに追加されず、ソースＦＥＣパケットはあらゆる点で元のソースパケットと同一である。
【００７４】
＜２．３．４  ＦＥＣリペアパケットに関するパケットフォーマット＞
ＦＥＣリペアパケットに関するパケットフォーマットが図４に示される。ＵＤＰペイロードは、リペアＦＥＣペイロードＩＤフィールド、およびＦＥＣ符号化プロセスによって生成された１つまたは複数のリペアシンボルを含む。リペアＦＥＣペイロードＩＤフィールドは、ＦＥＣアルゴリズムの動作のために必要とされる情報を含む。この情報は、ＦＥＣスキームによって定義される。リペアＦＥＣペイロードＩＤフィールドのフォーマットはＦＥＣスキームによって定義される。
【００７５】
ＦＥＣスキームによって定義されるパケットサイズの制約またはその他の制約を条件として、任意の数の完全なリペアシンボルがＦＥＣリペアパケットに含まれることができる。パケット内のリペアシンボル数は、シンボルの長さおよびパケットの長さから決定されることができる。部分的なリペアシンボルはＦＥＣリペアパケットに含まれるべきでない。
【００７６】
＜２．３．５  ＦＥＣストリーミング設定情報＞
ＦＥＣストリーミング設定情報は、ＦＥＣストリーミングフレームワークがＦＥＣ保護をＵＤＰフローに適用するために必要とする情報である。ここで規定されるフレームワークを使用するストリーミングに関する完全なコンテンツ配信プロトコルの仕様は、この情報がどのように導出され、送信機と受信機との間で伝達されるかの詳細を含むべきである。
【００７７】
ＦＥＣストリーミング設定情報は、いくつかのＵＤＰパケットフローの識別情報を含む。各ＵＤＰパケットフローは、タプル｛送信元ＩＰアドレス，送信先ＩＰアドレス，送信元ＵＤＰポート，送信先ＵＤＰポート｝によって一意に識別される。
【００７８】
ＦＥＣ−ＳＦの単一のインスタンスが、リペアパケットを含む１つまたは複数のＵＤＰパケットフローによって、ソースＵＤＰパケットフローの指定された集合の全てのパケットにＦＥＣ保護を提供する。ＦＥＣストリーミング設定情報は、ＦＥＣ−ＳＦの各インスタンスに関して以下を含む。
１．（１つまたは複数の）ＦＥＣリペアフローとして知られる、ＦＥＣリペアパケットを搬送する（１つまたは複数の）ＵＤＰパケットフローの識別情報。
２．（１つまたは複数の）ＦＥＣリペアフローによって保護される各ソースＵＤＰパケットフローに関して、
ａ．ソースパケットを搬送するＵＤＰパケットフローの識別情報。
ｂ．このフローに関する、０と２５５との間の整数の識別子。この識別子は、同じＦＥＣリペアフローによって保護される全てのソースＵＤＰパケットフローの間で一意的であるべきである。
３．ＦＥＣ符号化ＩＤ、（適用可能な場合）ＦＥＣインスタンスＩＤ、およびオプションでシンボルサイズ。
【００７９】
上記の項目（３）は、ＦＥＣオブジェクト伝送情報に含まれる。
【００８０】
別個のおよび独立したＦＥＣストリーミング設定情報を用いるＦＥＣ−ＳＦの複数のインスタンスが、送信機または受信機に存在する可能性がある。ＦＥＣ−ＳＦの単一のインスタンスが、上記（２）において識別された全てのソースＵＤＰパケットフローの全てのパケットを保護し、すなわち、それらのフローの全てのパケットは、セクション２．３．３において定義されたＦＥＣソースパケットであるべきである。単一のソースＵＤＰパケットフローは、２つ以上のＦＥＣ−ＳＦのインスタンスによって保護されるべきでない。
【００８１】
単一のＦＥＣリペアフローが、ＦＥＣ−ＳＦの単一のインスタンスに対してリペアパケットを提供する。その他のパケットはこのフロー内で送信されるべきでなく、すなわち、ＦＥＣリペアフロー内の全てのパケットは、セクション２．３．４において定義されたＦＥＣリペアパケットであるべきであり、同じＦＥＣ−ＳＦのインスタンスに関連すべきである。
【００８２】
ＦＥＣ−ＳＦは、各ソースブロックに対して使用されるべきシンボルサイズを知らされることを必要とする。この情報は、ＦＥＣストリーミング設定情報に含まれることができるか、またはこの情報は、その他の手段によって、例えば、ＦＥＣリペアペイロードＩＤフィールド内で伝達されることができる。完全なコンテンツ配信プロトコルの仕様は、この情報が送信機と受信機との間でどのように伝達されるかを規定すべきである。
【００８３】
＜２．３．６  ＦＥＣスキームの要件＞
好ましいＦＥＣスキームは組織的であり、個別のソースブロックに基づき、ソースパケットに関連するソースブロック番号および符号化シンボルＩＤがどのように導出されるか、または送信機から受信機に伝達されるか（例えば、ソースＦＥＣペイロードＩＤフィールド内で）を規定し、シンボルの長さがどのように導出されるか、または送信機から受信機に伝達されるか（例えば、ＦＥＣオブジェクト伝送情報の一部として）を規定する。
【００８４】
＜３．ストリーミングのためのＦＥＣスキーム＞
＜３．１  任意のパケットフローのためのＭＳＣＲ  ＦＥＣスキーム＞
この章は、ＵＤＰ上の任意のパケットフローのＭＳＣＲ保護のためのＦＥＣスキームを定義する。
＜３．１．１  フォーマットおよび符号＞
＜３．１．１．１  ＦＥＣオブジェクト伝送情報＞
＜３．１．１．１．１  ＦＥＣオブジェクト伝送要素＞
ＦＥＣオブジェクト伝送要素、ＦＥＣ符号化ＩＤが、所定の値に設定される。
＜３．１．１．１．２  共通＞
このスキームに関するこの共通ＦＥＣオブジェクト伝送情報要素およびそれらの要素の値の範囲は、最大ソースブロック長がシンボルを単位として表した２１６未満の非負の整数であり、符号化シンボルサイズがバイトを単位として表した２１６未満の非負の整数であるようなものである。符号化された共通ＦＥＣオブジェクト伝送情報要素に関するフォーマットは、図５において定義された４オクテットフィールドである可能性がある。
【００８５】
＜３．１．１．２  ＦＥＣペイロードＩＤ＞
＜３．１．１．２．１  ソースＦＥＣペイロードＩＤ＞
ソースＦＥＣペイロードＩＤは、図６に示されたようなものである可能性がある。そこで、ソースブロック番号（ＳＢＮ）（１６ビット）は、パケット内のソースデータが関連するソースブロックに関する整数の識別子であり、符号化シンボルＩＤ（ＥＳＩ）（１６ビット）は、ソースブロック内のソースパケットの開始シンボルのインデックスである。符号化シンボル識別子の解釈は、ＦＥＣストリーミングフレームワークによって定義される（セクション２参照）。
【００８６】
＜３．１．１．２．２  リペアＦＥＣペイロードＩＤ＞
リペアＦＥＣペイロードＩＤの構造が図７において定義され、そこで、ソースブロック番号（ＳＢＮ）（１６ビット）は、パケット内のリペアシンボルが関連するソースブロックに関する整数の識別子であり、符号化シンボルＩＤ（ＥＳＩ）（１６ビット）は、パケット内の符号化シンボルに関する整数の識別子であり、ソースブロック長（ＳＢＬ）（１６ビット）は、ソースブロック内のソースシンボル数である。ソースブロック番号、符号化シンボル識別子、およびソースブロック長の解釈は、ＦＥＣ符号の仕様によって定義されるようなものである可能性がある。
【００８７】
＜３．１．２  手順＞
このＦＥＣスキームは、セクション２で定義されたフレームワークの手順を使用して、ＦＥＣ符号が適用されることができるソースブロックを構築する。送信機は、ソースブロックに対してソースブロック番号を順番に割り当てるべきであり、ソースブロック番号２１６−１の後はゼロに戻すべきである。送信機は、ＦＥＣオブジェクト伝送情報内でシグナリングされる最大ソースブロック長より大きなソースブロックを構築すべきでない。
【００８８】
＜３．１．３  ＦＥＣ符号の仕様＞
ＭＳＣＲ  ＦＥＣ符号化器に渡されるソースブロックは、ソースブロック内の総シンボル数がＦＥＣオブジェクト伝送情報でシグナリングされる最大ソースブロック長（セクション３．１．１．１．２参照）に等しいようにゼロ個以上のパディングシンボルで拡張された、セクション３．１．２に従って構築されたソースブロックを含む。したがって、符号化されたＦＥＣによって使用されるＫの値は、最大ソースブロック長に等しい。パディングシンボルは、値ゼロに設定されたバイトである可能性がある。
【００８９】
ソースブロックの構築およびリペアシンボルの構築のために使用されるべきシンボルサイズＴは、ＦＥＣオブジェクト伝送情報でシグナリングされる符号化シンボルサイズ（セクション３．１．１．１．２参照）に等しい。パラメータＴは、任意のソースブロック内のソースシンボル数が最大ＫＭＡＸ＝８１９２であるように設定される。
【００９０】
推奨されるパラメータが、３．１．３．３において示される。
【００９１】
＜３．１．３．１  符号化パケットの構築＞
セクション２．３．４で説明されたように、各リペアパケットは、ソースブロック番号（ＳＢＮ）、符号化シンボルＩＤ（ＥＳＩ）、ソースブロック長（ＳＢＬ）、および（１つまたは複数の）リペアシンボルを含む。
【００９２】
リペアパケットに含まれるリペアシンボル数は、パケットの長さから計算される。リペアパケットに入れられるＥＳＩの値、およびリペアシンボルを生成するために使用されるリペアシンボルトリプルは、［２］のＣ．３．２．２節で説明されるように計算される。
【００９３】
リペアＦＥＣペイロードＩＤフィールドのソースブロック長フィールドは、ソースブロックに関連するパケットのソースパケット情報に含まれるシンボル数、すなわち、最大ソースブロック長までパディングする前のシンボル数に設定される。
【００９４】
＜３．１．３．２  転送＞
このセクションでは、ＭＳＣＲ符号化器／復号化器間の情報交換、および、ストリーミングのためのＭＳＣＲ  ＦＥＣを利用する任意の転送プロトコルについて記載する。
【００９５】
ストリーミングのためのＭＳＣＲ符号化器は、各ソースブロックについて、転送プロトコルから以下の情報を使用する。
−シンボルサイズ  Ｔ（バイト）
−ソースブロック内のシンボル数  Ｋ
−ソースブロック番号（ＳＢＮ）
−符号化されるソースシンボル  Ｋ・Ｔバイト
【００９６】
ＭＳＣＲ符号化器は、各リペアパケットについて、転送プロトコルに符号化パケット情報を供給し、以下を含む。
−ソースブロック番号（ＳＢＮ）
−符号化シンボルＩＤ（ＥＳＩ）
−ソースブロック長（ＳＢＬ）
−リペアシンボル
【００９７】
転送プロトコルはこの情報を透過的にＭＳＣＲ復号化器に通信する。
【００９８】
本明細書において適切な転送プロトコルが規定される。
【００９９】
＜３．１．３．３  パラメータ例＞
＜３．１．３．３．１  パラメータ導出アルゴリズム＞
このセクションでは、パラメータＴの導出の推奨値を提供する。当該推奨値は以下の入力パラメータに基づいている。
−  Ｂ  ソースブロックの最大サイズ（バイト）
−  Ｐ：リペアパケットの最大ペイロードサイズ（リペアＦＥＣペイロードＩＤを含まない）（バイト）、Ａの倍数である
−  Ａ：シンボル整列ファクタ（バイト）
−  ＫＭＡＸ：ソースブロック当たりのソースシンボルの最大数、［２］で規定されるようにＫＭＡＸ＝８１９２である
−  ＫＭＩＮ：ソースブロック当たりのシンボルの最小目標数
−  ＧＭＡＸ：リペアパケット当たりのシンボルの最大目標数
【０１００】
これらの入力は、ｃｅｉｌ（Ｂ／Ｐ）≦ＫＭＡＸを満足する必要がある。上述の入力に基づいて、転送パラメータＴは、以下の通りに算出される。
Ｇ＝ｍｉｎ｛ｃｅｉｌ（Ｐ・ＫＭＩＮ／Ｂ），Ｐ／Ａ，ＧＭＡＸ｝−パケット当たりの平均シンボル数
とすると
Ｔ＝ｆｌｏｏｒ（Ｐ／（Ａ・Ｇ））・Ａ
【０１０１】
上で導出されたＴの値は、使用されるＴの実際の値に対する指針とみなされるべきである。ＴがＰに分かれることを保証することが有利である可能性があるか、または（ソースブロック内のソースシンボルの最大数がＫＭＡＸを超えない限り）フルサイズのリペアシンボルが、失われたソースパケットの終わりに部分的なソースシンボルを回復するために使用されるときに、損失を最小化するためにＴの値をより小さく設定することが有利である可能性がある。さらに、Ｔの選択はソースパケットサイズの分布に依存する可能性があり、例えば、全てのソースパケットが同じサイズである場合、リペアパケットＰ’（ここで、Ｐ’はＴの倍数である）の実際のペイロードサイズが各ソースパケットがソースブロック内で占めるバイト数（またはそれを可能な限り少ないバイト数だけ上回るバイト数）に等しいようにＴを選択することが有利である。
【０１０２】
入力パラメータＡ、ＫＭＩＮ、およびＧＭＡＸに対する推奨される設定は、Ａ＝１６、ＫＭＩＮ＝６４０、ＧＭＡＸ＝１０である。
【０１０３】
＜３．１．３．３．２  例＞
上記のアルゴリズムは、Ａ、ＫＭＩＮ、およびＧＭＡＸに対する推奨値、ならびにＰ＝１４２４を仮定して、以下の表に示される転送パラメータをもたらす。
0005550834.tif 000004
【０１０４】
＜３．２  単一の順序付けられたパケットフローのためのＭＳＣＲ  ＦＥＣスキーム＞
このセクションは、ソースパケットがそれぞれ一意的なシーケンス番号を搬送する単一のパケットフローのＦＥＣ保護のための代替的なＦＥＣスキームを定義する。我々は、そのようなパケットフローを”順序付けられたフロー”と呼ぶ。第１の例は、サービスのための全てのデータが多重化されるＭＰＥＧ−２トランスポートストリームを含むＲＴＰフローのＦＥＣ保護である。この場合、ＲＴＰシーケンス番号が、ソースＦＥＣパケット識別情報を導出するために使用されることができる。
【０１０５】
セクション３．１において定義されたＦＥＣスキームと比較して、このスキームの第１の利点は、このスキームが全くソースパケットを修正しないことである。結果として、このＦＥＣスキームは、セクション３．１において定義されたスキームに従って修正されたソースパケットを認識しない従来の機器が存在する中で使用されることができる。
【０１０６】
このＦＥＣスキームにおいて、セクション３．１のスキームのソースＦＥＣペイロードＩＤによって果たされた役割は、シーケンス番号によって置き換えられる。各フロー内のパケットのシーケンス番号は、ストリーム内の各パケットに対して１ずつ増やされるべきである。
【０１０７】
所与の順序付けられたフロー内の各パケットに関する所与のソースブロック内のソースパケット情報のサイズは同じであるべきであり、所与のソースブロックに対してやはり全て同じサイズであるべきであるＦＥＣリペアパケットのサイズから導出される。
【０１０８】
＜３．２．１  フォーマットおよび符号＞
＜３．２．１．１  ＦＥＣオブジェクト伝送情報＞
＜３．２．１．１．１  必須＞
このＦＥＣスキームは、所定のＦＥＣ符号化ＩＤによって識別される。
＜３．２．１．１．２  共通＞
セクション３．１．１．１．２を参照
＜３．２．１．１．３  スキーム固有＞
スキームに固有のＦＥＣオブジェクト伝送情報は、このＦＥＣスキームによって定義されない。
＜３．２．１．２  ＦＥＣペイロードＩＤ＞
＜３．２．１．２．１  ソースＦＥＣペイロードＩＤ＞
ソースＦＥＣペイロードＩＤフィールドは、このＦＥＣスキームによって使用されない。ソースパケットは、このＦＥＣスキームによって全く修正されない。
【０１０９】
＜３．２．１．２．２  リペアＦＥＣペイロードＩＤ＞
このＦＥＣスキームのためのリペアＦＥＣペイロードＩＤが図８に示される。そこで、イニシャルシーケンス番号（フローｉのＩＳＮ）は、このサブブロックに含まれるべき第１のパケットのシーケンス番号の最も下位の１６ビットを指定する１６ビットのフィールドである。シーケンス番号が１６ビットよりも短い場合、受信されたシーケンス番号は、それぞれ長さが１６ビットになるようにゼロビットで論理的にパディングされる。符号化シンボルＩＤ（ＥＳＩ）は、どのリペアシンボルがこのリペアパケットに含まれるかを示す１６ビットのフィールドである。提供されるＥＳＩは、パケット内の第１のリペアシンボルのＥＳＩである。ソースブロック長（ＳＢＬ）は、シンボルで表したソースブロックの長さを示す１６ビットのフィールドである。
【０１１０】
＜３．２．２  手順＞
このＦＥＣスキームは、セクション２で定義されたフレームワークの手順を使用して、ＦＥＣ符号が適用されることができるソースブロックを構築する。そこで定義された手順に加えて以下の手順が適用される。
【０１１１】
＜３．２．２．１  ソースＦＥＣパケット識別情報の導出＞
ソースパケットに関するソースＦＥＣパケット識別情報は、パケットのシーケンス番号、およびリペアＦＥＣパケットで受信された情報から導出される。ソースブロックは、ブロック内の最初のソースパケットのシーケンス番号によって識別される。この情報は、イニシャルシーケンス番号フィールドでソースブロックに関連付けられた全てのリペアＦＥＣパケットでシグナリングされる。
【０１１２】
ソースブロック内のソースパケットに関する（バイトで表した）ソースパケット情報の長さは、全てが同じであるべきである、そのブロックに関するリペアパケットの符号化シンボルを含むペイロード（すなわち、リペアＦＥＣペイロードＩＤを含まない）の長さに等しい。シンボルで表したソースパケット情報長（ＳＰＩＬ）は、（共通ＦＥＣオブジェクト伝送情報でシグナリングされる）符号化シンボルサイズによってこの長さを割ったものに等しい。
【０１１３】
ソースブロックに含まれるソースパケットの集合は、イニシャルシーケンス番号（ＩＳＮ）およびソースブロック長（ＳＢＬ）から以下のように決定される。
Ｉはソースブロックのイニシャルシーケンス番号であるものとする
ＬＰはシンボルで表したソースパケット情報長であるものとする
ＬＢはシンボルで表したソースブロック長であるものとする
そのとき、Ｉ以上、Ｉ＋ＬＢ／ＬＰ−１以下のシーケンス番号を有するソースパケットがソースブロックに含まれる。
【０１１４】
ＦＥＣリペアパケットが受信されない場合、ＦＥＣ復号化はできず、受信機がソースパケットに関するソースＦＥＣパケット識別情報を識別する必要はないことに留意されたい。
【０１１５】
パケットに関する符号化シンボルＩＤが、以下の情報から導出される。
パケットのシーケンス番号Ｎｓ
ソースブロックに関するソースパケット化情報長ＬＰ
ソースブロックのイニシャルシーケンス番号Ｉ
【０１１６】
そのとき、シーケンス番号Ｎｓを有するパケットに関する符号化シンボルＩＤは以下の式によって決定される。
ＥＳＩ＝（Ｎｓ−Ｉ）・ＬＰ
【０１１７】
所与のソースブロックに関連する全てのリペアパケットは、同じソースブロック長、ソースパケット情報長、およびイニシャルシーケンス番号を含むべきであることに留意されたい。
【０１１８】
＜３．２．２．２  リペアパケットの符号化シンボルＩＤの導出＞
リペアパケットに関する符号化シンボルＩＤは、パケットがどのリペアシンボルを含むかを示す。これは、リペアＦＥＣペイロードＩＤの符号化シンボルＩＤフィールドによって直接与えられる。
【０１１９】
＜３．２．２．３  ＲＴＰフローに関する手順＞
ＲＴＰパケットフローの識別の場合、ＲＴＰシーケンス番号フィールドが、上述の手順におけるシーケンス番号として使用される。
【０１２０】
＜３．２．３  ＦＥＣ符号の仕様＞
セクション３．１．３の要件が適用される。
＜３．２．３．１  例示的なパラメータ＞
＜３．２．３．１．１  パラメータ導出アルゴリズム＞
セクション３．１．３．３．１のアルゴリズムが使用されることが推奨される。
【０１２１】
ＭＰＥＧ−２トランスポートストリームを搬送するＲＴＰストリームの場合、最大リペアパケットサイズは、
Ｐ＝ｃｅｉｌ（（ｎ・１８８＋１５）／Ａ）・Ａ
に設定されるべきである。
【０１２２】
ここで、ｎは、ＩＰソースパケット毎の１８８バイトのＴＳパケットの名目番号である。
【０１２３】
最大ソースブロックサイズは、送信機におけるアプリケーションの設定によって決定される。
【０１２４】
＜３．２．３．１．２  例＞
上記のアルゴリズムは、Ａ、ＫＭＩＮ、ＧＭＡＸに対する推奨値を仮定して、以下の表４に示されるようにＭＰＥＧ−２トランスポートストリームに関する転送パラメータをもたらす。
0005550834.tif 000005
【０１２５】
＜４  共通プロトコル要素＞
このセクションは、ストリーミングメディアのＦＥＣ保護のための完全なプロトコルを構築するために、セクション２において定義されたフレームワークおよびセクション３において定義されたＦＥＣスキームと併せて使用されることができるいくつかの共通プロトコル要素を定義する。
【０１２６】
＜４．１  ＦＥＣフィードバックプロトコル＞
＜４．１．１  概要＞
このセクションは、受信機が、ユニキャストストリームの場合にＦＥＣデータの受信に関するフィードバックを提供するための簡単で任意的なプロトコルを規定する。このフィードバックは、ＦＥＣパラメータを適合するために送信機によって使用されることができる。フィードバックは、‘フィードバックグループ’として知られるソースブロックのグループに関する受信および復号化の成功または失敗について提供される。
【０１２７】
フィードバックを受領する能力は、フィードバックが送信されるべきＩＰアドレスおよび送信先ＵＤＰポート、ならびにフィードバックが要求されるフィードバックグループの要求されるサイズと共に、送信機によって受信機に示されなければならない。
【０１２８】
フィードバックは”ベストエフォート”式に提供され、送信機は、フィードバックメッセージを受信することを信頼するべきでない。
【０１２９】
このバージョンのプロトコルにおいて、単一のフィードバックグループに関するフィードバックを提供する単一のフィードバックレポートメッセージが提供される。
・以下の情報が、各フィードバックレポートで提供される
・フィードバックグループ内のソースブロック数
・エラーなしに受信されたフィードバックグループ内のソースブロック数
・フィードバックグループ内の正常に復号化されたソースブロック数
・フィードバックグループ内の復号化することができなかったソースブロック数
・フィードバックグループ内の任意のソースブロックに関して受信されたパケットの最大数
・フィードバックグループ内の任意のソースブロックに関して受信されたパケットの最小数
・フィードバックに関する受信パケットの総数
【０１３０】
＜４．１．２  フォーマットおよび符号＞
＜４．１．２．１  全般的なメッセージフォーマット＞
ＦＥＣフィードバックプロトコルメッセージが、図９に従ってフォーマットされたＵＤＰペイロードを用いてＵＤＰ上で送信される。このバージョンのプロトコルでは、そのようなメッセージにおいてバージョンフィールドはゼロ（０）に設定される。
メッセージタイプ：
０ｘ００  フィードバックプロトコル
０ｘ０１〜０ｘｆｆ  予約
ソースブロック識別子：
このレポートが参照するグループ内の第１のソースブロックを識別する。ＦＥＣスキームがソースブロック番号を定義する場合、このソースブロック番号がソースブロック識別子として使用される。
ソースブロック数：
このレポートが参照するソースブロックの数
ペイロード：
ペイロードフィールドの内容はメッセージタイプに依存し、以下で定義される。
【０１３１】
＜４．１．２．２  メッセージペイロードフォーマット＞
フィードバックレポートに関するペイロードフィールドのフォーマットが図１０において定義される。
”エラーフリー”ブロックの数：全てのソースパケットがエラーなしに受信されたので復号化が必要とされなかったフィードバックグループからのソースブロックの数を示す。
”復号化成功”ブロックの数：復号化が必要とされ、正常に完了されたフィードバックグループからのソースブロックの数を示す。
”復号化失敗”ブロックの数：復号化が必要とされたが、不十分な情報が受信されたために正常に完了されることができなかったフィードバックグループからのソースブロックの数を示す。
最大受信パケット：フィードバックグループ内の任意のソースブロックに関して受信されたパケット（ソースおよびリペア）の最大数を示す。
最小受信パケット：フィードバックグループ内の任意のソースブロックに関して受信されたパケット（ソースおよびリペア）の最小数を示す。
総受信パケット：フィードバックグループ内の全てのソースブロックに関して受信されたパケット（ソースおよびリペア）の総数を示す。
【０１３２】
＜４．１．３  手順＞
＜４．１．３．１  ＦＥＣ送信機の手順＞
このセクションは、ＦＥＣで保護されたデータを送信し、ＦＥＣフィードバックプロトコルデータを受信しているデバイスにおける手順を定義する。
【０１３３】
＜４．１．３．１．１  概要＞
送信機におけるＦＥＣフィードバックプロトコルのサポートはオプションである。送信機は、ＦＥＣフィードバックプロトコルのサポート、サポートされる最も高いバージョン、メッセージが送信されるべきＩＰ送信先アドレスおよびＵＤＰ送信先ポート、ならびにフィードバックグループの要求されるサイズをＦＥＣストリーミング設定情報で示す。ＦＥＣストリーミング設定情報を伝達するために使用されるメカニズムは、コンテンツ配信プロトコルに固有である。
【０１３４】
ＦＥＣ送信機は、認識されないバージョン番号と共に受信されたＦＥＣフィードバックプロトコルパケットと、予約メッセージタイプと共に受信されたＦＥＣフィードバックプロトコルパケットとを無視することができる。
【０１３５】
予測されるよりも長いＦＥＣフィードバックプロトコルメッセージが受信される場合、送信機は、余分なバイトを破棄し、通常通りメッセージを処理すべきである。
【０１３６】
＜４．１．３．１．２  フィードバックレポートメッセージの受信＞
フィードバックレポートメッセージを受信すると、ＦＥＣ送信機は、フィードバックレポートメッセージで受信された情報に基づいて後続のソースブロックに関するＦＥＣパラメータ（ソースブロックサイズ、送信の速度および構成など）を適合することができる。
【０１３７】
フィードバックグループのサイズが単一のソースブロックである場合、および
・フィードバックレポートが、ソースブロックが正常に受信されるか、または正常に復号化されたことを示し、
・ＦＥＣ送信機が、ソースブロックに関するＦＥＣリペアパケットをまだ送信している場合、
ＦＥＣ送信機は、ソースブロックに関するＦＥＣリペアパケットを送信することを停止すべきである。
【０１３８】
＜４．１．３．２  ＦＥＣ受信機の手順＞
このセクションは、ＦＥＣで保護されたデータを受信し、ＦＥＣフィードバックプロトコルデータを送信しているデバイスにおける手順を定義する。
【０１３９】
＜４．１．３．２．１  概要＞
受信機におけるＦＥＣフィードバックプロトコルのサポートはオプションである。
【０１４０】
ＦＥＣフィードバックプロトコルのサポートがＦＥＣ送信機によって示されなかった場合、ＦＥＣ受信機は、ＦＥＣフィードバックプロトコルメッセージを送信すべきでない。
【０１４１】
ＦＥＣフィードバックプロトコルのサポートがＦＥＣ送信機によって示された場合、ＦＥＣ受信機は、ＦＥＣストリーミング設定情報内の情報を使用して、ＦＥＣ送信機によってサポートされる最も高いバージョン、メッセージが送信されるべきＩＰ送信先アドレスおよびＵＤＰ送信先ポート、ならびにフィードバックグループのサイズを判定することができる。
【０１４２】
ＦＥＣ受信機は、ＦＥＣ送信機によってサポートされる最も高いバージョンよりも高いバージョン番号を有するＦＥＣフィードバックプロトコルメッセージを送信すべきでない。
【０１４３】
ＦＥＣ受信機は、ＦＥＣフィードバックプロトコルが使用されるかどうかをＦＥＣストリーミングフレームワークのインスタンス毎に判定すべきである。フィードバックグループは、リペアパケットが受信されなかったソースブロックがいかなるフィードバックグループにも含まれるべきでないことを例外として、連続する一連のソースブロックを含むべきである。フィードバックグループ内のソースブロック数は、ＦＥＣストリーミング設定情報で示された要求されるフィードバックグループサイズに等しいべきである。
【０１４４】
フィードバックグループ内の各ソースブロックは、以下のセクションで説明される”エラーフリー”、”復号化成功”、または”復号化失敗”のいずれかにカテゴリー分けされるべきである。
【０１４５】
ＦＥＣ受信機は、フィードバックグループ内の全てのソースブロックのカテゴリーが判定されるや否やフィードバックレポートメッセージを送信すべきである。
【０１４６】
＜４．１．３．２．２  ”エラーフリー”ソースブロック＞
ソースブロックは、ＦＥＣ受信機がＦＥＣ復号化がソースブロックに対して必要ないと判定するや否や”エラーフリー”とみなされることができる。
【０１４７】
＜４．１．３．２．３  ”復号化成功”ソースブロック＞
ソースブロックは、ソースブロックを正常に復号化するや否や”復号化成功”とみなされることができる。
【０１４８】
＜４．１．３．２．４  ”復号化失敗”ソースブロック＞
ソースブロックは、ＦＥＣ受信機がソースブロックに対するＦＥＣ復号化が必要であるが、不可能であると判定するや否や”復号化失敗”とみなされることができる。ＦＥＣ受信機は、以下の時点で、ソースブロックに対するＦＥＣ復号化が必要であるが不可能であると判定することができる。
・ソースブロックに関する少なくとも１つのソースシンボルが未知であり、かつ、
・ソースブロックを復号化するために不十分なリペアシンボルが受信され、かつ、
・ソースシンボルがアプリケーション（例えば、メディアプレーヤ）によって必要とされる。
【０１４９】
ＦＥＣ受信機は、その他のとき、例えば、さらなるリペアシンボルが、ＦＥＣ受信機によって決定された何らかの期間の間、ソースブロックに関して受信されなかった場合に、ソースブロックに対するＦＥＣ復号化が必要であるが、不可能であると判定する可能性がある。
【０１５０】
＜４．２  ＦＥＣ送信構成＞
セクション２で定義されたＦＥＣストリーミングフレームワークは、送信されるパケットのいかなる構成も定めない。このセクションは、ストリームのＦＥＣソースパケットおよびＦＥＣリペアパケットに関する送信構成を決定するために送信機によって使用されることができるアプローチを説明する。
【０１５１】
＜４．２．１  簡単な一定速度のＦＥＣ送信＞
このセクションは、ＦＥＣソースパケットおよびＦＥＣリペアパケットの送信速度が各ソースブロック内で一定に保たれる簡単な送信構成を説明する。
【０１５２】
各ソースブロックに関して、ソースパケットが最初に送信され、その後リペアパケットが送信される。１つのソースブロックの全てのパケットが、次のブロックの任意のパケットの前に送信される。
【０１５３】
全てのデータ（ソースおよびリペア）の送信データレートは、ソースブロック内で一定であり、以下の式によって与えられる。
0005550834.tif 000006
ここで、
Ｒｓｅｎｄは送信速度である
Ｒｓｏｕｒｃｅはソースデータレートである
Ｄｒｅｐａｉｒはリペアデータの量（バイト、パケット化のオーバヘッドを含む）である
Ｄｓｏｕｒｃｅはソースデータの量（バイト、パケット化のオーバヘッドを含む）である
【０１５４】
＜４．３  ＦＥＣソースブロックの境界の決定＞
このセクションは、ＦＥＣソースブロックの境界を決定するために送信機によって使用されることができるいくつかのアルゴリズムを示す。
【０１５５】
＜４．３．１  保護期間ベース＞
このアプローチにおいて、ソースブロックは、”保護期間”として知られる期間に基づいて構築される。概して、保護期間は、ストリームのあらゆるソースブロックに対して同じである。しかし、保護期間は、ブロック毎に変更される可能性がある。
【０１５６】
リアルタイムストリームの場合、ソースブロックのソースパケットは、まさしく、保護期間に等しい期間内に到着するソースパケットである。
【０１５７】
予め符号化されるコンテンツの場合、ソースブロックのソースパケットは、まさしく、そのコンテンツから生成された非ＦＥＣ保護ストリームに関する通常の送信構成で、保護期間に等しい期間内に送信されるソースパケットである。
【０１５８】
このアプローチにおいて、セクション４．２．１およびその他の箇所の送信構成を使用して、パケットは、少なくとも任意のソースブロックの最も長い再生時間に等しい時間、受信機においてバッファリングされる。
【０１５９】
＜５  コンテンツ配信プロトコル＞
このセクションは、セクション２〜４において定義されたコンポーネントを使用するいくつかの完全なコンテンツ配信プロトコルを定義する。
【０１６０】
＜５．１  マルチキャストＭＰＥＧ−２トランスポートストリーム＞
このセクションは、ＭＰＥＧ−２トランスポートストリームのＦＥＣで保護されたマルチキャスト配信のためのコンテンツ配信プロトコルを定義する。
【０１６１】
＜５．１．１  制御プロトコル＞
セッション情報は以下を含む。
・各リペアフローに関する送信先ＵＤＰポート
・複数のリペアフローレイヤが提供される場合、各リペアフローのＩＰマルチキャストアドレス
・複数のリペアフローレイヤが提供される場合、リペアフローの結合順
・ＦＥＣオブジェクト伝送情報（最大ソースブロックサイズおよび符号化シンボルサイズ）
・受信機において要求される最小バッファリング時間
ＭＰＥＧ−２  ＴＳフローに対するフローＩＤはゼロである。
【０１６２】
＜５．１．２  転送プロトコル＞
ＭＰＥＧ−２トランスポートストリームのＦＥＣ保護は、
・セクション２で説明されたＦＥＣストリーミングフレームワーク
・セクション３．３で定義されたＦＥＣスキーム
・４．２．１で説明されたＦＥＣ送信構成
・４．３．１で説明されたＦＥＣソースブロックの境界の識別メカニズム
を使用して提供されることができる。
【０１６３】
各ＭＰＥＧ−２トランスポートストリームは、独立して保護されるべきである。
【０１６４】
＜５．２  ユニキャストＭＰＥＧ−２トランスポートストリーム＞
このセクションは、ＭＰＥＧ−２トランスポートストリームのＦＥＣで保護されたユニキャスト配信のためのコンテンツ配信プロトコルを定義する。
【０１６５】
＜５．２．１  制御プロトコル＞
セッション情報は以下を含むことができる。
・ＦＥＣオブジェクト伝送情報（最大ソースブロックサイズおよび符号化シンボルサイズ）
・受信機において要求される最小バッファリング時間
・要求されるＦＥＣフィードバックグループサイズ（または、フィードバックが要求されない場合はゼロ）
【０１６６】
ユニキャストＲＴＰフローに関連するリペアＦＥＣフローは、ＲＴＰフローが送信される送信先ＵＤＰポートよりも２高い送信先ＵＤＰポート番号に送信されることができる。
【０１６７】
ＭＰＥＧ−２  ＴＳフローに対するフローＩＤはゼロである。
【０１６８】
ＦＥＣフィードバックが送信機によって要求され、受信機によってサポートされる場合、ＦＥＣフィードバックメッセージが、サーバから受信機へのＦＥＣリペアストリームのためのソースアドレス／ポートとして使用されるアドレス／ＵＤＰポートに送信されることができる。
【０１６９】
＜５．２．２  転送プロトコル＞
ＭＰＥＧ−２トランスポートストリームのＦＥＣ保護は、
・セクション２で説明されたＦＥＣストリーミングフレームワーク
・セクション３．３で定義されたＦＥＣスキーム
・４．２．１で説明されたＦＥＣ送信構成
・４．３．１で説明されたＦＥＣソースブロックの境界の識別メカニズム
を使用して提供されることができる。
【０１７０】
各ＭＰＥＧ−２トランスポートストリームは、独立して保護されることができる。
【０１７１】
＜５．３  一般的なマルチキャストビデオ＞
このセクションは、任意のオーディオ／ビデオストリーム（例えば、ＲＴＰでカプセル化されたＨ．２６４）のＦＥＣで保護されたマルチキャスト配信のためのコンテンツ配信プロトコルを定義する。このセクションは、ＦＥＣが、オーディオ／ビデオストリームのＲＴＰでの直接的なカプセル化に対処する、ＤＶＢ  ＩＰＩハンドブックに対する将来の拡張にどのように適用されることができるかを説明するために提供される。
【０１７２】
＜５．３．１  制御プロトコル＞
セッション情報は以下を含む。
・各リペアフローに関する送信先ＵＤＰポート
・複数のリペアフローレイヤが提供される場合、各リペアフローのＩＰマルチキャストアドレス
・複数のリペアフローレイヤが提供される場合、リペアフローの結合順
・ＦＥＣオブジェクト伝送情報（最大ソースブロックサイズおよび符号化シンボルサイズ）
・保護されるＵＤＰフロー（例えば、オーディオおよびビデオフロー）のＩＰマルチキャストアドレス、ＵＤＰ送信先ポート番号、およびフローＩＤ
・受信機において要求される最小バッファリング時間
【０１７３】
＜５．３．２  転送プロトコル＞
オーディオ／ビデオストリームは、１つまたは複数のＵＤＰフロー（おそらくＲＴＰフロー）によって搬送されると仮定される。
【０１７４】
これらのＵＤＰフローのＦＥＣ保護は、
・セクション２で説明されたＦＥＣストリーミングフレームワーク
・セクション３．１で定義されたＦＥＣスキーム
・４．２．１で説明されたＦＥＣ送信構成
・４．３．１で説明されたＦＥＣソースブロックの境界の識別メカニズム
を使用して提供されることができる。
【０１７５】
＜５．４  一般的なユニキャストビデオ＞
このセクションは、任意のオーディオ／ビデオストリーム（例えば、ＲＴＰにカプセル化されたＨ．２６４）のＦＥＣで保護されたユニキャスト配信のためのコンテンツ配信プロトコルを定義する。このセクションは、ＦＥＣが、オーディオ／ビデオストリームのＲＴＰでの直接的なカプセル化に対処する、ＤＶＢ  ＩＰＩハンドブックに対する将来の拡張にどのように適用されることができるかを説明するために提供される。
【０１７６】
＜５．４．１  制御プロトコル＞
セッション情報は以下を含む。
・リペアフローに関する送信先ＵＤＰポート
・ＦＥＣオブジェクト伝送情報（最大ソースブロックサイズおよび符号化シンボルサイズ）
・保護されるＵＤＰフロー（例えば、オーディオおよびビデオフロー）のＵＤＰ送信先ポート番号およびフローＩＤ
・受信機において要求される最小バッファリング時間
・ＦＥＣフィードバックグループサイズ（または、ＦＥＣフィードバックが要求されない場合はゼロ）
【０１７７】
ＦＥＣフィードバックが送信機によって要求され、受信機によってサポートされる場合、ＦＥＣフィードバックメッセージが、サーバから受信機へのＦＥＣリペアストリームのためのソースアドレス／ポートとして使用されるアドレス／ＵＤＰポートに送信されることができる。
【０１７８】
＜５．４．２  転送プロトコル＞
オーディオ／ビデオストリームは、１つまたは複数のＵＤＰフロー（おそらくＲＴＰフロー）によって搬送されると仮定される。
【０１７９】
これらのＵＤＰフローのＦＥＣ保護は、
・セクション２で説明されたＦＥＣストリーミングフレームワーク
・セクション３．１で定義されたＦＥＣスキーム
・４．２．１で説明されたＦＥＣ送信構成
・４．３．１で説明されたＦＥＣソースブロックの境界の識別メカニズム
を使用して提供されることができる。
【０１８０】
＜６．ＦＥＣストリームの推奨事項＞
このセクションは、ＤＶＢ環境における上記のＦＥＣストリーミングプロトコルの使用に関するいくつかのさらなるオプションの推奨事項を提供する。
【０１８１】
＜６．１  マルチキャスト＞
＜６．１．１  レイヤ化されたＦＥＣ送信（オプション）＞
送信機は、単一のソースストリームに関連するリペアパケットのための２つ以上のＩＰマルチキャストアドレスを示すことができる。送信機は、各マルチキャストグループに異なるリペアパケットを送信すべきである。
【０１８２】
受信機は、ローカルの誤り率に従って受信リペアパケットの速度を適合するために任意の数のマルチキャストグループに参加することができる。
【０１８３】
しかし、ＩＰＴＶの品質目標を満たすためには、比較的まれなエラーイベントをも克服するのに十分なオーバヘッドが受信されなければならず、したがって、受信機は、要求されるリペアデータの量を決定するために十分に長い期間にわたって誤り率を計測すべきであることに留意されたい。
【０１８４】
＜６．２  ユニキャスト＞
＜６．２．１  ストリーム開始時のソースブロックの構築（オプション）＞
ソースブロックの境界が、セクション４．４．１において定義された保護期間アルゴリズムを使用して識別されるべきである。以下のアルゴリズムが、新しいストリームが再生されるべき任意の時点（例えば、ストリームの始まり、またはトリックモードを使用するとき）で使用されるべき保護期間、ＦＥＣオーバヘッド、および送信速度を決定するために推奨される。このアルゴリズムは、ソースレートを超える初期の利用可能な帯域幅をＦＥＣリペアデータと高速バッファを満たすデータとの間に均等に割り当てる。初期の利用可能な帯域幅は、名目の（長期の）帯域幅を超えることができるか、または初期の利用可能な帯域幅は、同じであってよいが、下回るべきでない。
Ｂｍａｘ  ストリーム（ソースおよびＦＥＣ）が利用可能な初期帯域幅であるものとする
Ｂｎｏｍ  ストリーム（ソースおよびＦＥＣ）に対する名目帯域幅であるものとする
Ｂｓｒｃ  ソース帯域幅であるものとする
Ｐｉｎｉｔ  初期バッファリング遅延であるものとする
Ｐｆｉｎａｌ  目標の保護期間であるものとする
Ｐ  ｉ＝０，１，．．．に対するｉ番目の保護期間であるものとする
Ｓｉｎｉｔ  初期ソース送信速度であるものとする
Ｒｉｎｉｔ  初期リペア送信速度
であるものとすると、そのとき、
0005550834.tif 000007
および、Ｐｉ＜Ｐｆｉｎａｌであるような全てのｉに対して、
0005550834.tif 000008
および、Ｐｉ≧Ｐｆｉｎａｌであるような全てのｉに対して、
0005550834.tif 000009
【０１８５】
Ｐｆｉｎａｌ未満の継続時間の保護期間の間、ソース送信速度はＳｉｎｉｔであるべきであり、リペア送信速度はＲｉｎｉｔであるべきである。この後、ソース送信速度はＢｓｒｃに下げられるべきである。この構成は、初期期間中、ソース送信速度が実際のソースデータレートよりも高く、したがって、各保護期間が、送信するために費やす時間よりも長い時間を再生するために費やすデータを含むことを意味する。結果として、後の保護期間は、受信機をデータ不足にすることなしに上記のアルゴリズムに従って長くされることができる。
【０１８６】
サービスディスカバリ情報で示される受信機における最小バッファリング時間はＰｉｎｉｔであるべきである。
【０１８７】
＜６．２．２  ＦＥＣフィードバックの使用（オプション）＞
ＦＥＣフィードバックは、個々のユーザに提供されるＦＥＣオーバヘッドを調整するために長期的に使用されることができる。しかし、ＩＰＴＶの品質目標を満たすためには、比較的まれなエラーイベントをも克服するのに十分なオーバヘッドが提供されなければならず、したがって、短い期間にわたって集められたフィードバックデータは、必要とされる長期のオーバヘッドを決定するのに十分でないことに留意されたい。
【０１８８】
保護期間が送信機と受信機との間のＩＰ往復遅延時間よりも大幅に長い場合、ＦＥＣフィードバックが、単一のソースブロックのフィードバックグループに対して要求されることができる。この場合、フィードバックレポートは、受信され、ソースブロックが正常に受信／復号化されたことを示すレポート内のこのソースブロックに関するＦＥＣリペアパケットの送信を止めるために使用されることができる。
【０１８９】
本発明が例示的実施形態に関して説明されたが、当業者は、多くの修正が可能であることを認識するであろう。例えば、本明細書において説明された方法およびプロセスは、ハードウェアコンポーネント、ソフトウェアコンポーネント、および／またはそれらのコンポーネントの任意の組合せを使用して実装されることができる。したがって、本発明が例示的実施形態に関して説明されたが、本発明は、添付の特許請求の範囲の範囲内の全ての修正および均等物を包含するように意図されることが理解されるであろう。
以下に本件出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］  データをストリーミングするための通信システムであって、前記データの全てが受信または送信される前に受信機がストリーミングされたデータの利用を開始できるように、前記データは送信機から受信機までストリーミングされ、
前記送信機は、送信されるデータを前方誤り訂正（ＦＥＣ）符号化するためのロジックを含み、それにより、送信されるストリームにはデータとＦＥＣ情報とが含まれ、前記データは前記受信機での消費速度よりも高い送信速度で送信されることを特徴とする通信システム。
［Ｃ２］  データをストリーミングするための通信システムであって、前記データの全てが受信または送信される前に受信機がストリーミングされたデータの利用を開始できるように、前記データは送信機から受信機までストリーミングされ、
前記送信機は、
送信されるデータを前方誤り訂正（ＦＥＣ）符号化するためのロジックであって、それにより、送信されるストリームにはデータとＦＥＣ情報とが含まれる、ロジックと、
送信の少なくとも一部分について、前記送信機の入力速度が前記受信機での消費速度よりも大きくなるよう送信を調節するためのロジックと、
ＦＥＣ量および／またはストリーミング送信の時間に対する入力速度超過を変更するためのロジックと、
を含むことを特徴とする通信システム。
【図面の簡単な説明】
【０１９０】
【図１】本願明細書に記載の可変ＦＥＣオーバヘッド技術を使用可能な通信システムのブロック図である。
【図２】ＦＥＣストリーミングフレームワーク・アーキテクチャの図である。
【図３】ＦＥＣソースパケットの図である。
【図４】ＦＥＣリペアパケットの図である。
【図５】ＦＥＣオブジェクト情報ブロックの図である。
【図６】ソースＦＥＣペイロードＩＤフォーマットの図である。
【図７】リペアＦＥＣペイロードＩＤフォーマットの図である。
【図８】代替のリペアＦＥＣペイロードＩＤフォーマットの図である。
【図９】ＦＥＣフィードバックプロトコル・メッセージフォーマットの図である。
【図１０】成功報告メッセージのためのペイロードフォーマットの図である。
【図１】
0005550834.tif 000010
【図２】
0005550834.tif 000011
【図３】
0005550834.tif 000012
【図４】
0005550834.tif 000013
【図５】
0005550834.tif 000014
【図６】
0005550834.tif 000015
【図７】
0005550834.tif 000016
【図８】
0005550834.tif 000017
【図９】
0005550834.tif 000018
【図１０】
0005550834.tif 000019