(57)【要約】  本発明は、データブロック（ＤＢ）に分類されたソースシンボル（Ｓ）の形態で送信されるデータをエンコードする工程と、データブロックのソースシンボルを、サブブロック（ＳＢ）に分割する工程と、各サブブロックに対し、サブブロックのソースシンボルの線形結合により、それぞれのリペアシンボル（Ｒ１−Ｒ９）を計算する工程と、データブロックのストリームでデータブロックを送信し、連続して、データブロックの各サブブロックを送信する工程であって、各サブブロックは、サブブロックのソースシンボル、続いて、サブブロックのリペアシンボルを送信することにより送信される工程と、を含むデータを送信するための方法に関する。【選択図】図９
2020503742.tif 000002
【特許請求の範囲】
【請求項１】
データブロック（ＤＢ）に分類されたソースシンボル（Ｓ）の形態で送信されるデータをエンコードする工程と、
複数のリペアシンボル（Ｒ１−Ｒ９）を各データブロックに割り当てる工程と、データの各ブロックに関して、
前記データブロックの前記ソースシンボルを、サブブロック（ＳＢ）に分割する工程であって、前記サブブロックの数は、前記データブロックに割り付けられた前記リペアシンボルの数と等しい、工程と、
前記データブロックの各サブブロックにリペアシンボルを割り当てる工程と、
前記データブロックにおける前記サブブロックのソースシンボル及び直前のサブブロックのソースシンボルの線形結合により、前記データブロックの各サブブロックの前記リペアシンボルを計算する、工程と、
データブロックのストリームで前記データブロックを送信し、連続して、前記データブロックの各サブブロックを送信する工程であって、各サブブロックは、前記サブブロックの前記ソースシンボル、続いて、前記サブブロックの前記リペアシンボルを送信することにより送信される工程、
を含むデータ送信方法。
【請求項２】
前記データブロックの各ソースシンボルが、前記データブロックの等しい又は１個ずつ異なる数のリペアシンボルを計算するために使用されるように、前記データブロックの各リペアシンボル（Ｒ１−Ｒ９）は、前記データブロックの前記ソースシンボル（Ｓ）のうち少なくとも一部の線形結合により算出される、請求項１に記載の方法。
【請求項３】
前記データブロック（ＤＢ）の各リペアシンボル（Ｒ１−Ｒ９）は、前記データブロックの先に送信された全てのソースシンボル（Ｓ）の線形結合により算出される、請求項１に記載の方法。
【請求項４】
前記データブロック（ＤＢ）の最後のサブブロック（ＳＢ［．．，４９］）のソースシンボル（Ｓ）の少なくとも一部から計算される複数のリペアシンボル（Ｒ）は、前記データブロックの終わりに送信される、請求項１〜３のうち１項に記載の方法。
【請求項５】
前記データブロック（ＤＢ）の各サブブロック（ＳＢ）は、等しい又は１個ずつ異なる数の前記ソースシンボル（Ｓ）を含む、請求項１〜４のうち１項に記載の方法。
【請求項６】
前記データブロック（ＤＢ）は、前記データブロックの終わりに送信されるリペアシンボル（Ｒ）と同じ数のサブブロック（ＳＢ）を含む、請求項１〜５のうち１項に記載の方法。
【請求項７】
前記データブロック（ＤＢ）のフォーマットを規定するため、
前記データブロックの終わりに送信されるリペアシンボル（Ｒ）の第１の数（Ｑ）を規定する工程と、
前記第１の数及び前記データブロックに割り当てられたリペアシンボルの数に応じて、前記データブロックのサブブロック（ＳＢ）の数（ＮＢ）を決定する工程か、又は前記データブロックのサブブロックの数及び前記第１の数に応じて、前記データブロックに割り当てられたリペアシンボル（Ｒ）の数（ｎ−ｋ）を決定する工程と、
前記データブロックにあるソースシンボルの数（ｋ）を前記サブブロックの数で割ることにより、サブブロック毎のソースシンボル（Ｓ）の最小数（ＫＢ）を計算する工程であって、前記ソースシンボルの最小数は、除法から得られた結果以下の最大の整数に等しく設定される工程と、
前記データブロックのソースシンボルの数と、前記サブブロック毎のソースシンボルの最小数による前記データブロックにあるサブブロックの数の積（ＮＢ・ＫＢ）の差（Δ）を計算する工程であって、差は、前記データブロックの前記サブブロックで足されるソースシンボルの数を規定する工程と、
を含む、請求項１〜６のうち１項に記載の方法。
【請求項８】
前記差（Δ）は、１増加した、サブブロック毎のソースシンボルの最小数（ＫＢ）に等しいソースシンボル（Ｓ）の数を有する前記データブロック（ＤＢ）のサブブロック（ＳＢ）の数を規定する、請求項７に記載の方法。
【請求項９】
ポイントツーポイントモードで、ユーザー端末（ＵＥ）から、受信状態が劣っていることをシグナリングするメッセージを受信する工程と、
ポイントツーポイントモードで、前記端末に、前記メッセージを受けて、前記メッセージを受信した後送信された各データブロックに対し少なくとも１つのリペアシンボル（Ｒ）を送信する工程と、
を含む、請求項１〜８のうち１項に記載の方法。
【請求項１０】
請求項１〜９のうち１項に記載の送信方法に従い送信されたデータを受信するための方法であって、受信方法は、データブロック（ＤＢ）のソースシンボル（Ｓ）のサブブロック（ＳＢ）を受信する工程であって、各サブブロックの受信に続いて、前記サブブロックに関連するリペアシンボル（Ｒ）が受信され、各リペアシンボルは、前記リペアシンボルに関連する前記サブブロックの前記ソースシンボルの線形結合に対応する、連続工程を含む方法。
【請求項１１】
前記データブロックの紛失した又は誤りのあるソースシンボル（Ｓ）を検出する工程と、
前記紛失した又は誤りのあるソースシンボルに伴う第１のリペアシンボル（Ｒ）の受信に際し、前記第１のリペアシンボルと、前記第１のリペアシンボルに対応する線形結合の間の等価性から得られる等式を解くことにより、紛失した又は誤りのあるソースシンボルを計算する工程と、
を含む、請求項１０に記載の方法。
【請求項１２】
マルチキャストモードで送信されたデータブロックの受信状態が悪いことを検出する工程と、
ポイントツーポイントモードで、サーバー（ＣＮＴＰ，ＭＢＭＳ）に、受信状態が劣っていることをシグナリングするメッセージを送信する工程と、
ポイントツーポイントモードで、前記マルチキャストモードで受信されたデータブロック（ＤＢ）のために、受信した前記データブロックの紛失したソースシンボル（Ｓ）を計算するために使用可能な追加のリペアシンボルを受信する工程と、
を含む、請求項１０又は１１に記載の方法。
【請求項１３】
請求項１〜９のうち１項に記載の方法を実施するように構成されるデータ送信デバイス。
【請求項１４】
請求項１０〜１２のうち１項に記載の方法を実施するように構成されるデータ受信用デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信用デバイスと受信用デバイスの間の通信回線におけるデータの送信、特に、データ誤り又はデータ損失のための訂正機構の実装に関する。
【背景技術】
【０００２】
データ損失又は破損を来す、送信回線を通したファイル又はデータストリーム送信の信頼性を確保するため、多くの誤り訂正符号が提案されている。
【０００３】
モバイルネットワークの分野、特に、ポイントツーマルチポイント通信及びブロードキャスト通信において、前方誤り訂正アプリケーションレイヤーＡＬ−ＦＥＣ（Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ  Ａｐｐｌｉｃａｔｉｖｅ  Ｌａｙｅｒ  ＡＬ−ＦＥＣ）は、大規模コンテンツの信頼できる配信を確保する上で主要な役割を担っている。ＡＬ−ＦＥＣは、拡張されたマルチメディアブロードキャストサービス（Ｅｘｔｅｎｄｅｄ  Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  Ｓｅｒｖｉｃｅｓ、ｅＭＢＭＳ）のための第３世代パートナシッププロジェクト（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ、３ＧＧＰ）により、必須とさえ規定されている。リードソロモン（ＲＳ）符号は、ＡＬ−ＦＥＣ誤り訂正に使用される符号のうち一般的に使用されるものである。この符号方式は、ｎ−ｋ個のリペアシンボルを含む、ｎ個の送信シンボルのうちｋ個のソースシンボルを再構成することができる、最大距離分離（ＭＤＳ）符号のカテゴリに属する。パケットデータ送信プロトコルの場合、ファイル、データストリーム、又はデータブロックは、同一のサイズであるか否かは問わず、シンボルに分割されるデータパケットの形態で送信される。シンボルの大きさは、ビット数で表現することができる。リペアシンボルＲＳは、ＧＦ（２ｍ）などのガロア体ＧＦで行われる操作により得られる。こうして、リペアシンボルは、ＧＦ（２ｍ）に属する係数を使用したソースシンボルの線形結合により算出される。通常、リペアシンボルの計算は、ＧＦ（２８）で行われ、処理されるデータブロックの大きさｎは、２５６個未満のシンボルに制限される。
【０００４】
ＡＬ−ＦＥＣブロックエンコードは、データブロックにおける損失又は誤りのあるシンボルを修復するため、データブロックの終わりに送信されたリペアシンボルを待つことを要するという欠点を有する。そのため、データブロックの第１のソースシンボルに誤りが生じた際、ソースシンボルの修復遅延は、データブロックの受信時間に達することがある。同様に、ストリームへのアクセス時間が第１及び第２のソースシンボルが開始する時間の間で生じた際、データブロックのストリームへのアクセス遅延は、ブロックの受信期間に達することがある。一方、全てのリペアシンボルがブロックの全てのソースシンボルから計算されるため、データブロックの全てのソースシンボルは、同一の高いレベルの保護を有する。
【０００５】
より大きなブロックサイズに対応する、低密度パリティ検査（ＬＤＰＣ）、Ｒａｐｔｏｒ／ＲａｐｔｏｒＱなど他の符号がある。しかし、リアルタイムアプリケーションにおいて、待ち時間の制約は、データブロックの大きさを制限する。ブロックベースのＡＬ−ＦＥＣ符号は、特に、修復能、複雑性、及び柔軟性の観点からその複数の性能優位性により、広く使用される。一方、ブロックベースのＡＬ−ＦＥＣ符号は、リペア待ち時間が大きい。データブロックの第１のシンボルのうち１つに誤りがある又は消失すると、ブロックの終わりのリペアシンボルを受信するまで修復することができない。
【０００６】
畳み込み符号も、スライディングウィンドウ機構を適用して提案されている。当該符号によれば、リペアシンボルは、スライディングウィンドウに属するソースシンボルにおいて、オンザフライで算出され、ウィンドウのソースシンボル後に送られる。例えば、リペアシンボルは、最大でＷ個のソースシンボルにおいて計算され、ｋ個のソースシンボル毎に送られる。ここで、ｋ＜Ｗである。そのため、全てのソースシンボルを受信する前に、リペアシンボルを受信するとすぐに消失した又は誤りのあるソースシンボルの修復を行うことができる。その代わり、この種の符号は、送信が始まった後、端末がブロードキャスト又はポイントツーマルチポイント送信のデータストリームにアクセスする際、アクセスの待ち時間の問題が起こる。実際、端末は、第１の使用可能なリペアシンボルを受信する前に、少なくともＷ個のソースシンボルを待たなければならない。加えて、ソースシンボルが損失する度、ｋ＋１個のソースシンボル分、データストリームへのアクセス遅延が増す。シンボルの損失率が、送信されたソースシンボルの数に対するリペアシンボルの比率に近づいたとき、ドリフトの影響が生じる。この場合、消失した又は誤りのあるシンボルを修復することは不可能である。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
そのため、アクセスの待ち時間が小さく、ソースシンボル毎に十分なレベルの保護を呈しつつ、消失した又は誤りのあるソースシンボルを修復するための待ち時間が小さい符号を提供することが望まれる。
【課題を解決するための手段】
【０００８】
データブロックに分類されたソースシンボルの形態で送信されるデータをエンコードする工程と、各データブロックに、またデータの各ブロックに対し、リペアシンボルの数を割り当てる工程と、データブロックのソースシンボルを、サブブロックに分割する工程であって、サブブロックの数は、データブロックに割り付けられたリペアシンボルの数と等しい工程と、データブロックの各サブブロックにリペアシンボルを割り当てる工程と、データブロックにおけるサブブロックのソースシンボル及び直前のサブブロックのソースシンボルの線形結合により、データブロックの各サブブロックのリペアシンボルを計算する工程と、データブロックのストリームでデータブロックを送信し、連続して、データブロックの各サブブロックを送信する工程であって、各サブブロックは、サブブロックのソースシンボル、続いて、サブブロックのリペアシンボルを送信することにより送信される工程と、を含むデータ送信方法のための実施形態を提供する。
【０００９】
一実施形態によれば、データブロックの各ソースシンボルが、データブロックの等しい又は１個ずつ異なる数のリペアシンボルを計算するために使用されるように、データブロックの各リペアシンボルは、データブロックのソースシンボルのうち少なくとも一部の線形結合により算出される。
【００１０】
一実施形態によれば、データブロックの各リペアシンボルは、データブロックの先に送信された全てのソースシンボルの線形結合により算出される。
【００１１】
一実施形態によれば、データブロックの最後のサブブロックのソースシンボルの少なくとも一部から計算される複数のリペアシンボルは、データブロックの終わりに送信される。
【００１２】
一実施形態によれば、データブロックの各サブブロックは、等しい又は１個ずつ異なる数のソースシンボルを含む。
【００１３】
一実施形態によれば、データブロックは、データブロックの終わりに送信されるリペアシンボルと同じ数のサブブロックを含む。
【００１４】
一実施形態によれば、方法は、データブロックのフォーマットを規定するため、データブロックの終わりに送信されるリペアシンボルの第１の数を規定する工程と、第１の数及びデータブロックに割り当てられたリペアシンボルの数に応じて、データブロックのサブブロックの数を決定する工程か又はデータブロックのサブブロックの数及び第１の数に応じて、データブロックに割り当てられたリペアシンボルの数を決定する工程と、データブロックにあるソースシンボルの数をサブブロックの数で割ることにより、サブブロック毎のソースシンボルの最小数を計算する工程であって、ソースシンボルの最小数は、除法から得られた結果以下の最大の整数に等しく設定される工程と、データブロックのソースシンボルの数と、サブブロック毎のソースシンボルの最小数によるデータブロックにあるサブブロックの数の積の差を計算する工程であって、差は、データブロックのサブブロックで足されるソースシンボルの数を規定する工程と、を含む。
【００１５】
一実施形態によれば、方法は、ポイントツーポイントモードで、ユーザー端末から、受信状態が劣っていることをシグナリングするメッセージを受信する工程と、ポイントツーポイントモードで端末に、メッセージを受けて、メッセージを受信した後送信された各データブロックに対し少なくとも１つのリペアシンボルを送信する工程と、を含む。
【００１６】
実施形態は、先に規定された送信方法に従い送信されたデータを受信するための方法であって、受信方法は、データブロックのソースシンボルのサブブロックを受信する工程であって、各サブブロックの受信に続いて、サブブロックに関連するリペアシンボルが受信され、各リペアシンボルは、リペアシンボルに関連するサブブロックのソースシンボルの線形結合に対応する連続工程を含む方法にも関し得る。
【００１７】
一実施形態によれば、受信方法は、データブロックの紛失した又は誤りのあるソースシンボルを検出する工程と、紛失した又は誤りのあるソースシンボルに伴う第１のリペアシンボルの受信に際し、第１のリペアシンボルと、第１のリペアシンボルに対応する線形結合の間の等価性から得られる等式を解くことにより、紛失した又は誤りのあるソースシンボルを計算する工程と、を含む。
【００１８】
一実施形態によれば、受信方法は、マルチキャストモードで送信されたデータブロックの受信状態が悪いことを検出する工程と、ポイントツーポイントモードで、サーバーに、受信状態が劣っていることをシグナリングするメッセージを送信する工程と、ポイントツーポイントモードで、マルチキャストモードで受信されたデータブロックのために、受信したデータブロックの紛失したソースシンボルを計算するために使用可能な追加のリペアシンボルを受信する工程と、を含む。
【００１９】
実施形態は、先に規定された送信方法を実装するように構成されるデータ送信デバイスにも関し得る。
【００２０】
実施形態は、上記で規定された受信方法を実装するように構成されるデータ受信用デバイスにも関し得る。
【００２１】
添付図面と関連して制限されることのない本発明の例示的な実施形態を、以下に記載する。
【図面の簡単な説明】
【００２２】
【図１】データ送信システムを概略的に表す図である。
【図２】送信システムの送信デバイスにて生成されるデータを送信するための従来のフォーマットを模式的に表す図である。
【図３】図２に表すフォーマットでリペアシンボルを計算するための方法を図解する図である。
【図４】送信システムの送信デバイスで生成されるデータを送信するための別の従来のフォーマットを模式的に表す図である。
【図５】データ送信フォーマット、及び図４に示すフォーマットでリペアシンボルを計算するための方法を図解する図である。
【図６】一実施形態にかかるデータ送信フォーマットを決定するための手順の工程を表す図である。
【図７】図６に示す手順を使用して得られる例示的データ送信フォーマットを図解する図である。
【図８】別の実施形態に係るデータ送信フォーマットを決定するための手順の工程を表す図である。
【図９】図８に図解する手順を使用して得られるデータ送信フォーマットの例、及びリペアシンボルを計算するための方法の例を図解する図である。
【図１０】図８に図解する手順を使用して得られるデータ送信フォーマットの例、及びリペアシンボルを計算するための方法の例を図解する図である。
【図１１】図８に図解する手順を使用して得られるデータ送信フォーマットの例、及びリペアシンボルを計算するための方法の例を図解する図である。
【図１２】図８に図解する手順を使用して得られるデータ送信フォーマットの例、及びリペアシンボルを計算するための方法の例を図解する図である。
【図１３】図８に図解する手順を使用して得られるデータ送信フォーマットの例、及びリペアシンボルを計算するための方法の例を図解する図である。
【図１４】図８に図解する手順を使用して得られるデータ送信フォーマットの例、及びリペアシンボルを計算するための方法の例を図解する図である。
【図１５】上記で提示したデータ送信フォーマットを使用して得られる性能を図解する曲線の図である。
【図１６】上記で提示したデータ送信フォーマットを使用して得られる性能を図解する曲線の図である。
【図１７】上記で提示したデータ送信フォーマットを使用して得られる性能を図解する曲線の図である。
【図１８】上記で提示したデータ送信フォーマットを使用して得られる性能を図解する曲線の図である。
【図１９】上記で提示したデータ送信フォーマットを使用して得られる性能を図解する曲線の図である。
【図２０】上記で提示したデータ送信フォーマットを使用して得られる性能を図解する曲線の図である。
【図２１】上記で提示したデータ送信フォーマットを使用して得られる性能を図解する曲線の図である。
【図２２】上記で提示したデータ送信フォーマットを使用して得られる性能を図解する曲線の図である。
【図２３】上記で提示したデータ送信フォーマットを使用して得られる性能を図解する曲線の図である。
【図２４】複数のモバイル端末にコンテンツを送るためのシステムを概略的に示す図である。
【発明を実施するための形態】
【００２３】
図１は、データ送信システムを概略的に示す。入力データファイル又はストリームＩＤＴは、通信回線ＣＨを通して入力データＩＤＴを受信機デバイスＲＤＶに送信するように構成される送信機デバイスＴＤＶに提供される。受信機デバイスは、入力データに対応する出力データＯＤＴを提供するように構成される。送信機デバイスＴＤＶは、シンボル生成器ＩＳＧと、エンコーダモジュールＥＮＣと、送信モジュールＸＭＴとを備える。シンボル生成器ＩＳＧは、Ｍビットバイナリワードの形態で、入力データＩＤＴを表すソースシンボルを生成するように構成される。こうして、入力データは、２Ｍ個の異なるソースシンボルとして表すことができる。パラメータＭの値は、通信システムに適合させる。シンボル生成器ＩＳＧにより作られるソースシンボルは、エンコードのためエンコードモジュールＥＮＣに提供され、その後、送信モジュールＸＭＴに供給される。エンコードモジュールＥＮＣは、ソースシンボルを集めリペアシンボルを含むデータブロックにするように構成される。送信モジュールＸＭＴは、エンコードモジュールＥＮＣから受信したデータブロックのデータを送信回線ＣＨに適合する送信フォーマットにフォーマットするように構成される。送信回線ＣＨは、リアルタイムチャネル、例えば、インターネットを通して確立されたリンク、又は複数の端末に対しコンテンツを配信するためのリンク、又は音声もしくは動画を送信するためのポイントツーポイントリンクであってもよい。
【００２４】
受信機デバイスＲＤＶは、送信されたデータＩＤＴをその初期フォーマットに修復するため、受信モジュールＲＥＣと、デコードモジュールＤＥＣと、アセンブリモジュールＤＡＳＭとを備える。受信モジュールＲＥＣは、送信回線ＣＨを通し送信された信号をソースシンボル及びリペアシンボルを含むシンボルに変換する。デコードモジュールＤＥＣは、受信モジュールＲＥＣにより作られたシンボルにおけるシンボルの誤り又は可能性のある欠如を検出し、受信したリペアシンボルを使用して、紛失した又は誤りのあるソースシンボルを再構築することを試みる。例えば、誤りは、送信されたシンボルにあるパリティビットを使用して検出することができる。アセンブリモジュールＤＡＳＭは、デコーダモジュールＤＦＣにより提供されたソースシンボルを集め、送信された入力データＩＤＴに対応する出力データＯＤＴを生成する。
【００２５】
図２は、エンコードモジュールＥＮＣが提供することができるデータブロックＤＢ［ｋ，ｋ＋ｒ］の従来のフォーマットを表す。データブロックＤＢは、ｋ個のソースシンボルＳ［１］〜Ｓ［ｋ］、続いて、ｒ（＝ｎ−ｋ）個のリペアシンボルＲ１［１，ｋ］〜Ｒｒ［１，ｋ］を含む。図３は、ｋ＝４９のソースシンボルＳ［１］〜Ｓ［４９］、及びｒ＝９のリペアシンボルを有するデータブロックフォーマットの場合のリペアシンボルＲ１［１，ｋ］〜Ｒｒ［１，ｋ］を計算する方法を図解する。図３において、各リペアシンボルＲ１［１，ｋ］〜Ｒｒ［１，ｋ］は、計算元の全ソースシンボルにわたり延びる矢で表される。こうして、リペアシンボルＲ１［１，４９］〜Ｒ９［１，４９］各々は、データブロックＤＢ［４９，５８］の４９個のソースシンボルから計算される。リペアシンボルＲｐ［ｉ，ｊ］は、式
【数１】
2020503742.tif 000003
（式中、αｐｌは、体ＧＦ（２ｍ）におけるランダムに選択された係数を表し、例えば、ｍ＝８で、ｐは、１〜（ｎ−ｋ）の間である）により、ソースシンボルのそれぞれの線形結合により計算することができる。係数αｐｌは、大きさがｋ×（ｎ−ｋ）の行列でまとめることができ、ソースシンボルＳ［１］の係数αｐｌは、リペアシンボルＲｐがゼロの計算において考慮されない。この場合、リペアシンボルは、式
【数２】
2020503742.tif 000004
により得ることができる。
【００２６】
係数αｐｌの行列及び送信されたデータブロックのフォーマットを規定するパラメータは、デコードモジュールＤＥＣに送信することができる。
【００２７】
図３の例において、第１のソースシンボルＳ［ｉ］のうち１つが消失した又は誤りがあると、消失した又は誤りのあるソースシンボルを修復することができるためには、（受信したデータブロックＤＢにこれ以上誤りがなければ）少なくとも１つの第１リペアシンボルＲ１［１，４９］の受信を待つことが必要である。実際、ｘ個の未知数を有するｘ個の連立方程式（ｘは、修復されるソースシンボルの数である）を解くことよって可能となるこのような修復には、修復する各ソースシンボルに対し少なくとも１つのリペアシンボルを有することが必要である。こうして、図２及び図３に図解したコード化するフォーマットは、４９個のソースシンボルのデータブロックにおいて誤りのある又は消失した最大で９個のソースシンボルを修復することを可能にさせる。さらに、ストリームへのアクセス時間が、第１の受信データブロックにおいて紛失又は誤りがあるソースシンボルの数がｒ＝９よりも大きいことを暗示する場合、及び少なくとも１つの誤りが第２の受信データブロックで検出される場合、データブロックＢ［４９，５８］のストリームへのアクセス遅延は、２つのデータブロックの送信時間に近似し得る。
【００２８】
図４は、エンコードモジュールＥＮＣが提供することができるシンボルストリームＳＳＴ［ｋ，ｗ］の別の従来のフォーマットを表す。シンボルフローは、ｋ個のソースシンボルの連続する群Ｓ［１］〜Ｓ［ｋ］，Ｓ［ｋ＋１］〜Ｓ［２ｋ］，．．．，Ｓ［（ｎ−１）ｋ＋１］〜Ｓ［ｎ・ｋ］，．．．であって、各群は、ｗ＞ｋで、データストリームにおいて、ｗ個の前のソースシンボルで計算されるリペアシンボルＲ１［ｋ−ｗ，ｋ］，Ｒ１［２ｋ−ｗ，２ｋ］，．．．，Ｒ１［ｎ・ｋ−ｗ，ｎ・ｋ］，．．．が続く、群を含む。
【００２９】
図５は、データストリームＳＳＴ［３，１５］に対し、リペアシンボルＲ１［ｎ・ｋ−ｗ，ｎ・ｋ］（ｎ＝１，２，．．．）を計算する方法を図解し、すなわち、ここでは、リペアシンボルは、ｗ（＝１５）個のソースシンボルＳのスライディングウィンドウに属するソースシンボルから計算され、リペアシンボルは、ｋ（＝３）個のソースシンボルの群ＳＢ［ｎ・ｋ−２，ｎ・ｋ］の後に発行される。図５において、各リペアシンボルＲ［ｘｗ，ｘ］は、計算元のｗ個のソースシンボルにわたり延びる矢で表される。こうして、リペアシンボルＲ［７，２１］は、ソースシンボル群ＳＢ［１８，２１］の後に送信され、ソースシンボルＳ［７］〜Ｓ［２１］から計算される。ストリームＳＳＴ［３，１５］にある次のリペアシンボルＲ［１０，２４］は、ソースシンボル群ＳＢ［２１，２４］の後に送信され、ソースシンボルＳ［１０］〜Ｓ［２４］から計算される。リペアシンボルＲ［ｉ，ｊ］も、式（１）又は（２）により計算することができる。
【００３０】
図５の例においては、次のリペアシンボルの受信に際し、消失した又は誤りのあるソースシンボルを修復することが可能である。ソースシンボルを修復するための待ち時間は、そのため、ｋ＝３のソースシンボルの受信時間未満である。受信した３個のソースシンボルの第１群においてソースシンボルが紛失した場合、ストリームＳＳＴ［３，１５］の第１のソースシンボルへのアクセス遅延は、ｗ＝１５のシンボルの受信期間と少なくとも等しい。さらに、ストリームの送信が、リペアシンボルが計算される３個のソースシンボルの連続群ＳＢ［ｎ・ｋ−２，ｎ・ｋ］各々において少なくとも１つの誤りを作ると、ストリームのソースシンボルへのアクセス遅延は、無限となることがある。
【００３１】
一実施形態によれば、データブロック中のデータストリームを分割し、送信された各データブロックをサブブロックに分割し、データブロックの各サブブロックに、サブブロックの最後のソースシンボルの直後に送信されるリペアシンボルを割り当てることにより、修復及びアクセスの待ち時間は、低減される。データブロック中の最後のサブブロックの後に、残りのリペアシンボルが送信される。
【００３２】
図６は、一実施形態に係る、データブロックのフォーマットを規定するための手順Ｐ１の工程Ｓ１〜Ｓ４を表す。特に、手順Ｐ１は、サブブロックの数ＮＢ及びサブブロック毎のソースシンボルの数ＫＢを決定する。手順Ｐ１は、エンコードモジュールＥＮＣに実装することができる。手順Ｐ１は、データブロックに割り付けられたリペアシンボルの数と等しいサブブロックの数にデータブロックを分割することに基づく。手順Ｐ１は、インプットとして、データブロックに存在するソースシンボルの数ｋ及びリペアシンボルを含むデータブロックにあるシンボルの総数ｎを受信する。工程Ｓ１において、サブブロックの数ＮＢは、データブロックに割り付けられたリペアシンボルの数に等しく設定される、すなわち、ｎ−ｋである。工程Ｓ２において、データブロックのサブブロック毎のソースシンボルの数ＫＢが、式
【数３】
2020503742.tif 000005
（ここで、関数ＦＬ（ｘ）は、数ｘ以下の最大の整数を提供する）により計算される。工程Ｓ３において、データブロックにあるソースシンボルの数ｋと数ＫＢ及びＮＢの積の差Δが計算される。数Δは、データブロックの全てのサブブロックがＫＢ個のソースシンボルを含むならば、データブロックのサブブロックのうち１つに割り当てられていない、残りのソースシンボルの数を表す。数Δは、サブブロックへのデータブロックの分割が（ＫＢ＋１）個のソースシンボルのΔ個のサブブロック及びＫＢ個のソースシンボルの（ＮＢ−Δ）個のサブブロックを含むことを明示するために使用される。（ＫＢ＋１）個のソースシンボルのΔ個のサブブロックは、データブロックの始めでも終わりでも構わずに配置することができる。あるいは、Δ個のソースシンボルは、サブブロックのうち１つ、例えば、データブロックの第１の又は最後のサブブロックから除去することができる。工程Ｓ４において、手順Ｐ１は、数ＫＢ、ＮＢ、及びΔを提供することにより終了する。こうして、手順Ｐ１は、結果、（ＫＢ＋１）個のソースシンボルのΔ個のサブブロック及びＫＢ個のソースシンボルの（ＮＢ−Δ）個のサブブロックＳＢへ各データブロックを分割することとなる。
【００３３】
例えば、データブロックは、（ｂ・ＫＢ＋１）から（（ｂ＋１）・ＫＢ）までのＫＢ個のソースシンボルを各々分類するＮＢ−Δ個の第１のサブブロック（ここで、ｂは、０から（ＮＢ−Δ−２）に変動する）、及び（ｂ・ＫＢ＋ｂ−ＮＢ＋Δ−１）から（（ｂ＋１）・ＫＢ＋ｂ−ＮＢ＋Δ）までの（ＫＢ＋１）個のソースシンボルを各々分類するΔ個の最後のサブブロック（ここで、ｂは、（ＮＢ−Δ−１）から（ＮＢ−１）に変動する）を含む。
【００３４】
従って、データブロックにあるｐ個のソースシンボル（ｐ＜ｎ−ｋ）の損失が発生したとき、データストリームへのリペア又はアクセスの待ち時間は、データブロックに続くｐ個のリペアシンボルＲ［ｉ，ｊ］の受信時間未満である。もちろん、データブロックで消失したソースシンボルの数が、データブロック毎のリペアシンボルの数（ｎ−ｋ）よりも多いと、受信されているデータブロックは修復可能でなく、そのため、次のデータブロックの受信を待つことが必要である。
【００３５】
図７は、手順Ｐ１により規定されるデータブロックＤＢの例示的フォーマット及びリペアシンボルを計算する方法を表す。本例において、データブロックは、ｋ＝４９のソースシンボルで、合計ｎ＝５８のシンボル、すなわち、ｎ−ｋ＝９のリペアシンボルＲ１〜Ｒ９を含む。手順Ｐ１は、各々ＫＢ＝５のソースシンボルを含み、サブブロックのうちいくつかにおいて分割されるΔ＝４のソースシンボルの差を有して、ＮＢ＝９のサブブロックへのデータブロックＤＢの分割を規定する。サブブロックにおいて分割されるΔ（＝４）個のソースシンボルは、例えば、データブロックＤＢの最後の４個のサブブロックに足すことができる。結果として、データブロックＤＢは、各々５個のソースシンボルを含むサブブロックＳＢ［１−５］（データブロックＤＢのソースシンボル１〜５を含む）、ＳＢ［６−１０］、ＳＢ［１１−１５］、ＳＢ［１６−２０］、ＳＢ［２１−２５］、各々６個のソースシンボルを含むサブブロックＳＢ［２６−３１］、ＳＢ［３２−３７］、ＳＢ［３８−４３］、及びＳＢ［４４−４９］を含む。ソースシンボルＳ［１］〜Ｓ［５］の線形結合により得られた、第１のリペアシンボルＲ１［１，５］は、第１のサブブロックＳＢ［１−５］の直後、従って、ソースシンボルＳ［５］の後に送信される。ソースシンボルＳ［１］〜Ｓ［１０］の線形結合により得られた第２のリペアシンボルＲ１［１，１０］は、第２のサブブロックＳＢ［６−１０］の直後に送信される、などである。
【００３６】
図７の例において、ソースシンボルの損失が発生したときの、データストリームへのリペア又はアクセスの待ち時間は、５個のソースシンボル及び続くリペアシンボルの受信時間未満である。
【００３７】
図７の例において、第１のサブブロックＳＢ［１，５］のソースシンボルＳ［１］〜Ｓ［５］が、データブロックＤＢに割り当てられた全てのリペアシンボルＲ１〜Ｒ９により保護されることは留意すべきである。一方、最後のサブブロックＳＢ［４４，４９］のソースシンボルＳ［４４］〜Ｓ［４９］は、最後のリペアシンボルＲ９によってのみ保護される。そのため、データブロックＤＢの最後のサブブロックＳＢ［４４，４９］を保護するソースシンボル及びリペアシンボルの数を増やすことが望ましくあり得る。このため、図８は、別の実施形態に係る、データブロックフォーマットを決定するための手順Ｐ２の工程Ｓ１０〜Ｓ１３を示す。特に、手順Ｐ２は、データブロック毎のソースシンボルの数ｋ、データブロックによるシンボルの総数ｎ、及び各データブロックの最後のサブブロックに割り当てられるリペアシンボルの数Ｑから、データブロック毎のサブブロックＳＢの数ＮＢ及びサブブロック毎のソースシンボルの数ＫＢを決定する。その後、手順Ｐ１（図６）により提供されるパラメータＫＢ及びＮＢは、数ＫＢの最小値及び数ＮＢの最大値とみなされる。手順Ｐ１において、最後のサブブロックに割り付けられたリペアシンボルの数Ｑは、１に設定される。
【００３８】
工程Ｓ１０において、サブブロックの数ＮＢは、データブロック毎のリペアシンボルの数ｎ−ｋから、量Ｑ−１を引くことにより計算される。工程Ｓ１１において、ソースシンボルの数ＫＢは、工程Ｓ１０で得たサブブロックの数ＮＢで、データブロック毎のソースシンボルの数ｋを割ることにより計算される。数ＫＢは、除法ｋ／ＮＢの結果未満の最大の整数に等しく設定される。従って、数ＮＢ及びＫＢは、式
【数４】
2020503742.tif 000006
により得られる。
【００３９】
Ｓ１２において、データブロックにおけるソースシンボルの数ｋと、数ＫＢ及びＮＢの積の間の差Δが計算される。従って、数Δは、ｋ−ＮＢ×ＫＢに等しい。Ｓ１３において、手順Ｐ２は、こうして計算された数ＫＢ、ＮＢ、及びΔに戻る。従って、手順Ｐ２は、例えば、ＫＢ個のソースシンボルの（ＮＢ−Δ）個のサブブロック及び（ＫＢ＋１）個のソースシンボルのΔ個のサブブロックを含む、ｋ個のソースシンボル及び（ｎ−ｋ）個のリペアシンボルのデータブロックの分割であって、各サブブロックには、例えば、式（１）又は（２）により、データブロックにおける先のソースシンボルの少なくとも一部にわたり計算されるリペアシンボルＲ［ｉ，ｊ］が続く、分割を規定する。こうして計算されたパラメータＫＢ、ＮＢ、及びΔは、デコードモジュールＤＥＣに送信することができ、その結果、デコードモジュールＤＥＣは、送信されたデータブロックにおいてサブブロック及びリペアシンボルを見つけることができる。
【００４０】
パラメータＱが１に設定されると、手順Ｐ２は、手順Ｐ１により規定されるフォーマットに従い、ｎ−ｋ（データブロックにおけるリペアシンボルの数）に等しいサブブロックの数ＮＢ及びＦＬ（ｋ／（ｎ−ｋ））に等しいサブブロック毎のソースシンボルの数ＫＢを提供する。ｋ＝４９及びｎ＝５８である例において、手順Ｐ２は、４に等しい差Δで、９に等しいサブブロックの数ＮＢ及び５に等しいサブブロック毎のソースシンボルの数ＫＢを提供する。図７のデータブロックフォーマットは、こうして成し遂げられる。パラメータＱがｎ−ｋに設定されると、手順Ｐ２は、１に等しいサブブロックＳＢの数ＮＢ、故にデータブロックにおけるソースシンボルの数ｋに等しいサブブロック毎のソースシンボルの数ＫＢを提供する。こうして、図３のフォーマットは、サブブロックへデータブロックを分割することなく、成し遂げられる。
【００４１】
もちろん、各データブロックにおけるサブブロックの数ＮＢは、固定され、従って手順２の入力で提供されるものとすることができる。この場合、工程Ｓ１０は、データブロック毎のリペアシンボルの数ｒ又はデータブロック毎のシンボルの総数ｎを計算する工程に置き換えられる。従って、データブロック毎のリペアシンボルの数ｒは、データブロックの終わりに足されるリペアシンボルの数Ｑ−１を加えた、データブロック毎のサブブロックの数ＮＢに等しく、データブロックの最後のサブブロックに割り当てられるリペアシンボルは数えない。工程Ｓ１３において、手順Ｐ２は、その後、データブロック毎のサブブロックの数ＮＢの代わりに、リペアシンボルの数ｒ又はデータブロック毎のシンボルの総数ｎを提供する。これは、固定値にデータブロック毎のリペアシンボルの数ｒを設定するために、及び数ｒ及びデータブロック毎のサブブロックの数ＮＢに応じて、データブロックの終わりのリペアシンボルの数Ｑを決定するためにも提供され得る。
【００４２】
図９は、手順Ｐ２により得られた、４９個のソースシンボル及び９個のリペアシンボルを有するデータブロックＤＢの例示的フォーマットを表す。この例において、データブロックＤＢの終わりのリペアシンボルの数Ｑは、３に等しく選択される。手順Ｐ２は、差Δがゼロで、各々ＫＢ＝７のソースシンボルを含むＮＢ＝７のサブブロックへのデータブロックＤＢの分割を規定する。図９のデータブロックＤＢは、こうして、サブブロックＳＢ［１，７］、ＳＢ［８，１４］、ＳＢ［１５，２１］、ＳＢ［２２，２８］、ＳＢ［２９，３５］、ＳＢ［３６，４２］、及びＳＢ［４２，４９］であって、各サブブロックのすぐ後には、リペアシンボル、それぞれＲ１［１，７］、Ｒ２［１，１４］、Ｒ３［１，２１］、Ｒ４［１，２８］、Ｒ５［１，３５］、Ｒ６［１，４２］、及びＲ７［１，４９］が続く、サブブロックを含む。最後のサブブロックＳＢ［４２，４９］の後には、３に等しく選択されたパラメータＱに従い、３個のリペアシンボルＲ７［１，４９］、Ｒ８［１，４９］、及びＲ９［１，４９］が続く。
【００４３】
こうして、ソースシンボルが損失した場合の当該データブロックへのリペア又はアクセスの待ち時間は、リペアシンボルを加えた７個のソースシンボルの受信時間以下である。
【００４４】
図７及び図９の例において、第１のサブブロックＳＢ［１，５］、ＳＢ［１，７］のソースシンボルが、データブロックＤＢに割り付けられた全てのリペアシンボルにより保護されることに留意すべきである。一方、データブロックＤＢの最後のサブブロックＳＢ［４４，４９］、ＳＢ［４３，４９］は、図７の例においてはたった１個のリペアシンボルＲ９［１，４９］により、図９の例においては３個のリペアシンボルＲ７［１，４９］、Ｒ８［１，４９］、及びＲ９［１，４９］により保護される。結果として、ブロックの始めで消失したソースシンボルの数がリペアシンボルの数よりも多いと、データブロックＤＢの消失したソースシンボルを修復することができず、次のデータブロックのソースシンボルの受信を待つことを要する。
【００４５】
データブロックにおける各ソースシンボルを保護するリペアシンボルの数を標準化することが望ましくあり得る。このため、例えば、ＫＢ個ソースシンボル（ｂ・ＫＢ＋１）〜（（ｂ＋１）・ＫＢ）（ここでｂは０から（ＮＢ−Δ−２）まで変動する）を各々含むＮＢ−Δ個の第１のサブブロックＳＢ及び（ＫＢ＋１）個のソースシンボル（ｂ・ＫＢ＋ｂ−ＮＢ＋Δ−１）〜（（ｂ＋１）・ＫＢ＋ｂ−ＮＢ＋Δ）（ここでｂは（ＮＢ−Δ−１）から（ＮＢ−１）まで変動する）を各々含むΔ個の最後のサブブロックＳＢを有するＮＢ個のサブブロックにデータブロックを分割する場合を考慮する。最後のＮＢ−１個のリペアシンボルは、ｂが（ＮＢ−Δ−１）のときはソースシンボル（ｂ・ＫＢ＋１）〜ｋ、ｂが（ＮＢ−Δ−２）より大きいときは（ｂ・ＫＢ＋ｂ−ＮＢ＋Δ−１）〜ｋにわたり計算することができる。いくつかのリペアシンボルの計算元となるソースシンボルの数が減少するため、リペアシンボルの計算及びソースシンボルの修復計算は簡略化される。
【００４６】
従って、図１０は、図９のフォーマット由来の、４９個のソースシンボル及び９個のリペアシンボルを有し、各ソースシンボルがＱ（＝３）個のリペアシンボルにより保護されるデータブロックＤＢの例示的フォーマットを示す。データブロックＤＢにおけるサブブロックの大きさ及び分割は、図９に示すフォーマットから変更されない。リペアシンボルＲ１〜Ｒ３は、常に、データブロックＤＢの第１のソースシンボルＳ［１］から計算される。一方、リペアシンボルＲ４［８，２８］、Ｒ５［１５，３５］、Ｒ６［２２，４２］、及びＲ７［２９，４９］は、２１個の前のソースシンボルから計算され、リペアシンボルＲ８［３６，４９］は、データブロックＤＢの最後１４個のソースシンボルＳ［３６］〜Ｓ［４９］から計算され、リペアシンボルＲ９［４３，４９］は、データブロックＤＢの最後７個のソースシンボルＳ［４３］〜Ｓ［４９］から計算される。
【００４７】
図１０の例において、３個を超えるソースシンボルがデータブロックＤＢの第１のサブブロックＳＢ［１，７］において消失すると、消失したソースシンボルを修復することができない。一方、リペアシンボルＲ４［８，２８］が受信されるとすぐに、次に続く３個のサブブロックＳＢ［８，１４］、ＳＢ［１５，２１］、ＳＢ［２２，２８］において消失したソースシンボルを修復することは可能であり、これは、その後消失したとみなされる第１のサブブロックのシンボルを認識することを要しない。
【００４８】
図１１は、手順Ｐ２により得られた、４９個のソースシンボル及び９個のリペアシンボルを有するデータブロックＤＢの例示的なフォーマットを示す。この例において、データブロックＤＢの終わりのリペアシンボルの数Ｑは、ＣＬ（（ｎ−ｋ）／２）、すなわち５（ここで関数ＣＬ（ｘ）は数ｘ以上の最小の整数を表す）と等しく選択される。手順Ｐ２は、差Δが４に等しく、各々ＫＢ＝９のソースシンボルを含む、ＮＢ＝５のサブブロックへのデータブロックＤＢの分割を規定する。結論としては、５に設定されるＱの選択は、結果、９個のソースシンボルの１個のサブブロック及び１０個のソースシンボルの４個のサブブロックへのデータブロックの分割となる。従って、図１１のデータブロックＤＢは、１０個のソースシンボルの４個のサブブロックＳＢ［１，１０］、ＳＢ［１１，２０］、ＳＢ［２１，３０］、ＳＢ［３１，４０］、及び９個のソースシンボルの１個のサブブロックＳＢ［４１，４９］を含み、各サブブロックのすぐ後には、リペアシンボルＲ１［１，１０］、Ｒ２［１，２０］、Ｒ３［１，３０］、Ｒ４［１，４０］、及びＲ５［１，４９］が続く。最後のサブブロックＳＢ［４１，４９］の後には、５に等しく選択されたパラメータＱに従い、５個のリペアシンボルＲ５［１，４９］、Ｒ６［１，４９］、Ｒ７［１，４９］、Ｒ８［１，４９］、及びＲ９［１，４９］が続く。
【００４９】
先に述べたように、このフォーマットでは、ソースシンボル毎のリペアシンボルの数を標準化することが可能である。従って、図１２は、各ソースシンボルが５個のリペアシンボルにより保護される、図１１のフォーマットに由来する、４９個のソースシンボル及び９個のリペアシンボルを有するデータブロックＤＢの例示的フォーマットを示す。データブロックＤＢにおけるサブブロックの大きさ及び分割は、図１１に示すフォーマットから変更しない。リペアシンボルＲ１〜Ｒ５は、データブロックＤＢの第１のソースシンボルＳ［１］から全て計算される。一方、他のリペアシンボルＲ６［１１，４９］、Ｒ７［２１，４９］、Ｒ８［３１，４９］、及びＲ９［４１，４９］は、それぞれ、ソースシンボルＳ［１１］、Ｓ［２１］、Ｓ［３１］、及びＳ［４１］から計算される。
【００５０】
図１３は、データブロックＤＢの終わりのリペアシンボルの数Ｑが６に等しく選択されるときの、手順Ｐ２により得られた、４９個のソースシンボル及び９個のリペアシンボルを有するデータブロックＤＢの例示的フォーマットを示す。手順Ｐ２は、数Δが１に等しく、各々ＫＢ＝１２のソースシンボルを含む、ＮＢ＝４のサブブロックへのデータブロックＤＢの分割を規定する。そのため、この分割は、サブブロックのうち１個、例えば、最後のサブブロックにあるソースシンボルを足すことを暗示する。こうして、図１３のデータブロックＤＢは、１２個のソースシンボルを含む３個のサブブロックＳＢ［１，１２］、ＳＢ［１３，２４］、及びＳＢ［２５，３６］、並びに１３個のソースシンボルの１個のサブブロックＳＢ［３７，４９］を含み、各サブブロックのすぐ後には、リペアシンボルＲ１［１，１２］、Ｒ２［１，２４］、Ｒ３［１，３６］、及びＲ４［１，４９］が続く。最後のサブブロックＳＢ［３７，４９］の後には、６に等しく選択されたパラメータＱに従い、６個のリペアシンボルＲ４［１，４９］、Ｒ５［１，４９］、Ｒ６［１，４９］、Ｒ７［１，４９］、Ｒ８［１，４９］、及びＲ９［１，４９］が続く。
【００５１】
先に述べたように、このフォーマットでは、ソースシンボル毎のリペアシンボルの数を標準化することが可能である。従って、図１４は、各ソースシンボルが６個のリペアシンボルにより保護される、図１３のフォーマット由来の、４９個のソースシンボル及び９個のリペアシンボルを有するデータブロックＤＢの例示的フォーマットを示す。データブロックＤＢにおけるサブブロックの大きさ及びサイズは、図１３に示すフォーマットから変更しない。リペアシンボルＲ１〜Ｒ６は、常に、データブロックＤＢの第１のソースシンボルＳ［１］から計算される。一方、他のリペアシンボルＲ７［１３，４９］、Ｒ８［２５，４９］、及びＲ９［３７，４９］は、それぞれソースシンボルＳ［１３］、Ｓ［２５］、及びＳ［３７］から計算される。
【００５２】
図１５〜図１８は、異なるデータブロックフォーマットでの、消失シンボルリペア時間ＲＴの確率の変動曲線を示す。１Ｍｂ／ｓのビットレートで１００個のソースシンボル、総じて、１２５個のシンボルのブロックの送信をシミュレートすることによりこれら曲線を得た。送信時間は、１００ｍｓに設定した。１０７個のソースシンボル、すなわち、データの１０５個のブロックの送信をシミュレートすることにより、これら計測値を得た。シンボル損失は、ベルヌーイ損失モデル（Ｂｅｒｎｏｕｌｌｉ  ｌｏｓｓ  ｍｏｄｅｌ）から得られる。ソースシンボルのリペア時間は、ソースシンボルが誤りなく受信されるべきであった時と、ソースシンボルが修復される時との間の時間に対応する。
【００５３】
図１５は、全てのリペアシンボルがデータブロックの終わりに送信されるとき（図３）の、リペアの確率の変動の曲線Ｃ１〜Ｃ５を、リペア時間の関数として示す。それぞれ、１、５、１０、１５、及び２０％のシンボル損失率で、曲線Ｃ１〜Ｃ５を得た。曲線Ｃ１によると、リペアの確率は、それぞれ５０ｍｓ及び９０ｍｓのリペア時間に対し、０．４及び１に達する。消失シンボルリペア時間は、シンボル損失率が増加するにつれ、徐々に増加する。従って、曲線Ｃ２によれば、リペア時間は、それぞれ確率０．４及び１で、約８２ｍｓ及び９２ｍｓに達する。曲線Ｃ３によると、リペア時間は、それぞれ確率０．４及び１で、約９１ｍｓ及び９６ｍｓに増加する。曲線Ｃ４によると、リペア時間は、それぞれ確率０．４及び１で、約９４ｍｓ及び９８ｍｓに増加する。曲線Ｃ５によると、リペア時間は、それぞれ確率０．４及び１で、約９６ｍｓ及び１００ｍｓに増加する。
【００５４】
図１６は、送信されたデータブロックのフォーマットが、データブロックの終わりのリペアシンボルと同じ数のサブブロックを含み、かつ、全てのサブブロックが同数のリペアシンボルにより実質的に保護されるとき（図１２）の、消失シンボルのリペアの確率の変動の曲線Ｃ１１〜Ｃ１５を、リペア時間の関数として示す。それぞれ、１、５、１０、１５、及び２０％のシンボル損失率で、曲線Ｃ１１〜Ｃ１５を得た。曲線Ｃ１１〜Ｃ１５によると、消失シンボルリペア時間は、確率０．４で、約３〜７ｍｓの間である。曲線Ｃ１１によると、リペアの確率は、凡そ１６ｍｓの消失シンボルリペア時間に対し、１である。このリペア時間は、シンボル損失率が増加すると、徐々に増加する。従って、曲線Ｃ１２によれば、消失シンボルリペア時間は、１に近い確率で、凡そ５０ｍｓに達する。曲線Ｃ１３によると、このリペア時間は、それぞれ確率０．９及び１で、凡そ５０ｍｓ及び９６ｍｓに増加する。曲線Ｃ１４によると、消失シンボルリペア時間は、それぞれ確率０．８及び１で、約７４ｍｓ及び９８ｍｓに増加する。曲線Ｃ１５によると、消失シンボルリペア時間は、それぞれ確率０．８及び１で、凡そ８４ｍｓ及び９８ｍｓに増加する。従って、図１２のフォーマットは、図３の従来のフォーマットよりも、消失シンボルリペア待ち時間の観点から十分に良い性能を提示する。
【００５５】
図１７は、送信されたデータブロックのフォーマットが、データブロックの終わりに２又は３個のリペアシンボルを含むとき（図９及び図１０）の、消失シンボルを修復する確率の変動の曲線Ｃ２１〜Ｃ２５を、リペア時間の関数として示す。それぞれ、１、５、１０、１５、及び２０％のシンボル損失率で、曲線Ｃ２１〜Ｃ２５を得た。曲線Ｃ２１〜Ｃ２５によると、リペア時間は、確率０．６で、約７ｍｓ未満である。曲線Ｃ２１によると、リペアの確率は、約１０ｍｓにおいて、１である。リペア時間は、シンボル損失率が増加すると、徐々に増加する。曲線Ｃ２２によれば、リペア時間は、１に近い確率で、約２０ｍｓに達する。曲線Ｃ２３によると、リペア時間は、確率１で、凡そ４６ｍｓである。曲線２４によれば、リペア時間は、確率１で、約８０ｍｓに増加する。曲線Ｃ２５によれば、リペア時間は、確率が０．９５超であるとき、７０ｍｓ未満であり、確率１で、９８ｍｓに達する。そのため、図９又は図１０のフォーマットは、図１２のフォーマットよりも、リペア待ち時間の観点からより良い性能を有する。
【００５６】
図１８は、送信されたデータブロックのフォーマットが、リペアシンボルと同じ数のサブブロックを含むとき（図７）の、消失シンボルを修復する確率の変動の曲線Ｃ３１〜Ｃ３５を、リペア時間の関数として示す。それぞれ、１、５、１０、１５、及び２０％のシンボル損失率で、曲線Ｃ３１〜Ｃ３５を得た。曲線Ｃ３１〜Ｃ３５によると、リペア時間は、確率０．８で、約１０ｍｓ未満である。曲線Ｃ３１によると、リペアの確率は、約７ｍｓで、１である。リペア時間は、シンボル損失の率が増加すると、徐々に増加する。曲線Ｃ３２によれば、消失シンボルリペア時間は、１に近い確率で、約２０ｍｓに達する。曲線Ｃ３３によれば、このリペア時間は、確率１で、約３４ｍｓに増加する。曲線Ｃ３４によれば、このリペア時間は、確率１で、約５６ｍｓに増加する。曲線Ｃ３５によれば、このリペア時間は、確率が０．９５超のとき、３０ｍｓ未満であり、１の確率で、７４ｍｓに達する。そのため、図７のフォーマットは、図９又は図１０のフォーマットよりも、リペア待ち時間の観点からより良い性能を有する。
【００５７】
図１９〜図２３は、異なるデータブロックフォーマットでの、データストリームのアクセス遅延確率の変動の曲線を示す。１Ｍｂ／ｓのビットレートで１００個のソースシンボル、総じて、１２５個のシンボルのブロック送信をシミュレートすることにより、これら曲線も得た。送信時間は、１００ｍｓに設定した。１０７個のソースシンボル、すなわち、データの１０６個のブロックの送信をシミュレートすることにより、各計測値を得た。シンボル損失は、ベルヌーイ損失モデルから得られる。データストリームへのアクセス遅延は、フローアクセス時間が第２の送信されたデータブロックの５０番目のソースシンボルで生じることを考慮することにより計算される。データストリームへのアクセス時間と、受信した第１のデータブロックの最後のシンボルの、又はスライディングウィンドウの、受信時の間で、シンボルの損失がないことで、ストリームへのアクセス遅延は、０ｍｓに固定される。図１９は、全てのリペアシンボルがデータブロックの終わりに送信され、送信されたデータブロックのフォーマットが単一のサブブロックを含むとき（図３）の、データフローのアクセス遅延確率の変動の曲線Ｃ４１〜Ｃ４５を示す。それぞれ、１、５、１０、１５、及び２０％のシンボル損失率で、曲線Ｃ４１〜Ｃ４５を得た。曲線Ｃ４１〜Ｃ４５は、アクセス遅延が、（確率１で達する）約１５０ｍｓを超えないことを示す。曲線Ｃ４１によれば、アクセス遅延は、０．６よりわずかに大きい確率で、ゼロである。アクセス遅延は、確率約０．７５で５０ｍｓに達し、確率０．８５超で１５０ｍｓに達する。曲線Ｃ４２によると、データストリームへのアクセス遅延は、確率約０．１２未満で、１５０ｍｓ未満である。曲線Ｃ４３〜Ｃ４５によれば、アクセス遅延は、０に近い確率で、１５０ｍｓ未満である。
【００５８】
図２０は、送信されたデータブロックのフォーマットが、データブロックの終わりに分類されたリペアシンボルと同じ数のサブブロックを含むとき（図１２）の、アクセス遅延確率の変動の曲線Ｃ５１〜Ｃ５５を示す。それぞれ、１、５、１０、１５、及び２０％のシンボル損失率で、曲線Ｃ５１〜Ｃ５５を得た。曲線Ｃ５１〜Ｃ５５によると、アクセス遅延は、確率０．７５超で、約５０ｍｓ未満である。曲線Ｃ５１によれば、０．６に近い確率で、アクセス遅延はゼロである。曲線Ｃ５１、Ｃ５２によれば、５０ｍｓのアクセス遅延は、１に近い確率で達する。曲線Ｃ５３によると、約１００ｍｓのアクセス遅延で、確率１に達する。曲線Ｃ５４及びＣ５５によると、約１５０ｍｓのアクセス遅延で確率１に達する。曲線Ｃ５４によれば、アクセス遅延は、確率０．９超で、５０〜１５０ｍｓの間である。曲線Ｃ５５によると、アクセス遅延は、確率０．７５超で、５０〜１５０ｍｓの間である。そのため、図９又は図１０のフォーマットは、図３のフォーマットよりもアクセスの待ち時間の観点から、より良い性能を有する。
【００５９】
図２１は、送信されたデータブロックのフォーマットが、データブロックの終わりに、２又は３個のリペアシンボルを含むとき（図９又は図１０）のアクセス遅延確率の変動の曲線Ｃ６１〜Ｃ６５を示す。それぞれ、１、５、１０、１５、及び２０％のシンボル損失率で、曲線Ｃ６１〜Ｃ６５を得た。曲線Ｃ６１〜Ｃ６５によると、確率０．９超で、アクセス遅延は、約５０ｍｓ未満である。曲線Ｃ６１によれば、０．６に近い確率で、アクセス遅延は、ゼロである。曲線Ｃ６１、Ｃ６２、Ｃ６３によれば、５０ｍｓのアクセス遅延は、１に近い確率で達する。曲線Ｃ６４によると、確率１は、約１３０ｍｓのアクセス遅延で達する。曲線Ｃ６５によれば、アクセス遅延は、確率０．９５超で、約１５０ｍｓに増加する。そのため、図９又は図１０のフォーマットは、図１１又は図１２のフォーマットよりも、アクセスの待ち時間の観点からより良い性能を有する。
【００６０】
図２２は、送信されたデータブロックのフォーマットが、リペアシンボルと同じ数のサブブロックを含むとき（図７）のアクセス遅延確率の変動の曲線Ｃ７１〜Ｃ７５を示す。それぞれ、１、５、１０、１５、及び２０％のシンボル損失率で、曲線Ｃ７１〜Ｃ７５を得た。曲線Ｃ７１〜Ｃ７５によると、アクセス遅延は、確率０．９５超で、約５０ｍｓ未満である。曲線Ｃ７１によれば、０．６に近い確率で、アクセス遅延は、ゼロである。曲線Ｃ７１、Ｃ７２によれば、５０ｍｓのアクセス遅延は、１に近い確率で、達する。曲線Ｃ７３によると、確率１は、約７０ｍｓのアクセス遅延で達する。曲線Ｃ７４、Ｃ７５によると、確率１は、約１５０ｍｓのアクセス遅延で達する。曲線Ｃ７４によれば、アクセス遅延は、確率０．９超で、５０〜１５０ｍｓの間である。曲線Ｃ７５によれば、アクセス時間は、確率０．８超で、５０〜１５０ｍｓのアクセス時間である。そのため、図７のフォーマットは、図９又は図１０のフォーマットよりもアクセスの待ち時間の観点からより良い性能を有する。
【００６１】
図１９〜図２２の曲線によると、データストリームへのアクセス遅延ＪＴは、データがデータブロックへ編成されるとき、約１５０ｍｓよりも小さい値に制限される。
【００６２】
図２３は、送信されたデータブロックのフォーマットが図５のものの形態で、５０個のソースシンボルのウィンドウｗを有するときのアクセスの待ち時間確率の変動の曲線Ｃ８１〜Ｃ８４を示す。それぞれ、１、５、１０、及び１５％のシンボル損失率で、曲線Ｃ８１〜Ｃ８４を得た。２０％の以上のシンボル損失率では、データストリームへのアクセス遅延は、無限となる。曲線Ｃ８１によれば、アクセス遅延は、０．６に近い確率で、ゼロであり、確率１で、５０ｍよりわずかに大きい。曲線Ｃ８２は、約８０ｍｓのアクセス遅延で、１に近い確率に達する。曲線Ｃ８３によると、１に近い確率は、約１５０ｍｓのアクセス遅延で達する。曲線Ｃ８４によれば、１に近い確率は、約５００ｍｓのアクセス遅延で達する。そのため、図５のフォーマットは、研究された他のフォーマットよりもアクセスの待ち時間の観点からより劣った性能を達成する。
【００６３】
一実施形態によれば、送信機デバイスＴＤＶを含む又は送信機デバイスＴＤＶに連結されるコンテンツサーバーは、受信機デバイスＲＤＶを含む、モバイル端末などの端末群に、マルチブロードキャスト（マルチキャスト）コンテンツを配信する。従って、図２４は、マルチメディアブロードキャストマルチキャストサービス（Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ、ＭＢＭＳ）又はｅＭＢＭＳサービス（ｅｎｈａｎｃｅｄ  ＭＢＭＳ）を実装するサーバーＭＢＭＳを介して、インターネットネットワークなどのネットワークＩＰＮに接続されるコンテンツサーバーＣＮＴＰなどの例を表す。端末ＵＥは、ゲートウェイＭＧＷを介してネットワークＩＰＮに接続されるモバイルネットワークＵＴＲＮに各々接続される。サーバーＣＮＴＰにより提供されるコンテンツは、以上に記載されるフォーマットのうちの１つに従い配信される。受信状態が劣っている端末ＵＥのうちいくつかは、リターン回線で、受信状態が劣っていることをシグナリングするメッセージをコンテンツサーバーＣＮＴＰに送り得る。従って、リターンメッセージは、パケット損失率、リペアシンボル使用後の残りの損失率、及び受信信号の質に関する他の特徴を知らせ得る。
【００６４】
対して、コンテンツサーバーＣＮＴＰは、受信状態が劣っていることを報告した端末に、ユニキャスト回線で、一時期、コンテンツサーバーＣＮＴＰの送信機デバイスＴＤＶにより送られたデータブロック毎に、１つ又は複数の追加のリペアシンボルを送る。こうして、コンテンツサーバーＣＮＴＰは、数万の端末ＵＥにマルチキャストコンテンツを送信することができ、ポイントツーポイントモードで、受信の質が悪い状態を報告する数百の端末ＵＥに追加のリペアシンボルを送信することができる。これらの提供により、リペアシンボルのみがポイントツーポイント回線により送信されるため、これら回線で大きな帯域幅を使用することなく、受信の質を保証しつつ、マルチキャストコンテンツサービスを提供することが可能となる。
【００６５】
良好な受信状態を知らせる返信メッセージを端末によりサーバーへ送付することで、この端末のための追加のリペアシンボルを送付することが終了し得る。この配信コンテンツの送信の終わりに停止しているこの送付に加え、ある期間の終わりでも終了し得る。そこで、端末は、ポイントツーポイント送信モードでの追加のリペアシンボルの送信を再度誘発するため、受信状態が劣っていることをシグナリングする新たなリターンメッセージを送信する可能性を常に有する。
【００６６】
なお、良好又は粗悪な受信状態のシグナリングメッセージの処理及び追加のリペアシンボルの送信は、端末ＵＥへのコンテンツの配信を確保して、コンテンツサーバーＣＮＴＰ以外のサーバー、例えば、ＭＢＭＳサーバーなどのサーバーにより行われる。さらに、マルチキャストサービスは、図２４によって例示されるもの以外の手段及びプロトコルで実装することができる。例えば、マルチキャストサービスは、Ｗｉ−Ｆｉネットワークで実装することができる。
【００６７】
当業者であれば、本発明が様々な代替実施形態及び様々な用途を対象とし得ることは明らかであろう。特に、本発明は、２個（又はそれ以上）のリペアシンボルを、各サブブロックに割り当てるために提供することができる。しかし、本解決策は、データのブロック毎のサブブロックの数を二倍にし、各サブブロックに単一のリペアシンボルを割り当てる解決策と比較して、訂正待ち時間の観点から準最適なものとみなされ得る。
【００６８】
一方、リペアシンボル各々の計算元となるソースシンボルは、データブロックにおいて、必ずしも連続するものではなく、リペアシンボルの直前に送信されたソースシンボルを必ずしも含まない。
【図１】
2020503742.tif 000007
【図２】
2020503742.tif 000008
【図３】
2020503742.tif 000009
【図４】
2020503742.tif 000010
【図５】
2020503742.tif 000011
【図６】
2020503742.tif 000012
【図７】
2020503742.tif 000013
【図８】
2020503742.tif 000014
【図９】
2020503742.tif 000015
【図１０】
2020503742.tif 000016
【図１１】
2020503742.tif 000017
【図１２】
2020503742.tif 000018
【図１３】
2020503742.tif 000019
【図１４】
2020503742.tif 000020
【図１５】
2020503742.tif 000021
【図１６】
2020503742.tif 000022
【図１７】
2020503742.tif 000023
【図１８】
2020503742.tif 000024
【図１９】
2020503742.tif 000025
【図２０】
2020503742.tif 000026
【図２１】
2020503742.tif 000027
【図２２】
2020503742.tif 000028
【図２３】
2020503742.tif 000029
【図２４】
2020503742.tif 000030
【国際調査報告】
2020503742.tif 000031
2020503742.tif 000032
2020503742.tif 000033
2020503742.tif 000034
2020503742.tif 000035
2020503742.tif 000036
2020503742.tif 000037
2020503742.tif 000038
2020503742.tif 000039
2020503742.tif 000040