(57)【要約】【課題】ＦＥＣ演算処理に起因して演算量が突発的に増大するのを防ぐ。【解決手段】本発明の一態様としての通信方法は、ネットワークからのメディアパケットの受信を試み、受信されたメディアパケットを第１のバッファリング手段に格納し、損失したメディアパケットを回復するための冗長データと、前記冗長データに関連する複数のメディアパケットを特定する情報とを含むＦＥＣパケットを受信し、受信されたＦＥＣパケットを第２のバッファリング手段に格納し、前記第２のバッファリング手段からＦＥＣパケットを選択し、選択された前記ＦＥＣパケットに含まれる冗長データと、前記第１のバッファリング手段において該冗長データに関連するメディアパケットとを用いて行うべきＦＥＣ演算処理を複数に分割した各分割演算処理を、前記メディアパケットの受信が試みられるごとに１つずつ順番に行う。【選択図】図１
2008131153.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークからのメディアパケットの受信を試みる第１の受信手段と、
前記第１の受信手段により受信されたメディアパケットを格納する第１のバッファリング手段と、
損失したメディアパケットを回復するための冗長データと、前記冗長データに関連する複数のメディアパケットを特定する情報とを含むＦＥＣ(Forward Error Correction)パケットを受信する第２の受信手段と、
前記第２の受信手段により受信されたＦＥＣパケットを格納する第２のバッファリング手段と、
前記第２のバッファリング手段からＦＥＣパケットを選択する選択手段と、
選択された前記ＦＥＣパケットに含まれる冗長データと、前記第１のバッファリング手段における該冗長データに関連するメディアパケットとを用いて行うべきＦＥＣ演算処理を複数に分割した各分割演算処理を、前記第１の受信手段によりメディアパケットの受信が試みられるごとに１つずつ順番に行うＦＥＣ演算処理手段と、
前記ＦＥＣ演算処理により回復されたメディアパケットを前記第１のバッファリング手段に挿入するメディアパケット挿入手段と、
前記第１のバッファリング手段内のメディアパケットをあらかじめ指定されたアプリケーションに順次配送するメディアパケット配送手段と、
を備えた通信装置。
【請求項２】
前記メディアパケットおよび前記ＦＥＣパケットは、ＲＴＰ（Real-time Transport Protocol）プロトコルに従ったパケットであることを特徴とする請求項１に記載の通信装置。
【請求項３】
前記ＦＥＣ演算処理手段は、前記冗長データに関連づけられたメディアパケットが前記アプリケーションに配送されたら、該冗長データを含むＦＥＣパケットを前記第２のバッファリング手段から消去することを特徴とする請求項１または２に記載の通信装置。
【請求項４】
前記ＦＥＣ演算処理は、前記冗長データ、前記冗長データに関連するメディアパケット間での排他的論理和（ＸＯＲ）演算処理であることを特徴とする１ないし３のいずれか一項に記載の通信装置。
【請求項５】
前記メディアパケット配送手段は、前記メディアパケットが前記第１のバッファリング手段へ格納されてから所定時間が経過したら、前記メディアパケットを前記アプリケーションに配送することを特徴とする請求項１ないし４のいずれか一項に記載の通信装置。
【請求項６】
前記メディアパケット配送手段は、
前記ＦＥＣパケットと、前記ＦＥＣパケットに関連するメディアパケットのうち、最初に受信されたパケットの受信時刻と、最後に受信されたパケットの受信時刻との差を遅延時間として計算し、
あらかじめ取得した前記メディアパケットの受信間隔と、前記ＦＥＣ演算処理の分割回数とを乗算することにより前記ＦＥＣ演算処理に要する時間としてのＦＥＣ演算時間を計算し、
計算した前記遅延時間と、計算した前記ＦＥＣ演算時間とを合計することにより前記所定時間を得ることを特徴とする請求項５に記載の通信装置。
【請求項７】
前記メディアパケットの受信間隔を計測するメディアパケット間隔計測手段をさらに備え、
前記メディアパケット配送手段は、前記メディアパケット間隔計測手段により計測されたメディアパケットの受信間隔の平均を、前記あらかじめ取得したメディアパケットの受信間隔として用いる、
ことを特徴とする請求項６に記載の通信装置。
【請求項８】
ネットワークからのメディアパケットの受信を試み、
受信されたメディアパケットを第１のバッファリング手段に格納し、
損失したメディアパケットを回復するための冗長データと、前記冗長データに関連する複数のメディアパケットを特定する情報とを含むＦＥＣ(Forward Error Correction)パケットを受信し、
受信されたＦＥＣパケットを第２のバッファリング手段に格納し、
前記第２のバッファリング手段からＦＥＣパケットを選択し、
選択された前記ＦＥＣパケットに含まれる冗長データと、前記第１のバッファリング手段において該冗長データに関連するメディアパケットとを用いて行うべきＦＥＣ演算処理を複数に分割した各分割演算処理を、前記メディアパケットの受信が試みられるごとに１つずつ順番に行い、
前記ＦＥＣ演算処理により回復されたメディアパケットを前記第１のバッファリング手段に挿入し、
前記第１のバッファリング手段内のメディアパケットをあらかじめ指定されたアプリケーションに順次配送する、通信方法。
【請求項９】
ネットワークからのメディアパケットの受信を試みるステップと、
受信されたメディアパケットを第１のバッファリング手段に格納するステップと、
損失したメディアパケットを回復するための冗長データと、前記冗長データに関連する複数のメディアパケットを特定する情報とを含むＦＥＣ(Forward Error Correction)パケットを受信するステップと、
受信されたＦＥＣパケットを第２のバッファリング手段に格納するステップと、
前記第２のバッファリング手段からＦＥＣパケットを選択するステップと、
選択された前記ＦＥＣパケットに含まれる冗長データと、前記第１のバッファリング手段において該冗長データに関連するメディアパケットとを用いて行うべきＦＥＣ演算処理を複数に分割した各分割演算処理を、前記メディアパケットの受信が試みられるごとに１つずつ順番に行うステップと、
前記ＦＥＣ演算処理により回復されたメディアパケットを前記第１のバッファリング手段に挿入するステップと、
前記第１のバッファリング手段内のメディアパケットをあらかじめ指定されたアプリケーションに順次配送するステップと、
をコンピュータに実行させるための通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信方法および通信プログラムに関する。
【背景技術】
【０００２】
ＲＴＰ（Real-time Transport Protocol）は、受信順序、受信タイミングなど、ＵＤＰ（User Datagram Protocol）単独では伝達されないリアルタイム・ストリーミング伝送に必要な付加情報を、伝送データパケット毎に併記することが可能な伝送プロトコルであり、受信時は付加情報に基づき受信処理を実行し、必要なデータを必要なタイミングで、送信時と同一の状態で受信可能とする伝送プロトコルである。受信側ではＲＴＰにより、インターネット上で発生するパケット間の順序違いや伝送間隔の揺らぎを修正し、極度に遅延したパケットの破棄や損失パケットの検出が可能となる。
【０００３】
一方、ＲＴＰはインターネットを構成する伝送プロトコルであるＩＰ（Internet Protocol）のベストエフォートという特性をそのまま引き継ぐ上位プロトコルであるＵＤＰを基盤とする伝送プロトコルであり、ＲＴＰ単独では伝送データの損失に関する対策がないため、独自にデータ損失を補完する必要があり、このための技術として再送制御や誤り訂正が存在する。
【０００４】
誤り訂正の具体的な手法としてＦＥＣ（Forward Error Correction：前方向誤り訂正）などが一般的に知られている。
【０００５】
ＦＥＣでは、送信側では、元データをグループ化した上で予め決められた手法で演算することにより各グループに対する冗長データを生成し、各グループのデータと並列に伝送する。受信側では、各グループ内で一部のデータが欠損した場合に、受信した残りのデータと冗長データから予め決められた手法で演算することにより、欠損したデータを回復することが可能となる。
【０００６】
そして、ＲＴＰに適用するＦＥＣ方式としてＲＦＣ２７３３で規定された方式がある。
【０００７】
従来のＲＦＣ２７３３に基づくＲＴＰに対するＦＥＣは、そもそも品質が良いとされるネットワークにおけるごく希なパケット損失を対象として設計されたものであり、連続するバースト損失に対する耐性が弱いという問題が知られている。これは達成できる回復性能が、連続する２４個のパケット内での演算で可能なものに制限されるためであり、演算手法として排他的論理和を採用するならばこのうち高々１つの欠損までに限られ、さらにこれ以上の回復性能を実現するためには冗長度が高くなるために帯域の使用率が増大する結果となり現実的ではない。このため、従来のＦＥＣ方式は、離散的な損失のみであれば有効であるが、インターネット上で多いと知られるバースト損失には全く効果がない。これに対し、ＦＥＣで対応できないバースト損失には、極端に冗長度を上げるよりもＡＲＱ（Automatic Repeat reQuest）などの方式を用いた再送による対処が必要であるとされている。ただし、ＡＲＱには、利用する通信帯域が安定しない、遅延が必要以上に増大する等の問題があり、リアルタイム・ストリーミング伝送における副作用が大きい。
【０００８】
だが、リアルタイム・ストリーミング伝送が高ビットレートとなる場合、このことはある単位時間内に伝送されるパケット数が増大するということであり、障害が発生する時間が同一であれば、その単位時間内で影響をうけるパケット数は、低ビットレートの場合に高々１つであったとしても、高ビットレートの場合は複数以上に渡る結果となるため、結果としてバースト損失が多くなりうる。ゆえにある程度の高品質なネットワーク上においてもこれまでは離散的であった損失がバースト損失となる傾向にあり、このような場合にもＦＥＣを適用可能とするため、ＦＥＣで対応できるバースト数を増大するための手法が提案されてきた。
【０００９】
この１つの手法として、Ｐｒｏ−ＭＰＥＧ(Moving Picture Experts Group)方式でも採用されるマトリクス形成を伴うＦＥＣ方式がある。これは、ＦＥＣのグループを形成する際に演算対象とする複数のパケットを正方形状に整列させ、横列と縦列とでグループ化する方式である。横列はパケットの順序通りに並べられるため、その順序に直交する縦列は離散的に選択されたものと同等となり、横列でバースト的に欠損した場合も各パケットの所属する演算グループが異なるために各縦列で演算すれば良く、単一の横列のみが欠損した場合には、縦列で見れば離散的な欠損として処理することが可能となる。このようにマトリクス形成により、バースト損失に効果的とされるパケットの並び替え（インターリービング）を単純かつ効率的かつ暗黙に実現でき、マトリクスの縦横の長さを変更することでＦＥＣの誤り耐性を柔軟に変更できる。
【００１０】
また、縦列グループに対する演算のみで回復出来ない場合は、横列グループに対する演算での回復と組み合わせ、縦列および横列での演算を繰り返すことにより、より多くの損失に対処することが可能となる。
【００１１】
このようにマトリクス形成により、従来のＦＥＣ方式で弱点とされるバースト損失に対する耐性を補強することが可能となった。
【非特許文献１】Ｊ．Ｒｏｓｅｎｂｅｒｇほか１名，“ＲＦＣ２７３３  Ａｎ  ＲＴＰ Ｐａｙｌｏａｄ  Ｆｏｒｍａｔ  ｆｏｒ  Ｇｅｎｅｒｉｃ  Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ”  ＩＥＴＦ，  Ｄｅｃｅｍｂｅｒ  １９９９
【非特許文献２】“Ｐｒｏ−ＭＰＥＧ  Ｃｏｄｅ  ｏｆ  Ｐｒａｃｔｉｃｅ  ＃３  ｒｅｌｅａｓｅ  ２”，  Ｐｒｏ−ＭＰＥＧ  Ｆｏｒｕｍ，  Ｊｕｌｙ  ２００４
【発明の開示】
【発明が解決しようとする課題】
【００１２】
しかしながら、ＲＴＰのＦＥＣ方式ではパケット損失を検出した際に回復処理を開始すればよいとしているため、マトリクス形成を伴うＦＥＣ方式においては、バースト損失が発生した場合、回復演算が発生した時点で、一時的に演算処理が突出して増大する問題があった。
【００１３】
すなわち、あるマトリクスで横列のパケットが全てバースト損失した場合、縦列と横列のパケット数を乗じた数、すなわちマトリクスサイズ分のパケットが演算対象パケット数となる。ある横列のパケットが全てバースト損失すると、縦列のパケット数から当該縦列の欠損パケット数（ここでは１つ）を除いた値に冗長パケット数（ここでは１つ）を加えた数に横列数を乗じた回数の演算が発生することとなり、この演算を本来の伝送タイミングを乱すことなく実行するために、欠損検出後の極めて短い時間で集中的に回復処理を行う必要が生じる。
【００１４】
そもそも、パケット欠損の発生が、伝送中のエラーに限らず、受信側の処理における取りこぼしの場合もあるため、このように処理を一時的に突発させることは受信側での他の処理（特に後段の処理）に対する影響が大きくなり望ましくない。特に、近年になり機器の性能が向上したことで実現が可能となったハイビジョンクラスのメディアストリーミング伝送では、これまでのリアルタイム・ストリーミングとは桁違いのビットレートでの伝送が行われるため、パケット毎の受信を処理する間の空き時間は微少となる。したがって取りこぼしを生じさせないためには、この空き時間の間に処理を完了させる必要があり、処理量を極端に突出させなければならず、システム全体の構成に与える影響が甚大である。すなわち、高ビットレートなストリーミング伝送を行う際には、受信側の他の処理に対して乱れを生じさせるなどの影響が少ない回復演算方法が必要である。
【００１５】
本発明は、回復処理（ＦＥＣ演算処理）に起因して受信側の演算量が突発的に増大するのを防ぐようにした通信装置、通信方法および通信プログラムを提供する。
【課題を解決するための手段】
【００１６】
本発明の一態様としての通信装置は、
ネットワークからのメディアパケットの受信を試みる第１の受信手段と、
前記第１の受信手段により受信されたメディアパケットを格納する第１のバッファリング手段と、
損失したメディアパケットを回復するための冗長データと、前記冗長データに関連する複数のメディアパケットを特定する情報とを含むＦＥＣ(Forward Error Correction)パケットを受信する第２の受信手段と、
前記第２の受信手段により受信されたＦＥＣパケットを格納する第２のバッファリング手段と、
前記第２のバッファリング手段からＦＥＣパケットを選択する選択手段と、
選択された前記ＦＥＣパケットに含まれる冗長データと、前記第１のバッファリング手段における該冗長データに関連するメディアパケットとを用いて行うべきＦＥＣ演算処理を複数に分割した各分割演算処理を、前記第１の受信手段によりメディアパケットの受信が試みられるごとに１つずつ順番に行うＦＥＣ演算処理手段と、
前記ＦＥＣ演算処理により回復されたメディアパケットを前記第１のバッファリング手段に挿入するメディアパケット挿入手段と、
前記第１のバッファリング手段内のメディアパケットをあらかじめ指定されたアプリケーションに順次配送するメディアパケット配送手段と、
を備える。
【００１７】
本発明の一態様としての通信方法は、
ネットワークからのメディアパケットの受信を試み、
受信されたメディアパケットを第１のバッファリング手段に格納し、
損失したメディアパケットを回復するための冗長データと、前記冗長データに関連する複数のメディアパケットを特定する情報とを含むＦＥＣ(Forward Error Correction)パケットを受信し、
受信されたＦＥＣパケットを第２のバッファリング手段に格納し、
前記第２のバッファリング手段からＦＥＣパケットを選択し、
選択された前記ＦＥＣパケットに含まれる冗長データと、前記第１のバッファリング手段において該冗長データに関連するメディアパケットとを用いて行うべきＦＥＣ演算処理を複数に分割した各分割演算処理を、前記メディアパケットの受信が試みられるごとに１つずつ順番に行い、
前記ＦＥＣ演算処理により回復されたメディアパケットを前記第１のバッファリング手段に挿入し、
前記第１のバッファリング手段内のメディアパケットをあらかじめ指定されたアプリケーションに順次配送する。
【００１８】
本発明の一態様としての通信装置プログラムは、
ネットワークからのメディアパケットの受信を試みるステップと、
受信されたメディアパケットを第１のバッファリング手段に格納するステップと、
損失したメディアパケットを回復するための冗長データと、前記冗長データに関連する複数のメディアパケットを特定する情報とを含むＦＥＣ(Forward Error Correction)パケットを受信するステップと、
受信されたＦＥＣパケットを第２のバッファリング手段に格納するステップと、
前記第２のバッファリング手段からＦＥＣパケットを選択するステップと、
選択された前記ＦＥＣパケットに含まれる冗長データと、前記第１のバッファリング手段において該冗長データに関連するメディアパケットとを用いて行うべきＦＥＣ演算処理を複数に分割した各分割演算処理を、前記メディアパケットの受信が試みられるごとに１つずつ順番に行うステップと、
前記ＦＥＣ演算処理により回復されたメディアパケットを前記第１のバッファリング手段に挿入するステップと、
前記第１のバッファリング手段内のメディアパケットをあらかじめ指定されたアプリケーションに順次配送するステップと、
をコンピュータに実行させる。
【発明の効果】
【００１９】
本発明により、ＦＥＣ演算処理に起因して演算量が突発的に増大するのを防ぐことができる。
【発明を実施するための最良の形態】
【００２０】
図１は、本発明の第１の実施形態に係わるＦＥＣ（Forward Error Correction：前方向誤り訂正）受信処理装置（通信装置）の構成を示すブロック図である。  
ＦＥＣ受信処理装置１１はネットワーク１２を介してＦＥＣ送信装置１３と通信可能に構成される。ＦＥＣ送信装置１３は、受信側で再生すべきメディアデータおよび順序番号等を含むメディアパケット、および、ネットワーク１２上等で損失したメディアパケットを回復するための冗長データ等を含むＦＥＣパケットを生成し、ネットワーク１２を介してＦＥＣ受信処理装置１１に送信する。メディアパケットおよびＦＥＣパケットは例えばＲＴＰ（Real-time Transport Protocol）に従ったパケットであり、本実施形態ではＲＴＰに従っているとする。ＦＥＣ送信装置１３によりＦＥＣパケットを生成する様子を図３に示す。また、ＦＥＣ送信装置１３により生成されたメディアパケットおよびＦＥＣパケットを送信する様子を図４に示す。
【００２１】
図３に示すようにＦＥＣ送信装置１３は、複数のメディアパケット（本例では１００個のメディアパケット１、２、３、・・・１００とする。ただし本発明は当然ながらこれに限定されない）を正方形状に整列させてマトリクスを形成し、１０行の横列グループと、１０列の縦列グループとを形成する。ＦＥＣ送信装置１３は、縦列グループごとにメディアパケット群を演算（本例ではＸＯＲとする）して冗長データを計算し、計算した冗長データを用いて各縦列グループからＦＥＣパケットＦ１、Ｆ２、Ｆ３・・・Ｆ１０を得る。ＦＥＣパケットには冗長データの他、該冗長データ（ＦＥＣパケット）に関連づけられるメディアパケットを示す情報、およびメディアパケットとは異なる系列の順序番号が含まれる。冗長データ（ＦＥＣパケット）に関連づけられるメディアパケットとは、冗長データを生成する元となったメディアパケットのことであり、例えばＦＥＣパケットＦ１の冗長データに関連づけられるメディアパケットは、メディアパケット１、１１、２１、３１、・・・、８１、９１である。本実施形態では縦列グループからのみＦＥＣパケットを生成することとするが、縦列グループに加え、横列グループからもＦＥＣパケットを生成することも可能である。
【００２２】
ＦＥＣ送信装置１３は、各縦列グループからＦＥＣパケットを生成したら、図４に示すように、同一のマトリクス（第１のマトリクスとする）に属するメディアパケット１、２、３、４、・・・９９、１００を順次、一定のペース（第１のペース）で送信するとともに、各ＦＥＣパケットＦ１、Ｆ２、Ｆ３、・・・Ｆ１０をメディアパケットの送信と並行して一定のペース（第２のペース）で送信する。本実施形態では第２のマトリクスのメディアパケットの送信と並行して第１のマトリクスから得られた各ＦＥＣパケットを送信している。ＦＥＣ送信装置１３は、第１のマトリクスに属するメディアパケットの送信が終了したら、第２のマトリクスに属するメディアパケットを順次第１のペースで送信するとともに、第２のマトリクスから得られた各ＦＥＣパケットをメディアパケットの送信と並行して送信する。本実施形態では第３のマトリクスのメディアパケットの送信と並行して第２のマトリクスから得られた各ＦＥＣパケットを送信している。第１のマトリクスの最後のメディアパケットと、第２のマトリクスの最初のメディアパケットとの間のペースは上記第１のペースを維持しているとする。
【００２３】
ネットワーク１２上でバーストロスが発生し、例えば図３に示すようにメディアパケット５１〜６０が損失した場合、受信側（ＦＥＣ受信処理装置１１）において以下のようにして損失パケットが回復される。すなわちＦＥＣパケットＦ１の冗長データと、メディアパケット１、１１、２１、３１、４１、６１、７１、８１、９１のデータをＸＯＲすることによりメディアパケット５１が回復され、他のメディアパケット５２〜６０も同様にして回復される。
【００２４】
ＦＥＣ受信処理装置１１におけるメディアパケット受信手段２１は、ネットワーク１２を介してＦＥＣ送信装置１３からメディアパケットを受信し、受信したメディアパケットが不正なパケットでなければメディアパケットバッファリング手段２３に渡す。より詳細には、ネットワーク１２から到来するメディアパケットは、例えばＯＳ（Operating System）が管理するプールにいったん格納され、メディアパケット受信手段２１はこのプールに対してメディアパケットの受信を試みる（受信動作を行う）。メディアパケットがプールに入っていれば、メディアパケット受信手段２１は、プールからメディアパケットを受け取り、受け取ったメディアパケットをメディアパケットバッファリング手段２３に渡す。プール内にメディアパケットが存在しなければ（空振りすれば）再度、適当な時間をおいて、プールに対して受信動作を行う。メディアパケットバッファリング手段２３は、メディアパケット受信手段２１から渡されたメディアパケットを内部のバッファに格納する。メディアバッファリング手段２３は、メディアパケットをバッファに格納する際、該メディアパケットの格納時刻Ｔｉｎを記録する。
【００２５】
ここで不正なメディアパケットの例としては、直前に受信したメディアパケットの順序番号と同じ番号をもつメディアパケット（重複パケット）、打刻されたタイムスタンプが期待値より以前の値をもつメディアパケット（既に再生タイミングを過ぎてしまっているため、受信しても意味がないメディアパケット）がある。また、現在のストリームのソース識別子と異なるソース識別子をもつメディアパケット、復号や認証に失敗したメディアパケットなどもあり、これらは現在のストリームと無関連として扱うべきメディアパケットである。
【００２６】
このようにメディアパケット受信手段２１は、不正でないメディアパケットを受信する毎に、受信したメディアパケットをメディアパケットバッファリング手段２３に渡し、メディアパケットバッファリング手段２３は、渡されたメディアパケットをバッファに格納する。これによりメディアパケットバッファリング手段２３にメディアパケットが逐次格納されていく。メディアパケットバッファリング手段２３は、バッファ内の各メディアパケットを順序番号の小さい順に並べている。
【００２７】
一方、ＦＥＣ受信処理装置１１におけるＦＥＣパケット受信手段２２は、ネットワーク１２を介してＦＥＣ送信装置１３からＦＥＣパケットを受信し、受信したＦＥＣパケットが不正なパケットでなければこれをＦＥＣパケットバッファリング手段２４に渡す。ＦＥＣパケットバッファリング手段２４は、受け取ったＦＥＣパケットを内部のバッファに格納する。ＦＥＣパケットバッファリング手段２４はＦＥＣパケットの順序番号にしたがってＦＥＣパケットを並べている。
【００２８】
対応関係検出手段２６は、ＦＥＣパケットのヘッダ情報（ＦＥＣパケットに関連づけられるメディアパケットを示す情報）からＦＥＣパケットに関連づけられたメディアパケット群を検出する（ＦＥＣの回復単位を判明させる）。検出は、ＦＥＣパケットをバッファに格納する際に行ってもよいし、ＦＥＣ演算処理手段２７により誤り訂正処理（ＦＥＣ演算処理）を行う際に行ってもよい。
【００２９】
ＦＥＣ演算処理手段２７は、ＦＥＣパケットバッファリング手段２４にＦＥＣパケットが存在する場合、ＦＥＣパケットバッファリング手段２４からＦＥＣパケットを読み出し、読み出したＦＥＣパケットと、このＦＥＣパケットに関連づけられるメディアパケットバッファリング手段２３内のメディアパケットとを用いて誤り訂正処理（ＦＥＣ演算処理）を行う。上述のようにＦＥＣパケットバッファリング手段２４内でＦＥＣパケットは順序番号にしたがって（例えば小さい順）に並べられており、順序番号にしたがってＦＥＣパケットが読み出される。ＦＥＣ演算処理手段２７は、順序番号にしたがってＦＥＣパケットを選択する選択手段を備えている。
【００３０】
ここで、本実施形態では、ＦＥＣ演算処理は一度に行うのではなく、ＦＥＣ演算処理を複数に分割した各分割演算処理を、メディアパケット受信手段２１による受信動作が行われるたびに１つずつ順番に行い、分割回数分の受信動作を行うことで、ＦＥＣ演算処理を完了させることを特徴とし、さらにメディアパケットの損失の有無および損失の個数に拘わらず当該ＦＥＣ演算処理を行うことを特徴とする。以下、ＦＥＣパケットＦ１と、メディアパケット１、１１、２１、３１、４１、５１、６１、７１、８１、９１とが関連づけられている場合を例に本実施形態におけるＦＥＣ演算処理を説明する。ただしメディアパケット５１はネットワーク１２上で損失したとする。
【００３１】
まずメディアパケット受信手段２１による前述のＯＳのプールに対する受信動作が行われると、メディアパケットが受信されたか否かに関係なく、ＦＥＣ演算処理手段２７は、ＦＥＣパケットＦ１の冗長データとメディアパケット１とのＸＯＲを計算して、（１つ目の分割演算処理を行って）第１の演算結果を得る。次に、またメディアパケット受信手段２１によるプールに対する受信動作が行われると、ＦＥＣ演算処理手段２７は、第１の演算結果とメディアパケット１１とのＸＯＲを計算して（２つ目の分割演算処理を行って）、第２の演算結果を得る。次に、またメディアパケット受信手段２１によるプールに対する受信動作が行われると、ＦＥＣ演算処理手段２７は、第２の演算結果とメディアパケット２１とのＸＯＲを計算して（３つ目の分割演算処理を行って）、第３の演算結果を得る。このようにメディアパケット受信手段２１による受信動作が行われるたびに、分割演算処理を行い、計９回の受信動作が行われることで（メディアパケット５１は損失していることに注意する）、ＦＥＣ演算処理は終了し、メディアパケット５１が回復する。仮にメディアパケット５１が損失していなかった場合は、１０回の受信動作によりＦＥＣ演算処理が終了することとなる（この場合演算結果は無視される）。ＦＥＣ演算処理手段２７は、このようなＦＥＣ演算処理を同一マトリクス内の他のＦＥＣパケットＦ２〜Ｆ１０についても行う。
【００３２】
このように、本実施形態では、ＦＥＣ演算処理をメディアパケットの損失の有無および個数に拘わらず行い、かつ、ＦＥＣ演算処理を複数に分割した各分割演算処理を受信動作のタイミングごとに１つずつ行うことにより、最大でマトリクスサイズ分のメディアパケットに対するＦＥＣ演算処理が、マトリクスサイズ分の受信動作タイミングに分散される。すなわち、従来のようにメディアパケットが欠損したことを検知した後に一括してＦＥＣ演算処理を行うのではなく、メディアパケットの欠損の有無に拘わらず全てのメディアパケットについてＦＥＣ演算処理を行い、かつ、このＦＥＣ演算処理を複数回に分散して行う。これによりＦＥＣ演算処理（メディアパケット回復処理）の負荷が突発的に（極度に）突出することを回避でき、ＦＥＣ演算処理に必要な演算量と演算時間（ＦＥＣ演算時間）Ｔｐとをあらかじめ一定に見積もることが可能となる。これについて詳しく説明するならば以下の通りである。
【００３３】
メディア再生の様に周期的な演算が必要とされる場合、周期的な演算の前に行うべき処理が必要な時刻までに完了するように構成されていなければ、周期性が乱される結果となる。周期的な演算の前に行うべき処理の処理量が均一であるとすれば、その処理に要する時間が自明となり、周期性の確保が容易となる。これは、特に組み込み機器などのように、予め予想される処理量に応じた計算能力を持ち、複数の周期的な演算が並行して動作する場合に有効である。特に周期的な演算の前に行うべき処理が、周期的な演算と関連性を持たない場合、当該処理の処理量が一定でないと、周期的な演算を適切なタイミングにスケジューリングすることが難しくなる。このため、周期的な演算の前に行うべき演算量と演算時間が一定であり、故に予め既知となっていることが望ましい。この点、本実施形態では、上述のように、ＦＥＣ演算処理に必要な演算量と演算時間とを一定に見積もることができるため、ＦＥＣ受信処理装置の後段におけるメディア再生等の周期的な演算が乱されるのを防ぐことができる。
【００３４】
ＦＥＣ受信処理装置１１におけるメディアパケット挿入手段２８は、損失パケットが存在しかつその数が１つであるかどうかを検査し、そうである場合は、ＦＥＣ演算処理手段２７による演算結果である、回復されたメディアパケットをメディアパケットバッファリング手段２３内のバッファの該当する位置に挿入する。すなわち、メディアパケット挿入手段２８は、回復されたメディアパケットをメディアパケットバッファリング手段２３に渡し、メディアパケットバッファリング手段２３は、メディアパケット挿入手段２８から受け取ったメディアパケットを、メディアパケットの順序番号に基づき、内部のバッファ内の該当する位置に格納する。この際、メディアパケットバッファリング手段２３は、メディアパケットの格納時刻Ｔｉｎを、「直前の順序番号をもつパケットのＴｉ＋受信間隔」または「直後の順序番号をもつパケットのＴｉ−受信間隔」として記録する。「受信間隔」は、あらかじめ取得または設定されたものを用いてもよいし、後述するようにして計算した受信間隔の平均を用いてもよい。なお、損失したメディアパケットが２つ以上である場合は、メディアパケットを回復できなかったものとして処理を進めるものとする。
【００３５】
ＦＥＣ受信処理装置１１におけるメディアパケット配送手段２９は、メディアパケットバッファリング手段２３内のバッファからメディアパケットを順次取り出し、上位アプリケーションに配送する。より詳細には、メディアパケット配送手段２９は、図示しないタイマーより得られる現在時刻と各メディアパケットの格納時刻Ｔｉとを比較し、現在時刻と格納時刻Ｔｉとの差が、あらかじめ設定されたバッファ時間（所定時間）Ｔｂより大きくなったメディアパケットから上位アプリケーションに配送する。
【００３６】
このバッファ時間Ｔｂは、遅延時間Ｔｓ＋ＦＥＣ演算時間Ｔｐとして表すことができる。ＦＥＣ演算時間Ｔｐは、ＦＥＣ演算処理に要する時間であり、本実施形態では、上述したように、あらかじめ一定に見積もることが可能である。遅延時間Ｔｓは、１つのマトリクスについて最初にメディアパケットが到着（バッファに格納）してから、同一マトリクス内の他の全てのメディアパケットおよび全てのＦＥＣパケットが揃うまでの時間である。すなわち、遅延時間Ｔｓは、最初にメディアパケットがバッファに格納されてから同一マトリクス全体についてＦＥＣ演算処理を開始可能となるまでに要する時間である。ＦＥＣ送信装置１３からメディアパケットおよびＦＥＣパケットを送信するペースは前述したとおり一定であり、このため遅延時間Ｔｓも一定に見積もることが可能である。バッファ時間Ｔｂは、このようにしてあらかじめ見積もられた遅延時間ＴｓとＦＥＣ演算時間Ｔｐとを合計したものに相当し、遅延時間ＴｓもＦＥＣ演算時間Ｔｐも一定に見積もることが可能であるためバッファ時間Ｔｂも一定に見積もることができる。メディアパケット配送手段２９は、メディアパケットの上位アプリケーションに対する配送を、このバッファ時間Ｔｂだけ遅延させてから行う。
【００３７】
ここで、上記説明では、バッファ時間Ｔｂは、あらかじめ設定することとしたが以下のようにしてＦＥＣ演算処理手段２７により計算することも可能である。
【００３８】
あるマトリクスから得られたＦＥＣパケットのうち最後に受信されたＦＥＣパケットの受信時刻をＴ１とし、該マトリクスに属するメディアパケットのうち最も早く到着したメディアパケットの受信時刻をＴ０とし、遅延時間Ｔｓ＝Ｔ１−Ｔ０とする。このＴｓを仕様上ＦＥＣ演算処理が演算開始となるタイミングの最悪値とする。
【００３９】
また、メディアパケットの受信間隔をＴｗとし、１つのマトリクスについてＦＥＣ演算処理を行うために必要な受信動作の最大の回数をＮとし、ＦＥＣ演算時間Ｔｐ＝Ｔｗ×Ｎとする。
【００４０】
Ｎは例えばマトリクスサイズと同数とし、マトリクスサイズはあらかじめ送信側と受信側とにおいて既知であるか、あるいは、ＨＴＴＰサーバからまたはＲＴＳＰのＤＥＳＣＲＩＢＥメソッドにてストリーム情報を取得し、このストリーム情報からマトリクスサイズを得る。
【００４１】
受信間隔Ｔｗは、（１）あらかじめ設定しておいてもよいし、（２）メディアパケットの受信間隔を計測し、計測した受信間隔を平均することにより取得してもよい。
【００４２】
（１）の場合、受信間隔Ｔｗがあらかじめ送信側と受信側とにおいて既知であるか、あるいは、別段の通信手段によりストリーム情報をＨＴＴＰサーバから取得またはＲＴＳＰのＤＥＳＣＲＩＢＥメソッドにて取得し、取得したストリーム情報に基づき、ビットレートをパケット毎のデータ転送バイト数で除することにより、パケットの受信間隔を得る。
【００４３】
（２）の場合、図５に示すように、ＦＥＣ受信処理装置１１に対し、メディアパケットの受信間隔を計測するメディアパケット間隔計測手段２５を追加する。メディアパケット間隔計測手段２５は、メディアパケットが受信される毎に、そのメディアパケットの格納時刻Ｔｉと、１つ前にバッファに格納されたメディアパケットの格納時刻Ｔｉｎとの差分を計測し、この差分を、受信したメディアパケットの順序番号と１つ前にバッファに格納されたメディアパケットの順序番号との差分で除算することにより、メディアパケットの受信間隔を計算し、その平均値を受信間隔Ｔｗとする。
【００４４】
ＦＥＣ演算処理手段２７は、このようにして計算した遅延時間Ｔｓと、ＦＥＣ演算時間Ｔｐとを加算することによりバッファ時間Ｔｂを得ることができる。
【００４５】
図２（Ａ）および図２（Ｂ）はＦＥＣ受信処理装置の動作を説明するためのフローチャートである。特に図２（Ａ）は、メディアパケット受信手段２１、メディアパケットバッファリング手段２３、メディアパケット配送手段２９間の動作関係を示し、図２（Ｂ）は、メディアパケット受信手段２１、ＦＥＣ演算処理手段２７、メディアパケット挿入手段２８間の動作関係を示す。
【００４６】
図２（Ａ）に示すように、メディアパケット受信手段２１は、メディアパケットの受信を試みる受信動作を行い（Ｓ１１）、メディアパケットを受信したら（Ｓ１２のＹＥＳ）、受信したメディアパケットをメディアパケットバッファリング手段２３内のバッファに格納する（Ｓ１３）。メディアパケットをバッファに格納したら、またはＳ１２においてメディアパケットを受信しなかったら（Ｓ１２のＮＯ）、メディアパケット配送手段２９は、現在時刻と格納時刻Ｔｉとの差がバッファ時間Ｔｂを超えているメディアパケットが存在するかどうかを検査し（Ｓ１４）、存在する場合は（Ｓ１４のＹＥＳ）、そのメディアパケットをバッファから取り出して上位アプリケーションに配送する（Ｓ１５）。この後、ユーザから終了指示が入力されたかどうかを検査し（Ｓ１６）、入力された場合は（Ｓ１６のＹＥＳ）処理を終了する。終了指示が入力されない場合（Ｓ１６のＮＯ）、あるいはＳ１４において現在時刻とＴｉとの差がＴｂ以下であるメディアパケットが存在しない場合は（Ｓ１４のＮＯ）、ステップＳ１１に戻り、メディアパケット受信手段２１により受信動作を行う。
【００４７】
図２（Ｂ）に示すように、メディアパケット受信手段２１によりメディアパケットの受信動作が行われると（Ｓ２１）、ＦＥＣ演算処理手段２７は、ＦＥＣ演算処理を複数に分割した各分割演算処理のうちの１つ（まだ処理されていないもの）を行う（Ｓ２２）。ＦＥＣ演算処理手段２７は、各分割演算処理の全てが完了したかどうか、すなわちＦＥＣ演算処理が完了したかどうかを判断し（Ｓ２３）、完了した場合は（Ｓ２３のＹＥＳ）、バッファリングを行うかどうかを判断する（Ｓ２４）。すなわち、損失パケットが存在しかつその数が１つであるかどうかを判断する。もしそうであれば（Ｓ２４のＹＥＳ）、メディアパケット挿入手段２８は、ＦＥＣ演算処理により得られたメディアパケット（回復したメディアパケット）を、メディアパケットバッファリング手段２３内のバッファにおける対応する位置に挿入する（Ｓ２５）。この後、ユーザから終了指示が入力されたかどうかを検査し（Ｓ２６）、入力された場合は（Ｓ２６のＹＥＳ）処理を終了する。終了指示が入力されない場合（Ｓ２６のＮＯ）、Ｓ２３においてＦＥＣ演算処理が完了していないと判断された場合（Ｓ２３のＮＯ）、あるいはＳ２４においてバッファリングしないと判断された場合（Ｓ２４のＮＯ）、ステップＳ２１に戻り、メディアパケット受信手段２１による受信動作を待機する。
【００４８】
以上のように、本実施形態によれば、メディアパケットおよびＦＥＣパケットに対する遅延時間Ｔｓ（１つのマトリクスについて最初にパケットが到着してからＦＥＣ演算処理に必要な全てのパケットが揃うまでの最悪値）を適切に設定するとともに、ＦＥＣ演算時間内でＦＥＣ演算処理を分散させることにより、演算処理量の突発的増大、演算処理の不完全性、無駄な遅延時間を無くし、演算処理量の時間的な平滑化、システム全体負荷の均一化、パケット配送周期の一定性を得ることができる。
【００４９】
なお、図１および図５のＦＥＣ受信処理装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、要素２１〜２９は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、ＦＥＣ受信処理装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。
【００５０】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【００５１】
【図１】本発明の実施形態に係わるＦＥＣ受信処理装置の構成を示すブロック図。
【図２】本発明の第１の実施形態の動作を説明するフローチャート。
【図３】ＦＥＣパケットの生成を説明する図。
【図４】メディアパケットとＦＥＣパケットとの送信を説明する図。
【図５】ＦＥＣ受信処理装置の他の構成例を示すブロック図。
【符号の説明】
【００５２】
１１：ＦＥＣ受信処理装置（通信装置）
１２：ネットワーク
１３：ＦＥＣ送信装置
２１：メディアパケット受信装置
２２：ＦＥＣパケット受信手段
２３：メディアパケットバッファリング手段
２４：ＦＥＣパケットバッファリング手段
２５：メディアパケット間隔計測手段
２６：対応関係検出手段
２７：ＦＥＣ演算処理手段
２８：メディアパケット挿入手段
２９：メディアパケット配送手段
【図１】
2008131153.tif 000003
【図２】
2008131153.tif 000004
【図３】
2008131153.tif 000005
【図４】
2008131153.tif 000006
【図５】
2008131153.tif 000007