(57)【要約】【課題】インターネットプロトコル（ＩＰ）テレビ（ＩＰＴＶ）を得る。【解決手段】インターネットプロトコル（ＩＰ）テレビ（ＩＰＴＶ）のためのホームネットワークにおいて、ＩＰＴＶセットトップボックス（ＳＴＢ）のコントローラが、ホームネットワークの動作及びネットワークにおけるデータパケットの統計を取得して解析する。ホームゲートウェイ（ＨＧ）において、統計が受信され、パケットが復号され、次いで、データパケット、修復パケット、及びラプタパケットに符号化され、統計に従ってパケット損失が減少される。すなわち、符号化パケットは、追加の誤り訂正符号を有する。【選択図】図７
2010246120.tif 000002
【特許請求の範囲】
【請求項１】
ホームネットワークにおいてインターネットプロトコルテレビを使用して通信するための装置であって、
前記ホームネットワークに接続されているＩＰＴＶセットトップボックスと、
前記ＩＰＴＶセットトップボックスから統計を受信するように構成されるホームゲートウェイとを備え、
前記ＩＰＴＶセットトップボックスは、
前記ホームネットワークの動作と、前記ホームネットワークによって通信されるデータパケット、修復パケット、及びラプタパケットとを特徴付ける、統計を取得して解析するように構成されるＳＴＢコントローラと、
前記ＳＴＢコントローラに接続されているＳＴＢ復号器とを含み、
前記ホームゲートウェイは、
前記統計を受信して解析するように構成されるＨＧコントローラと、
前記ＨＧコントローラに接続され、前記ＳＴＢ復号器が前記統計に従ってパケット損失を減少させるために、ＩＰネットワークから受信される前記データパケット、前記修復パケット、及び前記ラプタパケットを符号化するように構成されるＨＧ符号化器とを含む、
ホームネットワークにおいてインターネットプロトコルテレビを使用して通信するための装置。
【請求項２】
前記ＩＰＴＶセットトップボックスは、リアルタイムトランスポート制御プロトコルを使用して、前記統計を前記ＨＧコントローラへ送信する
請求項１記載の装置。
【請求項３】
前記統計は、送信バイト、送信パケット、損失パケット、ジッタ、ラウンドトリップ遅延、又はそれらの組み合わせから成る群から選択される
請求項１記載の装置。
【請求項４】
前記ＨＧ符号化器は、
前記修復パケットを強化修復パケットとして符号化するように構成される第１レイヤ強化符号化器と、
前記ラプタパケットを強化ラプタパケットとして符号化するように構成される第２レイヤ強化符号化器と、
前記統計に従って前記第１レイヤ強化符号化器及び第２レイヤ強化符号化器を選択するためのスイッチとを含む
請求項１記載の装置。
【請求項５】
前記ホームゲートウェイは、前記統計に基づいて、前記データパケット、前記修復パケット、及び前記ラプタパケットのみを送信するか、又は前記データパケット、前記修復パケット、前記ラプタパケット、及び強化修復パケットを送信するか、又は前記データパケット、前記修復パケット、前記ラプタパケット、前記強化修復パケット、及び強化ラプタパケットを送信する
請求項１記載の装置。
【請求項６】
前記第１レイヤ強化符号化器は、
修復パケットのセットを記憶するように構成されるバッファを含み、
前記修復パケットのセットに対して排他的ＯＲ演算を適用して、前記強化修復パケットを生成する
請求項４記載の装置。
【請求項７】
前記強化修復パケットは、前記修復パケットと同じ標準規格を使用する
請求項４記載の装置。
【請求項８】
前記標準規格は、ＳＭＰＴＥ２０２２−１標準規格である
請求項７記載の装置。
【請求項９】
前記第２レイヤ強化符号化器は、
ラプタパケットのセットを記憶するように構成されるバッファを含み、
前記ラプタパケットのセットに対して排他的ＯＲ演算を適用して、前記強化ラプタパケットを生成する
請求項４記載の装置。
【請求項１０】
ホームネットワークにおいてインターネットプロトコルテレビを使用して通信するための方法であって、
ホームゲートウェイにおいて、ソースデータストリームのデータパケット、修復パケット、及びラプタパケットを受信するステップと、
前記ホームネットワークに接続されているＩＰＴＶセットトップボックスにおいて、前記ホームネットワークの動作並びに前記ホームネットワークによって通信される前記データパケット、前記修復パケット、及び前記ラプタパケットを特徴付ける統計を取得して解析するステップと、
前記ホームゲートウェイにおいて、前記データパケット、前記修復パケット、及び前記ラプタパケットを符号化して、前記統計に従い、追加の強化修復パケット及び強化ラプタパケットを提供するステップと、
前記ＩＰＴＶセットトップボックスにおいて、前記データパケット、前記修復パケット、前記ラプタパケット、並びに前記追加の強化修復パケット及び前記強化ラプタパケットを復号して、前記ソースデータストリームを回復するステップと
を含む、ホームネットワークにおいてインターネットプロトコルテレビを使用して通信するための方法。
【請求項１１】
前記ＩＰＴＶセットトップボックスは、リアルタイムトランスポート制御プロトコルを使用して、前記統計を前記ホームゲートウェイへ送信する
請求項１０記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、包括的には、ホームネットワークにおけるインターネットプロトコルテレビ（ＩＰＴＶ）に関し、より詳細には、アプリケーションレイヤ前方誤り訂正（ＡＬ−ＦＥＣ）を使用してＩＰＴＶの品質を向上させることに関するものである。
【背景技術】
【０００２】
インターネットプロトコルテレビ
インターネットプロトコルテレビ（ＩＰＴＶ）は、従来の広帯域ケーブルチャネルを使用する代わりにインターネットプロトコル（ＩＰ）を使用してテレビコンテンツを提供する。ＩＰＴＶは、通常、「トリプルプレイ」と総称される、インターネットアクセスを使用したビデオオンデマンド（ＶＯＤ）、ボイスオーバＩＰ（ＶＯＩＰ）、又はデジタルデータ等の他のサービスとバンドルされる。
【０００３】
ＩＰＴＶは、多数の独特の特徴を有する。従来のＴＶネットワークでは、利用可能なすべてのコンテンツは、各顧客へ絶え間なく送信される。そして、顧客は、鑑賞する特定のコンテンツを選択する。これによって、例えば１チャネル当たり６ＭＨｚ、すなわち１００チャネルケーブルネットワークでは６００ＭＨｚのネットワーク帯域幅が消費される。
【０００４】
ＩＰＴＶでは、顧客によって選択されたコンテンツしか送信されない。その上、ＩＰＴＶは、デジタルビデオレコーダ（ＤＶＲ）が放送を同時に記録するための能力も有する。また、ＩＰＴＶは、顧客が、現在の番組から離れることなく、ピクチャーインピクチャー（ＰＩＰ）視聴を行うことも可能にする。ＩＰＴＶもパケットを使用し、これによって、誤り訂正が可能になる。誤り訂正は、従来のＴＶ信号には利用可能ではない。
【０００５】
前方誤り訂正
前方誤り訂正（ＦＥＣ）によれば、送信者は、送信されるパケットに誤り訂正符号（ＥＣＣ）を加える。そして、受信者は、ほとんどの誤りを検出して訂正することができる。ＦＥＣの１つの重要な部類には、線形ブロック誤り訂正符号が含まれる。一般に、ＦＥＣは、国際標準化機構（ＩＳＯ）プロトコルスタックのデータリンクレイヤ又は物理レイヤで使用されて、パケット損失を削減し、すべてのコンテンツについて一定のサービス品質（ＱｏＳ）を確保する。
【０００６】
アプリケーションレイヤ前方誤り訂正
高品質ＩＰＴＶサービスの１つの課題は、パケット損失によって引き起こされる顕著なアーティファクトを削減することである。高品質を達成するには、リングレイヤ及び物理レイヤにおけるＦＥＣ保護に加えて、アプリケーションレイヤ前方誤り訂正（ＡＬ−ＦＥＣ）を使用することができる。
【０００７】
図２は、ＡＬ−ＦＥＣ符号化及びＡＬ−ＦＥＣ復号の一般的な概念を示す。送信機２１０では、ソースパケット２１１が、ｋ個ごとに、ＦＥＣ符号化器２１２を通じてｎ個（ｎ＞ｋ）のパケットに符号化される。このｎ個のパケットは、ｋ個のデータパケット及びｎ−ｋ個の修復パケット２１３を含む。これらのデータパケット及び修復パケットは、チャネル２２０を通じて送信される。チャネル２２０は、どのネットワークに存在するものでもよい。ネットワーク状態に起因して、いくつかのパケット２３１は、送信中に損失される。受信機２３０では、ＦＥＣ復号器２３２が、受信されたすべてのパケットを利用して、損失されたソースパケットを回復する。
【０００８】
リアルタイムトランスポートプロトコル（ＲＴＰ）により搬送されるＩＰＴＶサービスについてのストリーミングメディアのＡＬ−ＦＥＣ保護のためのオプションのプロトコルについては、ETSI TS 102 034 v1.3.1の「Transport of MPEG 2 Transport Stream (TS) Based DVB Services over IP Based Networks」（DVB Blue Book A086rev5）、並びにM. Luby、T. Stockhammer、及びM. Watsonの「IPTV Systems, Standards and Architectures: Part II Application Layer FEC in IPTV Services」（IEEE Communications Magazine, pp. 94-101, May 2008）を参照されたい。
【０００９】
ETSI TS 102 034では、ＡＬ−ＦＥＣプロトコルは、図３に示すような階層構造を適用する。この階層構造では、ソースストリームは、データパケット３１５と、単純な修復パケットに基づくインターリーブされたパリティ符号、すなわち動画及びテレビの技術者協会（Society of Motion Picture and Television Engineers）（ＳＭＰＴＥ）２０２２−１符号によって符号化された修復パケット３２０のＡＬ−ＦＥＣストリームと、ラプタ符号（raptor code）によって符号化されたラプタパケット３３０のＡＬ−ＦＥＣストリームとを含む。ラプタ符号は、線形時間符号化及び線形時間復号を有するファウンテン符号の１つの部類である。受信機３４０では、復号器３５０がパケットの復号に使用されて、ソースストリーム３１０を回復する。
【００１０】
インターリーブされたパリティ符号（ＳＭＰＴＥ２０２２−１符号）
図４は、インターリーブされたパリティ符号（ＳＭＰＴＥ２０２２−１符号）の符号化プロセスを示す。ＤＰソースパケット２１１を有するソースブロック４４０は、Ｄ行Ｐ列に配列されている。同じＳＭＰＴＥ修復パケット４３０によってカバーされるデータパケット間の選ばれた期間はＰである。各列におけるＤ個のデータパケット４１０は、排他的ＯＲ（ＸＯＲ）ブロック４２０を通過して、ＳＭＰＴＥ修復パケット４３０が生成される。
【００１１】
いずれかのデータパケットが送信中に損失された場合、ＳＭＰＴＥ２０２２−１復号が実行される。１つの列で１つのデータパケットのみが欠落しており、且つ、対応する修復パケットが受信された場合、この欠落したデータパケットは、その修復パケットをこの列のデータパケットと排他的ＯＲすることによって回復することができる。
【００１２】
図５は、修復パケットのヘッダフォーマットを示す。いくつかのフィールドは、次のように説明される。ＳＮＢａｓｅロービット５１０は、その修復パケットに関連付けられるソースパケットの最小シーケンス番号である。オフセット５２０及びＮＡ５３０は、それぞれパラメータＰ及びＤを表す。
【００１３】
ＳＭＰＴＥ２０２２−１符号に関する詳細については、ＳＭＰＴＥ仕様２０２２−１「Forward Error Correction for Real-time Video/Audio Transport Over IP Network」を参照されたい。
【００１４】
ラプタ符号
ラプタ符号は、ファウンテン符号の一種である。ファウンテン符号は、レートレス消去符号としても知られており、線形ブロック符号に属する。ラプタ符号は、固定数のデータシンボルについて、符号化シンボル（データシンボル及び修復シンボルの双方を含む）の個数が潜在的に無限になる可能性があり、データシンボルの個数と等しいサイズ又はデータシンボルの個数よりも僅かに大きいサイズの符号化シンボルの任意のサブセットからデータシンボルを回復できるという特性を有する。これについては、米国特許第６，３０７，４８７号を参照されたい。
【００１５】
ＬＴ符号は、優れた性能を有するが、誤り性能を妥協することなくして、一定の符号化複雑度及び線形の復号複雑度を有することはない。ラプタ符号は、ＬＴ符号の拡張であり、この欠点を克服している。これについては、米国特許第６，３０７，４８７号及び第７，１３９，９６０号を参照されたい。
【００１６】
ＩＰＴＶ標準規格で使用されるラプタ符号は、組織線形ブロック符号である。組織符号の特性は、それらの符号語を２つの部分に区画できるということである。一方の区画はもとのままのデータシンボルを含み、他方の区画は修復シンボルを含む。特に指定のない限り、本明細書で「ラプタ符号」と言うときは、組織ラプタ符号を指すものとする。
【００１７】
ラプタ符号化器をデータパケットに適用するために、ソースパケットをブロックに区画することができる。ラプタ符号化器は、各ブロックに独立に適用される。各ブロックは、一意の整数のソースブロック番号（ＳＢＮ）によって識別される。各ブロックは、Ｋ個のソースシンボルに区画される。各ソースシンボルは、一意の整数の符号化シンボル識別子（ＥＳＩ）によって識別される。
【００１８】
各符号化パケットは、データシンボル又は修復シンボルを含む。各データパケット又は各修復パケットの符号化シンボルＩＤ  Ｘは、そのパケットで搬送される最初のデータシンボル又は修復シンボルの符号化シンボルＩＤである。そのパケットにおける後続のデータシンボル又は修復シンボルは、符号化シンボルＩＤ  Ｘ＋１〜Ｘ＋Ｇ−１を順に有する。ここで、Ｇはパケットにおけるシンボルの個数である。パケットは、同じブロックについて任意の個数のシンボルを含むことができる。
【００１９】
図６は、ラプタ符号の符号化プロセスを示す。最初に、Ｌ個の中間シンボル６３１（Ｌ＞Ｋ）を有する中間ブロック６３０が、Ｋ個のデータシンボル６１１のブロック６１０から中間シンボルジェネレータ６２０を通じて生成される。Ｃ＝（Ｃ［０］，…，Ｃ［Ｋ−１］）がソースブロックを表し、Ｅ＝（Ｅ［０］，…，Ｅ［Ｌ−１］）が中間ブロックを表すものとする。ＬＴ符号化器６４０を通じて、中間ブロック６３０は、符号化ブロック６５０に符号化される。符号化ブロック６５０は、変更されていないソースシンボル６１１及びいくつかの修復シンボル６５１を含む。ソースデータシンボル及び修復シンボルの双方が、符号化シンボルと呼ばれる。
【００２０】
最後のＬ−Ｋ個の中間シンボルと最初のＫ個の中間シンボルとの間には「前置符号化関係」がある。前置符号化関係は、
【００２１】
【数１】
2010246120.tif 000003
【００２２】
である。ここで、Ｇｐｒｅ−ｃｏｄｉｎｇは、（Ｌ−Ｋ）×Ｌバイナリ行列であり、０は長さ（Ｌ−Ｋ）の列ベクトルである。
【００２３】
このバイナリ行列において、要素は０又は１であり、・は、２つの要素ＧＦ（２）のガロア体上の行列乗算を表す。一例示のバイナリ行列は、
【００２４】
【数２】
2010246120.tif 000004
【００２５】
であり、
【００２６】
【数３】
2010246120.tif 000005
【００２７】
である場合、
【００２８】
【数４】
2010246120.tif 000006
【００２９】
となる。
【００３０】
図６に示すように、Ｋ個のソースデータシンボルは、Ｌ個の中間シンボルからＬＴ符号化器を通じて取得することができる。ＬＴ符号は線形ブロック符号であるので、Ｌ個の中間シンボル及びＫ個のソースデータシンボルは、Ｋ×Ｌバイナリ行列ＧＬＴによって関係付けることができる。すなわち、
【００３１】
【数５】
2010246120.tif 000007
【００３２】
である。
【００３３】
Ｄが、Ｌ−Ｋ個のゼロシンボルとその後に続くＫ個のソースデータシンボルとから成る列ベクトルを表すものとする。ＧＦ（２）上の行列Ａを
【００３４】
【数６】
2010246120.tif 000008
【００３５】
と定義する。このとき、
【００３６】
【数７】
2010246120.tif 000009
【００３７】
となる。
【００３８】
中間シンボルは、
【００３９】
【数８】
2010246120.tif 000010
【００４０】
である。
【００４１】
行列Ａは、最大階数であり、反転不能である。
【００４２】
中間シンボル６３１が生成された後、修復シンボル６５１が、ＬＴ符号化器６４０によって生成される。修復シンボルを
【００４３】
【数９】
2010246120.tif 000011
【００４４】
によって表すものとする。ここで、Ｊは、生成された修復シンボルの個数である。このとき、Ｌ個の中間シンボル及びＪ個の修復シンボルは、Ｊ×Ｌバイナリ行列Ｇ’ＬＴによって関係付けることができる。すなわち、
【００４５】
【数１０】
2010246120.tif 000012
【００４６】
となる。１つ又は複数の修復シンボルがグループ化されて、修復パケットが形成される。
【００４７】
復号プロセスは、次のように説明される。Ｖ≧Ｋは、ソースブロックの受信符号化シンボルの個数であるとし、Ｍ＝Ｌ−Ｋ＋Ｖであるとする。Ｄ’は、受信機に知られている値を有するＭ個のシンボルの列ベクトルであるとする。ここで、Ｍ個のシンボルの最初のＬ−Ｋ個は、ゼロの値を有し、Ｍ個のシンボルの残りのＶ個は、ソースブロックの受信符号化シンボルである。
【００４８】
Ｍ×Ｌバイナリ行列Ａ’は、受信符号化シンボルに基づいて生成することができ、この行列Ａ’は３つの部分から成る。Ａ’の第１の部分はＧｐｒｅ−ｃｏｄｉｎｇである。Ａ’の第２の部分は、受信ソースシンボルに対応するＧＬＴの行を含む。例えば、第１のソースデータシンボル、第３のソースデータシンボル、第５のソースデータシンボル、…が受信機で受信された場合、ＧＬＴの第１行、第３行、第５行、…が選択される。Ａ’の第３の部分は、受信修復シンボルに対応するＧ’ＬＴの行を含む。このとき、
【００４９】
【数１１】
2010246120.tif 000013
【００５０】
である。ソースブロックを復号することは、Ａ’及びＤ’からＥを解くことと等価である。Ａ’の階数がＬである場合に限り、Ｅを復号することができ、式（４）を使用して、欠落したソースデータシンボルを回復することができる。
【００５１】
ラプタ符号化及びラプタ復号に関するより詳細な情報については、ESTI TS 102 472の「Digital Video Broadcasting (DVB); IP Datacast over DVB-H:Content Delivery Protocols」を参照されたい。
【００５２】
ＩＰＴＶのためのＡＬ−ＦＥＣの復号
復号は、受信機側で次のように実行される。
【００５３】
ステップ１：ＳＭＰＴＥ２０２２−１復号。このステップでは、ＳＭＰＴＥ２０２２−１復号が使用され、欠落したすべてのデータパケットが回復され、ステップ２に進む。
【００５４】
ステップ２：ラプタ復号。このステップでは、ラプタ修復パケットが、受信データパケット及びステップ１で回復されたあらゆるデータパケットと共に、（上述したような）標準的なラプタ復号手順を使用して処理され、より多くのデータパケットが回復される。ラプタ復号の後、依然として欠落したデータパケットがある場合、ステップ３を実行する。
【００５５】
ステップ３：復号。このステップでは、未処理のＳＭＰＴＥ２０２２−１パケットが、ラプタ復号プロセスに加えることができる形態に変換され、ラプタ復号が継続する。復号の詳細については、ETSI TS 102 034 v1.3.1の「Transport of MPEG 2 Transport Stream (TS) Based DVB Services over IP Based Networks」（DVB Blue Book A086rev5, Oct. 2007）を参照されたい。
【００５６】
発明の動機
現行のＡＬ−ＦＥＣ方式は、パケット損失を効果的に削減できるが、いくつかのホームネットワークの場合、特に無線ネットワークの場合、パケットがホームネットワークに入った後に、さらなるパケット損失が起こる。エンドデバイスにおけるパケット損失は、時に予測よりも深刻になる可能性がある。この場合、ＩＰネットワークからホームゲートウェイ（ＨＧ）に到達したパケットは、すべてのソース情報を回復するのに十分ではあるが、ホームネットワーク内でのパケット損失がかなりの量となるため、ＩＰＴＶ−ＳＴＢは、すべてのソース情報を回復することができない。
【００５７】
この問題を解決するために、ＱｏＳの強化が必要とされる。ＱｏＳ調整可能なホームゲートウェイは、非特許文献１に記載されている。この文献の筆者は、受信データストリームの優先レベルの変更を記載しているが、ホームネットワーク内のパケット損失を取り扱っていない。この問題の１つの解決法は、受信機３４０が、追加のＦＥＣを送信するようにソース３１０に要求できるようにすることである。これについては、特許文献１及び特許文献２を参照されたい。
【００５８】
しかしながら、ソースは、ＩＰＴＶ−ＳＴＢから遠く離れていることが多く、ソースとの通信によって遅延が引き起こされる。
【先行技術文献】
【特許文献】
【００５９】
【特許文献１】米国特許出願公開第２００８／００２８２７９号明細書
【特許文献２】米国特許出願公開第２００８／００２８２８０号明細書
【非特許文献】
【００６０】
【非特許文献１】S. Lee、C. Cho、及びI. Hanによる「QoS-adjustable home gateway for IPTV serice」（ICCE, Jan. 2005, pp. 395-396）
【発明の概要】
【発明が解決しようとする課題】
【００６１】
したがって、パケット損失を削減しホームネットワークにおいて完全に動作する方式が望まれている。
【課題を解決するための手段】
【００６２】
本発明は、誤りが発生しやすいホームネットワークにおいて、特に、ホームネットワークによりパケット損失がさらに引き起こされ、ＩＰＴＶ−ＳＴＢが、送信パケットに組み込まれた誤り制御符号を使用してソースデータを完全に回復できないようになるときに動作する。
【００６３】
本発明の実施の形態は、ホームゲートウェイ（ＨＧ）及びＳＴＢの双方のＱｏＳ強化コンポーネントを提供し、ＳＴＢがＨＧ統計信号を送信することを可能にする。このＨＧ統計信号は、ホームネットワークの動作及びパケットを特徴付ける。ホームネットワークが深刻なパケット損失を有し、ＩＰＴＶサービスの品質が要件を満たすことができない場合、ＱｏＳ強化コンポーネントがアクティブ化される。
【００６４】
本発明の実施の形態は、ＳＴＢにリアルタイムトランスポート制御プロトコル（ＲＴＣＰ）を使用して、フィードバック信号をＨＧへ送信する。ＲＴＣＰは、リアルタイムトランスポートプロトコル（ＲＴＰ）に関係している。ＲＴＣＰは、ＲＴＰフローの帯域外制御情報を提供し、また、ＲＴＰによって提供されるＱｏＳに関するフィードバックも提供する。
【００６５】
ＨＧ及びＳＴＢのＱｏＳ強化コンポーネントは、階層構造を有する。第１レイヤ強化は、より多くの保護をＳＭＰＴＥ修復パケットに加えることである。そして、第２レイヤは、より多くの保護をラプタパケットに加える。ＱｏＳ強化コンポーネントがアクティブ化されると、１つ又は複数の適切なレイヤが、ＳＴＢからフィードバックされた統計に基づいて選択される。
【図面の簡単な説明】
【００６６】
【図１】本発明の実施の形態によるＩＰＴＶネットワーク及びホームネットワークのブロック図である。
【図２】従来のアプリケーションレイヤＦＥＣのブロック図である。
【図３】従来の階層化されたＡＬ−ＦＥＣに基づくＩＰＴＶ送信ネットワークのブロック図である。
【図４】ＳＭＰＴＥ２０２２−１修復パケットの生成のブロック図である。
【図５】ＳＭＰＴＥ２０２２−１修復パケットの従来のＦＥＣヘッダフォーマットのブロック図である。
【図６】従来のラプタ符号化シンボルの生成のブロック図である。
【図７】本発明の一実施の形態によるホームゲートウェイ及びＩＰＴＶ−ＳＴＢのブロック図である。
【図８】本発明の一実施の形態によるＨＧのＱｏＳ強化コンポーネントのブロック図である。
【図９】本発明の一実施の形態によるＨＧ  ＱｏＳ強化符号化器のブロック図である。
【図１０】本発明の一実施の形態によるＨＧ  ＱｏＳ強化符号化器の第１レイヤ強化符号化器のブロック図である。
【図１１】本発明の一実施の形態によるＨＧ  ＱｏＳ強化符号化器の第２レイヤ強化符号化器のブロック図である。
【図１２】本発明の一実施の形態による強化パケットのペイロードＩＤの構造のブロック図である。
【図１３】本発明の一実施の形態によるＩＰＴＶ−ＳＴＢのＱｏＳ強化のフロー図である。
【発明を実施するための形態】
【００６７】
図１は、本発明の実施の形態に係るＩＰＴＶネットワークを示す。ホームゲートウェイ（ＨＧ）１３１は、マルチメディアサーバ１１０を含むＩＰネットワーク１２０にネットワークデバイス１３０を接続するための、住宅１２５におけるインターフェースである。本明細書で使用されるように、住宅は、自宅とすることもできるし、アパートとすることもできるし、さらに、ホテル、病院等の一時的な住宅とすることもでき、すなわち、人々が居住することができ且つ例えばテレビ番組、ウェブコンテンツ、又は電話サービスといったマルチメディアコンテンツへのアクセスを所望できる任意の場所とすることができる。
【００６８】
このインターフェースは、ルータとして機能する。ルータは、異なるサービスを対応するデバイスへ分配するものである。ＩＰＴＶマルチメディアコンテンツは、ゲートウェイから無線接続又は有線接続を介し住宅ネットワーク１３２を通じて転送され、その後、ＩＰＴＶセットボックス（ＩＰＴＶ−ＳＴＢ）１３３により受信されて処理され、例えばＴＶ１３４に表示される。
【００６９】
ホームネットワーク１３２は、ローカルエリアネットワーク（ＬＡＮ）である。このＬＡＮは、無線ＬＡＮ、ケーブル、光ファイバ、又は他の可能な媒体を通じて住宅１２５内のデバイス１３０を接続する。ＩＰＴＶ−ＳＴＢ１３３は、例えば、ＴＶで表示するためにコンテンツを復号する。また、ＩＰＴＶ−ＳＴＢは、双方向通信も提供する。この双方向通信によって、ビデオオンデマンド（ＶＯＤ）及び他の対話型サービスが可能になる。
【００７０】
図７は、ホームゲートウェイ（ＨＧ）１３１を使用した、インターネットネットワーク１２０とホームネットワーク１３２との間の通信を示す。ホームネットワークは、インターネットプロトコルテレビセットトップボックス（ＩＰＴＶ−ＳＴＢ）１３３に接続される。ＩＰＴＶ−ＳＴＢ１３３は、ＳＴＢコントローラ１３５を含む。ＳＴＢコントローラは、ホームネットワークの動作の統計を取得して解析し、ＩＰＴＶ−ＳＴＢは、その統計をゲートウェイ１３１へフィードバックする（７０１）。
【００７１】
ＩＰＴＶ−ＳＴＢは、リアルタイムトランスポートプロトコル（ＲＴＰＣ）７０１を利用して、統計をＨＧ１３１へ送信する。ＲＴＣＰは、コメント要求（ＲＦＣ）３５５０に定義されている。ＲＦＣ３５５０は、インターネット公式プロトコル標準のＲＦＣ１８８９に取って代わるものである。
【００７２】
統計は、ホームネットワーク１３２の動作を特徴付けるだけでなく、送信バイト、送信パケット、損失パケット、ジッタ、及びラウンドトリップ遅延等のＩＰＴＶ−ＳＴＢによって受信されたパケットも特徴付ける。ＨＧのＨＧコントローラ８１０は、統計情報を解析し、どの種類のデータパケット７０２をＩＰＴＶ−ＳＴＢへ送信するのか、及びＩＰＴＶ−ＳＴＢからテレビ１３４等のホームネットワークデバイスへどの種類のデータを送信するのかを決定する。
【００７３】
以下でより詳細に説明するように、ホームネットワークは、低い誤り率、中程度の誤り率、及び高い誤り率を受ける。すなわち、ＬＬ＜ＭＭ＜ＨＨである。誤り率が低い場合、ソースパケットのみが送信される。誤り率が中程度の場合、強化修復パケットも送信される。誤り率が高い場合、ＨＧは、強化ラプタパケットも送信する。
【００７４】
図８は、ＱｏＳ強化コンポーネントを有するＨＧ１３１の細部を示す。ＨＧは、ＨＧコントローラ８１０を含む。このコントローラは、ＩＰＴＶ−ＳＴＢから受信される統計を受信して解析する。その後、ＨＧは、ＨＧ符号化器８２０へ制御信号８０３を送信する。この制御信号は、ＱｏＳ強化機能がアクティブ化されるべきかどうか、及びどの強化レイヤ（複数可）が使用されるべきかを示す。ＩＰＴＶ−ＳＴＢ１３３において、パケット損失が比較的低いＬＬである場合、ソースパケットのみが送信される。パケット損失が中程度のＭＭである場合、強化修復パケットも送信される。パケット損失が高いＨＨである場合、強化ラプタパケットも送信される。
【００７５】
図９に示すように、ＱｏＳ強化符号化器８２０は、セレクタ９１０、第１レイヤ強化符号化器９２０、及び第２レイヤ強化符号化器９３０を含む。このセレクタは、コントローラ８１０からの制御信号８０３によって制御される。
【００７６】
ソースパケット、修復パケット、及びラプタパケット９０１は、常に、ＱｏＳ強化符号化器の出力７０２へ転送される。スイッチ９０３が閉じられると、第１レイヤ強化符号化器９２０がアクティブ化されて、ＳＭＰＴＥ２０２２−１強化修復パケットを送信する。スイッチ９０４が閉じられると、第２レイヤ強化符号化器９３０がアクティブ化されて、強化ラプタパケットを送信する。
【００７７】
図４に示すように、ＳＭＰＴＥ２０２２−１符号化プロセスでは、ＤＰパケットを有するソースブロックが、Ｄ×Ｐアレイに配列される。ここで、Ｐはｆの因数を有し、Ｐ／ｆ＝ｒである。
【００７８】
本発明の第１レイヤ強化符号化器９２０では、バッファがＳＭＰＴＥ２０２２−１修復パケットを収集し、それらパケットのヘッダのＳＮＢａｓｅロービットフィールドをチェックする。ＳＮＢａｓｅロービット値ｉ、ｉ＋ｆ、ｉ＋２ｆ、…、ｉ＋（ｒ−１）ｆを有するパケットを１つのセットとみなす。ここで、ｉ＜ｆである。このとき、互いに素であるｆ個のこのようなセットが存在する。
【００７９】
同じセットにおけるｒ個のすべてのパケットがバッファ内に記憶された場合、それらパケットは排他的ＯＲされて、本発明の強化修復パケットが生成される。本発明の強化修復パケットのＦＥＣヘッダは、オフセットフィールド５２０がｆに変更され且つＮＡフィールド５３０がＤｒに変更されていることを除いて、このセットにおける最小のＳＮＢａｓｅロービット値を有するＳＭＰＴＥ２０２２−１修復パケットのＦＥＣヘッダと同じである。図５を参照されたい。本発明の新規な配列により、本発明の新しい強化修復パケットは、ソースブロックのｆ×Ｄｒアレイにおける列の排他的ＯＲとみなすことができる。セット内のいずれかのパケットが、ホームゲートウェイによって受信されない場合、対応する新しい強化修復パケットは生成されない。
【００８０】
図１０は、１８個のソースパケットを有するソースブロックの第１レイヤ強化符号化器９２０の細部を示す。ここで、Ｄ＝３であり、Ｐ＝６である。すなわち、６つの修復パケットが送信される。すべての修復パケットは受信され、バッファ１０１０内に記憶される。ｆ＝３及びｒ＝２と設定する。本発明の設計に基づくと、ＳＮＢａｓｅロービット値０及び３を有するパケットは、ＸＯＲブロック１０２０を通過し、新しい強化修復パケット１０３０が生成される。同様に、ＳＮＢａｓｅロービット値１及び４を有するパケットも結合され、ＳＮＢａｓｅロービット値２及び５を有するパケットも結合される。これらの新しいパケットのＦＥＣヘッダにおけるＳＮＢａｓｅロービットフィールドは、０、１、及び２にそれぞれ設定される。オフセットフィールド５２０は３に設定され、ＮＡフィールド５３０は６に設定される。
【００８１】
第１レイヤ強化符号化器９２０によって生成された本発明の追加の強化修復パケット１０３０は、現行のＳＭＰＴＥ２０２２−１復号器と互換性があるので、ＳＴＢは、本発明の新しい強化修復パケットを復号することができる。
【００８２】
ホームネットワークの誤り率が比較的高い場合、第２レイヤ強化符号化器９３０もアクティブ化される。第２レイヤ強化符号化器９３０も、バッファを使用して受信ラプタ符号化パケット（ソースパケット及び修復パケットを含む）を記憶する。
【００８３】
バッファは、受信ラプタパケットをＱ×ｙアレイに配列する。その後、同じ列のＱ個のラプタパケットがＸＯＲされて、新しい強化ラプタパケットが生成される。この配列によって、ホームネットワークにおけるバースト誤りを効果的に削減することができる。ラプタパケットは、必ずしも同じサイズを有するとは限らないので、ＸＯＲ演算に参加するパケットの最小サイズが、対応する強化ラプタパケットのサイズとして選択される。それよりも大きなサイズを有するラプタ符号化パケットについては、それらパケットの余分なシンボルは、ＸＯＲ演算に関与しない。
【００８４】
図１１は、第２レイヤ強化符号化器９３０の細部の構造を示す。受信ラプタ符号化パケット１１２０は、バッファ１１１０内に記憶される。バッファ１１１０は、この例では１２のサイズを有する。受信ラプタパケットは、２×６アレイに配列される。同じ列のラプタパケット１１２０はＸＯＲブロック１１３０を通過して、強化ラプタパケット１１４０が生成される。その後、６つの強化ラプタパケット１１４０がＳＴＢへ順次送信される。
【００８５】
図１２は、本発明の強化ラプタパケットのペイロードＩＤの構造を示す。１６ビットフィールドのソースブロック番号（ＳＢＮ）１２１０は、強化ラプタパケットのシンボルに関係するソースブロック６１０の整数の識別子を示す。次のＱ個の１６ビットフィールド１２２０は、Ｑ個のラプタ符号化パケット１１２０の符号化シンボルＩＤ（ＥＳＩ）である。これらＱ個のラプタ符号化パケット１１２０がこの強化パケットを生成する。符号化シンボルＩＤ（ＥＳＩ）は、ラプタ符号化パケットの符号化シンボルの整数の識別子を表す。最後の１６ビットフィールドは、ソースブロック長（ＳＢＬ）１２３０である。ＳＢＬ１２３０は、ソースブロック６１０におけるソースシンボル６１１の個数を与える。
【００８６】
ＩＰＴＶ−ＳＴＢ１３３は、強化ラプタパケット１１４０を取り扱う追加プロセスを有する。
【００８７】
図１３は、ＱｏＳ強化コンポーネントを有するＩＰＴＶ−ＳＴＢ１３３の構造の細部を示す。ＩＰＴＶ−ＳＴＢは、チャネルモニタ１３４０を含む。チャネルモニタ１３４０は、ＨＧからパケットのストリーム７０２を受信し、フィードバック信号７０１を送出する。入力ストリーム７０２について、ＳＴＢは、最初に、受信パケットが強化ラプタパケットであるか否かをチェックする（１３１０）。受信パケットが強化ラプタパケットである場合、新たな行が復号行列Ａ’に追加され、そうでない場合、受信パケットはＳＴＢ復号器１３６へ転送される。
【００８８】
受信強化パケットの個数がＮｅであり、且つ、０≦ｉ≦Ｎｅ−１について、各強化ラプタパケットのシンボル数がＷｉである場合、強化ラプタパケットｉのｊ番目のシンボルはｅｉ，ｊである。ここで、０≦ｉ≦Ｎｅ−１であり、０≦ｊ≦Ｗｉである。
【００８９】
【数１２】
2010246120.tif 000014
【００９０】
とする。すなわち、Ｄ’と受信強化パケットのすべてのシンボルとの連結とする。Ｄ’の長さはＭであるので、Ｄチルダの長さは、
【００９１】
【数１３】
2010246120.tif 000015
【００９２】
である。
【００９３】
Ｄチルダの各シンボルｅｉ，ｊについて、新たな行が行列Ａ’に追加される。この新たな行は、次のようにして生成される。
【００９４】
ステップ１：行ａがゼロに初期化される。
【００９５】
ステップ２：１≦ｌ≦Ｑについて、強化ラプタパケットｉのｌ番目の符号化シンボルＩＤフィールドが読み出される。このｌ番目の符号化シンボルＩＤをＥＳＩｌとする。ＥＳＩｌ＜Ｋである場合、ＧＬＴの（ＥＳＩｌ＋ｊ）番目の行がａとＸＯＲされる。ＥＳＩｌ≧Ｋである場合、Ｇ’ＬＴの（ＥＳＩｌ−Ｋ＋ｊ）番目の行がａとＸＯＲされる。
【００９６】
すべての新たな行がＡ’に追加された後、新たな行列Ａチルダが生成される。この行列Ａチルダは、Ａ’と比較して、
【００９７】
【数１４】
2010246120.tif 000016
【００９８】
個のより多くの行を有し、
【００９９】
【数１５】
2010246120.tif 000017
【０１００】
である。Ａチルダが少なくともＬの階数を有する限り、Ｅを解くことができる。Ａチルダは、Ａ’よりも多くの行を有するので、階数要件を満たすより高い確率を有する。
【０１０１】
ＱｏＳ強化ＳＴＢ復号
ＳＴＢ復号器１３６には３つのケースがある。
【０１０２】
ケース１：ＱｏＳ強化機能が一切アクティブ化されない。このケースでは、ＳＴＢ復号器は、ETSI TS 102 034標準規格で指定されたように機能する。
【０１０３】
ケース２：第１レイヤ強化符号化器９２０のみがアクティブ化される。このケースでは、ＳＴＢ復号のステップ１において、オリジナルのＳＭＰＴＥ２０２２−１修復パケット４３０及び第１レイヤ強化符号化器によって生成された強化修復パケット１０３０の双方が、従来のＳＭＰＴＥ２０２２−１復号器によって復号される。ステップ２は、ETSI TS 102 034のものと同じである。ステップ３において、未処理のＳＭＰＴＥ２０２２−１修復パケット４３０によって生成された仮想ラプタパケットのほかに、別の仮想ラプタパケットを、未処理の新しい強化修復パケット１０３０によって生成することができる。その後、ラプタ復号が継続する。
【０１０４】
ケース３：第１レイヤ強化符号化器及び第２レイヤ強化符号化器の双方がアクティブ化される。このケースでは、ＳＴＢ復号のステップ１において、オリジナルのＳＭＰＴＥ２０２２−１修復パケット４３０及び第１レイヤ強化符号化器によって生成された強化修復パケット１０３０の双方が、従来のＳＭＰＴＥ２０２２−１復号器によって復号される。ステップ２において、強化ラプタパケット１１４０が、上述したようにラプタ復号に関与する。ステップ３において、未処理のＳＭＰＴＥ２０２２−１修復パケット４３０によって生成された仮想ラプタパケットのほかに、別の仮想ラプタパケットを、未処理の強化修復パケット１０３０によって生成することができる。その後、ステップ２におけるラプタ復号が継続される。
【０１０５】
本発明を、好ましい実施の形態の例として説明してきたが、本発明の精神及び範囲内で他のさまざまな適合及び変更を行えることが理解されるべきである。したがって、本発明の真の精神及び範囲内に入るようなこのようなすべての変形及び変更を包含することが、添付の特許請求の範囲の目的である。
【図１】
2010246120.tif 000018
【図２】
2010246120.tif 000019
【図３】
2010246120.tif 000020
【図４】
2010246120.tif 000021
【図５】
2010246120.tif 000022
【図６】
2010246120.tif 000023
【図７】
2010246120.tif 000024
【図８】
2010246120.tif 000025
【図９】
2010246120.tif 000026
【図１０】
2010246120.tif 000027
【図１１】
2010246120.tif 000028
【図１２】
2010246120.tif 000029
【図１３】
2010246120.tif 000030
【外国語明細書】
2010246120.tif 000031
2010246120.tif 000032
2010246120.tif 000033
2010246120.tif 000034
2010246120.tif 000035
2010246120.tif 000036
2010246120.tif 000037
2010246120.tif 000038
2010246120.tif 000039
2010246120.tif 000040
2010246120.tif 000041
2010246120.tif 000042
2010246120.tif 000043
2010246120.tif 000044
2010246120.tif 000045
2010246120.tif 000046
2010246120.tif 000047
2010246120.tif 000048
2010246120.tif 000049
2010246120.tif 000050
2010246120.tif 000051
2010246120.tif 000052
2010246120.tif 000053
2010246120.tif 000054
2010246120.tif 000055
2010246120.tif 000056
2010246120.tif 000057
2010246120.tif 000058
2010246120.tif 000059
2010246120.tif 000060
2010246120.tif 000061
2010246120.tif 000062
2010246120.tif 000063
2010246120.tif 000064
2010246120.tif 000065
2010246120.tif 000066