JP2015222954A - 放送チャネル上の高速チャネルザッピングおよび高品質ストリーム保護 - Google Patents
放送チャネル上の高速チャネルザッピングおよび高品質ストリーム保護 Download PDFInfo
- Publication number
- JP2015222954A JP2015222954A JP2015126945A JP2015126945A JP2015222954A JP 2015222954 A JP2015222954 A JP 2015222954A JP 2015126945 A JP2015126945 A JP 2015126945A JP 2015126945 A JP2015126945 A JP 2015126945A JP 2015222954 A JP2015222954 A JP 2015222954A
- Authority
- JP
- Japan
- Prior art keywords
- block
- physical layer
- data
- source
- symbols
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 claims abstract description 99
- 230000008439 repair process Effects 0.000 claims description 70
- 230000005540 biological transmission Effects 0.000 claims description 55
- 230000011664 signaling Effects 0.000 abstract description 11
- 230000008569 process Effects 0.000 description 24
- 238000013507 mapping Methods 0.000 description 12
- 238000004891 communication Methods 0.000 description 9
- 230000008901 benefit Effects 0.000 description 7
- 238000013461 design Methods 0.000 description 7
- 238000010586 diagram Methods 0.000 description 7
- 230000036961 partial effect Effects 0.000 description 7
- 238000006243 chemical reaction Methods 0.000 description 6
- 230000008859 change Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000011084 recovery Methods 0.000 description 4
- 239000000872 buffer Substances 0.000 description 3
- 238000012937 correction Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 239000000243 solution Substances 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000003139 buffering effect Effects 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 238000006731 degradation reaction Methods 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000009897 systematic effect Effects 0.000 description 2
- 239000000654 additive Substances 0.000 description 1
- 230000000996 additive effect Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000013506 data mapping Methods 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000002330 electrospray ionisation mass spectrometry Methods 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000002347 injection Methods 0.000 description 1
- 239000007924 injection Substances 0.000 description 1
- 238000002372 labelling Methods 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
- H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
- H04N21/2383—Channel coding or modulation of digital bit-stream, e.g. QPSK modulation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
- H04N21/4382—Demodulation or channel decoding, e.g. QPSK demodulation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
- H04N21/4383—Accessing a communication channel
- H04N21/4384—Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】短いチャネルザッピング時間を可能とし、高品質配信を提供するためのFECコードを利用するチャネル上でストリーミングデータを送信および受信するための方法を提供する。【解決手段】多数の物理層ブロック内でソースブロック送信のシグナリングは、ストリーミングとオブジェクト配信アプリケーションとの両方へ実行され、最小の付加オーバヘッドを使用して、いくつかの場合オーバヘッドを使用せずに、ソースブロックの順位付けされたデータの表示および送信を示し、それらが生成されるソースブロックとシンボルがどのように関連するか示し、物理層ブロック内でインターリーブされたソースブロックを示す。必要とされる受信器電力源およびチャネルリソースの必要な量の最小化または改善するとともに、1以上のチャネル上でストリームを送りおよび体系付けることが、配信されたストリームの品質の向上のために実行され得る。【選択図】図5
Description
[0001] 本特許出願は2008年5月7日出願の「放送チャネル上の高品質FECストリーム保護および高速チャネルザッピング(Fast Channel Zapping and High Quality FEC Streaming Protection over a Broadcast Channel)」と題する仮出願番号第61/051,325号に対する優先権を主張する。
[0002] 本発明は、一般に、ストリーミング(streaming)とオブジェクト配信(object delivery)に関し、特に、送出されたストリームの質を保護するためのFECを用いる、信頼性の低いチャネル上のストリーミングとオブジェクト配信に関する。
[0003] チャネル上で、一般的にオーディオおよび/又はビデオデータであり、遠隔測定データのような他のタイプのデータでもある、ストリーミングデータ送信を考慮するためのプラクティスが普及している。1つの主要な関心事は、配信されたストリームの質の保証が高いこと、例えば、全てまたは殆どのオリジナルストリームデータが1つの受信器又は一連の受信器へ配信される、あるいは、受信器又は一連の受信器での再生のビデオ品質が高いことである。例えば、ストリーミングデータが送出されるチャネルは、完全に信頼性のあるものでなく、例えば、送信でデータの部分が失われ又は破損するかもしれない。したがって、しばしば高品質配信(high quality delivery)を達成するために他の手段は配信劣化(delivery degradation)を克服するために取られることを必要とし、そのような手段はオリジナルデータストリームへのFECのアプリケーション、例えば、リンクにおいて又はパケット破損に対する保護のための物理層において、パケット損失に対して保護するためのアプリケーション層又はトランスポート層を含んでもよい。他の手段は、例えばリンク層再送プロトコル又はアプリケーション層再送プロトコルのような、損失又は破損データを再送するための再送ストラテジーを使用することを含む。
[0004] そのようなシステムを設計するときのもう1つの主要な関心事は、例えばエンドユーザがビデオストリームの視聴の開始を最初に要求したときからビデオストリームの表示の開始に要する期間、又は、ユーザ要求により始動される新たなビデオストリームの表示開始および現在のビデオストリームの表示停止に要する期間である。この期間はしばしばチャネルザッピング時間(channel zapping time)と呼ばれる。一般的に、チャネルザッピング時間が短いほどエンドユーザ経験(end user experience)が良くなり、したがってより有益な総合的サービスである。例えば、チャネルザッピング時間をできるだけ短く、例えば1秒未満とすることがしばしば要求される。
[0005] ストリームがバックチャネル(backchannel)のない高い信頼性のあるチャネル上で配信(delivery)されるとき、あるいは、ストリームがそれほど信頼性のないチャネル上で配信されるときおよび損失データの再送を要求するために使用可能なバックチャネルがあるとき、そのようなチャネルザッピング時間および高品質ストリーム配信を達成することがしばしば可能であるが、ストリームがそれほど信頼性のないチャネル上で配信されるときおよびバックチャネルが信頼性の向上のために使用されず、代わりにFECの使用が適切かもしれないときには、そのようなチャネルザッピング時間を達成することが困難である。また、代わりに、FECの使用は適切かもしれない。
[0006] 最近、伝送の間にストリーミングメディアの保護のためにFECコードを使用することを考慮するためのプラクティスが普及している。それらの例が3GPP、3GPP2およびDVBのようなグループにより規格化された無線ネットワークやインターネットを含むパケットネットワーク上に送られたとき、ソースストリームは、それが生成され又は利用可能となるようにパケットに格納され、したがってパケットはそれが生成され又は利用可能とされた順にソースストリームを受信器へ搬送する。シナリオのこれらのタイプへのFECコードの典型的なアプリケーションでは、FECコードはソースストリームを含むオリジナルソースパケットへ付加的なリペアパケット(repair packet)を加えるために利用され、これらリペアパケットはソースパケット損失が生じた場合に受信リペアパケットが損失ソースパケットに含まれたデータの修復のために用いられることができるという特性を有している。他の例において、部分的なパケット損失が生じる可能性がある、つまり、受信器は、そのパケットの他の部分を受け取る間にパケットの部分を損失し、したがって、全体的にあるいは部分的に受け取られた例において、全体的にあるいは部分的に失われたソースパケットを回復するためにリペアパケットを使用することができる。まだ他の例で、例えば、ビットの値の反転のような他のタイプのコラプション(corruption)が送られたデータに生じる場合があり、このように、リペアパケットは、そのようなコラプションを修正し、そして、できるだけ正確なソースパケットの回復を提供するために使用されてもよい。他の例において、ソースストリームは個別のパケットの中で必ずしも送られないが、その代り、例えば連続的なビット・ストリームとして送られてもよい。
[0007] ソースストリームの保護を提供するために使用することができるFECコードの多くの例がある。リード・ソロモンコード(Reed-Solomon codes)は、通信システムにおける誤りおよび消去修正のための良く知られたコードである。例えばパケットデータネットワーク上の消去修正については、リード・ソロモンコード(Reed-Solomon codes)の良く知られた効率的なインプリメンテーションは、L.リゾー(Rizzo)「信頼性のあるコンピュータ通信プロトコルのための有効な消去コード(Effective Erasure Codes for Reliable Computer Communication Protocols)」、コンピュータ通信レビュー(Computer Communication Review)、27(2):24-36 (1997年4月)(以下「リゾー」という)、および、J.Bloemer、M.Kalfane、R.Karp、M.Karpinski、M.Luby、D.Zuckerman、「An XOR-Based Erasure-Resilient Coding Scheme」、テクニカルレポート(Technical Report) TR-95-48、国際計算機科学協会、バークレー、カリフォルニア、(1995年)(以下、「XOR-リード−ソロモン」という)に記述されるようなコーシーまたはバンデルモンドの行列を使用することである。FECコードの他の例は、LDPCコード、米国特許6,307,487号(以下、「Luby I」という)および米国公開特許出願2003/0058958号(以下、「Shokrollahi I」という)に記述されたような、連鎖反応コードおよびマルチステージ連鎖反応コード、を含み、それぞれ、すべての目的のためにここに組込まれる。
[0008] リード・ソロモンコードの変形のためのFEC復号プロセスの例は、「リゾー」および、「XOR−リード−ソロモン」に記載されている。これらの例において、復号は一旦十分なソースに適用され、修復データパケットが受信される。復号プロセスは、計算上集中的であってもよく、また、利用可能なCPUリソースに依存してもよく、これがブロック中のメディアによって測定された時間長に比べて、完了するために相当な時間を要してもよい。
[0009] 多くのアプリケーションでは、パケットは、FECプロセスが適用されるシンボルへさらにサブ分割される。1つのシンボルは、どんなサイズとすることも可能であるが、しばしば1つのシンボルのサイズはパケットのサイズと高々等しい。以下に、我々は、復号ブロックを備えるシンボルを「ソースシンボル(source symbols)」と称し、FECプロセス中に生成されたシンボルを「符号化シンボル(encoding symbols)」と称する。いくつかのFECコード、特にリード・ソロモンコードについては、ソースブロック毎の符号化シンボルの数が増大するにつれて、符号化および復号化時間は非現実的に増大する。したがって、実際上、多くの場合ソースブロックにつき生成可能な符号化シンボルの総数には例えば255の上限が存在する。シンボルがしばしば異なるパケットペイロード内に配置されるためこれは時には実用的な上限であって、例えばパケットペイロードが多くとも1024バイトである場合、符号化ソースブロックが多くとも255KB(キロバイト)であって、そして、各シンボルが別個のパケットに送られた場合これは当然ながらソースブロック自身のサイズ上の上限でもある。
[0010] より大きな時間に渡って送られるデータのブロックにFECコーディングを適用することは、より小さい時間に渡って送られるデータのブロックへFECコーディングよりも、一般的に同じ帯域幅のオーバヘッドのためのより好ましい保護をストリームに提供するので、送られたストリームが大きな期間に渡って拡散する間にFEC符号化および復号化をデータのブロックに適用することはしばしば望ましい。これは、多くのチャネルが損失および/または破損に関連する時間に従うからであって、例えば、データは、破損中に失われる可能性が高く、あるいは、それらが他の短い期間に渡るよりもチャネル特性がより悪くなる短い時間である可能性が高い。
[0011] 大きな時間に渡って拡散して送られたデータのブロックに適用されたFEC符号化を使用する課題は、これがチャネルザッピング時間に不利な影響を与える可能性があることである。例えば、受信器において、符号化されたデータのブロックは完全に回復され、そして、全体のブロックに対して十分なデータが受信された後に展開されことが可能であるかもしれない。したがって、FEC符号化されたデータのブロックが大きな時間に渡って送られると、チャネルザッピング時間は容認され得ないほど高くなるかもしれない。
[0012] 大きな時間に渡ってFEC符号化されたデータのブロックを同時に送信する間に短いチャネルザッピング時間の目的を構築するための1つの方法は、FEC符号化されたデータの中で最も重要なデータが最後に送られ最も重要でないデータが最初に送られるようにデータを順序付けることである。例えば、すべての目的のためにここに組込まれる、「前方向誤り訂正(FEC:Forward Error Correcting)コーディングとストリーミング」と題された米国特許出願11/423,391号(以下に「FECストリーミング」と称する)は、例えば、ソースデータの前にFEC修復データをソースブロックへ送り、その結果、受信器がソースブロックの中程おけるストリームに結合されていたとしても、受信器がソースブロックに関するソースデータの一部を受信して例えば再生のためのメディアプレイヤーへそれを送信することを開始することを可能にし、結果としてチャネルザッピング時間を最小化するための方法を説明している。
[0013] 別の関心事は、送信される実際のデータを識別するために利用されるヘッダーデータにより利用されるチャネルリソース量を最小化することである。一般に、ヘッダーデータは、一般的に、データを配信するために利用可能な容量に否定的な影響を与えるオーバヘッドである。例えば、4バイトのヘッダーデータが100バイトの実際のデータのそれぞれを識別するために使用される場合、ヘッダーオーバヘッドは大きな4%である。特に、ストリーミングとオブジェクト配信アプリケーション(object delivery applications)との両方にとって、しかし、より一般的には任意のデータ配信アプリケーションについてヘッダーオーバヘッドをできるだけ最小化することが望ましい。
[0014] 短いチャネルザッピング時間が要求されるときに信頼性を向上するためにバックチャネル(back channels)が使用されないときに、高品質ストリームがそれほど信頼性のないチャネル上で配信されることを可能にする方法、プロセスおよび装置である。与えられた信頼性のレベルを達成するための物理リソースの最小化は、例えばヘッダーオーバヘッドおよびFECオーバヘッドのために、同様に最高に重要なことである。
[0015] 実施形態は、短いチャネルザッピング時間を可能とし高品質配信を提供するためのFECコードを利用するチャネル上でのストリーミングデータの送信および受信するための新規性のある方法およびプロセスを示す。ストリーミングおよびオブジェクト配信のためにそのようなシステムにおいて必要とされるヘッダーオーバヘッドを最小化する、新規なシグナリング方法が説明される。ストリームの保護および送信するための新規な処理も説明される。
[0016] 添付の図面と共に後述される詳細な説明は、本発明の効果および性質についてのよりよい理解を提供する。
[0023] ここに記載された実施形態は、ストリーミングとオブジェクト配信アプリケーションとの両方のための、複数の物理層ブロック内でソースブロックの送信をシグナリングするための新規性のある方法を提供する。これらのシグナリング方法は、物理層ブロック内でインターリーブされたソースブロックをシグナルするために最小の付加オーバヘッドを使用し、いくつかの場合にオーバヘッドを使用しない方法、シンボルがそれらが生成されたソースブロックに対してどのように関係するかのシグナリング、および、ソースブロックに対して優先順位付けされたデータの表示およびシグナルされた送信、を含む。必要とされる受信器の電力資源およびチャネルリソースの必要な量を最小化する、または改善するとともに、配信されるストリームの品質を改善する、ストリームを体系化し1以上のチャネル上で送信のための付加的な方法が記述される。
[0024] 以下、ここに記載されたプロセスおよび方法が連続的なビット・ストリームネットワークとして転送ネットワークの他のタイプにどのように適用されうるか当業者が容易に理解することができるという認識とともに、ここの記載を単純にするために、データを搬送するネットワークはパケットに基づくと仮定される。以下、ここに記載されたプロセスおよび方法がビット・フリップとしてデータ送信破損の他のタイプへどのように適用されうるか当業者が容易に理解することができるという認識とともに、ここの記載を単純にするために、FECコードは損失パケット又はパケット内の損失部分的データに対する保護を提供すると仮定される。
[0025] 図1は、連鎖反応コーディングを利用する通信システム100のブロック図である。通信システム100において、入力ファイル101、又は入力ストリーム105は、入力シンボル生成器110へ供給される。入力シンボル生成器110は、値および位置(括弧内の整数として図1に表示された)を持つ入力シンボルと共に、入力ファイル又はストリームから1以上の入力シンボル(IS(0)、IS(1)、IS(2)...)のシーケンスを生成する。入力シンボルの可能な値、即ちそのアルファベットは、主として2Mシンボルのアルファベットであって、その結果、各入力シンボルはMビットの入力ファイルをコード化する。Mの値は、一般的に通信システム100の利用により決定される。しかし、用途から用途へMを可変にするために、汎用システムは入力シンボル生成器110へ入力されるシンボルサイズを含んでもよい。入力シンボル生成器110の出力は、符号器115へ供給される。
[0026] 鍵生成器120は、符号器115によって生成されるべき各出力シンボルのための鍵を生成する。それらがこの又は他の鍵生成器によって生成されたかどうかに関わらず、各鍵は、Luby I又はShokrollahi Iに記載された方法、又は、ストリームにおいて同じ入力ファイル又はデータのブロックのために生成された鍵の大きな比が固有であることを保障する任意の類似の方法の1つに従って生成される。例えば、鍵生成器120は、各鍵を生成するためのランダムナンバ生成器135の出力、ユニークなストリーム識別子130、および/又は、カウンタ125の出力の組み合わせを使用しても良い。鍵生成器120の出力は符号器115へ供給される。他の例、例えばいくつかのストリーミングアプリケーションにおいて、鍵の組は、ストリーム内のデータの各ブロックについて再利用および固定されてもよい。
[0027] 符号器115は、入力シンボル生成器から供給された入力シンボルから値B(I)を生成するとともに、鍵生成器120から供給された各鍵Iからシンボルを生成する。各出力シンボルの値は、その鍵と、ここにおいて出力シンボルの「関連した入力シンボル」あるいは単にその「関連要素」と称される1以上の入力シンボルのいくつかの機能とに基づいて生成される。典型的には、常にではなく、Mは入力シンボルと出力シンボルとに対して同じである、つまり、それらは両方ともビットと同じ数に対して符号化する。
[0028] いくつかの実施例では、入力シンボルの番号Kは入力シンボルの番号Kは関連要素を選ぶために符号器によって使用される。もし、入力がストリームであってKがストリーム内の各ブロック間で可変である場合のように、Kが予め知られていない場合、Kは単に推定値であってもよい。値Kは、入力シンボルへストレージを割り付けるために符号器115によっても使用されても良い。
[0029] 符号器115は、送信モジュール140へ出力シンボルを供給する。送信モジュール140は、鍵生成器120からそのような出力シンボルのそれぞれの鍵を供給される。チャネル145を通過して受信モジュール150へ、送信モジュール140は出力シンボルを送信し、使用されるキーイング方法に依存して、送信モジュール140は送信された出力シンボルの鍵についてのいくつかのデータも送信する。チャネル145は消去(erasure)チャネルであると仮定されるが、それは通信システム100の適切なオペレーションのための要求ではない。送信モジュール140がチャネル145のためのそれらの鍵についての任意の必要なデータおよび出力シンボルの送信に適合し、受信モジュール150がチャネル145からそれらの鍵についての潜在的ないくつかのデータおよびシンボルの受信に適合する限り、モジュール140、145および150は、任意の適切なハードウエア、ソフトウエア、物理メディア、あるいは、それらの組み合わせでもよい。Kの値は、関連要素を決定するために使用される場合、チャネル145を通過して送られてもよく、あるいは、復号器155と符号器115と一致により、予め設定されてもよい。
[0030] チャネル145は、あるポイントから別のポイントへの電話コネクションやテレビジョン送信器からテレビ受像機への放送リンクあるいはインターネットを介するパスのようなリアルタイムチャネルであっても良く、また、チャネル145はCD−ROM、ディスクドライブ、ウェブサイト等のようなストレージチャネルであっても良い。パーソナルコンピュータからインターネットサービスプロバイダ(ISP)へ電話回線を通して1つの入力ファイルを送信したとき、その入力ファイルがウェブサーバーに保存され、その後インターネットを通して受信者へ送信されるチャネルのように、チャネル145は、リアルタイムチャネルとストレージチャネルとの組み合わせあってもよい。
[0031] チャネル145がパケットネットワークを含む場合、通信システム100は、チャネル145を通じた送信において任意の2以上のパケットの相対的な順序(relative order)が維持されることは想定することができない。したがって、出力シンボルの鍵は1以上の上述のキーイングスキーム(keying scheme)を用いて決定され、出力シンボルが受信モジュール150を出た順序で必ずしも決定されない。
[0032] 受信モジュール150は、復号器155へ出力シンボルを供給し、受信モジュール150が受信するこれらの出力シンボルの鍵に関する任意のデータは鍵再生成器160へ供給される。鍵際生成器160は、受信された出力シンボルのための鍵を再生成し、これらの鍵を復号器155へ供給する。復号器155は、入力シンボル(再び IS(0), IS(1), IS(2), ...)を回復するために、鍵再生成器により供給されたその鍵を対応する出力シンボルとともに使用する。復号器155は、回復された入力シンボルを、入力ファイル101のコピー170又は入力ストリーム105のコピー175を生成する入力シンボル再組立器165へ供給する。
[0033] メディアストリーミングアプリケーションにおいて使用される場合、ソースメディアストリームを形成するソースパケットはソースブロックと呼ばれるグループに時々集められる。例えば、ソースブロックは時間の固定長を測定するソースパケットのグループでありえ、例えばリード・ソロモン消去コードは、ソースブロックのオリジナルソースパケットと合わせて受信器へ送られたリペアパケットを生成するためにこれらのソースブロックへ独立に適用され得る。
[0034] 送信器(sender)では、ソースストリームは、ソースパケットが到着したときにソースブロックへ連続的に分割され、そして、リペアパケットは各ソースブロックに対して生成されて送られる。特に、ライブあるいはインタラクティブストリームアプリケーションについて、FECコードの使用により追加される末端間遅延を最小化することはより好ましく、したがって、FECソリューションのデザイン全体が、送られる前の送信器においてソースパケットができる限り遅延が少ないような場合、ソースブロックに対する全てのソースおよびリペアパケットができるだけ総遅延が少なく送られることが好ましい。FEC符号化ストリームのレートができるだけ円滑であることも好ましく、すなわち、これはFEC符号化ストリーム帯域幅用法をより予測可能にし、ネットワークおよび他の競合し得るストリーム上のインパクトを最小化するため、FEC符号化ストリームレートにおける変動ができるだけ小さい、あるいは、オリジナルソースストリームにおいてすでに存在する変動がすくなくとも拡張することがないことが好ましい。パケットにおいて、ソースブロックへ送られたデータが、パケットがソースブロックへ送られた期間に渡ってできるだけ一様に広がることが好ましく、これはバースト損失(burst losses)に対する最良の保護を供給するからである。
[0035] 受信器(receiver)では、パケットが失われ、(例えばCRCチェックを使用して、検知され廃棄され得る)エラーとともに受信された場合、十分なリペアパケットが受信されたと仮定して、リペアパケットは1以上の損失ソースパケットの回復のために使用されてもよい。
[0036] いくつかのアプリケーションにおいて、パケットはFECプロセスが適用されるシンボルにさらに細分される。いくつかのFECコード、とくにリード・ソロモン符号について、符号化および復号化時間はソースブロック毎の符号化シンボルの数が増大すると非実用的に増大し、ソースブロック毎に生成され得る符号化シンボルの総数における上限がある。シンボルは、アプリケーション層で使用される異なるパケットペイロード内に一般的に位置しているため、これが実質的な上限をソースブロックの符号化上の最大長に拘束し、これがもちろんソースブロック自身のサイズ上の上限をも拘束する。
[0037] 多くのアプリケーションのために、保護は長い期間に渡って提供されることである場合、あるいは、メディアストリームレートが高い場合、1パケット当たり1つのシンボルを搬送することによりサポートされ得るよりも大きなソースブロックサイズに渡って保護を提供することは有利かもしれない。これらの場合では、より短いソースブロックを使用し、異なるソースブロックからソースパケットをインターリーブ(interleave)することは、個々のソースブロックからのソースパケットが大きな期間にわたって広げられる解決策を提供する。別の関連方法は、パケットに適合しないより大きなシンボルから大きなソースブロックを形成し、連続するパケット内に入れられるサブシンボルにシンボルを分割することである。この方法を使用すると、シンボルに対する損失パターンあるいは潜在的な異なるサブシンボル損失を有することの犠牲(expense)において、より大きいソースブロックが維持され得る。しかしながら、チャネルが強く関連する損失あるいはバースティー(bursty)を示す多くの場合において、シンボルを備えるサブシンボルの破損あるいは損失は高度に関連し、したがって、この方法を使用するときのFEC保護の低下はほとんどない。
・用語(Terminology)
・FECコード
[0038] この記述では、我々は、符号化されるデータ(ソースデータ)は同じ長さであって、(シングルビットまでの)任意の長さでありえる「シンボル(symbol)」へ分割される。各パケット内に包含されあるいは明白に搬送されたすべてのシンボルの数とともに、シンボルはパケット内のデータネットワーク上で搬送されることが可能である。ある場合には、ソースパケットはシンボル長の倍数(multiple)でないことがあり得、その場合にはパケット内の最後のシンボルは切り捨てられてもよい。この場合、FECコーディングのために、この最後のシンボルは黙示的に固定されたビット、例えばゼロ値ビットのパターンから引き延ばされたと推定され、これらのビットはパケット内に搬送されなくても受信器は最大限のシンボルの外にこの最後の切り捨てられたシンボルを満たすことができる。他の実施例では、ビットの固定されたパターンはパケット内に置かれることができ、それによって、パケットの長さと等しい長さへシンボルを有効に詰め込むことができる。シンボルのサイズはしばしばビットで測定することが可能であり、シンボルがMビットのサイズを有している場合にはシンボルは2Mシンボルのアルファベットから選択される。非2進法数字も熟考されるが、それらがより一般的に使用されるため2進数のビットが好まれる。
・用語(Terminology)
・FECコード
[0038] この記述では、我々は、符号化されるデータ(ソースデータ)は同じ長さであって、(シングルビットまでの)任意の長さでありえる「シンボル(symbol)」へ分割される。各パケット内に包含されあるいは明白に搬送されたすべてのシンボルの数とともに、シンボルはパケット内のデータネットワーク上で搬送されることが可能である。ある場合には、ソースパケットはシンボル長の倍数(multiple)でないことがあり得、その場合にはパケット内の最後のシンボルは切り捨てられてもよい。この場合、FECコーディングのために、この最後のシンボルは黙示的に固定されたビット、例えばゼロ値ビットのパターンから引き延ばされたと推定され、これらのビットはパケット内に搬送されなくても受信器は最大限のシンボルの外にこの最後の切り捨てられたシンボルを満たすことができる。他の実施例では、ビットの固定されたパターンはパケット内に置かれることができ、それによって、パケットの長さと等しい長さへシンボルを有効に詰め込むことができる。シンボルのサイズはしばしばビットで測定することが可能であり、シンボルがMビットのサイズを有している場合にはシンボルは2Mシンボルのアルファベットから選択される。非2進法数字も熟考されるが、それらがより一般的に使用されるため2進数のビットが好まれる。
[0039] ここでストリーミングのために我々が考慮するFECコードは、典型的に系統的()なFECコードであり、すなわち、ソースブロックのソースシンボルはソースブロックの符号化の一部に含まれ、したがってソースシンボルは送信される。その後、系統的なFECコードはソースシンボルのソースブロックから若干のリペアシンボルを生成し、そして、ソースおよびリペアシンボルの組み合わせはソースブロックへ送られたシンボルの符号化である。FECコードは、必要な分のリペアシンボルを効率的に生成する機能を有している。そのようなコードは「情報添加コード(information additive code)」および「起源コード(fountain code)」と称され、これらのコードの例は「連鎖反応コード(chain reaction code)」および「多段連鎖反応コード(multi-stage chain reaction code)」を含む。
[0040] リード・ソロモンコードのような他のFECコードは、限定された数のソースシンボルから限定された数のリペアシンボルだけを生成することが実質的に可能である。これらのタイプのコードについて、ソースブロックはなお比較的大きく、ソースブロックは、ソースブロックのソースシンボルの数が最大でソースシンボルの実用的な数の上限となり、ソースブロックから生成されるリペアシンボルの望まれる数は最大でリペアシンボルの実用的な数の上限となるように、十分な大きさのシンボルに分割される。これらのシンボルが物理層パケットの送信のための適切なサイズよりも大きい場合には、シンボルはそのようなパケットにおいて個々に搬送され得るサブシンボルへさらに分割されてもよい。後の説明を単純化するために、シンボルは分割不可能なユニットとして典型的に説明され、しかし多くの場合においてシンボルは複数のサブシンボルで構成されてもよく、ここで、説明においてシンボルはサブシンボルへ分割されてもよく、結果として生じる方法およびプロセスはシンボルを用いた説明とまったく同様であるだろう。
[0041] パケット内でシンボルを搬送するための多くの他の方法があり、下記の説明はこの例を単純化するために使用するが、それは限定することおよび包括することを意味するものではない。以下の説明の文脈では、「パケット」という用語はデータの単一ユニットとして送られるものを文字通り意味することを拘束される意味ではない。代わりに、それは、データの単一ユニットとして送られても送られなくてもよい部分的なシンボルと、シンボルの論理的なグルーピングの定義との広い概念を含むことを意味する。
[0042] シンボル、例えば他の方法において破損されたあるいは送信中にそれらの値が変わったシンボルの損失以外のデータの破損の形態があり、以下に説明される方法が等しく適用される。したがって、下記の説明はシンボルの損失についてしばしば説明し、その方法は他のタイプの破損、および、FEC誤り訂正コードやFECチェックサムコードやFEC検証コードのようなFEC消去コード以外の他のタイプのFECコードに等しくよく適用する。
・ストリーミング
[0043] ソースストリームのFEC保護を提供する目的のために、ソースストリームは1以上の論理ストリームの組み合わせ、例えば、オーディオRTPストリームとビデオRTPストリームとの組み合わせ、MIKEYストリームとRTPストリームとの組み合わせ、2以上のビデオストリームの組み合わせ、および、コントロールRTCPトラヒックよRTPストリームとの組み合わせであってもよい。送信器にソースストリームが到着したときに、例えばソースビットストリーム、ソースシンボルストリーム、あるいは、ソースパケットストリームであるフォーマットでは、送信器はソースブロック内にストリームを一時記憶し、ソースブロックからリペアストリームを生成してもよい。送信器は、例えばパケットネットワーク上に送られるパケット内で、リペアストリームおよびソースストリームを送り、予定(schedules)する。FEC符号化ストリームはソースおよびリペアストリームの結合である。受信器は、例えば損失あるいはビット反転(bit-flips)により破損されたかもしれないFEC符号化ストリームを受信する。受信器は、ソースストリームの全てのオリジナルソースブロックあるいは一部を再構築することを試み、受信器において例えばメディアプレイヤーにオリジナルストリームのこれらの再構築された一部を利用可能にさせる。
・ストリーミング
[0043] ソースストリームのFEC保護を提供する目的のために、ソースストリームは1以上の論理ストリームの組み合わせ、例えば、オーディオRTPストリームとビデオRTPストリームとの組み合わせ、MIKEYストリームとRTPストリームとの組み合わせ、2以上のビデオストリームの組み合わせ、および、コントロールRTCPトラヒックよRTPストリームとの組み合わせであってもよい。送信器にソースストリームが到着したときに、例えばソースビットストリーム、ソースシンボルストリーム、あるいは、ソースパケットストリームであるフォーマットでは、送信器はソースブロック内にストリームを一時記憶し、ソースブロックからリペアストリームを生成してもよい。送信器は、例えばパケットネットワーク上に送られるパケット内で、リペアストリームおよびソースストリームを送り、予定(schedules)する。FEC符号化ストリームはソースおよびリペアストリームの結合である。受信器は、例えば損失あるいはビット反転(bit-flips)により破損されたかもしれないFEC符号化ストリームを受信する。受信器は、ソースストリームの全てのオリジナルソースブロックあるいは一部を再構築することを試み、受信器において例えばメディアプレイヤーにオリジナルストリームのこれらの再構築された一部を利用可能にさせる。
[0044] ストリーミングアプリケーションについて、ソースストリームを保護するためにFECコードを使う方法の設計への入力であるいくつかの鍵パラメータ(key parameters)と、最適化するために典型的に重要であるいくつかの鍵メトリクス(key metrics)とがある。
[0045] 設計において2つ鍵入力パラメータは、保護期間(protection period)と保護量(protection amount)である。ソースブロックのための送信器の保護期間(sender protection period)は、ソースブロックから生成されたシンボルが送られるときの期間である。ソースブロックのための保護量は、ソースブロックにおけるソースブロックの数のパーセンテージあるいは比として表現される、ソースブロックへ送られるFECリペアシンボルの数である。例えば、保護期間が2秒で保護量が20%でソースブロックに10,000ソースシンボルがある場合。10,000ソースシンボルとソースブロックのための2,000リペアシンボルとが2秒の時間ウィンドウ(window of time)に渡って送られる。ソースブロック辺りの保護量と保護期間との両方は、次の1つのソースブロックとは異なることが可能である。例えば、ソースブロックはソースストリームにおけるあるソースパケット間に渡らないことが好ましく、例えば、最初のパケットはMPEG2ビデオストリームにおける画像群(GOP)の最後のパケットであり、2番目の連続したパケットは次のGOPの最初のパケットであるとき、これが保護期間の最後よりも前に生じたとしてもソースブロックは2番目のパケットより前であって最初のパケットよりも後で終了してもよい。これは、FEC保護ブロックがビデオコーディングブロックと提携することを可能とし、ビデオバッファリングおよびFECバッファリングによる受信器の待ち時間(latency)を最小化することができる長所を含む、多くの長所を持つことが可能となる。他のアプリケーションでは、それは各連続するソースブロックについて同じ保護期間および/またはソースブロックサイズをいつも維持するための様々な理由において有利になり得る。下記の説明の多くでは、単純化のために、保護期間と保護量との両方は後のソースブロックのそれぞれについて同じであると仮定される。当業者にとって、これが限定でないことは明らかであるべきであり、保護量あるいは保護期間のどちらかが又は両方が1つのソースブロックから次へ変化するとき、および、ソースブロックサイズが1から次へ変化するとき、この開示を読むことでどのようにここに説明された方法およびプロセスが適用されるか容易に判断することができる。
[0046] 後の議論のいくつかを単純化するために、オリジナルストリームのソースシンボルは安定したレートでFECコーディングを行う送信器へ到着し、一旦受信器が最初にソースシンボルを受信器で利用可能とし、次に後のソースシンボルが同じ安定したレートで受信器により利用可能になり、ソースシンボルが受信された最初のソースブロックにおいて、ソースシンボル損失がなくそして後のソースブロックのそれぞれにおいて符号化シンボル損失はうまくいくFEC復号をさせるための最大の可能性であるという仮定が、しばしば仮定される。この単純化する仮定は、後に説明された方法およびプロセスのデザインあるいはオペレーションにおいて固有ではなく、任意の方法でこの仮定にこれらプロセス限定することを目的としないが、方法およびプロセスのプロパティの説明のいくつかを単純化するためのツールとして単に導入される。例えば、可変レートストリームについて対応する条件は、送信器にそれらが到着するときと同じレートに近いあるいは同じで、ソースシンボルが受信器によって利用可能となることである。
[0047] 最小化するべき重要性のいくつかの鍵メトリクス(key metrics)は、送信器により導入された待ち時間である送信器待ち時間を含む。送信器待ち時間の最小化は、ビデオ会議のようなインタラクティブアプリケーションあるいはライブビデオストリーミングのようないくつかのアプリケーションにとって望ましい目標である。送信器待ち時間を最小化することを支援する全てのデザインの一態様は、送信器へそれらが送信器に届くときと同じ順序でソースシンボルを送ることである。送信器待ち時間を最小化する他のデザインの態様は後述される。
[0048] 別の重要な測定法はチャネルザッピング時間である。これは受信器がストリームを要求あるいは結合するときと、受信器がストリームから利用可能なソースシンボルを最初に生成するときまでストリームから符号化シンボルの受信を最初に開始するときとの間の時間である。例えばビデオストリームの再生について、ストリームが最初に利用可能になり始めるときと、ストリームが結合されるときとの間の時間も最小化し、それらが受信器により復号され渡される前にこれが受信器におけるストリーミングシンボルのためのメモリ要求を最小化するため、一般に、チャネルザッピング時間を最小化することがのぞましい。
[0049] 多くの既知のシステムについて、チャネルザッピング時間を最小化する重要な一態様は、送信器のためにソースシンボルのオリジナル送信順序(original sending order)を維持することである。後のセクションでは、我々は、ブロック内でソースシンボルを順序化し符号化(ordering and encoding)する新しい方法、FECコードを適用すること、および、チャネルザッピング時間を最小化する方法において符号化データを各ソースブロックへ送信することを説明する。
[0050] 我々がいま説明するように、多くの既知のシステムにとって、チャネルザッピング時間は典型的に多数のコンポーネントを備えている。連続するソースブロックへ分割されるストリームのためのこれらのコンポーネントの一例は、図2に示される。図2は、各ソースブロックのための保護シンボルがそのソースブロックのためのソースシンボルの直後に送られる保護期間毎の単一のソースブロックがある古典的なIPTV配置において使用されるかもしれないデザインを示し、例はソースブロックの開始において受信器がストリームを結合する場合を示す。この例におけるチャネルザッピング時間の2つのコンポーネントは保護期間と復号待ち時間(decode latency)である。受信器保護期間は受信器がソースブロックから受信された符号化シンボルをバッファする間の時間である。仮に送信器と受信器との間のチャネルが各ビット、バイト、シンボルあるいはパケットが送信器から受信器へ移動するためにかかる時間の量の期間における変化がない場合、送信器保護期間と受信器保護期間とは同じであることに注意する。したがって、事実上、送信器保護期間は配信におけるネットワークタイミング変化により同じソースブロックについて受信保護期間と異なっていてもよい。説明の単純化のために、我々は送信器保護期間と受信器保護期間とは各ソースブロックについて同じであると以下で仮定し、我々は送信器保護期間と受信器保護期間とに対して同じように「保護期間」という用語を使用する、つまり、ネットワーク配信時間は全てのデータについて同じであると我々は仮定し、当業者はネットワーク配信変動による送信器および受信器保護期間における差を考慮して、ここにおいて説明された装置および方法への必要な変更をすることができると我々は注意する。
[0051] 最初のソースブロックにおいていずれのソースシンボルの損失がない場合であっても、当業者は、後のソースブロックにおいて符号化シンボルの損失があるとき全ての後のソースシンボルの円滑なソースシンボル配信を保証するために、少なくとも保護期間の間、ソースシンボルを利用可能とし遅らせなければならないため、受信器待ち時間の保護期間コンポーネントは、これらの既知のシステムにおいて避けられない。保護期間中に、ソースブロックのいくつかあるいは大部分あるいは全てのFECコーディングは符号化シンボルの受信と同時に生じうる。保護期間の最後において、ソースブロックの最初のソースシンボルが受信器から利用可能となる前に生じる付加的なFEC復号があり得る、この期間は図2における復号待ち時間(decode latency)として名称付けられる。さらに、最初のソースシンボルが利用可能となった後であっても、ソースブロックの2番目および後のソースシンボルが利用可能となる前に生じる付加的なFEC復号があり得る。簡単のために、この付加的な復号は図2に示されず、この例において十分に速いレートで1番目の後の全てのソースシンボルを復号するための十分に利用可能なCPU資源があると仮定される。
[0052] これら既知のシステムにおいて、受信器がソースブロックの真ん中のストリームを結合しようとするとき、送信器によりソースパケットのオリジナル送信順が維持される限り、チャネルザッピング時間は最初の部分的なソースブロックからのソースシンボルの損失がないときの復号待ち時間と保護期間との和と同じくらい小さくなり得る。したがって、これらの既知のシステムについて、ソースシンボルのオリジナル送信順を維持することは送信器によって望ましい。
[0053] ストリーミング方法の別の目標は、FEC復号が実行された後、受信器における再生にそれが利用可能であるときと、ソースパケットFEC符号化が実行される前に送信器においてソースパケットがストリーミングのために準備されるときとの間に、FECの使用により導かれる待ち時間の全体で最悪の場合であるFEC末端間の待ち時間を最小化することであって、
[0054] ストリーミング方法の別の目標は、FECが使用されるときの送信レートにおける変動を最小化することである。この目標の1つの理由は、パケットネットワーク内では、変動する送信レートでのストリームは、ストリームの送信レート内のピークが制限された容量でネットワーク内のポイントで他のトラヒックでピークと一致するときのバッファオーバフローあるいはデータ過剰によるパケット損失により影響を受けやすいことである。最小では、FEC符号化ストリームのレートの変動はオリジナルソースストリームのレートの変動よりも悪くないべきであり、望ましくは、FEC保護がオリジナルソースストリームへより適用されると、FEC符号化ストリームのレートの変動がより小さくなる。特別の場合として、仮にオリジナルストリームが一定レートで送られる場合、FEC符号化ストリームも一定数にできるだけ近いレートで送るべきである。
[0054] ストリーミング方法の別の目標は、FECが使用されるときの送信レートにおける変動を最小化することである。この目標の1つの理由は、パケットネットワーク内では、変動する送信レートでのストリームは、ストリームの送信レート内のピークが制限された容量でネットワーク内のポイントで他のトラヒックでピークと一致するときのバッファオーバフローあるいはデータ過剰によるパケット損失により影響を受けやすいことである。最小では、FEC符号化ストリームのレートの変動はオリジナルソースストリームのレートの変動よりも悪くないべきであり、望ましくは、FEC保護がオリジナルソースストリームへより適用されると、FEC符号化ストリームのレートの変動がより小さくなる。特別の場合として、仮にオリジナルストリームが一定レートで送られる場合、FEC符号化ストリームも一定数にできるだけ近いレートで送るべきである。
[0055] ストリーミング方法の別の目標は、受信器で出来るだけ単純なロジックで使用することである。受信器は限定されたコンピュータ計算のメモリおよび他の資源能力を持つ装置内に構築されるため、これは多くの事情において重要である。さらに、いくつかの場合において、送信におけるシンボルのかなりの破損あるいは損失があるかもしれず、したがって、受信器は、コンディションが改善するとき受信が継続しているストリーム内から理解するための状況がなくあるいは殆どない壊滅的な損失あるいは破損シナリオから回復しなければならないかもしれない。したがって、より単純でより強い受信器ロジックはより速く確実な受信器はストリームの受信からソースストリームのソースシンボルを再び利用可能とし、回復し始めることが出来るだろう。
[0056] あるソースブロックへ送られるFEC符号化データが、他のソースブロックへ送られるデータがインターリーブされたより大きな期間に渡って送られるとき、ソースブロックへのFEC符号化データの送信は、チャネルにおける破損あるいは損失に対する最良の可能な保護を保証するためにできるだけ一様な時間に渡って発送されるべきである。
[0057] ソースブロックへのデータの送信は、タイムリーな様式において、決定された優先順で受信器がソースブロックのソースデータを回復することが出来るような状態であるべきである。
[0058] ストリームへ送られたデータは、ヘッダーオーバヘッドを最小化するために、ストリームに対応するできるだけ小さなヘッダー情報とともに送られるべきである。好ましくは、ストリームとともにヘッダー情報が送られず、ヘッダー情報のいくつかあるいは全てはシステムに埋め込まれた他の情報からすでに利用可能であるか、あるいはそれから導出される、および/又は、ヘッダー情報のいくつかあるいは全ては受信器における情報の到着のタイミングのような他の情報から推測され得る。
[0059] 次のセクションでは我々は、いくつかあるいは全てのこれらの目標に適合する装置、プロセスおよび方法について説明する。
・改善された送信および受信方法とプロセス
[0060] ある場合には、ブロックとして配信されるべきデータは優先させることが可能である。他の場合には、ブロックとして配信されるべきデータは必ずしも優先されない。いずれの場合も、データのオリジナルストリームはソースブロックに分割され、FECリペアデータは個々のそのようなソースブロックのために生成され、個々のそのようなソースブロックのための、そのソースブロックから生成されたFECリペアデータとオリジナルソースブロックデータとを備える符号化データは、ソースブロックのオリジナルプレイアウト時間よりも長い時間に渡って広げられる(したがって後のソースブロックのための符号化データは互いがインターリーブされる)。これらの場合には、適用されるFECコードは望まれる保護量までデータの損失に対するストリーム内のデータを保護する消去コードであり得、さらに、エラーを訂正するコードであるFECコード、あるいはデータの完全性を証明するために使用され得るFECコードのような他のタイプのFECコードも熟考するものである。これらの場合には、保護期間と称されるソースストリームの個々のソースブロックのための符号化データが送信される時間が長くなると、保護期間に渡って符号化データがより均等に広げられ、アプリケーション層FECコードにより提供されたパケット損失に対する保護のレベルが良くなる。
・改善された送信および受信方法とプロセス
[0060] ある場合には、ブロックとして配信されるべきデータは優先させることが可能である。他の場合には、ブロックとして配信されるべきデータは必ずしも優先されない。いずれの場合も、データのオリジナルストリームはソースブロックに分割され、FECリペアデータは個々のそのようなソースブロックのために生成され、個々のそのようなソースブロックのための、そのソースブロックから生成されたFECリペアデータとオリジナルソースブロックデータとを備える符号化データは、ソースブロックのオリジナルプレイアウト時間よりも長い時間に渡って広げられる(したがって後のソースブロックのための符号化データは互いがインターリーブされる)。これらの場合には、適用されるFECコードは望まれる保護量までデータの損失に対するストリーム内のデータを保護する消去コードであり得、さらに、エラーを訂正するコードであるFECコード、あるいはデータの完全性を証明するために使用され得るFECコードのような他のタイプのFECコードも熟考するものである。これらの場合には、保護期間と称されるソースストリームの個々のソースブロックのための符号化データが送信される時間が長くなると、保護期間に渡って符号化データがより均等に広げられ、アプリケーション層FECコードにより提供されたパケット損失に対する保護のレベルが良くなる。
[0061] 本発明の一実施例では、符号化データの送信は等しいサイズ、例えば120バイト毎、ここでは物理層パケットと称される中の物理チャネルに送られる。物理層パケットは、破損から物理層パケットそれぞれを保護するためにそれらに適用された物理層FECコードを有していてもよい。ある場合には、物理層パケットの数は、スロット、例えば512の物理層パケットについて、等しい数の物理層パケットのスロットへ分割される。物理層のプロトコルは、時々、各タイムスロット内の物理層パケットを区別し、独自に認定することが出来る。これらの場合には、FECシンボルは物理層パケットに直接マップされることができ、さらに、物理層パケットで搬送されるシンボルの識別は、シンボルデータとともに各物理層パケット内でシンボル識別データを搬送するための必要性を完全に取り除くこと、必要性を軽減すること、あるいは、物理層パケットの同一性を決定する方法により完全にあるいは大部分が決定され得る。ある場合には、シンボル識別データの部分的な量、あるいは、シンボルが生成されるソースブロックあるいはストリームの部分についてのいくつかの情報は、シンボルとともに物理層パケットに搬送されることが好ましい。例えば、121バイトの物理層パケットについて、1バイトのそのようなシンボル識別データがあってもよく、シンボルサイズは残りの120バイトであってもよく、一方で、オリジナルソースストリームからシンボルがどのように生成されたか完全に判断することは、例えば物理層を含むフレームおよび/または物理層パケットの受信タイミングにより、および/または、物理層パケットを含むフレームの識別子による、および/または、フレーム内の物理層パケットの位置によって、物理層パケットが独自に識別された方法およびシンボルとともに物理層パケット内に搬送されたシンボル識別データの組み合わせのからであるかもしれない。例えば、ソースシンボルが由来する多数のストリームのストリームにより分類された、および/または、ソースブロックの部分が一部であるデータの優先により分類されたソースブロックの例えば異なる部分から、1バイトの識別子は、シンボルが由来するソースブロックの部分を識別する。
[0062] 例えば「FECストリーミング」で説明されたように、仮にソースパケットよりも前にリペアパケットが送られる場合、ある改良は上記プロセスに成すことが可能である。ソースパケットは一般にリペアパケットの後に送られるためバッファに保存されるため、このアプローチは送信器において付加的な遅延の注入する損害がある。別の例として、リペアデータは全てのまたは一部のソースブロックのいずれかから生成され得る。例えば、リペアデータの部分は、ソースブロックの全体から生成されてもよく、他の部分は1以上のソースブロックの他の優先層から生成されてもよい。1以上の物理層パケットに渡り得るアプリケーション層パケットまたは物理層パケットにシンボルとともに搬送された識別シンボルデータがある場合、リペアシンボルのためのこの識別シンボルデータの部分はそれが生成されたソースブロックの部分を識別するかもしれない。
・シグナリング方法
[0063] いくつかの実施例では、各シンボルについて、シンボルに関連するヘッダーデータ、例えばヘッダーデータの1バイトは、そのシンボルについての信号情報、例えばもし1ストリーム以上ある場合にはストリーム識別子、もし1以上の物理層ブロックに渡って送られるべきソースブロックがある場合にはセグメント識別子、もしソースブロックが多数のサブブロックを備える場合にはサブブロック識別子、ソースブロック内のシンボルのシンボル順によるソースブロック内のシンボルの位置、等のために使用され得る。いくつかの実施例では、いくつか又は全てのこのヘッダーデータは物理層パケットにおける各シンボルとともに送信され得る。他の実施例では、各シンボルのためのヘッダーデータは、主としてあるいは殆ど他の情報から得られ、物理層パケット内で各シンボルとともに送られるヘッダーデータはない、あるいは殆どない。
・ソースブロック内のシンボル
[0064] 好ましくは、ソースブロックのシンボルの順序は、明示的にあるいは暗黙のいずれかに決定され、受信器と送信器と同じ順序である。順序におけるある他の望ましい特性は、時々、ストリーミングあるいはオブジェクト配信アプリケーションに有益である。好ましい特性は、例えば、ソースブロックのシンボルの順序は、全てのリペアシンボルが続く順で最初に全てのソースシンボルを有する。別の例は、シンボルはソースブロックのサブブロック構造により決定された順である、例えば、全てのソースブロックの最初のサブブロックに関連する全てのシンボルが最初に順序付けされ、ソースブロックの2番目のサブブロックと関連する全てのシンボルが2番目に順序付けされる等である。以前に説明したように、シンボルは多数のサブシンボルを備えていても良い。
・ソースブロック内のESI
[0065] ESI(符号化シンボル識別子(encoded symbol identifier))は、ソースブロックにおいてソースシンボルの数のような他の情報と協同するいくつかの場合では、シンボルがソースブロックからどのように生成されるか決定する任意の識別子である。ESIは、送信器においシンボルを生成するために、あるいは、受信器においてシンボルを回復するおよび/又は識別するために明白に使用され得る、又は、ESIは暗黙に使用され得る。好ましくは、各ソースブロックのシンボルは、送信器と受信器とがシンボル順序内のシンボルの位置から得られるシンボルのESIを決定し得る方法で順序付けられる。例えば、シンボルはソースブロックのシンボル順でj番目のシンボルである場合、jが正整数であり、そのシンボルのESIがjである場合であるかもしれない。
・シグナリング方法
[0063] いくつかの実施例では、各シンボルについて、シンボルに関連するヘッダーデータ、例えばヘッダーデータの1バイトは、そのシンボルについての信号情報、例えばもし1ストリーム以上ある場合にはストリーム識別子、もし1以上の物理層ブロックに渡って送られるべきソースブロックがある場合にはセグメント識別子、もしソースブロックが多数のサブブロックを備える場合にはサブブロック識別子、ソースブロック内のシンボルのシンボル順によるソースブロック内のシンボルの位置、等のために使用され得る。いくつかの実施例では、いくつか又は全てのこのヘッダーデータは物理層パケットにおける各シンボルとともに送信され得る。他の実施例では、各シンボルのためのヘッダーデータは、主としてあるいは殆ど他の情報から得られ、物理層パケット内で各シンボルとともに送られるヘッダーデータはない、あるいは殆どない。
・ソースブロック内のシンボル
[0064] 好ましくは、ソースブロックのシンボルの順序は、明示的にあるいは暗黙のいずれかに決定され、受信器と送信器と同じ順序である。順序におけるある他の望ましい特性は、時々、ストリーミングあるいはオブジェクト配信アプリケーションに有益である。好ましい特性は、例えば、ソースブロックのシンボルの順序は、全てのリペアシンボルが続く順で最初に全てのソースシンボルを有する。別の例は、シンボルはソースブロックのサブブロック構造により決定された順である、例えば、全てのソースブロックの最初のサブブロックに関連する全てのシンボルが最初に順序付けされ、ソースブロックの2番目のサブブロックと関連する全てのシンボルが2番目に順序付けされる等である。以前に説明したように、シンボルは多数のサブシンボルを備えていても良い。
・ソースブロック内のESI
[0065] ESI(符号化シンボル識別子(encoded symbol identifier))は、ソースブロックにおいてソースシンボルの数のような他の情報と協同するいくつかの場合では、シンボルがソースブロックからどのように生成されるか決定する任意の識別子である。ESIは、送信器においシンボルを生成するために、あるいは、受信器においてシンボルを回復するおよび/又は識別するために明白に使用され得る、又は、ESIは暗黙に使用され得る。好ましくは、各ソースブロックのシンボルは、送信器と受信器とがシンボル順序内のシンボルの位置から得られるシンボルのESIを決定し得る方法で順序付けられる。例えば、シンボルはソースブロックのシンボル順でj番目のシンボルである場合、jが正整数であり、そのシンボルのESIがjである場合であるかもしれない。
[0066] 好ましくは、しかし排他的でなく、シンボルのESL間の配置およびシンボル順序は、送信器と受信器との両方により容易に計算することが出来る。例えば、順序付けされたシンボルの組みの連続するESIは、0、1、2、3、・・・j、j+1、等であってもよく、すなわち、ESIはゼロで始まる連続する整数列であり、この場合では、したがってシンボル位置はESIと同じである。別の例として、順序付けされたシンボルの組の連続するESIは、5、10、15、20、・・・、5*j、5*(j+1)、等である。シンボル順序内でシンボル位置が与えられたシンボルが与えられるためのESIを決定することを受信器と送信器との両方が可能とする順序付けされたシンボルの組のSEIの配置を決定する多くの他の方法がある。好ましくは、送信器と受信器との両方により計算することが容易であるESIシーケンスは、ソースブロックと関連するシンボルのシンボル順を表現するためにしようされ得る。
・物理層ブロック内の物理層パケット
[0067] 物理層パケットが物理層ブロックで送られるとき、物理層ブロック内での物理層パケットの順序付けは全体的な構造の特性によりしばしば決定され得る。さらに、別の物理層ブロックからある物理層ブロックの区別は、例えば物理層シグナリングとタイミング情報とに基づいて、送信器および受信器により決定され得る。順序付けられたシンボルは、線形一致マッピングを含む様々な異なる方法を使用する、あるいは、連続するシンボルが、物理層ブロックの送信内で時間変化に富んだ方法で送信される物理層パケットへ配置されることを保証するマッピングを使用する物理層パケットへ配置されてもよく、例えば各連続するシンボルは、物理層ブロックの送信の異なる時象限で送られた物理層パケットに配置され、あるいは、連続するシンボルは主として異なる周波数の組(divergent sets of frequencies)で物理層パケットへ配置される。物理層ブロックで送られるべき順序付けされたシンボルの組は、全てのセグメント識別子の数が1以上であってもよい場合に、3番目のセグメント識別子と関連するシンボルが後続する、2番目のセグメント識別子と関連するシンボルが後続する1番目のセグメント識別子と関連するシンボル、等で構成されてもよい。各セグメント識別子と関連するシンボルの中で、シンボルはESIを連続的に増加させることにより順序付けされるかもしれない。望ましい特性は、物理層ブロック内で物理層パケットと順序付けされたシンボルとの間をマッピングがよく知られている(明示的にあるいは暗黙に)、および、送信器および受信器により決定することが容易であることである。
・物理層ブロック内の物理層パケット
[0067] 物理層パケットが物理層ブロックで送られるとき、物理層ブロック内での物理層パケットの順序付けは全体的な構造の特性によりしばしば決定され得る。さらに、別の物理層ブロックからある物理層ブロックの区別は、例えば物理層シグナリングとタイミング情報とに基づいて、送信器および受信器により決定され得る。順序付けられたシンボルは、線形一致マッピングを含む様々な異なる方法を使用する、あるいは、連続するシンボルが、物理層ブロックの送信内で時間変化に富んだ方法で送信される物理層パケットへ配置されることを保証するマッピングを使用する物理層パケットへ配置されてもよく、例えば各連続するシンボルは、物理層ブロックの送信の異なる時象限で送られた物理層パケットに配置され、あるいは、連続するシンボルは主として異なる周波数の組(divergent sets of frequencies)で物理層パケットへ配置される。物理層ブロックで送られるべき順序付けされたシンボルの組は、全てのセグメント識別子の数が1以上であってもよい場合に、3番目のセグメント識別子と関連するシンボルが後続する、2番目のセグメント識別子と関連するシンボルが後続する1番目のセグメント識別子と関連するシンボル、等で構成されてもよい。各セグメント識別子と関連するシンボルの中で、シンボルはESIを連続的に増加させることにより順序付けされるかもしれない。望ましい特性は、物理層ブロック内で物理層パケットと順序付けされたシンボルとの間をマッピングがよく知られている(明示的にあるいは暗黙に)、および、送信器および受信器により決定することが容易であることである。
[0068] 前に説明したように、シンボルは多数のサブシンボルで構成されてもよく、各物理層パケットは1以上のサブシンボルを搬送することが可能であってもよいが、シンボルを搬送するために十分大きくないかもしれない。この場合では、物理層パケットへシンボルをマッピングするためのプロセスおよび方法の前の説明は、この一層の考察を考慮に入れるために容易に修正され得る。例えば、ESIは、シンボルだけでなくシンボル内の特定のサブシンボルも識別するために修正されることが可能で、例えば、ESIはシンボルおよびサブシンボル識別子の両方である。別の例として、マッピングはシンボルのサブシンボルがいつも連続的に送られるような状態でもよく、順序付けられたシンボルから物理層パケットへのマッピングはシンボルの最初のサブシンボルを搬送する物理層パケットを識別する。
[0069] ある場合には、多くのシグナリングデータ(signaling data)は、物理層ブロック、例えば、物理層ブロックヘッダー情報内で搬送される他の情報、物理層ブロック識別子、および、物理層ブロック内で物理層パケットの位置からシンボルの順序付けにおけるシンボルの位置あるいはシンボルのESIを導く機能において利用可能であり得る。
[0070] 本発明のある実施例において、1つのシンボル、ソース又はリペアシンボルのいずれかは、ヘッダー識別データの最小の量とともに各物理層パケットにおいて搬送される。ソースブロックの順序付けられたシンボルの組は、送信器と受信器との両方に良く知られたプロセスを使用する物理層ブロック内で物理層パケットに連続して配置される。例えば、順序付けされた512シンボルの組は512の物理層パケットに連続して配置され得る。シンボルの順序付けは、送信器で決定され、帯域外で明白に受信器と通信するあるいは各ブロックのシンボルの順序を決定する前もって定義されたプロセスを通じて送信器と受信器との間で望ましくは暗黙に通信されることのいずれかが可能である。1以上のソースブロックに由来するシンボルが同じ物理層ブロック内に物理層パケットに配置されるべきとき、仮にソースブロックが順序付けされるならば、ソースブロックの順序とともに各ソースブロックについてのシンボルの順序付けは、物理層ブロック内で物理層パケットに配置されるべき全てのシンボルの順序付けを決定するために使用され得る。他の実施例では、多数のシンボルは各物理層パケットにおいて搬送される。まだ他の実施例では、シンボルは1つ以上の物理層パケットに渡ってもよく、例えば、シンボルがサブシンボルに分割されるとき各サブシンボルは物理層パケット内に搬送される。当業者は、ここに説明された方法およびプロセスがこれらの他の実施例にも適用可能であることを認識するだろう。
[0071] ある実施例において、物理層ブロックは異なる層でのブロック、例えば論理ブロックあるいはデータ、又は、データのアプリケーション定義ブロック、又は、送信ブロック、又は、メディア層ブロックであり得る。さらに、物理層パケットは送信パケット、又は、論理パケット、又は、アプリケーションパケット、又は、メディア層パケットであり得る。当業者はこれらの実施例の多くの本質的に等価な変形があることを認識するだろう。
・セグメント
[0072] ソースブロックに関連したソースおよびリペアシンボルは1以上の物理層ブロック内に送られることが可能である。ソースあるいはリペアシンボルのセグメント識別子は、好ましくは逆順で、ソースブロックの任意のシンボルを搬送する最初の物理層に比べてシンボルがどの物理層ブロックに搬送されるかを示すために使用されることが可能である。例えば、ソースブロックに関連した全てのシンボルは、セグメント識別子0を有し得るソースブロックの任意のシンボルを搬送する最後の物理層ブロックに搬送され、個々の前の物理層ブロック内の全てのシンボルのセグメント識別子は、そのソースブロックの任意のシンボルを搬送する後の物理層ブロック内のセグメント識別子よりも1大きいセグメント識別子を有することが出来る。全ての継続する物理層ブロックがそのソースブロックのシンボルを搬送する物理層ブロック内の特定のソースブロックのシンボルを搬送するとは限らないかもしれない、例えば、最初の物理層ブロックはシンボルをあるソースブロックへ搬送し、次の2番目の物理層ブロックはそのソースブロックへいずれのシンボルも搬送しないかもしれないが、次の3番目の物理層ブロックはそのソースブロックへシンボルを搬送するかもしれない。他の場合では、ソースブロックのセグメント構造は、別のソースブロックの新しいセグメントの開始およびあるソースブロックのあるセグメントの終わりを示すセグメント境界指標である物理層ブロック、又は、物理層パケットの順序内での例えば物理層パケット位置を示すことにより示されてもよい。例えば、最初の500の物理層パケットは最初のソースブロックに由来するセグメントに対応し、次の600の物理層パケットは2番目のソースブロックに由来するセグメントに対応し、残りの900の物理層パケットは3番目のソースブロックに由来するセグメントに対応する、2000の物理層パケットを備えた物理層ブロックについて、セグメント境界指標500、600は、最初のソースブロックのセグメントが最初の500の物理層パケットに対応すること、2番目のソースブロックのセグメントが次の600の物理層パケットに対応すること、そして、3番目のソースブロックのセグメントが残りの900の物理層パケットに対応することを示すために使用されてもよい。あるいは、セグメント境界識別子はシンボルのユニットで表現されてもよく、物理層ブロック内でのシンボルの順序に関連して決定されてもよい。
・セグメント
[0072] ソースブロックに関連したソースおよびリペアシンボルは1以上の物理層ブロック内に送られることが可能である。ソースあるいはリペアシンボルのセグメント識別子は、好ましくは逆順で、ソースブロックの任意のシンボルを搬送する最初の物理層に比べてシンボルがどの物理層ブロックに搬送されるかを示すために使用されることが可能である。例えば、ソースブロックに関連した全てのシンボルは、セグメント識別子0を有し得るソースブロックの任意のシンボルを搬送する最後の物理層ブロックに搬送され、個々の前の物理層ブロック内の全てのシンボルのセグメント識別子は、そのソースブロックの任意のシンボルを搬送する後の物理層ブロック内のセグメント識別子よりも1大きいセグメント識別子を有することが出来る。全ての継続する物理層ブロックがそのソースブロックのシンボルを搬送する物理層ブロック内の特定のソースブロックのシンボルを搬送するとは限らないかもしれない、例えば、最初の物理層ブロックはシンボルをあるソースブロックへ搬送し、次の2番目の物理層ブロックはそのソースブロックへいずれのシンボルも搬送しないかもしれないが、次の3番目の物理層ブロックはそのソースブロックへシンボルを搬送するかもしれない。他の場合では、ソースブロックのセグメント構造は、別のソースブロックの新しいセグメントの開始およびあるソースブロックのあるセグメントの終わりを示すセグメント境界指標である物理層ブロック、又は、物理層パケットの順序内での例えば物理層パケット位置を示すことにより示されてもよい。例えば、最初の500の物理層パケットは最初のソースブロックに由来するセグメントに対応し、次の600の物理層パケットは2番目のソースブロックに由来するセグメントに対応し、残りの900の物理層パケットは3番目のソースブロックに由来するセグメントに対応する、2000の物理層パケットを備えた物理層ブロックについて、セグメント境界指標500、600は、最初のソースブロックのセグメントが最初の500の物理層パケットに対応すること、2番目のソースブロックのセグメントが次の600の物理層パケットに対応すること、そして、3番目のソースブロックのセグメントが残りの900の物理層パケットに対応することを示すために使用されてもよい。あるいは、セグメント境界識別子はシンボルのユニットで表現されてもよく、物理層ブロック内でのシンボルの順序に関連して決定されてもよい。
[0073] ある好ましい実施例では、各物理層ブロック内で、各セグメント識別子に関連した高々1つのソースブロックがあり、したがって、セグメント識別子は異なるソースブロックに由来するシンボルの独自の区別のために使用されることが可能で、したがって、これらの場合にはセグメント識別子は物理層ブロック内に搬送されたシンボルを区別するためのソースブロック識別子として使用される。他の実施例では、シンボルのソースブロック識別子は他の手段、例えば、各シンボルに関連したヘッダー情報内のソースブロック識別子を含むこと、又は各物理層ブロックに関連したヘッダーデータ内のソースブロック識別子を含むことによって搬送される。ソースブロック識別子が物理層ブロックのヘッダー内で必ずしも搬送されないが、他の代替の場所、例えばコントロールデータストリーム、多数の物理層ブロックのヘッダー情報を含む個別の物理層ブロック内、あるいは、別のネットワークを介する送信で搬送されることが可能である他の変形がある。当業者は多くの同様の変形を認識するだろう。
・サブブロック
[0074] 符号化されたあるいは符号化されなかったソースブロックは1以上のサブブロック、例えば、論理的に関連したシンボルの部分に対応するソースブロックに関連した異なるソースおよびリペアシンボルに対応したサブブロックを備えていてもよい。例えば、1番目のサブブロックを備えた1番目のソースおよび/またはリペアシンボルの組は、ソースブロックに関連したビデオの部分の低解像度ビデオを表示するために使用することが出来るソースブロックの部分に対応してもよく、しかし。2番目のサブブロックを備える2番目のソースおよび/またはリペアシンボルの組は、1番目のサブブロックのいくつか又は全てとともに使用されたときソースブロックと関連したビデオの部分の高解像度ビデオを表示することが可能であってもよい。別の例として、サブブロック識別子はいくつか又は全てのソースブロックに関連したリペアシンボルを識別してもよく、あるいは、サブブロック識別子はいくつか又は全てのソースブロックに関連したソースシンボルを識別してもよい。ある場合には、サブブロック識別子は番号で明示的に各サブブロックにラベルを付すことにより示されてもよい。例えば、ソースブロックの1番目のサブブロックはサブブロック識別子0を有してもよく、しかし、ソースブロックの2番目のサブブロックはサブブロック識別子1を有してもよい。他の例では、サブブロック構造は、例えばシンボル順又はESI内での新たなサブブロックの開始およびあるサブブロックの最後を示すサブブロック境界指標であるシンボル順内でのシンボルの位置あるいはESIを示すことにより示されてもよい。例えば、900のソースシンボルと100のリペアシンボルとを備えたソースブロックについて、シンボルのESIはゼロで始まる整数の連続であり、1番目のサブブロックはソースシンボルを備え、2番目のサブブロックはリペアシンボルを備え、サブブロック境界指標900は1番目のサブブロックは0から899までのESIを有するシンボルに対応し、2番目のサブブロックは900のESIを有するシンボルで開始することを示すために使用されてもよい。ソース又はリペアシンボルのサブブロック識別子はシンボルがどのサブブロックの部分かを示す。
・各シンボル方法で送信されたヘッダーデータ
[0075] 一実施例では、物理層パケット内のシンボルとともに送られるべき各シンボルに関連したヘッダーデータはセグメント識別子、サブブロック識別子、および、ESIを備えている。例えば、可能なセグメント識別子の数が8で、可能なサブブロック識別子の数が8で、ESIの数が1024である場合、ヘッダーデータの等しく2バイト、つまり16ビットは各シンボルにとって十分である。物理層ブロック内の各物理層パケット内で、物理層パケットのコンテンツはシンボルに関連したヘッダーデータとともにシンボルを備え、ヘッダーデータはセグメント識別子とサブブロック識別子とを備える。
・サブブロック
[0074] 符号化されたあるいは符号化されなかったソースブロックは1以上のサブブロック、例えば、論理的に関連したシンボルの部分に対応するソースブロックに関連した異なるソースおよびリペアシンボルに対応したサブブロックを備えていてもよい。例えば、1番目のサブブロックを備えた1番目のソースおよび/またはリペアシンボルの組は、ソースブロックに関連したビデオの部分の低解像度ビデオを表示するために使用することが出来るソースブロックの部分に対応してもよく、しかし。2番目のサブブロックを備える2番目のソースおよび/またはリペアシンボルの組は、1番目のサブブロックのいくつか又は全てとともに使用されたときソースブロックと関連したビデオの部分の高解像度ビデオを表示することが可能であってもよい。別の例として、サブブロック識別子はいくつか又は全てのソースブロックに関連したリペアシンボルを識別してもよく、あるいは、サブブロック識別子はいくつか又は全てのソースブロックに関連したソースシンボルを識別してもよい。ある場合には、サブブロック識別子は番号で明示的に各サブブロックにラベルを付すことにより示されてもよい。例えば、ソースブロックの1番目のサブブロックはサブブロック識別子0を有してもよく、しかし、ソースブロックの2番目のサブブロックはサブブロック識別子1を有してもよい。他の例では、サブブロック構造は、例えばシンボル順又はESI内での新たなサブブロックの開始およびあるサブブロックの最後を示すサブブロック境界指標であるシンボル順内でのシンボルの位置あるいはESIを示すことにより示されてもよい。例えば、900のソースシンボルと100のリペアシンボルとを備えたソースブロックについて、シンボルのESIはゼロで始まる整数の連続であり、1番目のサブブロックはソースシンボルを備え、2番目のサブブロックはリペアシンボルを備え、サブブロック境界指標900は1番目のサブブロックは0から899までのESIを有するシンボルに対応し、2番目のサブブロックは900のESIを有するシンボルで開始することを示すために使用されてもよい。ソース又はリペアシンボルのサブブロック識別子はシンボルがどのサブブロックの部分かを示す。
・各シンボル方法で送信されたヘッダーデータ
[0075] 一実施例では、物理層パケット内のシンボルとともに送られるべき各シンボルに関連したヘッダーデータはセグメント識別子、サブブロック識別子、および、ESIを備えている。例えば、可能なセグメント識別子の数が8で、可能なサブブロック識別子の数が8で、ESIの数が1024である場合、ヘッダーデータの等しく2バイト、つまり16ビットは各シンボルにとって十分である。物理層ブロック内の各物理層パケット内で、物理層パケットのコンテンツはシンボルに関連したヘッダーデータとともにシンボルを備え、ヘッダーデータはセグメント識別子とサブブロック識別子とを備える。
[0076] この実施例では、受信器は以下のように物理層ブロック内の受信された物理層パケットを処理するかもしれない。物理層ブロック内の物理層パケットの受信に際して、受信器はそれが可読である各物理層パケット内でシンボルに関連したヘッダーデータから決定する。ヘッダーデータから、受信器は物理層パケット内に含まれるシンボルのESI、サブブロック識別子、およびセグメント識別子を決定することが出来る。セグメント識別子から、受信器はシンボルが可能なソースブロックの中に対応付けられるソースブロックを決定することが出来る。サブブロック識別子から、受信器はシンボルがソースブロックの可能なサブブロック内に関連付けられるサブブロックを決定することが出来る。ESIから、受信器は、ソースブロックに対するおよびソースブロックのサブブロックに対するシンボルの関係を決定することができ、ESIはソースブロック内のシンボルのシンボル位置を決定することに使用され、および/または、受信したリペアシンボルおよび他のソースシンボルから失ったソースシンボルを回復するためのFEC復号において使用されることが可能である。
[0077] 受信器は、その後、この情報に基づいてある行動を決定することが出来る。例えば、受信器は異なる目的のシンボルに関連したサブブロックを使用してもよい。例えば、サブブロックデータはソースブロックのいくつか又は全てを回復するためにどのようにFEC復号するか決定するため部分的に使用されてもよい。受信器内でより高いレベルの機能性をサポートする、例えば、マルチメディアの再生のためのマルチメディアプレイヤーへ全体として、受信されたソースブロックのどの部分上で渡すか決定するために、サブブロックデータは、上位層アプリケーション例えば、受信器内のマルチメディアプレイヤープロセスに、データの一部が渡されるべきであることを決定するためにしようされてもよい。例えば、受信器が1番目の物理層ブロックを受信したとき、1番目のセグメント識別子に関連したシンボルの部分は、1番目のセグメント識別子に対応したソースブロックに対応した低品質ビデオ部の再生のためにマルチメディアプレイヤーに渡されるかもしれない1番目のサブブロックに関連しているかもしれない。
受信器は、おそらくシンボルのサブブロックの組あるいはシンボルのサブブロックのユニットにおいて、メディアプレイヤーへ渡すこと、および/または、FEC復号化のために、これらのシンボルを組み合わせ、後の物理層ブロックにおいて受信された同じソースブロックのために、シンボルとともにそれらを組み合わせるために、最初のセグメント識別子以外のセグメントとソースブロックに関連した回復されおよび/または抽出したシンボルを保存することも決定してもよい。
[0078] 当業者は、上記実施例の組み合わせおよび変形があることを認識するだろう。例えば、シンボルとともに送られるシンボルのヘッダーデータは、セグメント識別子とサブブロック識別子とを含み、ESIを含まなくてもよい。別の変形例として、ESIだけがシンボルとともにヘッダーデータ内で送信され、セグメント識別子あるいはサブブロック識別子のような他のデータが使用される場合は他のデータから決定される。
[0079] 他の変形例として、各シンボルに関連したヘッダーデータは、サブブロック識別子を含まなくてもよい。この場合、サブブロック識別子は、例えば、導出されたESIにより暗黙に決定されてもよく、あるいはサブブロックはソースブロックのセグメントと一致し、あるいは、サブブロッキングは用いられない。
[0079] 他の変形例として、各シンボルに関連したヘッダーデータは、サブブロック識別子を含まなくてもよい。この場合、サブブロック識別子は、例えば、導出されたESIにより暗黙に決定されてもよく、あるいはサブブロックはソースブロックのセグメントと一致し、あるいは、サブブロッキングは用いられない。
[0080] 他の変形例として、各シンボルに関連したヘッダーデータはセグメント識別子を含まなくても、含んでもよい。この場合、セグメント識別子は、各物理層ブロック内で例えば固定された量の物理層パケットの配置により暗黙に決定されてもよく、あるいはサブブロックはセグメントと一致し、あるいは、分割することは用いられない。
[0081] 別の変形例として、各シンボルに関連したヘッダーデータはストリーム識別子も含んでもよい。この場合、ストリーム識別子は、ストリームの小さい数の中のどのストリームで、シンボルが例えばビデオストリームあるいはオーディオストリームと関連付けられるか決定してもよい。ストリーム識別子は例えば、ストリームが論理的に接続された場合に同じプログラムセグメントに対するオーディオおよびビデオストリームのような、他の識別子により算定されてもよく、例えばサブブロック識別子はストリーム識別子の全てあるいはいくつかを算定してもよいことに注意する。ストリーム識別子は、例えばストリームが論理的に独立している場合、異なるプログラムセグメントのためのオーディオ/ビデオストリームのような他の識別子を算定してもよく、例えばストリーム識別子はサブブロック識別子の全てあるいはいくつかを算定してもよい。
・各シンボル方法で送られたヘッダーデータがない
[0082] 別の実施例では、物理層パケットに搬送されたシンボルに関連したヘッダーデータはない。代わりに、ある最小のデータは物理層ブロックのヘッダーデータ内に搬送され得る。最小のデータは、例えば、セグメントテーブルを含むことができ、セグメントテーブルの各行は、物理層ブロックに搬送されたソースブロックのセグメントのシンボルの全ての中のソースブロックのセグメントのシンボル順序における1番目のシンボルのESIと物理層ブロックに搬送されたソースブロックのセグメントのシンボルの数を備えたセグメント識別子に対応する。例えば各セグメント内のシンボルの数がすべての物理層ブロックに渡っていつも同じであるため、セグメント内のシンボルの数はいくつかの実施例において含まれなくてもよい。
・各シンボル方法で送られたヘッダーデータがない
[0082] 別の実施例では、物理層パケットに搬送されたシンボルに関連したヘッダーデータはない。代わりに、ある最小のデータは物理層ブロックのヘッダーデータ内に搬送され得る。最小のデータは、例えば、セグメントテーブルを含むことができ、セグメントテーブルの各行は、物理層ブロックに搬送されたソースブロックのセグメントのシンボルの全ての中のソースブロックのセグメントのシンボル順序における1番目のシンボルのESIと物理層ブロックに搬送されたソースブロックのセグメントのシンボルの数を備えたセグメント識別子に対応する。例えば各セグメント内のシンボルの数がすべての物理層ブロックに渡っていつも同じであるため、セグメント内のシンボルの数はいくつかの実施例において含まれなくてもよい。
[0083] いくつかの実施例では、同じセグメント識別子が同じ物理層ブロック内で2以上のソースブロックに使用されるべきである場合において、セグメントテーブルはソーステーブルに代わってもよい。
[0084] 最小のデータは、例えば、いずれのサブブロックが物理層ブロック内に搬送された各ソースブロックのシンボルであるのかを示すサブブロックテーブルを備えることができる。このサブブロックテーブルのための多くの形式があり、例えば、サブブロック情報はセグメントテーブル内の適切なセグメント識別子行の各行に追加されてもよく、あるいは、別の例として、サブブロック情報が個別のテーブルに格納されてもよい。いくつかの実施例では、例えば、サブブロッキングが使用されないため、あるいは、サブブロッキングのシグナリングがより高いアプリケーション層で扱われるため、サブブロックテーブルは含まれなくてもよい。
[0085] この実施例では、受信器は、以下のような物理層ブロック内の受信した物理層パケットを処理するかもしれない。受信器は物理層ブロックヘッダーデータからサブブロックテーブルおよび/又はセグメントテーブルを読み格納する。セグメントテーブルから、受信器は物理層ブロックと共に搬送されたシンボルあるためにソースブロックの各セグメントに関連した初期のESIとシンボルの数とを決定することができる。シンボルを搬送する物理層パケットの位置の物理層識別子から、各セグメントに関連した初期ESIおよび数を含むセグメントテーブルから、および、物理層ブロックにおいて物理層パケットへ含まれたソースブロックの全てのセグメントから順序付けられ組み合わせられたシンボルの組のマッピングから、シンボルがどのソースブロックに関連付けられているかおよびシンボルのESIを決定することができる。サブブロックテーブルから、同様に受信器はソースブロックのそのサブブロックがシンボルと関連付けられているか決定することが出来る。
[0086] ESIから受信器は、ソースブロックのサブブロックとソースブロックとに対するシンボルの関係を決定することができ、ESIは他のソースシンボルおよび受信したリペアシンボルから受信されなかったソースシンボルを回復するためのFEC復号において使用されるべき、および/又は、ソースブロック内でシンボルのシンボル位置を決定するためにしようされることが出来る。
[0087] 受信器は、この情報に基づいて、ここに説明された「各シンボルと共に送信されたヘッダーデータ」方法として上述されたものを含むある動作を決定することが出来る。
[0088] 当業者は、上記の多くの変形があることを認識するだろう。一つの変形例として、各シンボルに関連したヘッダーデータは、例えばこの目的のために各物理層パケットの1バイトの部分を使用するサブブロック識別子を備えてもよい。サブブロック構造がソースブロック全体に渡るときこれはいくつかの場合において好ましいだろう、しかし、各シンボルとともに送られるヘッダーデータ内でサブブロック識別子をこのように搬送することは、ソースブロックの送信の最中にチャネルをつなぐ受信器がサブブロックのサブブロッキング構造を速く理解することを可能としてもよく、ソースブロックへのデータ送信はいくつかの物理層ブロックに渡ってもよい。
[0089] 別の例として、サブブロッキングは使用されなくてもよい。
[0090] 別の例として、各物理層パケットに関連したヘッダーデータは、例えば同じ物理層ブロック内で個別のデータとして送られ、あるいは、他の手段により受信器と通信され、あるいは、別の例として多数の物理層ブロックのヘッダーデータを含む個別の物理層ブロックで送られ、あるいは、別の例として他のネットワークを介して送られてもよい。
[0091] 別の例として、各シンボルに関連したヘッダーデータはストリーム識別子も含んでよい。この場合、ストリーム識別子は、ストリームの小さい数の中のどのストリームとシンボルが関連付けられているか決定してもよく、例えばオーディオストリームあるいはビデオストリームである。ストリーム識別子は他の識別子により算定さてもよく、例えば、ストリームが論理的に接続されている、例えば同じプログラムセグメントのオーディオおよびビデオストリームのような場合、例えばサブブロック識別子はストリーム識別子の全てあるいはいくつかを算定してもよいことに注意する。ストリーム識別子は他の識別子を算定してもよく、例えば、ストリームが論理的に独立している、例えば、異なるプログラムセグメントのオーディオ/ビデオストリームのような場合、例えばストリーム識別子はサブブロック識別子の全てあるいはいくつかを算定してもよい。ストリーム識別子は、サブブロック識別子とセグメント識別子とのための上述されたものと同様のフォーマットにおいて物理層ブロックのヘッダーデータ内に含まれてもよく、その場合では、受信器とストリーム構造を通信するための各シンボルに関連したヘッダーデータ内のストリーム識別子を含むことは必要ではないかもしれない。
[0092] 一例として、ソースブロック毎のセグメントの数が4であり、サブブロックの数が3であり、物理層ブロック毎の物理層パケットの数が512であり、100バイト毎の3つのシンボルが300バイトの各物理層パケットに含まれると仮定すると、各物理層ブロックは3*512=1536のシンボルを含む。そして、特定の1番目の物理層ブロックの1番目のセグメントテーブルおよび2番目の物理層ブロックの2番目のセグメントテーブルは図3に示されるようであってよく、2番目の物理層ブロックは1番目の物理層ブロックの後に連続的に送信される。この例において、セグメント識別子はセグメントテーブルに明示的に搬送されなくてもよいが、その代わり、テーブルの行数、すなわち、セグメント識別子jに対応する行jにより暗示されてもよい。
[0093] 1番目のセグメントテーブルにおいて、識別子0のセグメントのシンボルの数は450であり、最初の450のシンボルが物理層パケットマッピングのための順序付けられたシンボルに従って配置された150の物理層パケットにより搬送されるだろう。この例では、セグメント識別子0のシンボルのESIは、0から449までの連続する整数である。識別子1のセグメントのシンボルの数は300であり、300のシンボルが物理層パケットマッピングのための順序付けられたシンボルに従って配置された最初の150物理層パケットの後に100の物理層パケットにより搬送されるだろう。この例では、セグメント識別子1のシンボルのESIは420から719までの連続する整数である。
[0094] 2番目のセグメントテーブルにおいて、識別子0のセグメントのシンボルの数は420であり、最初の420のシンボルが物理層パケットマッピングのために順序付けられたシンボルに従って配置された140の物理層パケットにより搬送されるだろう。j=0、1、2について、1番目のセグメントテーブルにおいてセグメント識別子jのソースブロックは、2番目のセグメントテーブルにおいてセグメント識別子j+1のソースブロックと同じであることに注意する。したがって、1番目のセグメントテーブルにおいて識別子jのセグメントの初期のESIは、このマッピングの下で2番目のセグメントテーブルにおいて識別子j+1のセグメントのシンボルの数と初期のESIの和である。
[0095] データは物理層ブロックのヘッダーに必ずしも搬送されず、しかし、代わりの他の場所、例えば、コントロールデータストリーム、多数の物理層ブロックのヘッダー情報を含む個別の物理層ブロックへ伝送され得、あるいは、別のネットワークを介する送信され得る。当業者は上述の方法の多くの他の同様の変形を認識するだろう。
・FECペイロードID間のマッピング
[0096] 例えば、コメント5052のためのインターネット技術特別調査委員会要求(IETF RFC 5052:Internet Engineering Task Force Request for Comments 5052)およびコメント5053のためのインターネット技術特別調査委員会要求(IETF RFC 5053:Internet Engineering Task Force Request for Comments 5053)で説明されたように、多くのアプリケーション層に対して標準に記述され、アプリケーション層内に送られたサブシンボルのグループあるいはシンボルのグループあるいはシンボルに典型的に関連したFECコードはFECペイロードID(識別子)である。最も単純な場合について、FECペイロードIDはシンボルに関連し、FECペイロードIDはシンボルが生成されたソースブロック数、シンボルのESI、およびいくつかの場合では最小の関連したESIを伴うリペアシンボルの初期ESI(この初期ESIは、ソースシンボルが2番目のサブブロックの部分としてのリペアシンボルおよび1番目のサブブロックの部分であることを識別する、サブブロック識別子としてみることができる。)とを備える。
・FECペイロードID間のマッピング
[0096] 例えば、コメント5052のためのインターネット技術特別調査委員会要求(IETF RFC 5052:Internet Engineering Task Force Request for Comments 5052)およびコメント5053のためのインターネット技術特別調査委員会要求(IETF RFC 5053:Internet Engineering Task Force Request for Comments 5053)で説明されたように、多くのアプリケーション層に対して標準に記述され、アプリケーション層内に送られたサブシンボルのグループあるいはシンボルのグループあるいはシンボルに典型的に関連したFECコードはFECペイロードID(識別子)である。最も単純な場合について、FECペイロードIDはシンボルに関連し、FECペイロードIDはシンボルが生成されたソースブロック数、シンボルのESI、およびいくつかの場合では最小の関連したESIを伴うリペアシンボルの初期ESI(この初期ESIは、ソースシンボルが2番目のサブブロックの部分としてのリペアシンボルおよび1番目のサブブロックの部分であることを識別する、サブブロック識別子としてみることができる。)とを備える。
[0097] 上述したプロセスおよび方法のいくつかにおいて、FECペイロードIDは各シンボルとともに送られず、代わりの他の方法はチャネル容量を最大にするために各シンボルと共に送られるヘッダーデータの量を最小にすることを説明する。それは、この情報を受信器へ伝えるために上述された方法を使用するものへFECペイロードIFを使用するものから送信フォーマットを変換する送信器においていくつかの場合では有用である。さらに、それは、FECペイロードIDを使用するものへ受信器にこの情報を伝えるための上述の方法を使用するものから送信フォーマットを変換する受信器においてもいくつかの場合に有用である。例えば、シンボルを識別するためのFECペイロードIDを使用するすでに開発されたソフトウエアがあるかもしれないし、上述された方法を使用する送信フォーマットと共存する関連したデータおよびシンボルのストリームの出力を生成するためのこのソフトウエアを使用して生成された関連したヘッダーデータおよびシンボルのストリームの出力をとることが便利かもしれない。
[0098] FECペイロードID間のマッピング方法フォーマットは上に提供された記述から容易に導かれるだろう。
・チャネルザッピングを最適化する配列の送信
[0099] チャネル上で送られるべき優先されたストリームについて、ここで送られるべきデータは異なる物理層ブロック、例えばフレームあるいはスーパーフレームに分割され、ソースブロックへ送られるべきデータは、それらの優先の逆の順で、優先された方法におけるそのような複数の物理層ブロック上でインターリーブされることが可能である。例えば、「FECストリーミング」において説明したように、ソースブロックのリペアデータは、これらの説明の文脈において、チャネルザッピング時間を減らすためにソースブロックのソースデータに対して優先に送られ得る。ソースブロックへ与えられた優先順位でデータを含むデータは、サブブロック内で一まとめにされ得る。例えば、上述の例を継続すると、リペアシンボルは優先度のより低いサブブロックであり、ソースシンボルは2番目に高い優先度のサブブロックであると考えられ、したがって、より低い優先度のサブブロックはより高い優先度のサブブロックに対して優先に送られ得る。
・チャネルザッピングを最適化する配列の送信
[0099] チャネル上で送られるべき優先されたストリームについて、ここで送られるべきデータは異なる物理層ブロック、例えばフレームあるいはスーパーフレームに分割され、ソースブロックへ送られるべきデータは、それらの優先の逆の順で、優先された方法におけるそのような複数の物理層ブロック上でインターリーブされることが可能である。例えば、「FECストリーミング」において説明したように、ソースブロックのリペアデータは、これらの説明の文脈において、チャネルザッピング時間を減らすためにソースブロックのソースデータに対して優先に送られ得る。ソースブロックへ与えられた優先順位でデータを含むデータは、サブブロック内で一まとめにされ得る。例えば、上述の例を継続すると、リペアシンボルは優先度のより低いサブブロックであり、ソースシンボルは2番目に高い優先度のサブブロックであると考えられ、したがって、より低い優先度のサブブロックはより高い優先度のサブブロックに対して優先に送られ得る。
[0100] 図4は、一実施例がサブブロック内でデータを優先付けし、および優先付けした送信順でサブブロックを配置してもよい方法の一例を示す。図4では、データストリーム470はデータの様々なサブブロックおよびブロックで表される。例えば、データストリーム470は、P1-Px 420−422、 b1-bz430−435、および B1-By440−442のようなシンボルの様々なサブブロックおよびI−フレーム(ZI)のような様々なビデオブロックおよびオーディオブロック450で示される。図4では、P1420はストリーム内の最も高い優先度のサブブロックを表し、b1-bz430−435、 B1-By440−442, P2-Px421−422、オーディオブロック450、 および I−フレーム (ZI)410がそれぞれ後に続く。これらの優先レベルを与えられると、ストリームのサブブロックおよびブロックは送信配列480により示されるように配列され得る。最も低い優先度のブロック(ZI410)は、送信の開始時に受信器へ送信されることが可能で、一方、最も高い優先度のデータ(P1420)は最後に送信され得る。さらに、様々なサブブロック間の従属性は送信順序の優先付けを生成するときに考慮に入れることも可能である。例えば、いくつかの実施例によれば、サブブロックb1、B1およびb2はP1に依存してもよい。これらの実施例では、P1が送信される前に、これらの依存するサブブロックを送信することが有利かもしれない。したがって、P1が受信されるとすぐに、その依存したサブブロックの全ておよびP1内のデータが受信器で速く利用可能とすることができる。一旦、送信配列が決定されると、送信配列は状況に応じて異なる物理層ブロックにデータを分割するためにしようされることができる。
[0101] 物理層ブロックへ優先付けられたサブブロックを配置して各物理層ブロックへサブブロックを配置するための一つの方法。図5は、この方法の1つの実施例の例を示す。図5は様々な物理層ブロック501−504内での壊れた1セットのデータ500を示す。図5のブロックは、矢印509により示された方向で送信されるものとして表される。例えば、物理層ブロック501は、物理層ブロック504に先立って送信され(したがって、物理層ブロック504の前に送信され)、そして物理層ブロック501内でセクション580はセクション520に先立って送信される。図5に示されたように、データ500のいくつかは、各物理層ブロック501−504内に配置される。各セグメントは各物理層ブロックの対応するセクション内に配置されるが、明確性のために、データ500内のデータの各セグメントは物理層ブロック501−504の一つ内の配置のみを示す。FECデータ510は、520−523で物理層ブロック内に配置され、P1データ420は540−543で物理層ブロック内に配置され、b1-bzデータ430−435は530−533で物理層ブロック内に配置され、B1-Byデータ440−442は550−553で物理層ブロック内に配置され、P2-Pxデータ421−422は560−563で物理層ブロックに配置され、オーディオデータ450は570−573で物理層ブロック内に配置され、そして、I−フレーム(ZI)410は物理層ブロック580−583内に配置される。図5に示すような方法で物理層ブロック内にサブブロックを配置する1つの利点は、各物理層ブロック内に各優先グループのセグメントが含まれるため、受信器での再生動作がより予測可能となることである。しかしながら、様々な優先レベルが典型的には異なるデータ量を含むため、各物理層ブロック内での様々なセグメントが典型的には異なるサイズである。これは、データを解くために受信器でより複雑な処理により受信器で潜在的な性能の問題に先行することができ、異なるセグメントサイズによるスタット・マキシング(stat-muxing)の問題があるかもしれない。
[0102] 別の方法は異なる物理層ブロック上でできるだけ均等にシンボルデータを広げることであり、これは一般にチャネル悪化に対して最良の保護を提供する。図6はこの方法の一実施例の例を示す。図6は様々な物理層ブロック601−604内の壊れた1セットのデータ600を示す。図6中のブロックは矢印609により示された方向で送信されることとして表される。例えば、物理層ブロック601は物理層ブロック604の前に送信され(したがって、物理ブロック604の前に送信され)、物理層ブロック601内でセクション640はセクション610の前に送信される。図6に示すように、シンボルデータ600内で優先する様々なデータはブロック605−608内で一まとめにされる。ブロック650−608は、次に、等しい量で、物理層ブロック601−604へ配置される。明確性のために、データ600の各セグメントは各物理層ブロックの対応するセクション内に配置されるが、物理層ブロック601−604の1つの中の配置のみを示す。例えば、ブロック605は610−613内に配置され、ブロック606は620−623内に配置され、ブロック607は630−633内に配置され、ブロック608は640−643内に配置され、図6に示された配置の結果、いくつかのサブブロックはグループ間に分離している。例えば、セグメントB1-By440−442からのデータはブロック606および607の両方内に含まれてもよい。さらに、与えられた物理ブロックは特定の優先度からのデータを含んでいなくてもよい。例えば、ブロック601は610でFEC520データを含んでいなくてもよく、一方、ブロック604は613でP1420からのデータを含んでいなくてもよい。図6に示された方法の1つの利点は、物理層ブロックのセグメントが同じサイズであるので、受信器はセグメントを解くためにより少ない処理を要求するであろうことである。これは受信器の性能の改善に帰着してもよい。さらに、一定のセグメントサイズは、スタット・マキシング(stat-muxing)をより簡単にする。しかしながら、所定の物理層ブロックに含まれる正確な優先レベルに関して保障がなく、受信器での再生動作はそれほど予測可能でなくなるかもしれない。
[0103] データをマッピングする間の関心事は、この高い優先順位データが受信されるとすぐに受信器が再生を開始可能とするために、ソースブロックの十分な高い優先順位のデータが1番目の物理層ブロックに送られることである。ここで、いくつかのソースブロックの高い優先順位のデータが、受信器が1番目の物理層ブロックを受信した後に利用可能となるべき場合に、Nはデータがソースブロックへ送られるべき物理層ブロックの数であり、これを構築するための1つの方法は、高い優先順位のデータの量がソースブロックへ送られるべきデータの総量の最大1/Nの比である方法のように符号化されたあるいは符号化されていないソースブロック内でデータを優先付けすることである。一般に、受信器がK物理層ブロックを受信した後に、データの最初のJ優先順位がある1番目のソースブロックに利用可能となると仮定すると、最初のJ優先順位におけるデータの比が最大でK/Nである場合に構築されることができる。
[0104] 好ましい分割ストラテジーの一例は下記であり、上記の方法が使用されても使用されなくても、使用することができる。ソースブロックへの送信データがN物理層ブロック内に送られることになっていると仮定すると、送信データは、もしあれば、送られるべきソースブロックから生成されたFECリペアシンボルおよびソースブロックのソースシンボルを備える。ソースブロックの送信データがK優先順位に分割されると仮定すると、優先順位jの送信データの比はj=1、…、KについてP_jである。
[0105] 上記のように、優先順位jの送信データはサブブロックjと称される、サブブロックへグループ化され得る。そして、最後の物理層ブロック内で送信データの比はP1と1/Nとの最大値であり得、すなわち、出来る限り残りのデータのいくつかおよび最も高い優先順位のサブブロック1内の全てのデータは最後の物理層ブロックNで送信される。M_1をこの最大値にさせ、L_1=1−M_1をデータの比M_1が最後の物理層ブロックN で送信される後に物理層ブロックN-1、…、で送られるべきデータの残りの比とする。そうすると、物理層ブロックN-1で送信される送信データの比はP_1+P_2−M_1および1/N −1の最大値となり得、すなわち、2番目に高い優先順位のサブブロックおよび最も高い優先順位のサブブロックの全ては最後の2つの物理層ブロックで送信され、可能な限り残りのデータのいくつかも同様である。これは、2つの物理層ブロックが受信された後、最初の2つの優先順位のデータが受信器において再生されるべきであると仮定している。
[0106] 各物理層ブロックでどの送信データを送るかを決定するためにこの方法は拡張することができる。この方法は、送信されたソースブロックデータを再生する受信器への受信器要求が異なる例えば、優先順位2の送られたデータ2つの物理層ブロックの後に代わって3つの物理層ブロックを受信する後に再生されるべきである場合のために拡張することができる。上記の方法は、同じ物理チャネル上で一括のストリームあるいは多くの異なるストリームの多重化の要求により修正され得、各物理層ブロックにおいて利用可能なスペースの量は、一括ストリームあるいは各ストリームの送信データの各優先順位のどれくらいが各ブロックで送られるべきか決定するために使用される。
[0107] 上記の優先順位は完全な順序付けを説明する必要はなく、すなわち、優先順位は部分的な順序でよく、その場合には、いくつかの実施例において、実際に優先順位の大部分で比較不能である優先付けられたデータは送信順序で混合されてもよく、優先付けられたデータの配置する順序を選択するための選択がある。
[0108] 上述のように、これらの提案された送信配列のいくつかを実施することは、ここで説明されたプロセス、例えば、各シンボルとともに送信されるヘッダーデータ、各シンボルとともに送信されたヘッダーデータではない等、を含むESI、改善された送信および受信方法のいずれかを使用して遂行され得る。
・ソースブロックの部分的なFECコーディング
[0109] FECリペアデータはソースブロック全体から生成することができ、ソースブロックから生成されたリペアシンボルとソースブロックからの十分なソースシンボルが受信された場合にソースブロックの全体あるいは重要な部分を回復する能力を提供する。FECリペアデータはソースブロックの部分のみから生成されてもよく、例えば、FECリペアデータの1セットはソースブロックの1番目の部分から生成されてもよく、FECリペアデータの2番目のセットはソースブロックの2番目の部分から生成されてもよい。一例として、ソースブロックの2番目の部分はソースブロックのある付加的な部分とソースブロックの1番目の部分とを含んでもよい。ソースブロックのソースシンボルは高い優先順位のソースサブブロックと、低い優先順位のソースサブブロックへ分割されると仮定する。その後、FECリペアシンボルの1番目のサブブロックは高い優先順位のソースサブブロックから生成され得、FECリペアシンボルの2番目のサブブロックは高い優先順位のソースサブブロックと低い優先順位のソースサブブロックとの連結から生成され得る。サブブロックの送信順序は、次のとおりであり得る:FECリペアシンボルの2番目のサブブロック、低い優先順位のソースサブブロック、FECのリペアシンボルの1番目のサブブロック、高い優先順位のソースサブブロック。この場合、受信器が高い優先順位のソースサブブロックの部分あるいは全部のみを受信する場合、破損があり過ぎなければ、これを直ちに再生しようとすることができる。受信器が高い優先順位のソースサブブロックおよびFECリペアシンボルの1番目のサブブロックの部分あるいは全てを受信する場合、破損があり過ぎなければ、FECリペアシンボルの1番目のサブブロックを使用する高い優先順位のソースサブブロックを回復しようとすることができる。受信器が高い優先順位のソースサブブロック、FECリペアシンボルの1番目のサブブロック、および低い優先順位のソースサブブロックの部分あるいは全てを受信する場合、受信器はFECリペアシンボルの1番目のサブブロックを使用する高い優先順位のソースサブブロックの破損した部分を回復し、メディアプレイヤーに低い優先順位のソースサブブロックの受信した部分と高い優先順位のソースサブブロックの回復した部分とを送ろうとすることができる。受信器が4つのサブブロック全ての部分をあるいは全部を受信した場合、受信器はすべてのFECリペアシンボルを使用してソースシンボルの全てを回復することができる。
・ソースブロックの部分的なFECコーディング
[0109] FECリペアデータはソースブロック全体から生成することができ、ソースブロックから生成されたリペアシンボルとソースブロックからの十分なソースシンボルが受信された場合にソースブロックの全体あるいは重要な部分を回復する能力を提供する。FECリペアデータはソースブロックの部分のみから生成されてもよく、例えば、FECリペアデータの1セットはソースブロックの1番目の部分から生成されてもよく、FECリペアデータの2番目のセットはソースブロックの2番目の部分から生成されてもよい。一例として、ソースブロックの2番目の部分はソースブロックのある付加的な部分とソースブロックの1番目の部分とを含んでもよい。ソースブロックのソースシンボルは高い優先順位のソースサブブロックと、低い優先順位のソースサブブロックへ分割されると仮定する。その後、FECリペアシンボルの1番目のサブブロックは高い優先順位のソースサブブロックから生成され得、FECリペアシンボルの2番目のサブブロックは高い優先順位のソースサブブロックと低い優先順位のソースサブブロックとの連結から生成され得る。サブブロックの送信順序は、次のとおりであり得る:FECリペアシンボルの2番目のサブブロック、低い優先順位のソースサブブロック、FECのリペアシンボルの1番目のサブブロック、高い優先順位のソースサブブロック。この場合、受信器が高い優先順位のソースサブブロックの部分あるいは全部のみを受信する場合、破損があり過ぎなければ、これを直ちに再生しようとすることができる。受信器が高い優先順位のソースサブブロックおよびFECリペアシンボルの1番目のサブブロックの部分あるいは全てを受信する場合、破損があり過ぎなければ、FECリペアシンボルの1番目のサブブロックを使用する高い優先順位のソースサブブロックを回復しようとすることができる。受信器が高い優先順位のソースサブブロック、FECリペアシンボルの1番目のサブブロック、および低い優先順位のソースサブブロックの部分あるいは全てを受信する場合、受信器はFECリペアシンボルの1番目のサブブロックを使用する高い優先順位のソースサブブロックの破損した部分を回復し、メディアプレイヤーに低い優先順位のソースサブブロックの受信した部分と高い優先順位のソースサブブロックの回復した部分とを送ろうとすることができる。受信器が4つのサブブロック全ての部分をあるいは全部を受信した場合、受信器はすべてのFECリペアシンボルを使用してソースシンボルの全てを回復することができる。
[0110] 上記方法は個々のサブブロック上で別々にFEC保護を提供することが好ましく、例えば、単に低い優先順位のソースサブブロックに代わってソースブロック全体を保護するFECリペアシンボルの2番目のサブブロックを有することが好ましいことに注意する。例えば、2つのソースサブブロックのそれぞれが、100ソースシンボルずつ備え、2つのFECサブブロックのそれぞれが50リペアシンボルずつ備えると仮定する。上位方法を使用することは、高い優先順位のソースサブブロックから60のソースシンボルが損失し、低い優先順位のソースサブブロックから30のソースシンボルが損失した場合であっても全てのソースブロックの回復を可能とするが、2つのソースサブブロックが2つのFECリペアサブブロックにより独立に保護されている場合、高い優先順位のサブブロックの回復は可能ではない(サブブロックの60のソースシンボルが損失し、サブブロックを保護する50のリペアシンボルしかない)。そのようなFEC保護は、例えば、リード・ソロモンコードを使用して実現され、ここで、オーバラップするサブブロックを保護する上記の方法において使用されるとき、リード・ソロモンコードが殆ど理想的な回復特性を示すことを実験が示している。
[0111] これらの方法は、長すぎる期間に渡る保護が受信されたデータの全時間にときどき消失する場合の保護のために有用である。代わりに、短いブロック上でFEC保護を提供し、短いブロックを含むより長いブロック上でもFEC保護を提供することは好ましい。このように、周囲の期間において多すぎない損失を伴う機能停止、そして、短いブロックに渡るFEC保護はそれらに回復することを可能とし、しかしより長いブロックに渡る付加的なFEC保護はより長い期間上により多くの損失があることを可能にする。
・多数の物理層ブロックストリームを受信すること
[0112] 論理的に接続されたストリームが物理層ブロックのシグナルストリーム上で送られるストリーミングアプリケーションについて、物理チャネル全体は多数のそのような物理層ブロックストリームにより構成されるかもしれない。例えば、この例では各物理層ブロックストリームは256Kbps、あるいは1Mbpsであってもよく、しかし、50のそのようなストリームがある結果、利用可能な物理チャネル全体は12.5から50Mbpsかもしれない。
・多数の物理層ブロックストリームを受信すること
[0112] 論理的に接続されたストリームが物理層ブロックのシグナルストリーム上で送られるストリーミングアプリケーションについて、物理チャネル全体は多数のそのような物理層ブロックストリームにより構成されるかもしれない。例えば、この例では各物理層ブロックストリームは256Kbps、あるいは1Mbpsであってもよく、しかし、50のそのようなストリームがある結果、利用可能な物理チャネル全体は12.5から50Mbpsかもしれない。
[0113] 典型的に、受信器は、メモリの問題およびパワーの問題を含む様々な異なる理由により。物理層ブロックのストリームの1つを一度に受信してもよい。しかしながら、物理層ブロックの1以上のストリームを受信することは受信器にとって利点があり得る。例えば、受信が全てのそのようなストリームを受信することである場合、1つのストリームから別のものへのチャネルザッピングは殆ど即座に生じ得、新しいストリームの全てのデータは受信器がそのストリームへチャネルを変更する前の期間に到着するため、そして受信器が移動する新しいストリームは高い品質レベルで最初から再生されることができる。例えば、時々I−フレームと称され、時々IDRフレーム(Independent Data Refresh frames)と称されるビデオストリーム内のリフレッシュフレームがそれらの大きなサイズによりたまに送られるとき、ストリームが高度に圧縮されるような方法でビデオ符号化された場合であっても、あるいは、ストリームが長い保護期間でFEC保護を使用して保護される場合であっても当てはまる。これは典型的にGOP(Group of Pictures)により広げられた時間が高度に圧縮されたビデオストリームにおいてある程度大きくなり得ることを意味する。例えば、ビデオストリームのGOPの期間は10秒であってよく、FEC保護は10秒のGOP全体を保護することを提供されてもよい。この場合、ストリームからの高い優先順位のデータが出来るだけ速く表示され、より低い優先順位のデータもストリーム再生向上するように速く再生の質を向上する表示される上記方法のいくつかを使用しないで、受信器が同時に1つのチャネルのみを受信した場合チャネルザッピング時間が10秒と同じくらい高くなり得、しかし、受信器が全てのチャネルを受信する場合チャネルザッピング時間は殆ど瞬間であり得る。
[0114] 受信器が物理層パケットの1以上のストリームを同時に受信する解決策を考慮する場合、いくつかの最適化が可能である。例として、例えば再生のためのメディアプレイヤーへ容易に送信されるストリームのみ、誤り訂正復号(error-correction decoding)あるいは消去保護復号(erasure protection decoding)のいずれかを受信器が例えば行うFECコードのためにのみ必要である。受信器がチャネルを変更する場合他のストリームのデータは格納されFEC復号のみされることができ、FEC復号は、新しいチャネルへ受信されたデータ上で非常に速く生じ得、メディア再生を殆ど直ちに開始する。
[0115] 別の可能な最適化として、受信器が一度に1つのストリームのみを受信するとき、受信器が最初にストリームを結合するとき受信器が再生可能なストリームの前の部分を有していた場合、必要とされないストリームに含まれる重複データがあってもよい。そのような重複データの例は、たとえそれが低い品質であったとしても、受信器がストリームを結合して殆ど直ちにいくつかのビデオを再生開始することができるように、ビデオストリーム単独に非常に頻繁に含まれる低品質のIDRフレームであるかもしれない。受信器が、高品質のIDRフレームと前に送信された全ての後のフレームとを含むストリームの前の部分を含む場合、頻繁な低品質のIDRフレームを含むことは必要ないだろう。低い品質のIDRフレームは利用可能な帯域幅のかなりの量を使用し得る、例えば、低い品質のIDRフレームのそれぞれは3KBでありそれらが256Kbpsのストリームで各秒に送られる場合、低い品質のIDRフレームは利用可能な帯域幅の9%以上を使用する。もし受信器が、そのストリームへチャネルを変更することに先立って受信器が変更するストリームのデータを受信する場合、低い品質のIDRフレームの送信は必要ではない。
[0116] 物理層ブロックの多数のストリームを聞く1つの欠点は、それがシグナルストリームを聞くよりも受信器でよりパワーを使用することである。さらに、シグナルストリームより多数のストリームから受信されたデータを格納するためにはより多くのメモリおよび他のリソースが必要である。これらの欠点を最小化するために使用することができるいくつかの方法がある。1つのそのような方法は、上記利点を達成するために受信器が一度に少数のストリームのみを受信すること必要とするような方法で利用可能なストリーム上で全体的にデータおよび/または論理を体系付けることである。
[0117] 例えば、受信器がどのストリームへチャネルを変更してもよいか予測することができる論理がある場合、その論理は受信器がそのチャネルへ実際の変更の前にこれらの適当なチャネルを受信するような状態であり得る。
[0118] 別の例として、物理層ブロックストリーム内のデータは、IDRストリームと称される、全ての他のビデオストリームのIDRフレームの全てを搬送する1つの物理層ブロックストリームがあるように体系付けられてもよく、各他の物理層ブロックストリームはビデオストリームのIDRフレームを除くビデオストリームの1つのデータの全てを搬送する。この例では、受信器はメディアプレイヤーにより現在再生されるビデオストリームの現在の物理層ブロックストリームを受信し、一方IDRストリームを同時に(常にあるいは断続的に適切なとき)受信してもよい。したがって、受信器はビデオストリームのいくつかあるいは全てのIDRフレームを利用可能とすることができ、それはチャネル変更が受信器で生成されたとき新しいビデオストリームの表示を開始するための使用、あるいは、サムネイルチャネルガイドモードで利用可能なビデオストリームのいくつかあるいは全てについての情報の再生のいずれかのために使用することができる。IDRストリームはいつでも受信されてよく、あるいは継続的に受信されてもよく、例えば、現在再生するビデオストリームのためのIDRフレームを含むIDRストリームからの物理層ブロックを単に受信する。全ての場合で、もし望まれれば、FEC保護は各物理層ブロックストリーム上で提供され得る。これらの方法の1つの長所は、受信器がどんな時点でも高々2つの物理層ブロックストリームにおいて受信するし、物理層ブロックチャネルを全て同時に受信するという長所の全てあるいは殆どを得る。
[0119] 発明は典型的な実施例に関して記述されているが、当業者は多数の変更が可能であることを認識するだろう。例えば、ここに説明されたプロセスは、ハードウエアコンポーネント、ソフトウエアコンポーネント、および/またはそれらの組み合わせを使用して実行されてもよい。例えば、ここで説明された方法は、方法を実行するためのコンピュータプロセッサを管理することが出来るコンピュータ実行可能コードを含むCD−ROM、DVD等のようなコンピュータ可読媒体上で、具体化されてもよい。したがって、発明は典型的な実施例について説明されたが、次の請求項の範囲内の変更および等価物の全てをカバーするように発明が意図されることは正しく認識されるだろう。
[0119] 発明は典型的な実施例に関して記述されているが、当業者は多数の変更が可能であることを認識するだろう。例えば、ここに説明されたプロセスは、ハードウエアコンポーネント、ソフトウエアコンポーネント、および/またはそれらの組み合わせを使用して実行されてもよい。例えば、ここで説明された方法は、方法を実行するためのコンピュータプロセッサを管理することが出来るコンピュータ実行可能コードを含むCD−ROM、DVD等のようなコンピュータ可読媒体上で、具体化されてもよい。したがって、発明は典型的な実施例について説明されたが、次の請求項の範囲内の変更および等価物の全てをカバーするように発明が意図されることは正しく認識されるだろう。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
[C1] 放送チャネル上でデータストリームを配信するための電子配信システムであって、前記放送チャネルは、1以上のソースから複数の受信器へ信号を送るためのチャネルであって、各受信器は同じ信号を実質的に受信することを試み、
物理層ブロックの物理層パケット内で前記データストリームのためのデータを送信する送信システムを備え、送られたデータが前記データストリームとどのように関係があるのかの表示は、少なくとも前記物理層ブロックに基づいている、電子配信システム。
[C2] 前記送られたデータが前記データストリームとどのように関係があるかの表示は、少なくとも前記物理層ブロックのヘッダー内の情報に基づき、送信システムは前記物理層の前記ヘッダーが前記表示を含むように構成する、C1記載の電子配信システム。
[C3] 前記送られたデータが前記データストリームとどのように関係があるかの表示は、少なくとも一部分、前記物理層パケットのヘッダー内の情報に基づいているC1記載の電子配信システム。
[C4] 前記送られたデータは、データのソースブロック内の複数のシンボルへ体系付けられ、前記表示は1つのシンボルがソースブロックと1つのシンボルとソースブロックとの間の関連性の表示とから、どのように形成されるかの表示を備えるC1記載の電子配信システム。
[C5] 前記表示は符号化シンボル識別子であって、前記符号化シンボル識別子は少なくとも部分的に物理層ブロックのヘッダー内に搬送される、C4記載の電子配信システム。
[C6] 前記表示は、符号化シンボル識別子であって、前記符号化シンボル識別子はコントロールデータチャネル内で搬送される、C4記載の電子配信システム。
[C7] シンボルとソースブロックとの間の関連性は、物理層ブロックのヘッダーから主に決定され得る、C4記載の電子配信システム。
[C8] データの前記送られたシンボルはソースブロックから生成されたFEC修復データを含む、C4記載の電子配信システム。
[C9] データの1以上の論理ストリームは物理層ブロックの単一ストリーム内に送られる、C4記載の電子配信システム。
[C10] データの送られたシンボルは物理層ブロックの1以上のストリーム上で送られる、C4記載の電子配信システム。
[C11] データの前記送られたシンボルが前記ストリーム又はオブジェクトデータとどのように関係するかの表示は、送られるデータの前記シンボルを搬送する物理層パケットに少なくとも部分的に搬送される、C4記載の電子配信システム。
[C12] ソースブロックへ送られた前記データは、異なる優先順位の異なるサブブロックへ体系付けられる、C4記載の電子配信システム。
[C13] ソースブロックの前記サブブロック構造の表示は、物理層ブロックのヘッダーから主に決定される、C12記載の電子配信システム。
[C14] ソースブロックの前記サブブロック構造の表示は、物理層ブロックへ搬送された物理層パケットから主に決定され得る、C12記載の電子配信システム。
[C15] データの前記送られたシンボルは、サブブロックの結合および異なるサブブロックから生成されたFEC修復データを含む、C12記載の電子配信システム。
[C16] 優先順位の前記サブブロックは、前記サブブロックの送信順を決定するために利用される、C12記載の電子配信システム。
[C17] 優先順位の前記サブブロックは、前記物理層ブロックへ前記サブブロックを位置づけるために利用される、C12記載の電子配信システム。
[C18] 前記物理層ブロックへ位置づけられた優先順位の前記サブブロックは、異なる物理層ブロック間で分割される、C17記載の電子配信システム。
[C19] 放送チャネル上でデータストリーム配信するための電子配信システムの送信器から受信器へデータを送信するための方法であって、ここにおいて、前記放送チャネルは1以上のソースから複数の受信器へ信号を送るためのチャネルであって、各受信器は実質的に同じ信号を受信しようとする:
物理層ブロックの物理層パケット内の前記データストリームへ前記送信器からデータを送信することを備え、送られたデータが前記データストリームとどのように関連するかの表示は少なくともブロックの前記物理層の少なくとも一部に基づく、方法。
[C20] C19に記載された前記方法を実行するためのコンピュータ実行可能コードを備えるコンピュータ可読媒体。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
[C1] 放送チャネル上でデータストリームを配信するための電子配信システムであって、前記放送チャネルは、1以上のソースから複数の受信器へ信号を送るためのチャネルであって、各受信器は同じ信号を実質的に受信することを試み、
物理層ブロックの物理層パケット内で前記データストリームのためのデータを送信する送信システムを備え、送られたデータが前記データストリームとどのように関係があるのかの表示は、少なくとも前記物理層ブロックに基づいている、電子配信システム。
[C2] 前記送られたデータが前記データストリームとどのように関係があるかの表示は、少なくとも前記物理層ブロックのヘッダー内の情報に基づき、送信システムは前記物理層の前記ヘッダーが前記表示を含むように構成する、C1記載の電子配信システム。
[C3] 前記送られたデータが前記データストリームとどのように関係があるかの表示は、少なくとも一部分、前記物理層パケットのヘッダー内の情報に基づいているC1記載の電子配信システム。
[C4] 前記送られたデータは、データのソースブロック内の複数のシンボルへ体系付けられ、前記表示は1つのシンボルがソースブロックと1つのシンボルとソースブロックとの間の関連性の表示とから、どのように形成されるかの表示を備えるC1記載の電子配信システム。
[C5] 前記表示は符号化シンボル識別子であって、前記符号化シンボル識別子は少なくとも部分的に物理層ブロックのヘッダー内に搬送される、C4記載の電子配信システム。
[C6] 前記表示は、符号化シンボル識別子であって、前記符号化シンボル識別子はコントロールデータチャネル内で搬送される、C4記載の電子配信システム。
[C7] シンボルとソースブロックとの間の関連性は、物理層ブロックのヘッダーから主に決定され得る、C4記載の電子配信システム。
[C8] データの前記送られたシンボルはソースブロックから生成されたFEC修復データを含む、C4記載の電子配信システム。
[C9] データの1以上の論理ストリームは物理層ブロックの単一ストリーム内に送られる、C4記載の電子配信システム。
[C10] データの送られたシンボルは物理層ブロックの1以上のストリーム上で送られる、C4記載の電子配信システム。
[C11] データの前記送られたシンボルが前記ストリーム又はオブジェクトデータとどのように関係するかの表示は、送られるデータの前記シンボルを搬送する物理層パケットに少なくとも部分的に搬送される、C4記載の電子配信システム。
[C12] ソースブロックへ送られた前記データは、異なる優先順位の異なるサブブロックへ体系付けられる、C4記載の電子配信システム。
[C13] ソースブロックの前記サブブロック構造の表示は、物理層ブロックのヘッダーから主に決定される、C12記載の電子配信システム。
[C14] ソースブロックの前記サブブロック構造の表示は、物理層ブロックへ搬送された物理層パケットから主に決定され得る、C12記載の電子配信システム。
[C15] データの前記送られたシンボルは、サブブロックの結合および異なるサブブロックから生成されたFEC修復データを含む、C12記載の電子配信システム。
[C16] 優先順位の前記サブブロックは、前記サブブロックの送信順を決定するために利用される、C12記載の電子配信システム。
[C17] 優先順位の前記サブブロックは、前記物理層ブロックへ前記サブブロックを位置づけるために利用される、C12記載の電子配信システム。
[C18] 前記物理層ブロックへ位置づけられた優先順位の前記サブブロックは、異なる物理層ブロック間で分割される、C17記載の電子配信システム。
[C19] 放送チャネル上でデータストリーム配信するための電子配信システムの送信器から受信器へデータを送信するための方法であって、ここにおいて、前記放送チャネルは1以上のソースから複数の受信器へ信号を送るためのチャネルであって、各受信器は実質的に同じ信号を受信しようとする:
物理層ブロックの物理層パケット内の前記データストリームへ前記送信器からデータを送信することを備え、送られたデータが前記データストリームとどのように関連するかの表示は少なくともブロックの前記物理層の少なくとも一部に基づく、方法。
[C20] C19に記載された前記方法を実行するためのコンピュータ実行可能コードを備えるコンピュータ可読媒体。
Claims (20)
- 放送チャネル上でデータストリームを配信するための電子配信システムであって、前記放送チャネルは、1以上のソースから複数の受信器へ信号を送るためのチャネルであって、各受信器は同じ信号を実質的に受信することを試み、
物理層ブロックの物理層パケット内で前記データストリームのためのデータを送信する送信システムを備え、送られたデータが前記データストリームとどのように関係があるのかの表示は、少なくとも前記物理層ブロックに基づいている、電子配信システム。 - 前記送られたデータが前記データストリームとどのように関係があるかの表示は、少なくとも前記物理層ブロックのヘッダー内の情報に基づき、送信システムは前記物理層の前記ヘッダーが前記表示を含むように構成する、請求項1記載の電子配信システム。
- 前記送られたデータが前記データストリームとどのように関係があるかの表示は、少なくとも一部分、前記物理層パケットのヘッダー内の情報に基づいている請求項1記載の電子配信システム。
- 前記送られたデータは、データのソースブロック内の複数のシンボルへ体系付けられ、前記表示は1つのシンボルがソースブロックと1つのシンボルとソースブロックとの間の関連性の表示とから、どのように形成されるかの表示を備える請求項1記載の電子配信システム。
- 前記表示は符号化シンボル識別子であって、前記符号化シンボル識別子は少なくとも部分的に物理層ブロックのヘッダー内に搬送される、請求項4記載の電子配信システム。
- 前記表示は、符号化シンボル識別子であって、前記符号化シンボル識別子はコントロールデータチャネル内で搬送される、請求項4記載の電子配信システム。
- シンボルとソースブロックとの間の関連性は、物理層ブロックのヘッダーから主に決定され得る、請求項4記載の電子配信システム。
- データの前記送られたシンボルはソースブロックから生成されたFEC修復データを含む、請求項4記載の電子配信システム。
- データの1以上の論理ストリームは物理層ブロックの単一ストリーム内に送られる、請求項4記載の電子配信システム。
- データの送られたシンボルは物理層ブロックの1以上のストリーム上で送られる、請求項4記載の電子配信システム。
- データの前記送られたシンボルが前記ストリーム又はオブジェクトデータとどのように関係するかの表示は、送られるデータの前記シンボルを搬送する物理層パケットに少なくとも部分的に搬送される、請求項4記載の電子配信システム。
- ソースブロックへ送られた前記データは、異なる優先順位の異なるサブブロックへ体系付けられる、請求項4記載の電子配信システム。
- ソースブロックの前記サブブロック構造の表示は、物理層ブロックのヘッダーから主に決定される、請求項12記載の電子配信システム。
- ソースブロックの前記サブブロック構造の表示は、物理層ブロックへ搬送された物理層パケットから主に決定され得る、請求項12記載の電子配信システム。
- データの前記送られたシンボルは、サブブロックの結合および異なるサブブロックから生成されたFEC修復データを含む、請求項12記載の電子配信システム。
- 優先順位の前記サブブロックは、前記サブブロックの送信順を決定するために利用される、請求項12記載の電子配信システム。
- 優先順位の前記サブブロックは、前記物理層ブロックへ前記サブブロックを位置づけるために利用される、請求項12記載の電子配信システム。
- 前記物理層ブロックへ位置づけられた優先順位の前記サブブロックは、異なる物理層ブロック間で分割される、請求項17記載の電子配信システム。
- 放送チャネル上でデータストリーム配信するための電子配信システムの送信器から受信器へデータを送信するための方法であって、ここにおいて、前記放送チャネルは1以上のソースから複数の受信器へ信号を送るためのチャネルであって、各受信器は実質的に同じ信号を受信しようとする:
物理層ブロックの物理層パケット内の前記データストリームへ前記送信器からデータを送信することを備え、送られたデータが前記データストリームとどのように関連するかの表示は少なくともブロックの前記物理層の少なくとも一部に基づく、方法。 - 請求項19に記載された前記方法を実行するためのコンピュータ実行可能コードを備えるコンピュータ可読媒体。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US5132508P | 2008-05-07 | 2008-05-07 | |
US61/051,325 | 2008-05-07 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011508678A Division JP5847577B2 (ja) | 2008-05-07 | 2009-05-07 | より低いレベルのパケット構造から導かれる記号識別子を用いた放送チャネル上の高品質ストリーム保護 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2015222954A true JP2015222954A (ja) | 2015-12-10 |
Family
ID=41265414
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011508678A Expired - Fee Related JP5847577B2 (ja) | 2008-05-07 | 2009-05-07 | より低いレベルのパケット構造から導かれる記号識別子を用いた放送チャネル上の高品質ストリーム保護 |
JP2015126945A Pending JP2015222954A (ja) | 2008-05-07 | 2015-06-24 | 放送チャネル上の高速チャネルザッピングおよび高品質ストリーム保護 |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011508678A Expired - Fee Related JP5847577B2 (ja) | 2008-05-07 | 2009-05-07 | より低いレベルのパケット構造から導かれる記号識別子を用いた放送チャネル上の高品質ストリーム保護 |
Country Status (14)
Country | Link |
---|---|
US (1) | US20100017686A1 (ja) |
EP (1) | EP2286585A4 (ja) |
JP (2) | JP5847577B2 (ja) |
KR (1) | KR101367886B1 (ja) |
CN (1) | CN102017617B (ja) |
AU (1) | AU2009244223B2 (ja) |
BR (1) | BRPI0912524A2 (ja) |
CA (1) | CA2723386A1 (ja) |
IL (1) | IL208689A0 (ja) |
MX (1) | MX2010012117A (ja) |
RU (1) | RU2010150108A (ja) |
TW (1) | TW201014366A (ja) |
UA (1) | UA95881C2 (ja) |
WO (1) | WO2009137705A2 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7473693B2 (ja) | 2017-06-02 | 2024-04-23 | ヴィド スケール インコーポレイテッド | 次世代ネットワークを介した360度ビデオ配信 |
Families Citing this family (61)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7068729B2 (en) | 2001-12-21 | 2006-06-27 | Digital Fountain, Inc. | Multi-stage code generator and decoder for communication systems |
US6307487B1 (en) | 1998-09-23 | 2001-10-23 | Digital Fountain, Inc. | Information additive code generator and decoder for communication systems |
US9240810B2 (en) | 2002-06-11 | 2016-01-19 | Digital Fountain, Inc. | Systems and processes for decoding chain reaction codes through inactivation |
US6909383B2 (en) | 2002-10-05 | 2005-06-21 | Digital Fountain, Inc. | Systematic encoding and decoding of chain reaction codes |
KR101083655B1 (ko) * | 2003-07-15 | 2011-11-16 | 소니 주식회사 | 무선 통신 시스템, 무선 통신 장치 및 무선 통신 방법, 및컴퓨터·프로그램 |
KR101161193B1 (ko) | 2004-05-07 | 2012-07-02 | 디지털 파운튼, 인크. | 파일 다운로드 및 스트리밍 시스템 |
JP5550834B2 (ja) | 2006-02-13 | 2014-07-16 | デジタル ファウンテン, インコーポレイテッド | 可変fecオーバヘッド及び保護期間を利用したストリーミング及びバッファリング |
US9270414B2 (en) | 2006-02-21 | 2016-02-23 | Digital Fountain, Inc. | Multiple-field based code generator and decoder for communications systems |
US7971129B2 (en) | 2006-05-10 | 2011-06-28 | Digital Fountain, Inc. | Code generator and decoder for communications systems operating using hybrid codes to allow for multiple efficient users of the communications systems |
US9380096B2 (en) | 2006-06-09 | 2016-06-28 | Qualcomm Incorporated | Enhanced block-request streaming system for handling low-latency streaming |
US9386064B2 (en) | 2006-06-09 | 2016-07-05 | Qualcomm Incorporated | Enhanced block-request streaming using URL templates and construction rules |
US9419749B2 (en) | 2009-08-19 | 2016-08-16 | Qualcomm Incorporated | Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes |
US9209934B2 (en) | 2006-06-09 | 2015-12-08 | Qualcomm Incorporated | Enhanced block-request streaming using cooperative parallel HTTP and forward error correction |
US9178535B2 (en) | 2006-06-09 | 2015-11-03 | Digital Fountain, Inc. | Dynamic stream interleaving and sub-stream based delivery |
US9432433B2 (en) | 2006-06-09 | 2016-08-30 | Qualcomm Incorporated | Enhanced block-request streaming system using signaling or block creation |
MX2010002829A (es) | 2007-09-12 | 2010-04-01 | Digital Fountain Inc | Generacion y comunicacion de informacion para identificacion de fuentes para permitir comunicaciones seguras. |
US9281847B2 (en) | 2009-02-27 | 2016-03-08 | Qualcomm Incorporated | Mobile reception of digital video broadcasting—terrestrial services |
US9288010B2 (en) | 2009-08-19 | 2016-03-15 | Qualcomm Incorporated | Universal file delivery methods for providing unequal error protection and bundled file delivery services |
US9917874B2 (en) | 2009-09-22 | 2018-03-13 | Qualcomm Incorporated | Enhanced block-request streaming using block partitioning or request controls for improved client-side handling |
US9136981B2 (en) | 2010-03-03 | 2015-09-15 | Qualcomm Incorporated | Block aggregation of objects in a communication system |
US9049497B2 (en) | 2010-06-29 | 2015-06-02 | Qualcomm Incorporated | Signaling random access points for streaming video data |
US9235585B1 (en) | 2010-06-30 | 2016-01-12 | Emc Corporation | Dynamic prioritized recovery |
US8438420B1 (en) | 2010-06-30 | 2013-05-07 | Emc Corporation | Post access data preservation |
US9367561B1 (en) * | 2010-06-30 | 2016-06-14 | Emc Corporation | Prioritized backup segmenting |
US9697086B2 (en) | 2010-06-30 | 2017-07-04 | EMC IP Holding Company LLC | Data access during data recovery |
US9185439B2 (en) | 2010-07-15 | 2015-11-10 | Qualcomm Incorporated | Signaling data for multiplexing video components |
US9596447B2 (en) | 2010-07-21 | 2017-03-14 | Qualcomm Incorporated | Providing frame packing type information for video coding |
US8806050B2 (en) | 2010-08-10 | 2014-08-12 | Qualcomm Incorporated | Manifest file updates for network streaming of coded multimedia data |
US9270299B2 (en) | 2011-02-11 | 2016-02-23 | Qualcomm Incorporated | Encoding and decoding using elastic codes with flexible source block mapping |
US20120208580A1 (en) * | 2011-02-11 | 2012-08-16 | Qualcomm Incorporated | Forward error correction scheduling for an improved radio link protocol |
US8958375B2 (en) * | 2011-02-11 | 2015-02-17 | Qualcomm Incorporated | Framing for an improved radio link protocol including FEC |
KR20120137198A (ko) * | 2011-06-11 | 2012-12-20 | 삼성전자주식회사 | 통신 시스템에서 패킷 송수신 장치 및 방법 |
US10498359B2 (en) | 2011-07-14 | 2019-12-03 | Microsoft Technology Licensing, Llc | Correction data |
GB2492830B (en) | 2011-07-14 | 2018-06-27 | Skype | Correction data |
US9253233B2 (en) | 2011-08-31 | 2016-02-02 | Qualcomm Incorporated | Switch signaling methods providing improved switching between representations for adaptive HTTP streaming |
US9843844B2 (en) | 2011-10-05 | 2017-12-12 | Qualcomm Incorporated | Network streaming of media data |
JP5860673B2 (ja) | 2011-11-07 | 2016-02-16 | 日東電工株式会社 | 粘着剤組成物、粘着剤層、粘着剤層付偏光板および画像形成装置 |
KR102028948B1 (ko) * | 2011-11-08 | 2019-10-17 | 삼성전자주식회사 | 멀티미디어 통신 시스템에서 어플리케이션 계층-순방향 오류 정정 패킷 송/수신 장치 및 방법 |
EP2783475B1 (en) | 2011-11-21 | 2017-11-15 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Interleaving for layer-aware forward error correction |
JP5875106B2 (ja) | 2011-11-24 | 2016-03-02 | 日東電工株式会社 | 粘着剤組成物、粘着剤層、粘着剤層付偏光板および画像形成装置 |
WO2013081414A1 (en) * | 2011-11-30 | 2013-06-06 | Samsung Electronics Co., Ltd. | Apparatus and method of transmiting/receiving broadcast data |
US9294226B2 (en) | 2012-03-26 | 2016-03-22 | Qualcomm Incorporated | Universal object delivery and template-based file delivery |
JP5425258B2 (ja) | 2012-04-16 | 2014-02-26 | 日東電工株式会社 | 粘着剤組成物、粘着剤層、粘着剤層付偏光フィルムおよび画像形成装置 |
KR101961736B1 (ko) * | 2012-04-23 | 2019-03-25 | 삼성전자 주식회사 | 통신 시스템에서 패킷 송수신 장치 및 방법 |
TWI610554B (zh) | 2012-07-10 | 2018-01-01 | Vid衡器股份有限公司 | 無線傳輸/接收單元中內容切換/品質驅動切換的方法 |
JP6073503B2 (ja) * | 2013-01-18 | 2017-02-01 | フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン | データストリーム間で同期される開始記号識別子を有する少なくとも2つのデータストリームからの記号を有するソースブロックを用いる前方誤り訂正 |
WO2014189278A1 (ko) * | 2013-05-22 | 2014-11-27 | 엘지전자 주식회사 | Ip 기반의 디지털 방송 시스템에서 계층간 시그널링 데이터 처리 방법 및 장치 |
US9582904B2 (en) | 2013-11-11 | 2017-02-28 | Amazon Technologies, Inc. | Image composition based on remote object data |
US9641592B2 (en) | 2013-11-11 | 2017-05-02 | Amazon Technologies, Inc. | Location of actor resources |
US9805479B2 (en) | 2013-11-11 | 2017-10-31 | Amazon Technologies, Inc. | Session idle optimization for streaming server |
US9634942B2 (en) | 2013-11-11 | 2017-04-25 | Amazon Technologies, Inc. | Adaptive scene complexity based on service quality |
US9578074B2 (en) | 2013-11-11 | 2017-02-21 | Amazon Technologies, Inc. | Adaptive content transmission |
US9413830B2 (en) | 2013-11-11 | 2016-08-09 | Amazon Technologies, Inc. | Application streaming service |
US9604139B2 (en) | 2013-11-11 | 2017-03-28 | Amazon Technologies, Inc. | Service for generating graphics object data |
JP2015136057A (ja) * | 2014-01-17 | 2015-07-27 | ソニー株式会社 | 通信装置、通信データ生成方法、および通信データ処理方法 |
KR102208814B1 (ko) | 2014-03-28 | 2021-01-28 | 삼성전자주식회사 | 통신 시스템에서 패킷 송수신 방법 및 장치 |
US9455750B2 (en) | 2014-07-28 | 2016-09-27 | Qualcomm Incorporated | Source block size selection |
RU2666326C2 (ru) * | 2014-07-29 | 2018-09-06 | Хуавей Текнолоджиз Ко., Лтд. | Устройство и способ шифрования и передачи данных |
US20160323063A1 (en) * | 2015-05-01 | 2016-11-03 | Qualcomm Incorporated | Bundled Forward Error Correction (FEC) for Multiple Sequenced Flows |
KR101870750B1 (ko) * | 2017-12-28 | 2018-06-26 | 오픈스택 주식회사 | 패킷 전송 순서 재배열을 이용한 영상 인코딩 장치 및 그 동작 방법 |
US11863317B2 (en) * | 2021-08-25 | 2024-01-02 | BitRipple, Inc. | Methods for reliable low latency data delivery using erasure codes and feedback |
Family Cites Families (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6307487B1 (en) * | 1998-09-23 | 2001-10-23 | Digital Fountain, Inc. | Information additive code generator and decoder for communication systems |
KR100607934B1 (ko) * | 1999-08-27 | 2006-08-03 | 삼성전자주식회사 | 광대역 무선 통신에서의 링크 계층의 오류 제어방법 및 이를위한 기록 매체 |
US6633564B1 (en) * | 1999-09-22 | 2003-10-14 | Nortel Networks Limited | Method and apparatus for inserting packets into a data stream |
US6845105B1 (en) * | 2000-09-28 | 2005-01-18 | Telefonaktiebolaget Lm Ericsson | Method and apparatus for maintaining sequence numbering in header compressed packets |
US7136395B2 (en) * | 2000-11-30 | 2006-11-14 | Telefonaktiebolaget L M Ericsson (Publ) | Method and system for transmission of headerless data packets over a wireless link |
US7289497B2 (en) * | 2001-07-03 | 2007-10-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Implicit packet type identification |
EP1521384A3 (en) * | 2003-08-20 | 2007-03-14 | Siemens Aktiengesellschaft | A method for transmitting a multimedia message |
KR100602633B1 (ko) * | 2003-11-08 | 2006-07-19 | 삼성전자주식회사 | 패킷의 헤더를 압축하는 방법 및 그 장치 |
US7817579B2 (en) * | 2004-03-29 | 2010-10-19 | Intel Corporation | Access point having at least one or more configurable radios |
KR101161193B1 (ko) * | 2004-05-07 | 2012-07-02 | 디지털 파운튼, 인크. | 파일 다운로드 및 스트리밍 시스템 |
KR100800887B1 (ko) * | 2004-05-07 | 2008-02-04 | 삼성전자주식회사 | 무선 통신 시스템에서 방송 서비스 데이터 송/수신 방법 및 시스템 |
EP2214412A3 (en) * | 2004-05-13 | 2012-11-14 | Qualcomm Incorporated | Delivery of information over a communication channel |
WO2006038054A1 (en) * | 2004-10-06 | 2006-04-13 | Nokia Corporation | Packet transmission using error correction of data packets |
US7751324B2 (en) * | 2004-11-19 | 2010-07-06 | Nokia Corporation | Packet stream arrangement in multimedia transmission |
CN100413370C (zh) * | 2004-12-13 | 2008-08-20 | 上海贝尔阿尔卡特股份有限公司 | 传输多媒体广播/多播业务告知指示的方法和设备 |
CN101223723A (zh) * | 2005-05-19 | 2008-07-16 | 诺基亚公司 | 用于在dvb-h传输系统中为标记有优先级的数据报提供非均衡差错保护的系统和方法 |
CA2610101C (en) * | 2005-06-17 | 2013-07-30 | Samsung Electronics Co., Ltd. | Apparatus and method for transmitting/receiving broadcast data in a mobile communication system |
CN1917411B (zh) * | 2005-08-16 | 2012-03-07 | 中兴通讯股份有限公司 | 一种实现多载波高速下行分组接入的系统和方法 |
US7676733B2 (en) * | 2006-01-04 | 2010-03-09 | Intel Corporation | Techniques to perform forward error correction for an electrical backplane |
ES2392461T3 (es) * | 2006-01-05 | 2012-12-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Gestión de archivo contenedor de medios |
WO2007095551A2 (en) * | 2006-02-13 | 2007-08-23 | Digital Fountain, Inc. | Fec streaming with aggregation of concurrent streams for fec computation |
CN101072227A (zh) * | 2006-05-11 | 2007-11-14 | 华为技术有限公司 | 一种视频广播系统中的发送系统、方法和接收系统 |
MX2010002829A (es) * | 2007-09-12 | 2010-04-01 | Digital Fountain Inc | Generacion y comunicacion de informacion para identificacion de fuentes para permitir comunicaciones seguras. |
US20090094356A1 (en) * | 2007-10-09 | 2009-04-09 | Nokia Corporation | Associating Physical Layer Pipes and Services Through a Program Map Table |
-
2009
- 2009-05-07 CN CN200980116202.XA patent/CN102017617B/zh not_active Expired - Fee Related
- 2009-05-07 EP EP09743691.9A patent/EP2286585A4/en not_active Withdrawn
- 2009-05-07 RU RU2010150108/07A patent/RU2010150108A/ru not_active Application Discontinuation
- 2009-05-07 MX MX2010012117A patent/MX2010012117A/es active IP Right Grant
- 2009-05-07 JP JP2011508678A patent/JP5847577B2/ja not_active Expired - Fee Related
- 2009-05-07 TW TW098115118A patent/TW201014366A/zh unknown
- 2009-05-07 WO PCT/US2009/043184 patent/WO2009137705A2/en active Application Filing
- 2009-05-07 CA CA2723386A patent/CA2723386A1/en not_active Abandoned
- 2009-05-07 US US12/437,251 patent/US20100017686A1/en not_active Abandoned
- 2009-05-07 AU AU2009244223A patent/AU2009244223B2/en not_active Ceased
- 2009-05-07 UA UAA201014668A patent/UA95881C2/ru unknown
- 2009-05-07 KR KR1020107027519A patent/KR101367886B1/ko not_active IP Right Cessation
- 2009-05-07 BR BRPI0912524A patent/BRPI0912524A2/pt not_active IP Right Cessation
-
2010
- 2010-10-13 IL IL208689A patent/IL208689A0/en unknown
-
2015
- 2015-06-24 JP JP2015126945A patent/JP2015222954A/ja active Pending
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7473693B2 (ja) | 2017-06-02 | 2024-04-23 | ヴィド スケール インコーポレイテッド | 次世代ネットワークを介した360度ビデオ配信 |
Also Published As
Publication number | Publication date |
---|---|
WO2009137705A2 (en) | 2009-11-12 |
KR20110015615A (ko) | 2011-02-16 |
TW201014366A (en) | 2010-04-01 |
MX2010012117A (es) | 2010-12-01 |
AU2009244223A1 (en) | 2009-11-12 |
RU2010150108A (ru) | 2012-06-20 |
CN102017617A (zh) | 2011-04-13 |
WO2009137705A3 (en) | 2010-02-11 |
UA95881C2 (ru) | 2011-09-12 |
IL208689A0 (en) | 2010-12-30 |
KR101367886B1 (ko) | 2014-02-26 |
EP2286585A2 (en) | 2011-02-23 |
CN102017617B (zh) | 2014-08-13 |
JP2011523806A (ja) | 2011-08-18 |
EP2286585A4 (en) | 2015-06-17 |
JP5847577B2 (ja) | 2016-01-27 |
BRPI0912524A2 (pt) | 2015-10-13 |
US20100017686A1 (en) | 2010-01-21 |
AU2009244223B2 (en) | 2013-02-14 |
CA2723386A1 (en) | 2009-11-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5847577B2 (ja) | より低いレベルのパケット構造から導かれる記号識別子を用いた放送チャネル上の高品質ストリーム保護 | |
JP5442816B2 (ja) | 可変fecオーバヘッド及び保護期間を利用したストリーミング及びバッファリング | |
US9350488B2 (en) | Content delivery system with allocation of source data and repair data among HTTP servers | |
US9178535B2 (en) | Dynamic stream interleaving and sub-stream based delivery | |
US9246630B2 (en) | Method, device, and system for forward error correction | |
KR101591238B1 (ko) | Http 서버들 사이의 소스 데이터 및 리페어 데이터의 할당에 의한 컨텐츠 전달 시스템 | |
US8458571B2 (en) | Data transmission method and equipment | |
KR20190043060A (ko) | 멀티미디어 통신 시스템에서 응용 계층 순방향 오류 정정 방식을 사용하여 미디어 데이터를 송수신하는 방법 및 장치 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20160726 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20160830 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20170321 |